Transaction Lifecycle

RISE's transaction lifecycle facilitates a streamlined process, designed to reduce latency to as low as possible. Unlike other blockchain, RISE aims to provide near-instant responses to users' transactions.

Transaction Preparation & Broadcasting

The lifecycle of a transaction starts with a user creating and signing a transaction, and submitting it to an RPC node via his frontend.

P2P Propagation

After receiving the transaction from the user, the RPC node performs some sanity check and then broadcasts this transaction to the sequencer using the P2P network.

Mempool Pre-Execution

As described in the CBP, the transaction is pre-executed as soon as it lands in the sequencer's mempool. The CBP makes use of idle time to execute transactions while other tasks are happening. This is one of the way we reduce E2E latency for transaction processing.

$\mathtt{Shred}$ Inclusion

Pending transactions (i.e, residing in the mempool) are included in a $\mathtt{Shred}$. $\mathtt{Shreds}$ partition a canonical L2 block into multiple consecutive yet separately-verifiable segments. $\mathtt{Shreds}$ allow an L2 block to be incrementally constructed, each $\mathtt{Shred}$ serves as a batch of preconfirmations for transactions it contains. And importantly, each $\mathtt{Shred}$ does not require merkleization, allowing RISE to reduce its latency to just a few miliseconds.

Pending transactions are pre-executed while sitting in the mempool, therefore, at the time of $\mathtt{Shreds}$ inclusion, we can reuse the pre-executed one from the previous step.

$\mathtt{Shred}$ Propagation & Early Updates

The sequencer broadcasts a $\mathtt{Shred}$ to other nodes via the P2P network after it is created. As soon as a node receives a new $\mathtt{Shred}$, it immediately executes transactions within this $\mathtt{Shred}$ (or apply changes provided by the $\mathtt{Shred}$) to get the latest state of the network. This enables faster state synchronization across the network and a quicker response to the user's transaction. At this point, the receipt for the transaction is available and can be returned to the user.

L2 Block Inclusion

After a predefined period of time (i.e, L2 blocktime), $\mathtt{Shreds}$ are batched together to create a canonical L2 block. At this time, merkleization is done to seal the L2 block.

L1 Block Inclusion

Periodically, L2 blocks are batch-submitted to the DA layer and the L1 for finalizing. At this state, transactions are considered safe (if no fraud challenge is triggered).