Based Preconfirmations

WARNING

The content in this page is subject to change as many components are still in the active research phase.

On a simple based rollup, transaction confirmation time depends on the confirmation time on the L1 (i.e, 12 seconds). This is not wanted in a rollup as users are familiar with fast confirmations given by centralized sequencers. Based preconfirmations are introduced to address this UX problem of a vanilla based rollup faced by users.

A preconfirmation (or preconf) is a promise by the current proposer (or whomever he delegates, so-called a preconfer) that certain event will happen at the specific timestamp in the future. The fundamental difference of a based preconfirmation protocol from the centralized approach is the shift from a trust-based system to a more trustless and cryptographically enforced system.

RISE is implementing based preconfirmations to reduce transaction latency to as low as a few miliseconds.

Architecture

Registration

A registry contract is deployed for any L1 validators to sign up to become a sequencer for the RISE rollup. Upon registration, L1 validators also need to stake some collaterals. This collateral requirement ensures that L1 validators are economically discouraged to misbehave as this will result in their collaterals being slashed.

Slashing

The L1 proposer is expected to honor all promises it makes. Failure in honoring any promises will lead to one of the following slashing events.

• Liveness faults. When a preconfirmed transactions were not included on-chain and the proposer's slot was missed.
• Safety faults. When a preconfirmed transactions were not included on-chain and the proposer's slot was not missed.

Gateway

Issuing preconfs adds many requirements to L1 proposers. To mitigate this sophistication, in our design, we assume the proposer delegates sequencing right to a sophisticated entity called a gateway. The delegation is somewhat similar to how most proposers today delegate their block building tasks to builders. Slashing is imposed to the L1 proposer for liveness faults and to the delegated gateway (if any) for safety faults.

The delegation of preconf rights can occur through on-chain or off-chain mechanisms. We consider the off-chain approach (i.e, via the existing PBS pipeline) in this design.

Batch Preconfs

Preconfirmations are issued in batches using $\mathtt{Shreds}$. Batch preconfirmations inherently align with the operational efficiency of rollups, which are designed to process transactions in bulk. By issuing a single preconfirmation for multiple transactions, rollups can potentially achieve lower overhead per transaction compared to providing individual preconfirmations for each user. $\mathtt{Shreds}$ are currently variable in time to balance between throughput and latency.

Preconf Propagation

Users can submit transactions to any node, which will eventually be forwarded to the current gateway. The gateway orders these transactions into a $\mathtt{Shred}$, executes this $\mathtt{Shred}$ and then broadcasts the resulting $\mathtt{Shred}$ through the P2P network. $\mathtt{Shreds}$ enable early updates for nodes, allowing faster state synchronization across the network and effectively faster receipts to users' transactions.

If any $\mathtt{Shred}$ is missing, a node can request it from other nodes in the P2P network. It is worth noting that empty $\mathtt{Shred}$ might not be broadcast to save bandwidth. At the very end of an L2 block, the current leader broadcasts a block seal message to signify the construction of a new L2 block based on previously published $\mathtt{Shreds}$.

Fallback Sequencer

To ensure liveness and availability, a default fallback sequencer (e.g., operated by RISE) is chosen when the current sequencer is not available or not existing in the current slot. This can happen in many scenarios such as:

• At the beginning, there are only a few L1 validators opting-in to become a sequencer. This creates a big gap between two consecutive preconf slots and often referred to as the cold-start problem.
• The current gateway experiences a liveness failure, preventing the rollup from progressing.

Rollout Path

Achieving fully permissionless, based sequencing is the ultimate goal that we want for RISE's decentralization. To this end, we perform incremental rollout to not only test the software without potential validator impacts, but also to identify the optimal configurations, providing the best balance of validator and user experience.

Centralized Sequencer

In the first phase, a single centralized sequencer is used to provide preconfirmations. At this phase, the sequencer is still fully trusted and no slashing is imposed. Preconfs at this phase are optimistic and have no guarantee (other than the sequencer being honest) to be honored. This phase is the current status quo of RISE today.

$\mathtt{Shreds}$ Slashing

At this phase, slashing rules are implemented for $\mathtt{Shreds}$ to discourage any misbehavior from the sequencer. Any such misbehavior regarding $\mathtt{Shreds}$ will result in the sequencer being slashed. Preconfs at this phase have economic guarantees that they will be fulfilled.

Gateway Creation

A gateway is progressively created as a separate component and related functionalities are migrated away from the sequencer to the gateway. Connections between the gateway and the sequencer are fully trusted and any misbehavior of the gateway will lead to the sequencer being slashed.

Furthermore, a registry contract can be deployed to initially allow other whitelisted validators/gateways to join.

Permissionless Participation

Anyone can register to become a gateway and L1 validators are able to delegate their sequencing rights to the gateway of their favor. At this stage, RISE is fully permissionless and has the highest security level.

Other Resources

• The original post on based preconfirmations
• Ethereum sequencing calls
• Fabric's education series