Understanding Solana: Leader Rotation Mechanism

Scalability is an ongoing challenge for the blockchain industry.

With the explosive growth of decentralized finance, blockchains’ demand for scalability are increasing. Various blockchains are trying to solve this challenge with scalability solutions such as sharding, Layer2 and sidechains. Solana takes a more straightforward approach — providing an ultra-fast, secure and censorship-resistant public chain in Layer1 to provide a highly scalable open infrastructure for global decentralized applications.

Thanks to the original PoH (Proof-of-History) consensus, Solana, with top performance in the industry, is on its way to becoming the world’s first Web-level decentralized network. Based on PoH, all nodes on the Solana chain are able to generate a unified timestamp through algorithms, reducing trust costs and improving efficiency, while all its verification and processing are performed in an asynchronous state.

(1) Leaders and Role

There are multiple roles in the Solana ecosystem (leaders, validators, archivers, etc.). Unlike the DPoS blockchain, Solana does not delegate these roles among network participants, the nodes on Solana play a part in fulfilling all network roles.

Leaders on Solana are tasked with producing new blocks. Leaders rotate every 4 blocks (1.6 seconds). While a node occupies a Leader position, it cram all transactions into the four blocks they are producing and show these blocks containing the transactions to the relevant groups of nodes, called Solana Clusters. These nodes validate the transactions using digital timestamps as reference and then rapidly pass on the records to other relevant nodes on the network.

The genesis configuration declares the first leader for the first epoch. This leader ends up scheduled for the first two epochs because the leader schedule is also generated at slot 0 for the next epoch. The length of the first two epochs can be specified in the genesis configuration as well. The minimum length of the first epochs must be greater than or equal to the maximum rollback depth as defined in Tower BFT.

Supported by PoH, the leaders rotate constantly. Regardless of the network condition, the entire network does not need to communicate with any validators, and does not stop when errors occur, but immediately starts the next action at a new block height, which means that Solana’s network becomes a “perpetual motion machine”, as the leaders and validators are rotatable.

At the same time, leader rotation decisions in Solana are made asynchronously. This core innovation opened up the design space going up the stack.

(1) Solana’s Leader Rotation

Leaders are precisely selected, but the drawback of only one leader at a time also exists.

A malicious leader can censor votes and transactions. Since censoring cannot be distinguished from the network dropping packets, the cluster cannot simply elect a single node to hold the leader role indefinitely. Instead, the cluster avoids the risk of a malicious leader through a “rotation” mechanism.

As mentioned earlier, the generation and certification of leaders are performed asynchronously. Throughout the system, each leader is assigned a slot in a slot order list “leader schedule”, against which each validator can select the expected leader using the same algorithm. When the validator receives a new signed ledger entry, it can be certain that an entry was produced by the expected leader.

Therefore, if you want to ensure the smoothness of the system judgment, the scheduling of the “leader schedule” must be calculated well in advance of its assigned slot, so that the ledger state it uses to calculate the schedule can be finalized.

So how does the “leader schedule” come about?

1. Periodically use the PoH tick height (a monotonically increasing counter) to seed a stable pseudo-random algorithm.

2. At that height, sample the bank for all the staked accounts with leader identities that have voted within a cluster-configured number of ticks. The sample is called the active set.

3. Sort the active set by stake weight.

4. Use the random seed to select nodes weighted by stake to create a stake-weighted ordering.

5. This ordering becomes valid after a cluster-configured number of ticks.

That duration is called the leader schedule offset. Solana sets the offset to the duration of slots until the next epoch.

That is, the leader schedule for an epoch is calculated from the ledger state at the start of the previous epoch. The offset of one epoch is fairly arbitrary and assumed to be sufficiently long such that all validators will have finalized their ledger state before the next schedule is generated. A cluster may choose to shorten the offset to reduce the time between stake changes and leader schedule updates.

Due to such asynchrony, any new information committed to the root fork will not be active until the next period, when a new leader is born and the first block that crosses the epoch boundary is produced.

If the duration of the partition does not exceed one epoch, this communication will not be interrupted, but will continue to operate as follows:

1. A validator continuously updates its own root fork as it votes.

2. The validator updates its leader schedule each time the slot height crosses an epoch boundary.

For example: Let’s assume an epoch duration of 100 slots. The root fork is updated from fork computed at slot height 99 to a fork computed at slot height 102. Forks with slots at height 100, 101 were skipped because of failures. The new leader schedule is computed using fork at slot height 102. It is active from slot 200 until it is updated again

There is no inconsistency in this leapfrog solution, because every validator that is voting with the cluster has skipped 100 and 101 when its root passes 102. All validators, regardless of voting pattern, would be committing to a root that is either 102, or a descendant of 102.

Without increasing network throughput, Solana validators can manage a mempool size of 100,000. That means that with network throughput of 50,000 TPS, a 100,000 transaction mempool is executed in a matter of seconds.

Validators push forwarding to the edge of the network, which is called the Gulf Stream. Since every validator knows the order of upcoming leaders, validators forward transactions to the expected leader ahead of time. This allows validators to execute transactions ahead of time, reduce confirmation times, switch leaders faster, and reduce the memory pressure on validators from the unconfirmed transaction pool, allowing Solana to process up to 50,000 transactions per second.

(2) Conclusion

Solana’s core innovation is PoH, which enables Solana’s network to authenticate time-sources without permission and can work before reaching a consensus, thus greatly improving scalability and liquidity.

And the leader rotation mechanism is an important manifestation of the “one step ahead” concept: one step ahead in creating “leader schedules”, one step ahead in pushing transactions and information to new leaders, and one step ahead in processing the right information, bypassing errors and failures …… Due to trustless asynchronous processing, Solana is one step ahead in terms of processing speed

With its unique consensus and various mechanisms, Solana now has a huge influence in the encryption world, and we will wait and see to what extent the adoption rate of its ecosystem will increase.