————————————————————
In the world of blockchain, propagating block data is like delivering packages; whoever can deliver it faster is better!
🔹Solana's 'Turbine'
🔹Monad's 'RaptorCast'
🔹Celestia's 'Vacuum'
Which block propagates the fastest?
📍First, let's simply understand how they propagate data?
These three networks all split large blocks into smaller fragments and use 'erasure coding' technology. But their delivery methods differ.
Solana and Monad: using a 'push' mode. Block producers push data to validators, just like a courier directly delivers packages to your doorstep.
Celestia's Vacuum!: using a 'pull' mode. Validators ask, 'Hey, what data do I lack? Send it to me!' It's somewhat like ordering takeout, directly delivering the demand to the door.
👉🏻 Where's the difference?
Solana and Monad pursue 'fast confirmation': high-stake validators receive data first, quickly validate, and block confirmation speeds soar.
Celestia's Vacuum! pursues 'throughput': the leader only needs to upload approximately 1 times the block data to allow the network to handle more transactions, achieving high efficiency.
Data propagation consists of two steps.
Each network has two stages for data propagation:
——Preparation phase: preparing materials before block production.
——Distribution phase: once the block is ready, it is distributed to everyone.
Next, let's take a look at how these three operate!
1️⃣Solana's approach
🔻Solana's preparation phase:
Gulfstream + swQOS enables high-performance transaction distribution. Unlike the global mempool of systems like Ethereum, each leader node in Solana maintains a local mempool.
This localized design eliminates the congestion overhead caused by multi-hop gossip, significantly improving transaction throughput. DApps submit transactions to RPC nodes, which then single-hop forward the transactions to the upcoming leader via Gulfstream. Since the leader scheduling is known in advance, any validator can accurately route the transactions to the next round's leader.
To prevent spamming with junk transactions, Solana uses 'swQOS': transactions from high-stake validators are prioritized, fair and efficient.
🔻Solana's distribution phase:
Turbine's mechanism is to not send the entire block after it's ready, but to cut it into small fragments (each about 1280 bytes) and send them to other validators.
It's like a production line, where validators collect fragments while validating and voting, ensuring efficiency.
💡How does Turbine work?
Turbine distributes to the entire network through a 'tree-like distribution' structure, similar to tiered delivery of express packages.
Simply put, the leader first sends shreds to the 'root nodes'.
Root nodes group by stake's 'equity level', prioritizing wealthy big players for fragment distribution.
Big players then forward to the next layer's little brothers.
Currently, the first layer of Vacuum has 200 validators, so most validators can obtain complete block data with just 2-3 hops.
Turbine also uses erasure coding technology; even if some shreds are lost, as long as a certain number are obtained, the entire data can be recovered. This mechanism supports pipelined validation and voting, improving the overall network response speed while the leader produces blocks.
2️⃣Monad's approach
🔻Monad's preparation phase:
Monad is quite similar to Solana, but Monad does not rely on a global mempool; instead, each validator maintains a local mempool and directs transactions to the local storage pool of the next three leader nodes.
At the start of each epoch, the leader order is determined once, and RPC nodes can accurately route transactions based on this plan. This design ensures high bandwidth utilization while also increasing the speed at which transactions are included in blocks.
🔻Monad's distribution phase:
Monad uses the RaptorCast mechanism, which is somewhat similar to SOL's Turbine but has a more 'flattened' structure, requiring only 2 hops to complete data distribution, using an NxN broadcasting mechanism (N being the total number of validators).
First, the leader erases the block coding into several small fragments and distributes these fragments to all validators at once, with each node receiving different amounts of data blocks based on its stake weight; then, all validators broadcast the received fragments to all other validators.
This mechanism ensures that 99% of nodes in the network can complete the data retrieval of the entire block within 2 hops, with the maximum propagation delay not exceeding twice the longest single hop, significantly shortening the block propagation cycle.
3️⃣Celestia's approach
Celestia's Vacuum takes a different route, aiming not for the fastest confirmation but for maximum throughput (handling more transactions).
Solana and Monad push data, while Vacuum! pulls data, allowing validators to find the data they need themselves.
It's like when you're hungry, you actively go to the fridge to find something to eat, instead of waiting for someone to feed you.
🔻Celestia's preparation phase:
💡Step One: Announcement (VAC)
Before block production, validators synchronize the transaction pool with something called 'VAC' (Validator Availability Certificate):
VAC is like a sticky note that says: 'I have transaction Y here, guaranteed to deliver it to you before block height H!'
Validators create VACs for high-priority transactions to share with others, rather than sending the entire transaction directly.
This avoids bandwidth waste caused by full transaction propagation, only propagating commitment information for high-priority transactions.
💡Step Two: Data Retrieval
When a node detects that it does not yet hold a VAC, it will decide whether to initiate a WantBlob request based on criteria such as capacity and priority, actively pulling data. This on-demand retrieval mechanism is linked with the VAC's gossip, allowing data to circulate in the network only once.
🔻Celestia's distribution phase:
As the transaction pool has been synchronized in advance, when the leader begins to produce blocks, most of the data propagation is already completed.
The leader only needs to broadcast a 'mini-block' (compact block), which contains commitments for transactions in the block, bitmap, and metadata mapping information.
After receiving the 'mini-block', the validator checks and requests any missing data (called 'parity data') to complete the block.
Ideally, the validator already has all the data, and the leader only needs to send a mini-block to finish the job.
If some low-priority transactions were not picked up by validators before, they immediately send a 'WantBlob' request to retrieve data from other nodes.
💡Fast data recovery:
Most nodes obtain data in advance through VAC, so they only need to verify integrity and fill in necessary data. If some low-priority transactions are not yet synchronized, nodes can immediately request and quickly complete data recovery.
Vacuum! achieves nearly theoretical maximum throughput data synchronization efficiency, with block size close to total data transfer volume at a ratio of 1:1. Although it adds an extra hop delay, the design still maintains high efficiency due to the pipelined execution of requests and responses, especially suitable for large-scale network environments with wide geographical distribution.
In a globally distributed network, hop count does not necessarily determine speed. Sometimes a detour can be faster (like avoiding a traffic jam on the highway). Vacuum! dynamically finds the fastest, least congested path, flexibly.
Summary:
🔹Solana: Turbine, tree-like distribution, pursuing fast confirmation, suitable for high-frequency trading.
🔹Monad: RaptorCast, achieving speed and efficiency with two hops.
🔹Celestia: Vacuum!, a pull mode, king of throughput, suitable for large data volume scenarios.
These three have their pros and cons. As for who is the strongest? It depends on what you need more: speed? Throughput? Or a balance of both.
➡️ Original article translation link: https://x.com/ShivanshuMadan/status/1909637621896430020?t=q1yqoBiEtdZJRXpQD_tDRg&s=19
