A Solana cluster is a set of validators working together to serve client transactions and maintain the integrity of the ledger. Many clusters may coexist. When two clusters share a common genesis block, they attempt to converge. Otherwise, they simply ignore the existence of the other. If transactions are sent to the wrong cluster, they are ignored. 

University of Chicago

-Solana Clusters
-Synchronization
-Leader Rotation
-Fork Generation
-Managing Forks 
-Turbine Block Propagation
-Secure Vote Signing 
-Stake Delegation and Rewards 

How Solana Works

Solona Clusters 

Fast, reliable synchronization is the biggest reason Solana is able to achieve such high throughput, and this is done with Proof of History or PoH. Leader nodes "timestamp" blocks with cryptographic proofs that some duration of time has passed since the last proof. All data hashed into the proof most certainly have occurred before the proof was generated. The node then shares the new block with validator nodes, which are able to verify those proofs. The blocks can arrive at validators in any order or even could be replayed years later. With such reliable synchronization guarantees, Solana is able to break blocks into smaller batches of transactions called entries. Entries are streamed to validators in realtime, before any notion of block consensus. This process is similar to verifiable delay functions (VDF).

Synchronization

At any given moment, a cluster expects only one validator to produce ledger entries. By having only one leader at a time, all validators are able to replay identical copies of the ledger. The drawback of only one leader at a time, however, is that a malicious leader is capable of censoring votes and transactions. Since censoring cannot be distinguished from the network, the cluster cannot simply elect a single node to hold the leader role indefinitely. Instead, the cluster minimizes the influence of a malicious leader by rotating which node takes the lead. Cluster leaders are decided via an algorithm with creates a schedule of leaders. 

Leader Rotation 

Forks occur naturally as a product of the leader rotation described above. Nodes take turns being leaders and generating the PoH that encodes state changes. The cluster can tolerate loss of connection to any leader by synthesizing what the leader would have generated had it been connected but not ingesting any state changes. The possible number of forks is thereby limited to a "there/not-there" skip list of forks that may arise on leader rotation slot boundaries. At any given slot, only a single leader's transactions will be accepted.

Fork Generation 

When a fork occurs, a node leader is assigned to it. Votes are held on the continuation of the fork. Eventually, an allotted amount of time will run out and the fork will end. A leader can not bounce from fork to fork and must see the assigned fork through.

Managing Forks

A Solana cluster uses a multi-layer block propagation mechanism called Turbine to broadcast transaction shreds to all nodes with minimal amount of duplicate messages. The cluster divides itself into small collections of nodes, called neighborhoods. Each node is responsible for sharing any data it receives with the other nodes in its neighborhood, as well as propagating the data on to a small set of nodes in other neighborhoods. This way each node only has to communicate with a small number of nodes. 

Turbine Block Propagation 

A validator receives entries from the current leader and submits votes confirming those entries are valid. This vote submission presents a security challenge, because forged votes that violate consensus rules could be used to slash the validator's stake. Solana addresses this risk by splitting off a separate vote signer service that evaluates each vote to ensure it does not violate a slashing condition.

Secure Vote Signing 

Stakers are rewarded for helping to validate the ledger. They do this by delegating their stake to validator nodes. Those validators do the legwork of replaying the ledger and sending votes to a per-node vote account to which stakers can delegate their stakes. The rest of the cluster uses those stake-weighted votes to select a block when forks arise. Both the validators and the stakers are compensated for this work. 

Learn Before

Related