One unique feature of Solana’s design is that it enables continuous block building and propagation. This is enabled by several key innovations such as leader selection, Gulf Stream (no mempool), and Turbine (block propagation).
Because of Solana’s continuous nature, it is imperative that other validators receive the most updated state in an efficient manner. The naive implementation would be to directly propagate all blocks to all other validators. However, especially given Solana’s throughput, this would unnecessarily increase bandwidth and other resource requirements (as the leader would have to send all block data to every other validator), decreasing decentralization.
Bandwidth is a scarce resource and Turbine is Solana’s solution for efficiently propagating information from the leader of a given block to the rest of the network. Turbine was specifically designed to mitigate the stress of egress (sending data out) from the leader to the network. The core ideas behind Turbine have been in the mind of academics for many years as evidenced by this paper published in 2004 as well as more recent work.
In this post, we will provide a comprehensive analysis of how Turbine works and how it fits into the broader landscape of transaction inclusion on Solana. Lastly, we will provide context on how Turbine stacks up to other “data availability” solutions and open research areas.
Before a block is propagated (transmitted to other validators in the network), the leader first builds and orders the block given the incoming stream of transactions. After the block is built, it is ready to be sent via Turbine to the rest of the network. This is what is referred to as block propagation. Vote messages are then passed between validators (included as part of the block itself) in order to satisfy either the commitment status “confirmed” or “finalized”. This is part of consensus and will be explored in a future post.
Visualization of where Turbine lies in the lifecycle of a Solana transaction
While leaders build and propose entire blocks, the actual data is sent as shreds (partial blocks) to other validators in the network. Shreds are the atomic units sent between validators.
At a high level, Turbine takes shreds and sends them to a set of validators, who then relay those shreds to a new set of validators. The following diagram outlines the continuous process of shred propagation:
Although it is called “block propagation”, data is propagated at the shred-level.
In this example, Validator 1 is the designated slot leader. During its slot (validators are assigned leader for 4 consecutive slots), Validator 1 builds and proposes a block. Validator 1 first breaks the block into sub-blocks called shreds through a process called shredding. Shredding splits the block data into Maximum Transmission Units (MTU)-sized data shreds and generates corresponding recovery shreds via the Reed-Solomon erasure coding scheme.