Introduction

Solana is designed for speed and scalability, pushing the limits of blockchain throughput and latency. Achieving web-scale performance requires an unconventional architecture that tightly integrates with hardware and streams data continuously. Unlike many blockchains that gather transactions into discrete blocks and broadcast them after a full block is assembled, Solana’s approach is to build and propagate blocks in real-time during each short time window (slot). This continuous block production dramatically reduces latency. In this deep dive, we’ll explore Solana’s block building process end-to-end – from its unique timekeeping and leader schedule to the internals of how a validator ingests transactions, produces a block, and propagates it to the network. We’ll also compare Solana’s native block production with alternative approaches like Jito, and define key terms in a glossary for easy reference. Whether you’re a general software engineer, a budding Solana developer, or coming from another blockchain background, this guide will clarify how Solana builds blocks at record speed while maintaining consistency across a decentralized network.

Time Units, Leaders, and Schedule Assignment

Slots and Epochs: Solana partitions time into fixed intervals called slots. Each slot lasts roughly 400 milliseconds and represents the opportunity for a validator to produce a block. Slots are numbered continuously, and a group of slots forms an epoch. An epoch can span many thousands of slots (depending on network configuration) and is the interval after which stake distribution and leader schedules are recomputed.

Leader Rotation: In Solana, validators take turns being the leader (block producer) for each slot. The leader is responsible for assembling and publishing the block for that 400 ms slot. To minimize any one validator’s influence (or ability to censor transactions), leadership rotates rapidly. In fact, Solana assigns each chosen leader a short sequence of consecutive slots – by default 4 slots (1.6 seconds) per leader – before moving to the next leader. This means a given validator, if selected, will produce up to four blocks in a row, then pass the lead. The consecutive slots approach amortizes the cost of leader switching and allows leaders to “warm up,” but it’s still brief enough (under 2 seconds) to prevent centralized control. Leader schedules are determined in advance for each epoch and known to all validators.

Stake-Weighted Leader Schedule: The schedule of who leads each slot is computed deterministically from the stake distribution. Roughly, Solana uses a stake-weighted random selection – validators with more stake (or stake delegated to them) get proportionally more slots, but the exact slot assignments are pseudorandom. At the epoch boundary, the network uses a randomized seed (derived from the PoH tick count at that point) to shuffle the active validators and assign slots for the next epoch. This process ensures all validators independently calculate the same schedule and that it’s unpredictable in advance yet unbiased by any validator (no one can easily game which slots they’ll get). By the time a new epoch starts, every validator knows the slot-to-leader mapping for that epoch. They will reject any block not signed by the expected leader for its slot.

Slot Execution: During its assigned slot(s), the leader’s job is to gather transactions and output a valid block (or blocks). If a leader is offline or fails to produce a block in its slot, that slot’s time still passes (400ms ticked away by PoH; more on PoH shortly) and the opportunity is missed – the next leader will start on the next slot’s block. Since only the designated leader’s block is accepted for a given slot, no two competing blocks can be produced for the same slot. However, forks can occur if a leader builds on a parent that isn’t in the main chain (e.g. a previous block was missing or the leader didn’t receive it in time). We’ll discuss how Solana handles forks and finality in a later section.

Transaction Forwarding (Gulf Stream): An important aspect of Solana’s design is that it avoids a traditional mempool. Instead of waiting for transactions to trickle through a global pool, Solana uses a mechanism often dubbed Gulf Stream, where transactions are pushed to the expected leaders ahead of time. Validators and RPC nodes know the leader schedule, so they forward new transactions to the current and upcoming leaders. In fact, about two slots before a validator’s leader slot, other nodes stop sending it new transactions so it can focus on block production, and instead start routing transactions to the next in line. As a validator’s turn to lead approaches, it experiences a surge of incoming packets as the entire network directs transactions its way. This proactive forwarding means that when a slot begins, the leader likely already has a queue of transactions ready to go, maximizing the useful work done in the mere 400ms available. By contrast, many blockchains rely on passively waiting for transactions in a mempool, which could add delay. Solana’s approach helps achieve its signature low latency.

Proof of History: A Cryptographic Clock

A core innovation underpinning Solana’s speed is Proof of History (PoH) – a cryptographic source of time that keeps the entire network in sync about when events happened, without requiring slow consensus on timestamps. PoH is often described as a verifiable delay function or cryptographic clock.

At its heart, PoH is simply a continuously running hash chain inside each validator. One can imagine a single processor repeatedly computing a SHA-256 hash, where each new hash takes the previous hash as part of its input. Because each hash depends on the prior one, you cannot parallelize this work – you must perform them one after the other. Over time, this sequence of hashes serves as a ticks of a clock: if you see a chain of, say, 1 million SHA-256 hashes, you know that a certain minimum amount of time has elapsed (because even the fastest hardware can only do so many in a given time). Critically, verifying the sequence is fast – others can check any segment of the hash chain in parallel – but producing it is slow and sequential. This makes PoH a trustless time source: as long as the hash function is secure, no validator can fake or shortcut the passage of time.

Every validator continuously runs a PoH generator (often in a dedicated thread) even when it is not the leader. This generates a stream of hashes, and at fixed intervals the hash output is marked as a tick – essentially a heartbeat indicating a small time unit has passed. In Solana’s configuration, a tick is generated every 6.25 milliseconds, and one slot of 400ms contains 64 ticks. Thus, the PoH hash stream provides a granular timeline subdividing each slot. When a validator becomes the leader, it doesn’t start a new clock – it already has this PoH timer running and simply continues it, using it to timestamp the block’s data as it’s produced.

How does PoH tie into block production? Each block in Solana consists of a series of entries, where each entry is a batch of transactions that were executed (we’ll cover the execution in the TPU section). After processing a batch of transactions, the leader takes the hash of that batch’s data and feeds it into the PoH generator to produce the next hash. In doing so, the hash chain now irrevocably includes a fingerprint of those transactions at that point in time. In effect, PoH provides each entry with a timestamp and ordinal in the history – everyone can later verify that entry X came before entry Y because it’s embedded in the hash sequence. The last tick of the slot effectively seals the block. By the end of the 64 ticks, the leader will have generated the block’s PoH hash and all validators will have seen those ticks, so they know the slot is complete.

PoH’s key benefit is establishing a global ordering of events without requiring synchronization messages. It acts as a source of time that all validators follow, ensuring leaders can’t cheat the schedule. Even if a leader is absent or malicious, they can’t produce hashes faster than time permits, and if they don’t produce any entries, other validators will still see the ticks progress and know the slot passed without a block. The next leader can then fill in any gap by producing the remaining ticks (empty entries) for the missed slot before proceeding. Because PoH is always running, the network doesn’t halt if someone fails to fill their slot – time marches on. In short, PoH is the backbone that keeps Solana’s many moving parts in sync and enforces the rhythm of block production, acting as a decentralized clock for the system.

Timestamps vs. Consensus: It’s important to note that PoH by itself is not a consensus mechanism – it doesn’t decide which fork is correct – but it feeds into Solana’s consensus (Tower BFT) by providing a consistent ordering of events and a way to quickly get agreement on the when and in what order before the what. Traditional BFT consensus requires multiple rounds of voting to order transactions, but Solana can skip a lot of that overhead because the order is implicitly set by the PoH timestamp each entry carries. This drastically reduces communication between validators during block production.

Leader’s Pipeline: The Transaction Processing Unit (TPU)

When a validator is in the leader role, it runs an accelerated pipeline to take in user transactions and output a block. This pipeline is called the Transaction Processing Unit (TPU) – essentially, the block producer module of the Solana validator client. The TPU comprises multiple stages working in parallel to ingest, verify, execute, and package transactions into shreds for propagation. We’ll walk through each stage of the TPU, from receiving transactions to broadcasting the finished block.

Figure: The Solana leader node’s Transaction Processing Unit (TPU) pipeline. Incoming transactions flow from the network (left) into the Fetch Stage, then to signature verification, and into the Banking Stage where transactions are executed and grouped into entries. Each entry’s result is fed into the PoH Service (the clock icon) which timestamps it into the ledger’s hash chain. Finally, the Broadcast Stage converts blocks into shreds and transmits them over the Turbine tree (right). The state changes are applied to the in-memory bank and later saved to the Accounts DB (bottom).

1. Ingestion – Fetch Stage: The leader begins by accepting transactions from the network. Solana uses a high-performance UDP-based protocol (QUIC) for transaction ingestion. In the Fetch Stage, the TPU is essentially listening on a QUIC socket for incoming packet batches. These transactions are coming from many sources: RPC nodes, other validators forwarding pending transactions (Gulf Stream), and clients. The Fetch Stage quickly deserializes packets into transaction messages and pushes them into the pipeline’s buffer. At this point, no heavy processing has been done – it’s just gathering the raw transactions as fast as possible (Solana’s networking is tuned to handle very high packet rates, often bursts of millions of packets per second).

2. Signature Verification – SigVerify Stage: Next, transactions enter the Signature Verification Stage. Each Solana transaction is signed by the sender (and possibly other signers) and includes those signatures in the message. The TPU must validate every signature to ensure transactions are authentic and not maliciously fabricated. In this stage, the validator checks each transaction’s signatures using efficient cryptographic verification (ed25519). This step is highly parallelizable – Solana’s implementation uses SIMD instructions and can offload to GPU in some cases, though on modern CPUs it can handle thousands of sigchecks quickly without special hardware. The SigVerify stage also weeds out any duplicate transactions (by tracking recent signature values) and ensures the transaction has the required number of signatures. Transactions failing these checks are dropped early, so they don’t waste further resources.

3. Scheduling and Execution – Banking Stage: Once transactions are verified, they proceed to the Banking Stage, the heart of the TPU. The banking stage is responsible for executing transactions and updating the ledger state (accounts) accordingly – effectively building the block. It’s called “banking” because it operates on a Bank, which is Solana’s in-memory state for that slot (a snapshot of all accounts and balances at the start of the block). Importantly, the Bank provides an interface to apply transactions and record the results.

A key innovation of Solana (also known as the Sealevel runtime) is the ability to execute many non-conflicting transactions in parallel. Each transaction in Solana declares upfront which accounts it will read and write. Using this information, the banking stage can group transactions into batches (called entries) such that no two transactions in an entry conflict on the same account. Solana’s default is to pack up to 64 transactions per entry. For example, if transaction A and B both want to write to the same account X, they must go in different entries (sequentially executed), but if A and B touch entirely different accounts, they can be executed in parallel within one entry. This design imposes a bit of extra burden on developers to specify accounts, but it eliminates runtime race conditions and allows maximal parallelism. In the banking stage, the TPU maintains multiple execution threads. Typically six threads are used: four for normal transactions and two reserved for vote transactions. Vote transactions (which validators generate for consensus) are handled separately to ensure they don’t get starved and are processed promptly, as they are critical for finalizing blocks.

Within each entry’s execution, the process is as follows: The Bank locks the accounts that will be written or read, to prevent conflicts across threads. Then, the transactions are executed on Solana’s runtime (SVM), which interprets the BPF-based smart contracts. As each transaction finishes, its state changes (account balance updates, program state updates, etc.) are applied in the Bank. Once all transactions in the entry are executed, the entry is considered completed. The result of the entry – typically a list of transactions and the resulting state changes – is then hashed and sent to the PoH service.

4. PoH Recording: The PoH service (discussed earlier) now takes the entry’s hash and mixes it into the ongoing hash chain. If this step is successful – meaning the PoH has properly sequenced and accepted the entry – the TPU then commits the entry: it unlocks the accounts (so subsequent transactions can use them) and makes the state changes official in the Bank. This effectively appends the entry into the block’s timeline. The PoH integration is crucial: it timestamps the entry, proving the order of transactions in the ledger. If the PoH service were to fail (e.g. the leader falls behind on PoH), the entry wouldn’t be added and the transactions might be retried in the next slot by the next leader. Under normal conditions, PoH is always running fast enough to not be a bottleneck, since it can handle the hashing of an entry much faster than 400ms.

The banking stage repeats this cycle continuously during the slot: form non-conflicting batches, execute them in parallel, and PoH-record them, interleaving with tick hashes. Any transactions that couldn’t fit or arrived too late in the slot might be forwarded to the next leader’s queue.

By the end of the slot (after 64 ticks), the leader will have processed as many transactions as it could and inserted tick entries for any leftover PoH ticks with no transactions. The final PoH hash of the slot becomes that block’s hash. The Bank now contains the updated state after all those transactions. This in-memory Bank will later be persisted once the block is finalized. Because all state changes are deterministic given the transaction list, any validator that replays the same transactions in the same order will end up with the identical Bank state – that’s the basis for validation.

5. Broadcast Stage: As the leader is executing transactions and creating entries, it also needs to distribute the block data to the other validators. Solana does this on the fly, rather than waiting until the end of the block. In the Broadcast Stage, the TPU takes the entries and chops them into shreds (short for ledger fragments) to send out over the network. We’ll discuss shreds and the Turbine propagation in detail in the next section, but in essence the Broadcast stage packages the data and uses UDP multicast to efficiently send pieces of the block to different peers. The broadcast runs in parallel with the Banking stage – as soon as an entry is ready and recorded in PoH, it can be dispatched as shreds. This parallelism is another reason Solana achieves low end-to-end block times: the network transmission overlaps with computation.

Finally, once the slot is complete, the leader has transmitted all its shreds. Those shreds contain all the entries (transactions and ticks) for that slot’s block. At this point, the leader is done with its duty; the TPU’s work for that slot finishes and the next scheduled leader will take over in the next slot. The leader continues to run PoH (it never stopped) but now it will just be verifying someone else’s work until it’s leader again.

Continuous vs Discrete Block Building: It’s worth emphasizing how Solana’s TPU implements a streaming block production. Transactions are processed and output concurrently, rather than assembling an entire block then releasing it. As soon as an entry is executed and hashed into PoH, it’s sent out. This means other validators can start receiving parts of the block before the slot even ends. It’s a bit like video streaming versus downloading – Solana “streams” the block to validators in real-time. Most other blockchains build blocks discretely: gather txs in mempool → order and execute → produce block → broadcast whole block. Solana’s method greatly cuts down idle time and pipeline bubbles, contributing to its high throughput and low latency.

Validator’s Pipeline: The Transaction Validation Unit (TVU)

While the leader’s TPU is busy creating the block, every other validator is running the counterpart process: the Transaction Validation Unit (TVU). The TVU’s job is to receive the data for new blocks, verify them, and integrate them into the validator’s copy of the ledger state. Essentially, the TVU is a pipeline that takes the incoming shreds from the leader and reconstructs the block, executes the same transactions the leader did (to confirm validity), and prepares the validator to vote and to potentially produce the next block when its turn comes. Just like the TPU, the TVU is broken into stages:

Figure: The Transaction Validation Unit (TVU) workflow inside a Solana validator. Shreds arriving from upstream validators (or directly from the leader) enter the Shred Fetch stage, then pass through signature verification. In the Retransmit stage, the validator forwards shreds to its downstream peers per the Turbine protocol. In the Replay stage, the validator reconstructs and replays transactions to update its state (the Bank/Accounts DB) exactly as the leader did, and also generates votes. If this validator is the next leader, the Replay stage will signal the system to start the TPU for the new slot.

1. Shred Fetch Stage: As the leader’s broadcast stage is emitting shreds, each validator’s TVU begins with a Shred Fetch Stage listening for those packets. Peers send and receive shreds via UDP (and QUIC) over the Turbine protocol (discussed below). The incoming data could be from the leader or intermediate nodes. The Shred Fetch stage simply collects all shreds, categorizes them by the originating slot and shard (shred index), and queues them up for verification. Since multiple slots could be propagating in the network (e.g., if a fork or a delayed block is arriving), validators can fetch shreds for different slots concurrently, but they prioritize the shreds for the most recent slots they expect (following the leader schedule).

2. Shred Verify Stage: The next step is verifying the integrity and authenticity of the shreds. In the Shred Verify (Leader Signature) Stage, the validator checks that each shred is valid and genuinely signed by the leader of the slot. Recall that each batch of shreds carries a Merkle root signature from the leader (and coding shreds include erasure coding info). The validator performs sanity checks: correct shred index ordering, no corrupt data, and critically, that the leader’s signature on the shred batch is valid. This proves the shred came from the legitimate leader (or at least someone who can sign on its behalf). If any shred fails verification, it’s discarded. This stage ensures that by the time shreds move on, they are authentic pieces of the block.

3. Retransmit Stage: Solana’s data propagation is cooperative – each validator that receives shreds will forward them to other validators as needed (unless it’s the very bottom of the tree). In the Retransmit Stage, the validator plays its part in the Turbine protocol by sending shreds to a specific subset of peers (its children in the tree). Based on the network topology, each node knows which peers should receive copies of each shred (determined by layer assignments and the shred’s index). The validator’s TVU takes newly verified shreds and immediately transmits them onward. This way, even if not all validators are directly connected, the block data quickly fans out through the network. We’ll detail Turbine’s structure in the next section, but from the TVU perspective, retransmission is just a quick forwarding step. Note that if a validator is toward the bottom of the Turbine tree, it might have no downstream peers for a given shred, in which case it doesn’t need a retransmit stage for those shreds.

By the time the shred fetch/verify/retransmit stages are done, the validator will have (hopefully) gathered all the data shreds for the slot’s block. Thanks to erasure coding, it doesn’t need 100% of them to reconstruct – as long as it has a complete set of data shreds or enough coding shreds to recover missing ones, it can rebuild the block. The collection of shreds is assembled in memory into the original sequence of entries and transactions. Now the validator needs to validate that block’s contents.

4. Replay Stage (Block Validation): The final and most crucial stage of the TVU is the Replay Stage. This is where the validator takes the transactions from the shreds and replays them against its own state, effectively performing the same computations the leader did. The goal is to end up with the same result (same state changes) and confirm that the block is valid (no illegal transactions, no divergent outcome). The Replay stage uses the same Bank model: the validator has a Bank for the parent block state; it creates a new Bank for this incoming block (child slot) and then executes all the transactions in order. Because the leader already determined an order and batched them into entries, the validator just follows that. It executes the transactions (using the SVM runtime) and updates its Bank, verifying that all signature checks, account locks, etc. match up. If the leader double-spent or did something inconsistent, the replay would detect it (the transactions wouldn’t apply cleanly). In practice, honest leaders won’t err here; replay should exactly mirror what the leader’s TPU did, since the transactions and order are identical.

During replay, the validator also checks for votes in the block (vote transactions from various validators) and keeps track of which votes it sees. It may also incorporate its own vote at the end (we’ll cover voting shortly). The Replay stage is single-threaded in current implementations – it replays transactions sequentially in the exact order of the ledger (parallel execution by the leader is fine because the ordering of commits is fixed into entries). This makes sure that the validator’s result is bit-for-bit the same ledger state outcome.

A lot happens in the Replay stage besides just executing transactions: this is the point where the validator determines if it needs to take any consensus actions. For example, if this block extends the fork the validator was voting for, it will vote for this new block. The validator’s consensus algorithm (Tower BFT) runs during or after replay to decide on votes. Additionally, if the validator was the next leader, the Replay stage would signal that it’s time to transition to leader mode. In Solana’s implementation, once a validator finishes replaying the latest slot and sees that according to the schedule it’s the next leader, it will synchronize its PoH to the latest hash and start its own TPU for the new slot. Essentially, the Replay stage is the hinge between validator mode (TVU) and leader mode (TPU) – when a validator’s turn comes, replay hands control to the TPU to begin block production.

After replay, the validator will have updated its Accounts DB (Bank state) with the new block, stored the shreds in its Blockstore (on-disk ledger storage), and generated a vote transaction for this block if it chooses to (which it will send out in a future slot). The new block is now part of the validator’s working chain.

To summarize the TVU: it ingests shreds, verifies them, redistributes them, then rebuilds and verifies the block by executing transactions, finally updating local state. If everything checks out, the network has effectively agreed that the leader’s block is valid. At that point, the only step left is formalizing consensus via voting.

Shreds and Turbine: Propagating Blocks Fast

Solana achieves incredible network throughput in part by how it propagates block data. Instead of sending whole blocks monolithically, Solana breaks blocks into smaller pieces called shreds, and uses an optimized protocol called Turbine to spread these shreds across the network. This design ensures that even at tens of thousands of transactions per second, block data distribution doesn’t become a bottleneck.

What are Shreds? A shred is a fixed-size piece of block data, optimized to fit in a standard UDP packet (around 1,200 bytes, up to MTU ~1280 bytes). As the leader produces entries (batches of transactions) in the block, the data is serialized and cut into many shreds. There are two kinds of shreds: data shreds, which contain the actual transaction data and state bits, and coding shreds, which contain Reed-Solomon erasure codes that provide redundancy. Solana’s default configuration groups shreds into batches with a forward error correction rate of 32:32 (data:coding) – i.e., for every 32 data shreds, 32 coding shreds are generated. This means the leader actually sends 64 shreds, but any 32 of them are sufficient to reconstruct the original 32 data shreds (coding shreds can recover up to 50% packet loss). In effect, as long as at least half of the shreds in each batch arrive, validators can recombine them to get the full block. This high redundancy is tailored for the realities of UDP traffic, where packet loss can occur. It significantly improves the chances that all validators get the block data without needing retransmission.

Shreds are sequentially numbered (index within the slot) and also cryptographically linked. The leader computes a Merkle tree over each batch of 64 shreds and signs the root hash. This signature is included in a special shred, allowing validators to verify integrity – if someone altered a shred or tried to inject a fake one, the Merkle proof would fail and the leader’s signature wouldn’t match. Each batch’s Merkle root is also linked to the previous batch, chaining them. These measures ensure shred authenticity and order: validators can trust that a given shred came from the legitimate leader and is in the correct sequence of the block. With shreds prepared, the next challenge is how to get them to thousands of validators rapidly.

Turbine Protocol: Turbine is Solana’s answer to efficient block broadcast. It’s inspired by gossip protocols and BitTorrent-like spreading, but structured to minimize the network load on any single node. The idea is to organize validators into a layered tree topology. When a leader wants to send out shreds, it doesn’t try to send each shred to all N validators (which would be N copies and overwhelming). Instead, the leader sends each shred to a small subset of validators, who then forward it to others, and so on, in a multi-hop fan-out tree.

The Turbine tree is constructed by dividing validators into layers (groups). The first layer (layer 1) might contain, say, 200 validators for a network of thousands, but Solana often uses a fanout of 8 or 16 (the maximum nodes each node will send to). For illustration, assume a simple fanout = 3:

• The leader first sends all shreds to a designated root node (layer 0, just 1 node). This root is actually one of the validators, chosen for that shred using a deterministic method (often the first validator in a stake-weighted shuffled list). The root acts as the initial relay.
• The root node then forwards the shreds to, say, 3 validators in the next layer (layer 1). Those 3 each forward to 3 more in layer 2, resulting in 9 nodes getting the data. Those 9 forward to 3 each in layer 3 (if the network were bigger), and so on.

This process continues until all validators have the shreds (the tree depth depends on the total network size and fanout). Each node only sends out at most fanout copies of each shred, regardless of the total network size. So if fanout = 3, even if there are 1000 validators, an individual node never has to send more than 3 copies of the data. This is crucial for scalability: the leader (and every node) has an O(fanout) outgoing bandwidth requirement, instead of O(N). Turbine dramatically reduces the leader’s network load by distributing the work of block propagation.

Turbine also incorporates stake-weighting in tree construction. The validator list is shuffled with bias to stake, so higher-staked nodes tend to appear higher in the tree (closer to the root). This is beneficial because those nodes are more likely to be online and have good connectivity, and also because getting data to them quickly means the nodes controlling more stake (hence votes) receive the block sooner, aiding fast consensus. Additionally, the root node is rotated for each shred or batch based on the shred index. This means responsibility is spread and it’s harder for any single node to constantly be a bottleneck or target.

An example Turbine propagation tree (fanout = 3) for a cluster of 15 validators. The leader (L, top) sends shreds to a chosen root (node 0). Node 0 forwards to 3 nodes (layer 1: nodes 1,2,3). Each layer1 node forwards to its 3 children in layer 2 (colored arrows for each parent’s group). In this schematic, node 1’s children are 4,5,6; node 2’s are 7,8,9; node 3’s are 10,11,12. One extra node 13 receives data via node 4 in layer3 (since 15 doesn’t fill layer2 completely). In Turbine, each validator only transmits to a few others, significantly reducing bandwidth per node.

As shreds are propagated, packet loss can still happen at any given hop. That’s where the coding shreds come into play – even if some percentage of shreds are lost, the data can be recovered. Solana’s protocol also has a Repair Service: if a validator notices it’s missing shreds (e.g., can’t complete a block because some indexes are missing), it will request those specifically from peers (out of band). However, Turbine and FEC together are designed to make such repair requests rare in normal operation by keeping distribution robust. The network also continuously measures performance; for example, if packet loss is consistently high, the cluster could adjust FEC rates (trade more redundancy for reliability).

From the moment the leader starts broadcasting, to the moment all validators have the full block, only a few hundred milliseconds have passed. Turbine’s multi-layer gossip achieves this propagation extremely fast – much like how rumors spread in a social network, but engineered for reliability. Once validators have the shreds, their TVUs, as described, assemble and replay the block.

In summary, shreds break the block into bite-sized, redundant chunks, and Turbine orchestrates a massively parallel delivery of those chunks. This combination is a cornerstone of Solana’s scalability, ensuring that even as block sizes and validator counts grow, block data can get everywhere in the network quickly without drowning any single node in traffic.

Forks, Finality, and Blockstore (Fork Management via Voting)

Solana’s pursuit of speed means it does not wait for global agreement on each block before moving to the next. Blocks are produced optimistically, which inevitably leads to temporary forks in the ledger. In this section, we’ll see how Solana handles forks and achieves eventual finality through validator voting and a custom consensus algorithm (Tower BFT). We’ll also touch on the role of the Blockstore in managing forks and storing ledger data.

Why Forks Happen: In Solana, the network could be working on different branches of the ledger if something goes awry with timing. For example, if a leader fails to transmit a block, the next leader might build on the last block it did receive, effectively skipping the missing slot. Or, two leaders in a row might build on different previous blocks (perhaps due to network delays) resulting in divergent chains. Because the network doesn’t halt block production to reconcile, it’s possible to have forks where block A and block B both claim to follow the same parent block. This is expected behavior, and it’s the job of consensus voting to resolve it.

However, note that within a single slot, only one block is valid – the one signed by the designated leader. Validators will reject any block for slot X that isn’t from the scheduled leader X. So you will not see two different blocks both legitimately at slot 100 (if a leader tries equivocating and producing two versions, that’s slashable). Forks in Solana are more like: one chain might lack a block 99 (skipped because leader 99 was down) and goes from 98 → 100, whereas another chain got the 99 block and goes 98 → 99 → 100 → etc. These “skip forks” can occur at slot boundaries when leaders change. The architecture inherently limits fork possibilities to this kind of pattern (there’s no scenario of two different valid blocks at the same slot height except via malicious duplication, which is handled by slashing).

Voting and Tower BFT: To converge on one canonical chain, Solana uses a Proof-of-Stake consensus with a mechanism called Tower BFT. Validators participate by voting on blocks that they consider to be part of the best chain. A vote in Solana is itself a special transaction that the validator’s node signs (using its voting key) and sends into the network (usually to be included in the next block by a leader). A vote essentially says “I affirm that up to block X (at slot Y) is valid and should be the chain.” Votes serve two purposes: (1) signal that the validator has verified the block and all prior blocks in that chain, and (2) lock the validator to prefer that chain, helping the network come to agreement.

Tower BFT is an adaptation of the classical Byzantine Fault Tolerance (BFT) consensus, fine-tuned to exploit the PoH clock. In Tower BFT, when a validator votes on a block, it cannot quickly revoke that vote; instead, it must wait some number of slots (a lockout period) before it could vote on an alternative chain if one appears. Each time a validator votes on the same chain consecutively, it increases its lockout exponentially (like doubling the period). If a validator keeps voting on a fork, its commitment to that fork grows, and switching to a different fork would mean forfeiting all those votes (which could include slashing risks or loss of reward). This mechanism incentivizes validators to stick with the majority fork and not frivolously jump to another chain unless absolutely necessary (i.e., unless their chain is clearly not going to be finalized).

As votes accumulate, the network can measure the weight (total stake of voting validators) behind each fork. When one fork has >2/3 of the stake’s votes at a certain sequence of slots, it becomes the canonical chain and can be finalized. In Solana, finality is often discussed in terms of supermajority confidence – for example, after a block has been voted on by 2/3 of stake with sufficient lockout such that a conflicting fork is mathematically impossible (unless >1/3 of validators are malicious, breaking safety assumptions), that block is finalized (or “confirmed” in Solana’s terminology). In normal conditions, forks are short-lived: honest validators will all vote on the first chain they see, which is usually the one the majority also sees first thanks to fast Turbine propagation. So typically the “heaviest” (most voted) fork grows quickly and any alternative fork (like one missing a block) gets pruned away as it fails to gather votes.

Blockstore and Fork Management: Each validator stores all received shreds and blocks in a local blockstore (a persistent database on disk). The blockstore holds the ledger, including any forks that haven’t been finalized. Think of blockstore as a local copy of the blockchain that might have a few branches at the tip. The validator’s consensus algorithm (Tower) will nominate one branch as the working one (the fork it’s voting on), but it keeps the other branch’s data just in case it needs to switch (say the other fork becomes heavier). As votes come in and forks are resolved, the validator will purge the stale fork data from memory and mark those blocks as dead in blockstore (or remove them during ledger cleanup). The blockstore cleanup service in Solana also prunes old finalized blocks to save disk space over time, since after finality they are not needed for fork switching.

In practice, how finality manifests is: after a few slots (usually within 1–2 seconds), you’ll have a block that has achieved enough votes such that it’s finalized. Validators will record a “root” – a pointer to the latest finalized block – and any forks that diverged before that root are discarded. Client RPCs will report confirmations: 1 confirmation, 2 confirmations, … up to “finalized”. Solana’s typical confirmation times (when a block is optimistically confirmed by supermajority) are often around 0.5s – 1s, and finality (which might require an additional round or two of votes) often within 1-2 seconds, though this can vary.

Slashing for Misbehavior: Solana’s consensus has rules to discourage validators from acting against the protocol. If a leader produces two different blocks for the same slot (duplication), or a validator votes for two forks that can’t both finalize, these are slashable offenses. Solana’s protocol includes detection of such cases (for example, nodes gossip proof of double votes). Slashed validators lose a portion of their staked SOL, providing a strong economic deterrent to misbehavior. The fork selection (Tower BFT) design, by construction, avoids many equivocation scenarios by locking votes, but it’s still important for security that participants face penalties for violating the rules.

In summary, fork management in Solana relies on fast votes rather than slow block-by-block consensus rounds. Forks naturally occur due to the asynchronous, pipelined production, but they are quickly resolved as validators vote on the chain they believe is valid and stick with it. Thanks to PoH ordering and Turbine propagation, validators usually agree on the same block, so votes converge and finality is reached after a small number of slots. The blockstore ensures validators keep track of all potential forks until finality, at which point a single chain is committed to moving forward.

Alternative Approaches: Solana Native vs. Jito Block Production

Solana’s block production as described is the “native” approach implemented in the open-source validator client (originally by Solana Labs, now Agave by Anza, etc.). This approach gives the leader full control over which transactions to include and in what order, with no specific rules beyond basic validity. In fact, Solana does not mandate how a leader must order transactions within a block – the leader can technically include any transactions it wants from the ones it receives. By default, a leader might simply take transactions roughly in the order they arrive (perhaps processing higher-fee ones first), but there isn’t an elaborate in-protocol auction or mempool prioritization. This simplicity favors low latency: users submit transactions to the current leader, and that leader just immediately includes as many as possible.

However, as Solana’s ecosystem evolved, opportunities for MEV (Maximal Extractable Value) – where certain ordering of transactions can yield extra profit (e.g., arbitrage or liquidations in DeFi) – became significant. Enter Jito, an alternative Solana validator client (maintained by the Jito team) that modifies the block production process to capture this value. Jito is a fork of the Solana/Agave client that introduces an out-of-protocol blockspace auction for leaders. The idea is to create a marketplace for transaction order within a block, similar to how Flashbots works on Ethereum.

In the Jito model, when a validator is the leader, it doesn’t directly use the standard TPU to gather transactions. Instead, it advertises a Jito-Relayer service. Other nodes still send transactions to what they think is the leader’s TPU, but they’re actually hitting the relayer (which is just a proxy). The Jito relayer then holds incoming transactions for a very short time (e.g. 200ms) before handing them to the leader’s pipeline. Why the hold? Because during those milliseconds, the relayer can run a private off-chain auction: searchers and trading bots submit bundles of transactions (with attached bids, or tips) to a Jito Block Engine. These bundles might contain, say, a profitable arbitrage or liquidation transaction that is only valuable if it’s ordered in a particular way. The Block Engine selects the highest-paying bundles and constructs an optimal ordering for the block. Essentially, it’s as if Jito acts as a block builder, deciding which transactions (and in what order) maximize fees/tips for the leader. After 200ms, the winning bundle transactions are chosen and merged with the regular transactions (which might pay only the normal fees). The combined ordered list is then fed into the leader’s execution pipeline to produce the block.

From the outside, the network doesn’t see anything different – the leader still produces a valid block of transactions. But under the hood, Jito might have reordered or included certain transactions that pay extra. Jito takes a fee (e.g. 5%) of the extra tips earned via its auction, and the rest goes to the block producer. This creates a strong incentive: validators using Jito can earn higher rewards because they capture MEV that otherwise would be missed. As a result, over 80% of Solana’s stake (as of late 2024) was running the Jito client – a remarkable adoption for an alternative client. Essentially, the economics drove validators to adopt Jito for the additional income.

It’s worth noting that Jito operates out-of-protocol – Solana’s protocol itself hasn’t changed; Jito works within the rules (leaders can choose order freely) but adds an external process. This means non-Jito validators and users don’t have to do anything special; it’s mostly a change on the leader side. Another effect of Jito is it delays transaction propagation slightly (that 200ms hold), introducing a small latency increase, but presumably the MEV gains compensate validators for that. The Jito relayer also hides this from others – other nodes just think it’s the normal leader endpoint.

Comparison: The native Solana approach optimizes for minimal latency and fairness (first-come-first-serve ordering, roughly), while Jito introduces a controlled latency to optimize for profit. In native Solana, there is effectively no public mempool – transactions either get in a block or expire after a short time if not included. In Jito, one could say there is a very short-lived private mempool (the relayer buffer) and an off-chain mempool/auction (Jito Block Engine) where sophisticated traders compete. This mirrors, to some extent, Ethereum’s recent proposer/builder separation, except it’s not built into the protocol but provided by a third-party client.

Other blockchains or Solana-inspired systems might take different approaches. For instance, some might have longer mempools with priority gas auctions (like Ethereum pre-merge), or different leader election (some protocols like Aptos/Sui use consensus rounds for each block, which is slower but more uniform). Solana’s design choice is speed first, accepting temporary forks. Approaches like Sei (mentioned as a comparison) still use mempools and slower BFT rounds, which trade off latency for perhaps simpler behavior. The Firedancer client (by Jump Crypto) is another alternative implementation of the Solana validator (in C++) that aims to drastically increase throughput by optimizing the pipeline, though it largely follows the same block production logic as native Solana (with possible improvements in how parallelization is done). Firedancer is expected to further increase performance, but it’s not changing consensus or adding auctions like Jito – it’s about efficiency in processing and networking.

In summary, Solana’s native block building is a straightforward, leader-decides-all process with no built-in MEV capture, focusing on getting blocks out fast. Jito’s approach adds a smart layer to reorder transactions for maximum profit via a blockspace auction, aligning Solana with the growing trend of MEV-aware block production. The success of Jito shows that even in a protocol without a mempool, there was room to optimize transaction ordering for profit. As Solana grows, it will be interesting to see how these dynamics evolve – whether the protocol itself adopts any of these practices or continues to rely on market-driven client innovation.

Glossary of Key Terms

• Accounts DB / Bank: In-memory database of all accounts (state) on Solana. The Bank represents a snapshot of the state at a particular slot (block). When transactions are executed in the Banking stage, they read from and write to the Bank’s accounts. Once a block is finalized, the Bank’s state changes are flushed to disk (Accounts DB). Each slot has its own Bank instance derived from its parent slot’s Bank.
• Blockstore: The on-disk storage for the ledger on each node. The blockstore holds shreds and assembled blocks, including different forks. It provides random access to ledger data and is pruned as needed. Think of it as the persistent blockchain database for a validator, supporting retrieval of any past block or pending fork blocks.
• Entry: A batch of transactions that are executed together and recorded into the ledger with one PoH hash. Solana groups transactions into entries (up to 64 transactions by default) that have no conflicting account writes. Entries are the units that get hashed into the PoH sequence. Between entries, tick entries (empty) are inserted to mark passage of time.
• Epoch: A large unit of time (several hundred thousand slots) over which the leader schedule and stake distribution remain fixed. At the end of an epoch, stake-weighted leader election is performed to assign leaders to each slot in the next epoch. Rewards for staking are also distributed at epoch boundaries.
• Fork: A divergence in the ledger where two different sequences of blocks share a common ancestor but then differ. Forks happen in Solana when different validators have different views of the most recent blocks (often due to skipped slots or network latency). Consensus voting (Tower BFT) is used to choose one fork as the canonical chain and abandon the others.
• Proof of History (PoH): Solana’s verifiable delay function (VDF) that provides a global source of time and ordering. It’s a continuous SHA256 hash chain run by each validator. PoH hashes serve as timestamps (ticks) and are used to sequence entries in blocks. PoH is not a consensus mechanism by itself but is integral to Solana’s synchronized clock and leader schedule enforcement.
• Slot: The basic time interval in Solana in which one leader can produce a block. A slot is roughly 400 ms and corresponds to up to one block (though a leader might extend into a few contiguous slots). Slots are numbered sequentially forever. They are the cadence of leader rotation – each slot has an assigned leader (even if no block is produced, the slot number progresses).
• Shred: A fragment of block data, sized to fit in a network packet (~1KB). Shreds can be of type “data” (transaction data) or “coding” (erasure codes). Validators recombine shreds to reconstruct blocks. Shreds are propagated via Turbine and include integrity checks (Merkle roots and leader signatures).
• TPU (Transaction Processing Unit): The component of the validator responsible for producing blocks (the leader pipeline). It consists of stages: Fetch Stage (ingest packets), SigVerify Stage (verify signatures), Banking Stage (execute transactions in parallel, update state), PoH (timestamp entries), and Broadcast Stage (send out shreds). The TPU is only active when the validator is the leader.
• Turbine: Solana’s block propagation protocol that sends shreds through the validator network using a tree topology. It significantly reduces network load by having each validator forward shreds to a limited number of others (fanout) rather than everyone to everyone. Turbine uses layered routing, stake-weighted assignment of nodes to layers, and rotates the “root” nodes per shred.
• TVU (Transaction Validation Unit): The counterpart to the TPU, this is the pipeline that validators run to consume incoming shreds and validate blocks (the validator pipeline). It includes Shred Fetch (receive shreds), Shred Verify (check integrity), Retransmit (forward shreds to peers), and Replay (execute transactions to confirm the block and update state). The TVU is basically always running on each validator to process new blocks.
• Tower BFT: Solana’s PoH-enhanced Byzantine Fault Tolerance consensus algorithm. Tower BFT leverages the PoH clock to reduce communication and uses a voting mechanism with stacked lockouts that function like a tower – each vote increases the commitment to a fork unless supermajority votes finalize it. Tower BFT ensures convergence on one fork by penalizing switching forks too often (enforced via the lockout mechanism and slashing).
• Vote (Transaction): A special transaction by which a validator affirms a block. Votes are signed by the validator’s vote key and usually include the slot that is being voted on (and some recent slot history). Votes are processed like normal transactions (they go through the TPU of the current leader and are recorded on-chain). They carry no monetary transfer but are used by the consensus to measure fork support. Voting also earns validators rewards (for voting on the eventually finalized fork).

Special Thanks

A special thank you to the team at Helius/Turbin3 for their comprehensive Solana Executive Overview, which was an invaluable resource in writing this post.

References (Solana Documentation & Research)

• Fitzgerald, G. (Solana Labs). Solana Block Production and Architecture. – “Each slot lasts 400 milliseconds, and each leader is assigned four consecutive slots (1.6 seconds) before rotation to the next leader…” helius.dev.
• Anza (Agave Solana Client Documentation). Leader Rotation and Fork Generation. – Describes how leaders are scheduled and how forks occur at slot boundaries when leaders skip slots docs.anza.xyz docs.anza.xyz.
• Helius Dev. Solana Executive Overview (2024). – Comprehensive report explaining Solana’s transaction pipeline (TPU/TVU), PoH, Turbine, and consensus in accessible terms helius.dev helius.dev.
• Helius Dev. Turbine: Block Propagation on Solana. – “Solana uses a multi-layer block propagation mechanism called Turbine to broadcast ledger entries to all nodes… each node only has to communicate with a small number of nodes” docs.anza.xyz docs.anza.xyz.
• Solana Labs. Whitepaper: A New Architecture for a High Performance Blockchain (2018). – Introduces Proof of History to “encode trustless passage of time into a ledger” and outlines the original design of the Solana protocol solana.com.
• Jito Labs. Economic Analysis of Jito Solana Client. – Discusses how >80% of stake adopted the Jito client to capture MEV via out-of-protocol blockspace auctions, using a relayer that delays transactions by 200ms for bundle submission helius.dev helius.dev.
• Eclipse. Block-STM vs Sealevel: Parallel Execution Engines. – A comparative study on Solana’s parallel transaction processing (Sealevel) versus an alternative approach, providing insights into the Banking Stage design and performance.
• Solana Foundation. Tower BFT Consensus Specification. – Details on how voting and lockouts work to achieve finality, and how votes are incorporated as transactions on-chain docs.anza.xyz docs.anza.xyz.