Based Rollups

Sequencers are the most powerful role in a rollup design. Most of rollups on Ethereum today have centralized sequencers. These sequencers are ofter operated by the rollups' team or reputable organizations. Centralized sequencers offer high performance, high throughput, low latency, and fast preconfirmations to users. However, they serve as a single point-of-failure, the rollups will stop progressing if their sequencers are offline. Furthermore, operating in a centralized manner means that these sequencers might have to comply with governments' rules, sanctions, etc,. Therefore, they might compulsorily censor users' transactions.

RISE is a based rollup, differentiating itself from other rollups by having its sequencing driven by the base L1. A rollup is said to be based-sequenced, when its sequencing is driven by the base L1. RISE uses the L1 as sequencers, eliminating the need for additional security assumptions and ensuring the same security strength for all components involved.

Here is the simplified workflow of a based rollup.

• Users submit transactions directly to the current L1 proposer.
• The proposer does some check and orders transactions into a block.
  • The proposer also issues a soft confirmation to the user, as a receipt.
• The proposer then proposes a new block containing ordered transactions to L1. He also posts the related data to DA (in the figure above, L1 is used as the DA layer).
• Rollup execution node listens to new blocks on L1 and then executes them.

Based sequencing is the decentralisation strategy for RISE. With the based approach, we offer:

• Credible neutrality. Credible neutrality is a superpower that grows the network effect of Ethereum.
• Shared sequencing & Atomic interoperability. Most rollups today are silo-ed, which means that each rollup has a unique sequencing strategy and execution environment. As a result, communications between rollups must be done in an asynchronous way, in which rollup A must talk to L1 first, and then L1 will relay the message to rollup B later (Note that the process might not be atomic, i.e, the message from A -> L1 succeeded but the message L1 -> B failed). RISE is sequenced by L1 validators, who can also sequence other rollups at the same time. Therefore, it is possible that users on RISE can talk to contracts on a different rollup in an atomic way, making synchronous composability possible.
• Decentralisation. RISE inherits the decentralisation of the L1 and naturally reuses L1 searcher-builder-proposer infrastructure. L1 searchers and block builders are incentivised to extract rollup MEV by including rollup blocks within their L1 bundles and L1 blocks. This then incentivises L1 proposers to include rollup blocks on the L1.
• Censorship resistance & Liveness guarantees. RISE enjoys the same liveness and censorship resistance guarantees as the L1 because RISE is sequenced by L1 validators.

Historical Context

While Ethereum is maximizing for security, rollups were introduced to address the scalability issues of Ethereum without requiring any additional security assumption. By this, rollups should inherit the liveness and censorship resistance of Ethereum. The first rollup rolled out a few years ago was actually proposed this way. However, it was later abandoned due to its impracticality, bad UX. If it were to go live, it would have to inherit the 12-second block time and users would have wait exactly the same time for confirmations, the same as a regular Ethereum transaction. At the time, we had no idea of how preconfirmations would be realized, the current PBS infrastructure was not yet running. Besides, because rollup transactions are visible while residing in mempool, they are prone to MEV attacks (e.g, sandwiching or front-running).

As a consequence, a centralized sequencer was added to make UX better and to prevent any mean of bad MEV. The sequencer is highly performant, providing high throughput, low latency, and instant finality (at L2 chain) to users who trust the service. The sequencer receives transactions from users and orders them into block. It issues soft commitments for transaction ordering. While these commitments lack the on-chain enforcement mechanisms of slashing or arbitration, users can rely on the sequencer's inherent responsibility for transaction selection and ordering. These commitment can be seen as preconfirmations. It also promises not to perform any attack on users' transactions. However, all the UX gains come with serious tradeoffs.

• Liveness. The sequencer can prevent the network from progressing (thus, compromise liveness) by stop operating.
• Censorship resistance. Because the sequencer is the only party who can order transactions, it can perform censorship on certain transactions or on certain users.

Most rollups implemented an expensive escape hatch for users to force inclusion of their transactions in case the sequencer is malfunctioning. The escape hatch serves as a fallback mechanism for rollups to inherit the security of Ethereum. As a combination, the centralized sequencer and the escape hatch give users fast preconfs with eventual Ethereum security. In the happy case, users obtain fast preconfirmations with a delay until their transactions are settled on Ethereum. In the worst case, they have to exit the rollup by directly sending transactions to Ethereum via the escape hatch. In any case, users can always experience the great security of Ethereum.

Later on, the Ethereum Researcher Justin Drake introduced a new concept of based rollups. The revival of based sequencing is expected to introduce new paradigms for rollups and chain interactions, emphasizing seamless transitions and enhanced user experiences. Together with based preconfirmations, this is a promising response to the limitations of existing rollup solutions, particularly in terms of decentralisation and security.

Based Preconfirmations

By default, 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 were then 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. Preconfers are expected to honor all promises they make on-chain. 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 preconfer's slot was missed.
• Safety faults. When a preconfirmed transactions were not included on-chain and the preconfer's slot was not missed.

A general paradigm of based preconfirmations and how it fits into the current MEV pipeline.

RISE Based Sequencing

This is an active area of research - More to come on this topic from the RISE team!