Solana’s Secret to Staying Fast? A Blockchain Gossip Network

Key Takeaways

1. Solana uses a peer-to-peer gossip protocol based on the Plumtree algorithm, allowing decentralized communication between nodes to propagate state changes efficiently across the network without relying on a central source.
2. Every 0.1 seconds, Solana nodes exchange "push" and "pull" messages, ensuring continuous and up-to-date information sharing to maintain rapid data dissemination and synchronization across the network.
3. The gossip protocol consists of four main message types—Push, Pull, Prune, and Ping/Pong—that help distribute data, request missing information, manage node connections, and check node vitality.
4. Gossip data is stored in a Cluster Replicated Data Store (CrdsTable), which is continuously updated with incremental updates to the network's state, ensuring data availability and synchronization among nodes.
5. Solana's archive system uses "warehouse nodes" to store transaction history, with recent data (1-2 epochs) retained by validators, while full transaction history is stored in Ledger Archives or Google Bigtable instances for easy access by RPCs and other participants.

Gossip

Gossip protocol is a peer-to-peer communication method in distributed systems, where the nodes in the network exchange state information periodically about themselves and other nodes each node is connected to in a decentralized manner. This is similar to how rumors spread on social media. It implies that any slight state change will eventually be propagated through the network, and all nodes will have full information on that state change.

On Solana, its implementation of the gossip protocol uses an informal communication method with a tree broadcast approach heavily modeled against the Plumtree algorithm. This makes the propagation of state changes without relying on a central head source. It acts as a control panel for Solana as it aids validators and RPC nodes to know which addresses and ports are open for communication. Solana Gossip works with other major components such as validators, turbine protocol, archive nodes, proof of history, etc. The Validators and RPCs exchange signed data objects every 0.1 seconds over UDP using gossip, guaranteeing information availability throughout the network. Every gossip message has to be at or below the maximum transmission unit (MTU) of 1280 bytes, known as the "packet struct" in the codebase.

The gossip protocol serves as a central mechanism for nodes to efficiently manage cluster communication by continuously sharing signed data objects, such as contact information, ledger height, and votes. Every 0.1 seconds, nodes exchange "push" and "pull" messages—where push messages can be forwarded and both types may trigger responses—facilitating rapid data dissemination across the network. Operating over a well-known UDP/IP port or port range, the gossip protocol enables nodes to advertise their gossip endpoints (socket addresses) to one another after the cluster is bootstrapped. This decentralized, high-frequency communication graph ensures Solana’s nodes remain synchronized and resilient, supporting the blockchain’s scalability and performance.

In Solana's gossip protocol, four message types facilitate cluster communication: Push messages, the most frequent, distribute data to a select group of "push peers." Pull messages, along with their Pull Responses, are sent periodically to retrieve any missing information by requesting and delivering unshared data. Prune messages enable nodes to trim down their active connections as needed. Lastly, Ping and Pong messages serve as vitality checks, where a ping prompts a pong reply to confirm a peer node’s operational status.

Gossip data is stored in a Cluster Replicated Data Store (CrdsTable). This data structure is continuously updated with gossip protocol messages. These messages contain gossip records, which are essentially incremental updates to the CrdsTable.

Archive

Solana differentiates itself from other blockchains by not requiring the full transaction history to determine an account's current state. Its account model ensures that the state at any given slot is known, enabling validators to store the current state without needing to process all historical blocks. RPCs and validators typically don't retain the entire ledger history; instead, they store only 1 or 2 epochs (2-4 days) of transaction data, which is enough to validate the latest block.

Archive data is managed by "warehouse nodes," run by professional RPC service providers, the Solana Foundation, and other ecosystem participants to ensure transaction history is accessible. These warehouse nodes often maintain either a Ledger Archive, which stores raw ledger and AccountsDB snapshots for replaying from scratch, or a Google Bigtable Instance, which stores block data from the genesis block onward in a format suitable for RPC requests.

Conclusion

In conclusion, Solana's gossip protocol and archive system enable efficient communication and data synchronization across the network. The gossip protocol ensures rapid state propagation, while the archive system stores transaction history for easy access by validators and RPCs. Together, these features support Solana's scalability, performance, and decentralization.