RISE Book

Appearance

Shreds ​

Shreds enable a user experience that feels like the modern web, but on a blockchain. They generate transaction preconfirmations within single-digit milliseconds, reacting to demand in real time. Unlike traditional blockchains, which wait for discrete blocks to process, Shreds are continuous and interrupt-driven.

Latency with and without Latency with and without

When posting summaries to L1 and DA (i.e, posting transactions to DA and proposing new stateRoots), a rollup typically batches multiple L2 blocks together to reduce costs. As a result, we observe that merkleization is not required for every L2 block. This is the idea of incremental block building. In short, we break L2 blocks (12-second long) into Shreds (sub-second long), essentially mini-blocks without a state root. Constructing and validating these Shreds is much faster due to the omission of state root merkelization. Therefore, broadcasting them enables rapid transaction and state confirmations. This much-improved latency doesn't sacrifice security, as new L2 blocks can only provide unsafe confirmations anyway.

flow

Shreds ​

Shreds partition an L2 block into multiple consecutive, connecting segments. Each Shred for an L2 block is identified via its sequencer number. In other words, block_num and seq_num together can always identify a Shred. The sequence number is increasing for each Shred and is reset when a new L2 block is constructed.

A Shred contains a ChangeSetRoot that commits to all state changes made within the Shred. Recall that during execution, the sequencer uses the flatDB to access data and records all changes to a ChangeSet. The number of entries in a ChangeSet is relatively small compared to the state size because it only holds the changes, therefore, the data is often sparse and can fit in memory. As a result, constructing the ChangeSetRoot can be efficiently done.

Block Propagation ​

Broadcasting is done per Shred instead of waiting for the full L2 block. Shreds with invalid signatures are discarded. As peer nodes receive valid Shreds, they optimistically construct a local block and provide preconfirmations to users.

Shreds PropagationShreds Propagation

The sequencer might also broadcast the ChangeSet within a Shred to its peers. This ChangeSet can be verified against the ChangeSetRoot attached to the Shred’s header. Nodes trusting the sequencer can apply the ChangeSet immediately to their local state without re-executing transactions.

Batch Preconfirmations ​

Preconfirmations are issued per batch via Shreds instead of per individual transaction. Users can receive preconfirmations without waiting for the entire L2 block to be completed. Note that the Shred blocktime can be configured to balance multiple factors, including preconfirmation latency and network bandwidth.

Efficient Merkleization ​

Merkleization's performance is influenced by both the size of state data and the number of changes (i.e., the size of the ChangeSet). Additionally, batch updates are more efficient than sequential updates.

Merkleization for an L2 block only happens after the last Shred is generated. Accumulating changes over multiple Shreds reduces the number of final keys that need updating, thanks to transaction overlap. The same data is likely to be accessed multiple times across blocks, especially with popular dApps like Uniswap.

Other Resources ​