Turbine is Solana's multi-layer process for broadcasting transaction shreds across a cluster while minimizing duplicate messages. The cluster is divided into neighborhoods: each node shares received data with nodes in its own neighborhood and forwards it to a small set of nodes in other neighborhoods. This limits the number of peers with which each node must communicate.

University of Chicago

Google

Solana reaches high-throughput consensus by combining several interlocking subsystems. Validators organize into clusters and synchronize using Proof of History timestamps, while leader rotation designates a single validator at a time to produce ledger entries. When connectivity to a leader is lost, the cluster tolerates fork generation, and a leader assigned to a fork must see it through rather than switching forks. Turbine propagates blocks efficiently across the cluster with minimal duplicate messages, secure vote signing isolates the vote-casting logic to protect validators from having their stake slashed for forged votes, and stake delegation lets token holders share in rewards for helping secure the network.

How Solana Works

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

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. 

Stake Delegations and Rewards

A Solana cluster is a set of validators that processes client transactions and maintains a shared ledger. Multiple clusters can coexist. Clusters with a common genesis block attempt to converge; clusters without one ignore each other. Transactions sent to the wrong cluster are ignored.

Solana Clusters

A Solana validator receives ledger entries from the current leader and votes to confirm entries it considers valid. Because a forged or consensus-violating vote could expose the validator's stake to slashing, secure vote signing isolates vote evaluation in a separate signer service. The service checks each proposed vote for slashing-condition violations before signing it.

Learn Before

Related