Validators, the leader schedule and block propagation

A leader produces a block and has to get it to every other validator. Sending it directly to each one would require the leader to have a separate connection to every node and to transmit the block once per node, which does not scale. Turbine solves this by borrowing the structure of a peer-to-peer file-sharing network: the leader sends the block to a small number of nodes, and each of those sends it to a small number of others, in layers.

The cluster is divided into layers. The leader communicates with a root node, which forms layer zero. The root sends to a bounded number of nodes in layer one, each of those sends to a bounded number in layer two, and so on until every node has the block. Each node therefore only has to communicate with a small number of peers, and the number of layers grows logarithmically with the size of the cluster rather than linearly.

The tree is not fixed. It is regenerated for every shred — a fragment of the block — using a seed derived from the slot leader's identity, the slot, the shred index and the shred type. The list of nodes is shuffled with a stake weighting before the tree is built, so higher-staked nodes tend to sit closer to the leader and receive data sooner. Regenerating the tree per shred makes it harder for a node to predict and target a specific position in the propagation path.

Turbine transmits over UDP and uses erasure coding to tolerate loss. A block is split into groups of shreds, and each group carries enough redundancy that the group can be reconstructed even if some shreds are lost in transit. Because retransmission compounds packet loss at every hop, the amount of redundancy has to account for both the network's loss rate and the depth of the tree. The documentation gives the failure probability as a binomial calculation over the shred group.

Most networks hold pending transactions in a mempool, a pool that every node maintains and gossips about. Solana does not. Instead, clients and validators forward transactions directly to the validators that are scheduled to lead upcoming slots. The design is called Gulf Stream, and it is described as a mempool-less forwarding protocol.

The reason for avoiding a mempool is scale. At high transaction rates, a gossip protocol that has to propagate every pending transaction to every node becomes the bottleneck: the cost of filtering and forwarding the pool grows faster than the network can absorb it, and the leader ends up retransmitting transactions it already has. Forwarding to the known upcoming leader avoids both problems, because the transaction goes where it will be used rather than everywhere.

Gulf Stream depends on the leader schedule being known in advance, which is why the two mechanisms are described together. A client signs a transaction referencing a recent blockhash, and that reference bounds how long the transaction is valid. The client forwards it to a validator, which forwards it to one of the upcoming leaders. Because the blockhash expires after a bounded number of slots, the client can eventually conclude that a transaction which has not been included never will be.

The design has a side effect that matters under load. Because validators know who the upcoming leaders are, they can forward transactions ahead of time and drop ones that are already invalid, and a leader can prioritise transactions based on the stake of the validator that forwarded them. That gives the network a way to degrade rather than collapse when it is under stress.

Validators do not only receive blocks; they vote on them. A vote is a transaction, signed by the validator, that records which block the validator considers valid. Votes are how the cluster converges on a single history, and they are also how a validator earns rewards for participating.

Because votes are transactions, they compete for the same block space as everything else, and they carry the same base fee per signature. The protocol reserves a portion of each block for vote transactions so that consensus messages are not crowded out by user activity. That reservation is a deliberate design choice: without it, a period of high demand could delay the votes the network needs to finalise blocks, which would slow the chain precisely when it is busiest.

The practical consequence for a user is the difference between confirmation and finality. A transaction can be included in a block and still, in principle, be rolled back if the cluster later settles on a different history. Once enough stake has voted on a block, that possibility is closed off. Clients choose a commitment level that reflects how much certainty they need, trading latency against the risk of a rollback.