Kulcs elvitelek

1. A Solana a Plumtree algoritmuson alapuló peer-to-peer pletyka protokollt használ, amely lehetővé teszi a csomópontok közötti decentralizált kommunikációt, hogy hatékonyan terjessze az állapotváltozásokat a hálózaton anélkül, hogy központi forrásra támaszkodna.
2. 0,1 másodpercenként a Solana csomópontok "push" és "pull" üzeneteket cserélnek, biztosítva a folyamatos és naprakész információmegosztást a gyors adatterjesztés és szinkronizálás érdekében a hálózaton keresztül.
3. A pletykaprotokoll négy fő üzenettípusból áll – Push, Pull, Prune és Ping/Pong –, amelyek segítenek az adatok terjesztésében, a hiányzó információk lekérésében, a csomóponti kapcsolatok kezelésében és a csomópontok életképességének ellenőrzésében.
4. A pletykaadatokat a Cluster Replicated Data Store (CrdsTable) tárolja, amely folyamatosan frissül a hálózat állapotának fokozatos frissítéseivel, biztosítva az adatok elérhetőségét és a csomópontok közötti szinkronizálást.
5. A Solana archívumrendszere "raktárcsomópontokat" használ a tranzakciós előzmények tárolására, a legutóbbi adatokat (1-2 korszakot) az érvényesítők megőrzik, míg a teljes tranzakciós előzményeket a Ledger Archives vagy a Google Bigtable példányai tárolják, hogy az RPC-k és más résztvevők könnyen hozzáférhessenek.

Pletyka

A Gossip protokoll egy peer-to-peer kommunikációs módszer elosztott rendszerekben, ahol a hálózat csomópontjai időszakonként állapotinformációt cserélnek magukról és a többi csomópontról, amelyekhez az egyes csomópontok decentralizált módon csatlakoznak. Ez hasonló ahhoz, ahogy a pletykák terjednek a közösségi médiában. Ez azt jelenti, hogy minden csekély állapotváltozás végül a hálózaton keresztül fog terjedni, és minden csomópont teljes információval fog rendelkezni az állapotváltozásról.

A Solanán a pletykaprotokoll implementációja informális kommunikációs módszert használ a Plumtree algoritmussal erősen modellezett fa broadcast megközelítéssel. Ez lehetővé teszi az állapotváltozások terjedését anélkül, hogy központi fejforrásra támaszkodna. A Solana vezérlőpultjaként működik, mivel segíti az érvényesítőket és az RPC csomópontokat, hogy megtudják, mely címek és portok vannak nyitva a kommunikációhoz. A Solana Gossip más fontos összetevőkkel működik együtt, mint például a validátorok, a turbina protokollok, az archív csomópontok, az előzmények igazolása stb. A Validátorok és az RPC-k 0,1 másodpercenként cserélnek aláírt adatobjektumokat UDP-n keresztül pletyka segítségével, garantálva az információk elérhetőségét a hálózaton keresztül. Minden pletykaüzenetnek meg kell haladnia az 1280 bájtos maximális átviteli egységet (MTU), amely a kódbázisban "csomagstruktúraként" ismert.

A pletykaprotokoll központi mechanizmusként szolgál a csomópontok számára a fürtkommunikáció hatékony kezelésére az aláírt adatobjektumok, például a kapcsolattartási adatok, a főkönyvi magasság és a szavazatok folyamatos megosztásával. 0,1 másodpercenként a csomópontok "push" és "pull" üzeneteket cserélnek – ahol a push üzenetek továbbíthatók, és mindkét típus válaszokat válthat ki – megkönnyítve az adatok gyors terjesztését a hálózaton. A jól ismert UDP/IP-porton vagy porttartományon keresztül működő gossip-protokoll lehetővé teszi a csomópontok számára, hogy a fürt rendszerindítása után hirdethessék egymásnak pletykavégpontjaikat (socket-címeiket). Ez a decentralizált, nagyfrekvenciás kommunikációs grafikon biztosítja a Solana csomópontjainak szinkronizálását és rugalmasságát, ami támogatja a blokklánc méretezhetőségét és teljesítményét.

A Solana pletykaprotokolljában négy üzenettípus segíti a fürtkommunikációt: A leggyakrabban előforduló push üzenetek az adatokat a „push társak” kiválasztott csoportjához osztják el. A lehívási üzeneteket a lehívási válaszukkal együtt rendszeres időközönként elküldik, hogy lekérjék a hiányzó információkat a meg nem osztott adatok lekérésével és kézbesítésével. A metszésüzenetek lehetővé teszik a csomópontok számára, hogy szükség szerint csökkentsék aktív kapcsolataikat. Végül a Ping és Pong üzenetek életképesség-ellenőrzésként szolgálnak, ahol a ping egy pong választ kér a peer csomópont működési állapotának megerősítésére.

A pletykaadatokat a Cluster Replicated Data Store (CrdsTable) tárolja. Ez az adatstruktúra folyamatosan frissül pletykaprotokoll üzenetekkel. Ezek az üzenetek pletykarekordokat tartalmaznak, amelyek lényegében a CrdsTable inkrementális frissítései.

Archívum

A Solana azzal különbözteti meg magát a többi blokklánctól, hogy nincs szüksége a teljes tranzakciós előzményekre a fiók aktuális állapotának meghatározásához. A fiókmodell biztosítja, hogy az adott rés állapota ismert legyen, lehetővé téve az érvényesítők számára az aktuális állapot tárolását anélkül, hogy az összes előzményblokkot fel kellene dolgozniuk. Az RPC-k és az érvényesítők általában nem őrzik meg a teljes főkönyvi előzményeket; ehelyett csak 1 vagy 2 epocha (2-4 nap) tranzakciós adatot tárolnak, ami elegendő a legutóbbi blokk érvényesítéséhez.

Az archív adatokat a professzionális RPC-szolgáltatók, a Solana Foundation és az ökoszisztéma más résztvevői által működtetett "raktárcsomópontok" kezelik, hogy biztosítsák a tranzakciós előzmények hozzáférhetőségét. Ezek a raktárcsomópontok gyakran vagy egy Ledger Archive-ot tartanak fenn, amely a nyers főkönyvi és AccountsDB pillanatképeket tárolja a nulláról való újrajátszáshoz, vagy egy Google Bigtable-példányt, amely a blokkadatokat tárolja a keletkezési blokktól kezdve az RPC-kéréseknek megfelelő formátumban.

Következtetés

Összefoglalva, a Solana pletykaprotokollja és archív rendszere hatékony kommunikációt és adatszinkronizálást tesz lehetővé a hálózaton keresztül. A pletykaprotokoll biztosítja a gyors állapotterjesztést, míg az archív rendszer tárolja a tranzakciós előzményeket, hogy az érvényesítők és az RPC-k könnyen hozzáférhessenek. Ezek a szolgáltatások együtt támogatják a Solana méretezhetőségét, teljesítményét és decentralizálását.