Die wichtigsten Erkenntnisse Solana verwendet ein Peer-to-Peer-Gossip-Protokoll, das auf dem Plumtree-Algorithmus basiert und eine dezentrale Kommunikation zwischen Knoten ermöglicht, um Statusänderungen effizient im gesamten Netzwerk zu verbreiten, ohne auf eine zentrale Quelle angewiesen zu sein. Alle 0,1 Sekunden tauschen Solana-Knoten „Push“- und „Pull“-Nachrichten aus und gewährleisten so einen kontinuierlichen und aktuellen Informationsaustausch, um eine schnelle Datenverbreitung und -synchronisierung im gesamten Netzwerk aufrechtzuerhalten. Das Gossip-Protokoll besteht aus vier Hauptnachrichtentypen – Push, Pull, Prune und Ping/Pong – die dabei helfen, Daten zu verteilen, fehlende Informationen anzufordern, Knotenverbindungen zu verwalten und die Knotenvitalität zu überprüfen. Gossip-Daten werden in einem Cluster Replicated Data Store (CrdsTable) gespeichert, der kontinuierlich mit inkrementellen Updates des Netzwerkstatus aktualisiert wird, um die Datenverfügbarkeit und Synchronisierung zwischen den Knoten sicherzustellen. Das Archivsystem von Solana verwendet „Warehouse-Knoten“ zum Speichern des Transaktionsverlaufs, wobei aktuelle Daten (1–2 Epochen) von den Validierern aufbewahrt werden, während der vollständige Transaktionsverlauf in Ledger-Archiven oder Google Bigtable-Instanzen gespeichert wird, damit RPCs und andere Teilnehmer problemlos darauf zugreifen können. Tratsch Das Gossip-Protokoll ist eine Peer-to-Peer-Kommunikationsmethode in verteilten Systemen, bei der die Knoten im Netzwerk regelmäßig Statusinformationen über sich selbst und andere Knoten austauschen, mit denen sie dezentral verbunden sind. Dies ähnelt der Verbreitung von Gerüchten in sozialen Medien. Es bedeutet, dass jede noch so kleine Zustandsänderung im Netzwerk verbreitet wird und alle Knoten über diese Zustandsänderung vollständig informiert sind. Auf Solana nutzt die Implementierung des Gossip-Protokolls eine informelle Kommunikationsmethode mit einem Tree-Broadcast-Ansatz, der stark am Plumtree-Algorithmus orientiert ist. Dies ermöglicht die Verbreitung von Zustandsänderungen ohne die Abhängigkeit von einer zentralen Quelle. Es fungiert als Kontrollzentrum für Solana und hilft Validatoren und RPC-Knoten, zu erkennen, welche Adressen und Ports für die Kommunikation geöffnet sind. Solana Gossip arbeitet mit anderen wichtigen Komponenten wie Validatoren, Turbinenprotokoll, Archivknoten, Verlaufsnachweisen usw. zusammen. Die Validatoren und RPCs tauschen alle 0,1 Sekunden signierte Datenobjekte über UDP mithilfe von Gossip aus und gewährleisten so die Informationsverfügbarkeit im gesamten Netzwerk. Jede Gossip-Nachricht muss die maximale Übertragungseinheit (MTU) von 1280 Bytes, die im Code als „Paketstruktur“ bezeichnet wird, nicht überschreiten. Das Gossip-Protokoll dient als zentraler Mechanismus für Knoten zur effizienten Verwaltung der Clusterkommunikation durch den kontinuierlichen Austausch signierter Datenobjekte wie Kontaktinformationen, Ledger-Höhe und Stimmen. Alle 0,1 Sekunden tauschen Knoten „Push“- und „Pull“-Nachrichten aus – wobei Push-Nachrichten weitergeleitet werden können und beide Arten Antworten auslösen können – und ermöglichen so eine schnelle Datenverbreitung im Netzwerk. Das Gossip-Protokoll arbeitet über einen bekannten UDP/IP-Port oder Portbereich und ermöglicht es Knoten, ihre Gossip-Endpunkte (Socket-Adressen) nach dem Bootstrapping des Clusters untereinander bekannt zu geben. Dieser dezentrale, hochfrequente Kommunikationsgraph stellt sicher, dass die Knoten von Solana synchronisiert und belastbar bleiben und unterstützt so die Skalierbarkeit und Leistung der Blockchain. Im Gossip-Protokoll von Solana erleichtern vier Nachrichtentypen die Cluster-Kommunikation: Push-Nachrichten, die am häufigsten vorkommenden, verteilen Daten an eine ausgewählte Gruppe von „Push-Peers“. Pull-Nachrichten werden zusammen mit ihren Pull-Antworten regelmäßig gesendet, um fehlende Informationen durch Anforderung und Bereitstellung nicht freigegebener Daten abzurufen. Prune-Nachrichten ermöglichen es Knoten, ihre aktiven Verbindungen nach Bedarf zu reduzieren. Ping- und Pong-Nachrichten dienen schließlich der Vitalitätsprüfung. Ein Ping löst eine Pong-Antwort aus, um den Betriebsstatus eines Peer-Knotens zu bestätigen. Gossip-Daten werden in einem Cluster Replicated Data Store (CrdsTable) gespeichert. Diese Datenstruktur wird kontinuierlich mit Gossip-Protokollnachrichten aktualisiert. Diese Nachrichten enthalten Gossip-Datensätze, die im Wesentlichen inkrementelle Aktualisierungen der CrdsTable darstellen. Archiv Solana unterscheidet sich von anderen Blockchains dadurch, dass es nicht den gesamten Transaktionsverlauf benötigt, um den aktuellen Status eines Kontos zu bestimmen. Das Kontomodell stellt sicher, dass der Status in jedem Slot bekannt ist. Dadurch können Validierer den aktuellen Status speichern, ohne alle historischen Blöcke verarbeiten zu müssen. RPCs und Validierer speichern in der Regel nicht den gesamten Ledger-Verlauf, sondern nur ein oder zwei Epochen (2–4 Tage) an Transaktionsdaten, was für die Validierung des letzten Blocks ausreicht. Archivdaten werden von „Warehouse-Knoten“ verwaltet, die von professionellen RPC-Dienstleistern, der Solana Foundation und anderen Teilnehmern des Ökosystems betrieben werden, um den Zugriff auf den Transaktionsverlauf zu gewährleisten. Diese Warehouse-Knoten verwalten häufig entweder ein Ledger-Archiv, das Roh-Ledger- und AccountsDB-Snapshots zur Wiedergabe von Grund auf speichert, oder eine Google Bigtable-Instanz, die Blockdaten ab dem Genesis-Block in einem für RPC-Anfragen geeigneten Format speichert. Abschluss Zusammenfassend lässt sich sagen, dass Solanas Gossip-Protokoll und Archivsystem eine effiziente Kommunikation und Datensynchronisation im gesamten Netzwerk ermöglichen. Das Gossip-Protokoll gewährleistet eine schnelle Statusverbreitung, während das Archivsystem den Transaktionsverlauf für den einfachen Zugriff durch Validierer und RPCs speichert. Zusammen unterstützen diese Funktionen die Skalierbarkeit, Leistung und Dezentralisierung von Solana.
