Ključni podaci za van Solana koristi peer-to-peer trač protokol temeljen na algoritmu Plumtree, dopuštajući decentraliziranu komunikaciju između čvorova za učinkovito širenje promjena stanja kroz mrežu bez oslanjanja na središnji izvor. Svake 0,1 sekunde Solana čvorovi razmjenjuju "push" i "pull" poruke, osiguravajući kontinuirano i ažurno dijeljenje informacija kako bi se održalo brzo širenje podataka i sinkronizacija diljem mreže. Protokol ogovaranja sastoji se od četiri glavne vrste poruka—Push, Pull, Prune i Ping/Pong—koje pomažu u distribuciji podataka, traženju informacija koje nedostaju, upravljaju vezama čvorova i provjeravaju vitalnost čvora. Podaci o tračevima pohranjuju se u pohranu repliciranih podataka klastera (CrdsTable), koja se kontinuirano ažurira inkrementalnim ažuriranjem stanja mreže, osiguravajući dostupnost podataka i sinkronizaciju među čvorovima. Solanin arhivski sustav koristi "skladišne čvorove" za pohranjivanje povijesti transakcija, s najnovijim podacima (1-2 epohe) koje čuvaju validatori, dok je potpuna povijest transakcija pohranjena u Ledger Archives ili Google Bigtable instancama za jednostavan pristup RPC-ovima i drugim sudionicima. Trač Gossip protokol je peer-to-peer komunikacijska metoda u distribuiranim sustavima, gdje čvorovi u mreži povremeno razmjenjuju informacije o stanju o sebi i drugim čvorovima na koje je svaki čvor povezan na decentraliziran način. To je slično onome kako se glasine šire društvenim mrežama. To implicira da će se svaka neznatna promjena stanja na kraju proširiti kroz mrežu, a svi će čvorovi imati punu informaciju o toj promjeni stanja. Na Solani, njegova implementacija protokola ogovaranja koristi neformalnu komunikacijsku metodu s pristupom emitiranja stabla koji je snažno modeliran prema Plumtree algoritmu. Ovo omogućuje širenje promjena stanja bez oslanjanja na središnji glavni izvor. Djeluje kao upravljačka ploča za Solanu jer pomaže validatorima i RPC čvorovima da znaju koje su adrese i portovi otvoreni za komunikaciju. Solana Gossip radi s drugim glavnim komponentama kao što su validatori, turbinski protokol, arhivski čvorovi, dokaz povijesti, itd. Validatori i RPC-ovi razmjenjuju potpisane objekte podataka svakih 0,1 sekundu preko UDP-a koristeći trač, jamčeći dostupnost informacija u cijeloj mreži. Svaka trač poruka mora biti na ili ispod maksimalne jedinice prijenosa (MTU) od 1280 bajtova, poznate kao "struktura paketa" u bazi koda. Protokol ogovaranja služi kao središnji mehanizam za čvorove za učinkovito upravljanje komunikacijom klastera kontinuiranim dijeljenjem potpisanih podatkovnih objekata, kao što su podaci o kontaktu, visina knjige i glasovi. Svake 0,1 sekunde čvorovi razmjenjuju "push" i "pull" poruke—gdje se push poruke mogu proslijediti i obje vrste mogu pokrenuti odgovore—olakšavajući brzo širenje podataka kroz mrežu. Radeći preko dobro poznatog UDP/IP porta ili raspona portova, trač protokol omogućuje čvorovima da reklamiraju svoje trač krajnje točke (adrese utičnica) jedni drugima nakon što se klaster podigne. Ovaj decentralizirani visokofrekventni komunikacijski grafikon osigurava da Solanini čvorovi ostanu sinkronizirani i otporni, podržavajući skalabilnost i izvedbu blockchaina. U Solaninom protokolu tračanja, četiri vrste poruka olakšavaju klastersku komunikaciju: Push poruke, najčešće, distribuiraju podatke odabranoj skupini "push peer-a". Poruke povlačenja, zajedno s njihovim odgovorima na povlačenje, šalju se povremeno kako bi se dohvatile informacije koje nedostaju traženjem i isporukom nedijeljenih podataka. Poruke skidanja omogućuju čvorovima da prema potrebi skraćuju svoje aktivne veze. Na kraju, Ping i Pong poruke služe kao provjere vitalnosti, gdje ping traži pong odgovor za potvrdu operativnog statusa ravnopravnog čvora. Podaci o tračevima pohranjuju se u skladište repliciranih podataka klastera (CrdsTable). Ova se struktura podataka kontinuirano ažurira porukama protokola tračanja. Ove poruke sadrže zapise o tračevima, koji su u biti inkrementalna ažuriranja CrdsTablea. Arhiva Solana se razlikuje od drugih blockchaina po tome što ne zahtijeva potpunu povijest transakcija za utvrđivanje trenutnog stanja računa. Njegov model računa osigurava da je stanje na bilo kojem mjestu poznato, omogućujući validatorima da pohrane trenutno stanje bez potrebe za obradom svih povijesnih blokova. RPC-ovi i validatori obično ne čuvaju cijelu povijest knjige; umjesto toga, pohranjuju samo 1 ili 2 epohe (2-4 dana) transakcijskih podataka, što je dovoljno za provjeru valjanosti posljednjeg bloka. Arhivskim podacima upravljaju "čvorovi skladišta", koje vode profesionalni pružatelji RPC usluga, Zaklada Solana i drugi sudionici ekosustava kako bi se osigurala dostupnost povijesti transakcija. Ovi skladišni čvorovi često održavaju Ledger Archive, koji pohranjuje neobrađenu knjigu i snimke AccountsDB-a za ponovnu reprodukciju od nule, ili Google Bigtable instancu, koja pohranjuje podatke bloka od bloka geneze nadalje u formatu prikladnom za RPC zahtjeve. Zaključak Zaključno, Solanin protokol ogovaranja i arhivski sustav omogućuju učinkovitu komunikaciju i sinkronizaciju podataka preko mreže. Protokol ogovaranja osigurava brzo širenje stanja, dok sustav arhiviranja pohranjuje povijest transakcija za lak pristup validatorima i RPC-ovima. Zajedno, ove značajke podržavaju Solaninu skalabilnost, performanse i decentralizaciju.
