Vanilla based rollups explained

FacebookLinkedInTwitter
Vanilla based rollups explained

Vanilla based rollups are a new concept for rollups that take advantage of Layer 1. Helmed by LimeChain, the concept aims to retain the advantages of standard based rollups, while introducing a novel decentralized sequencing method dubbed vanilla based sequencing. The new addition seeks to address some of the limitations of the traditional method. Let’s take a closer look.

What are vanilla based rollups

We’ve already discussed the topic of based rollups and how they work. Basically, instead of having their own sequencers, based rollups take advantage of the existing pool of L1 block proposers to also handle sequencing duties for L2 transactions.

The proposed Vanilla based sequencing method aims to utilize L1 block proposers in a novel way designed to address some of the limitations of the current method. Specifically, when it comes to selecting an L1 block proposer to perform L2 sequencing.

Vanilla based sequencing

The standard approach is to task the current L1 proposer to take over the sequencing duties for the rollup for the duration of the current L1 slot. This method, dubbed ‘leader election’, has the benefit of making sure that the L1 proposer has the authority and the incentive to include rollup transactions during their slot, which means that there’s little downtime. But there is a caveat.

In order for a L1 block proposer to become eligible as rollup sequencers, they need to opt in for extra slashing conditions designed to discourage bad behavior. But if the current L1 proposer hasn’t opted in, then we need to wait for an L1 proposer that is eligible to perform rollup sequencing duties, which could potentially result in large downtimes. It is that limitation that the proposed vanilla based sequencing design seeks to address. Its solution is to employ two separate selection mechanisms depending on whether the current L1 block proposer has opted in or not.

If the L1 proposer has opted in, the selection is conducted just as in the standard based approach – the proposer takes over rollup sequencing duty for the duration of their slot.

However, if the current proposer is not eligible, a secondary selection mechanism called ‘fallback selection’ kicks in and randomly selects a sequencer among all the eligible L1 proposers. The selected proposer has the incentive to process the rollup transactions to the base layer.

However, fallback selection also comes wit a small caveat, namely the fact that the selected sequencer may have the necessary incentive, but does not have control over the current Layer 1 slot. This means that the sequencer competes with all other possible transactions that the current block proposer can add to the ledger during their slot. Because of this, the rollup sequencer will likely need to employ tactics like sending the rollup transactions to the L1 mempool with an increased base tip to offer a higher incentive to the block proposer.

Still, vanilla based sequencing offers a great solution that can eliminate significant downtimes and keep the rollup rolling, no pun intended.

Preconfirmation support

The proposed vanilla based rollups design also includes a number of other features aimed at bringing improved user experience, security and convenience for users. One such feature is preconfirmations.

Preconfirmations, also referred to as ‘preconfs’ are signed promises  that guarantee the user that their transactions will be included and executed within a certain timeframe. Preconfs are issued by L1 proposers that have opted in to additional slashing conditions to become so-called ‘preconfers’. Users have to pay tips for the service. The main goal of preconfs is to enable faster transaction confirmation and improve user experience. The concept was originally proposed for Ethereum and based rollups and validiums and is set to play a key part within the vanilla based rollup design, as well.

To support preconfs, the vanilla based rollups design introduces two new types of transactions – inclusion preconfirmation and execution preconfirmation. The former represents a commitment to the inclusion of a transaction in a sequence, while the latter is a commitment to the inclusion and the subsequent end state resulting from the transaction.

In order to ensure predictable fees, both preconf transactions will have predictable pricing mechanisms. Also, wallets will be able to retry preconf requests without involving the user, thus further improving the user experience.

Conclusion

The vanilla based rollups design aims to leverage the significant advantages of based rollups in terms of liveliness and decentralization, while addressing some of their biggest limitations, such as those relating to the mechanism for choosing L2 sequencer from a pool of L1 proposers. It also aims to provide user experience that is on par with centralized sequencers without sacrificing any of the advantages that come with the decentralized approach. 

To put it in other words, the vanilla based rollup design seeks to combine the best of both worlds and open up exciting new possibilities for the development and evolution of Layer 2 solutions.

FacebookLinkedInTwitter