Contenu source (brut)
<p>What would you do if you had a time machine that was perpetually 10 milliseconds into the future? What trades would you make? What accounts would you monitor? <em>How much more money would you make</em>? </p><p><a href="https://www.helius.dev/laserstream" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">LaserStream</span></a> is Helius’ next-generation gRPC streaming service, which consistently outperforms other data-streaming services across all regions around the world without the burden of needing to maintain dedicated nodes. </p><p>Streaming data as fast as possible is crucial for the detection of on-chain events (e.g., swaps, liquidations, price updates) and submitting transactions that react to those events. The difference between a couple of milliseconds for RFQ desks, liquidation bots, and high-frequency trading is the difference between winning and missing an opportunity.</p><p>LaserStream’s best-in-class performance for latency-sensitive operations is largely because it builds upon low-latency <em>shreds</em>. That is, LaserStream receives propagated block data as soon as it becomes available, giving users earlier visibility into Solana state updates. With its globally distributed pipeline, automatic replay, automatic failover, and client SDKs, LaserStream is, undoubtedly, the easiest and fastest way to stream real-time data on Solana. These advantages make LaserStream’s integration crucial for exchanges, trading apps, MEV bots, and anyone serious about latency-sensitive operations.</p><p>This article explores shreds, the smallest units of blocks on Solana, why they matter, and how LaserStream uses them to power the fastest data streaming solution possible. The article is designed so that each section can be read in isolation. However, readers new to shreds and streaming data on Solana would benefit from reading each section sequentially.</p><h2>What are shreds?</h2><p>Shreds are the foundational unit that enables Solana’s high-performance data propagation, offering early access to on-chain state changes.</p><p>Solana is designed for maximum speed and throughput. To achieve this, it cannot transmit blocks as a single, large unit across the network. Instead, blocks are divided into smaller packets known as <em>shreds</em>—the atomic units of data propagation in Solana. </p><p>These shreds represent portions of transaction data before they are assembled into a block. Each shred is approximately 1.2 KB in size, optimized to fit within the Maximum Transmission Unit (MTU) of standard network packets to ensure lightning-fast delivery without fragmentation. </p><p>There are two types of shreds:</p><h3>Data Shreds</h3><p>Data shreds encapsulate the core transaction data from a block, divided into fixed-size pieces. They include serialized entry batches, which are groups of transactions prefixed by a count for efficient processing.</p><h3>Coding Shreds</h3><p>Coding shreds provide redundancy using Reed-Solomon erasure coding, a forward error correction technique that generates parity data. This allows for missing or corrupted shreds to be reconstructed. Coding shreds are organized into Forward Error Correction (FEC) sets alongside data shreds, typically in balanced ratios (e.g., 32 data to 32 coding shreds) to tolerate up to 50% of packet loss. Leaders can adjust this ratio based on network conditions to maintain high reliability.</p><h3>How are shreds propagated on Solana?</h3><p>The process starts with the leader (i.e., the validator currently responsible for producing blocks) batching and serializing transactions into entries. These entries are then divided, or <em>shredded</em>, into smaller segments referred to as shreds. All shreds are signed by the leader using either a legacy system (i.e., signing each shred individually) or a Merkle-based scheme (i.e., signing the Merkle root of the entire FEC set) as defined by <a href="https://github.com/solana-foundation/specs/blob/main/p2p/shred.md" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">Solana’s shred specification</span></a>. This ensures authenticity and data integrity. </p><img src="/_next/image?url=/api/media/file/solana-shred-propagation-diagram.jpg&w=3840&q=90" alt="A simplified diagram of how Solana shreds are propagated to nodes through Turbine" /><p>Shreds are sent to other validators using <a href="https://www.helius.dev/blog/turbine-block-propagation-on-solana"><span style="text-decoration: underline">Turbine</span></a>, Solana’s multi-layer, fanout-based propagation system. Under Turbine, the leader transmits shreds to a root node, which distributes them to subsequent layers of validators in a tree-like structure. Each layer forwards to the next with a fanout of 200 nodes per layer, typically spanning 2 to 3 hops depending on the number of active validators. This tree structure minimizes bandwidth while achieving the network-wide distribution of transactions in milliseconds.</p><p>Stake-weighted shuffling prioritizes delivery to higher-staked validators. Turbine first sorts validators by the amount of stake they hold (i.e., their stake weight). Validators with higher stake are placed earlier in this list, and after a deterministic shuffle, they tend to end up in earlier layers of the tree closer to the leader. Thus, fewer hops means lower latency. So, <em>validators with more stake receive shreds sooner</em>. </p><p><strong>Note:</strong> Turbine will be replaced by Rotor in the future once <a href="https://www.helius.dev/blog/alpenglow"><span style="text-decoration: underline">Alpenglow</span></a> is implemented. Even with these changes, a validator’s stake will still influence which peers validators will broadcast to.</p><h3>How are shreds reassembled into blocks?</h3><p>Once received by a validator, shreds are reassembled by first verifying their signatures for authenticity and using Reed-Solomon erasure coding to reconstruct any missing or corrupted data shreds from the available coding shreds in the FEC set. </p><p>The reconstructed data shreds are then deshredded. That is, their payloads are concatenated in order using shred indices to reform serialized entry batches. </p><p>These batches are then deserialized into individual transactions and entries, which can be assembled into a complete block.</p><h2>Why do shreds matter? </h2><p><em>Shreds matter because they compress the reaction window in a network where timing is paramount</em>. </p><p>Shreds are crucial for unlocking Solana’s high-performance advantages, particularly in latency-sensitive applications such as high-frequency trading, request-for-quote (RFQ) desks, liquidation engines, and oracle updates. </p><p>Shreds provide the earliest visibility into emerging on-chain events, unlike most other blockchains, where applications must wait until complete block production and confirmation, which can add delays of hundreds of milliseconds to several seconds. </p><p>Raw shreds can be awkward to work with since the receiver must verify their authenticity, reconstruct any missing data shreds, deshred and deserialize them into transactions and entries, and, finally, parse them for actionable events like swaps or account changes.</p><p>However, this “early peek” into pending transactions and account updates offers an unparalleled advantage, directly translating into higher success ratios in competitive scenarios.</p><p>For example, a liquidation bot monitoring collateral ratios could detect and act on a vulnerable position using shreds well before their competitors using slower methods like WebSockets, thus winning the liquidation. </p><p>Similarly, arbitrage traders identifying market inefficiencies and low-latency DEX aggregators <a href="https://www.helius.dev/blog/dflow" rel="noopener noreferrer" target="_blank"><span style="text-decoration: underline">quoting prices</span></a> can benefit from this latency edge, as milliseconds determine profitabil
