Preconfirmations: Explained

Introduction

Preconfirmations, or "Preconfs," are a recent innovation in the Ethereum ecosystem designed to enhance transaction efficiency. They can be described as “A credible heads-up before a confirmation happens.” (Murat, Primev Research) This concept aims to significantly reduce transaction confirmation times, potentially achieving sub-second UX while preserving the core principles of decentralization and security.

While considered a fresh concept, there has actually been long term work on Preconfirmations as early as 2012, for Bitcoin. Infact, the concept was called a 0conf in earliest references.

In 2023, Uri Klarman brought the concept to light for Ethereum. The concept was further explored by Primev and later that year, Justin Drake introduced “based preconfs.”

In decentralized systems, a "fast game" is an interaction that occurs in a brief period between two blockchain blocks (Barnabe, ethresear.ch). The chain has no access to this interaction, by design. Preconfirmations can be considered as one such fast game, working towards mitigating issues with block confirmation (Primev).

Preconfirmations allow users to achieve greater certainty about the success of their transactions well before the actual confirmation on the Ethereum main chain. By leveraging Rollups, which bundle multiple transactions for efficient processing, Preconfs provide an early indication of transaction success, speeding up the overall confirmation process.

"Preconfers" will provide guarantees about transaction inclusion and receive tips from users for this service. By leveraging this technology, users will be able to achieve rapid transaction assurance and sub-100 millisecond latency.

Preconfirmations are necessary because specific challenges currently inhibit Ethereum's slot duration from optimal performance. Some of the issues are inclusion uncertainty for end users, builder market concentration, Validator timing games, and value extraction from the end user.

This article will dig deeper into how Preconfirmations work in the Ethereum ecosystem.

Why Ethereum Preconfirmation?

Sequencing is a fundamental blockchain concept that involves ordering and processing transactions. Layer-2 Rollups mostly use centralized sequencers to expedite access and achieve fast block finality. However, centralization can lead to issues like monopolies, transaction censorship, Maximal Extractable Value (MEV) exploitation, and higher gas prices. Consequently, Layer-2 Rollups are aiming to better align with Ethereum to leverage its security, neutrality, and network effects.

By using Ethereum for preconfirmations, Layer-2s inherit the same benefits they gain from using Ethereum for settlement and data availability. While Ethereum excels in these areas, sequencing remains a challenge. Currently, each Rollup operates as a silo, but network effects could be maximized through synchronous composability using the Layer-1 base layer as the shared sequencer.

What Are Based Rollups?

Some Rollup projects have decided to become Based Rollups, integrating preconfirmations to enhance transaction processing. For instance, Coinbase has joined the effort by building a simple key-value store as a Based Rollup. Additionally, other projects like Aztec are considering this approach, and various teams are actively investing resources in this novel concept. One of major proponents of Based Rollups is Taiko.

Based Rollups consist of collaboration between these key parties: Layer-1 Proposers and Layer-2 Searchers and Builders, to add the next Rollup block as the next Layer-1 block. Here's a simplified example of how it works [Four Pillars]:

• L2 Searchers select user transactions from the mempool, wrap them into bundles.

• The L2 Block Builders sequence the transactions into full L2 blocks. L1 searchers also can be L2 block builders.

• L1 Searchers include these L2 blocks as L1 Bundles to L1 Block Builders

• The L1 Block Builder sends the L1 block (containing L2 Block data) to the L1 validator, and it is proposed as usual in the Ethereum network.

The term "Based Rollup" is also credited to Ethereum Foundation researcher Justin Drake, who is working to align Layer-2 Rollups with Ethereum to capitalize on Layer-1's decentralization, liveness, and sovereignty. The key advantages of Based Rollups are security, credible neutrality, and network effects.

Preconfirmations and Validators

How do we get Layer-1 to provide Preconfirmations? Validators are one way, but they'll need a way to opt into the mechanism, which brings up the notion of re-staking.

A subset of Ethereum's Validators can commit to Preconfirmation through re-staking. These Validators will guarantee that they will include Based Rollup blocks in Layer-1 blocks in the future. However, this can only function when the Validators know which Proposer is assigned to which block on at least 32 blocks. We have multiple articles that touch on the concept if you need to familiarize yourself with re-staking.

Another way to go about this are passive joining methods for validators. Validators could opt-in to mev-commit for example and utilize block-builder services to provide the preconfs.

Additionally, some teams are exploring different ways to "register." For example, Spire is working on an on-chain registration process using a smart contract. While re-staking is still necessary for implementing slashing mechanisms, the registration itself could be managed on-chain.

From Proposer to Preconf — Slashing Conditions

A Layer-1 Proposer can become a Preconfer by agreeing to two slashing conditions:

1. Liveness fault

2. Safety faults

If a Preconfirmation promise exists but is reneged upon, it will result in an unhappy user with slashing implications. With staking requirements in place, protocols can punish bad actors financially via slashing. In both cases above, the Preconf can be financially penalized for not honoring the Preconfirmation.

A Liveness fault is the more subtle of the two. An example is when a Preconf makes a promise, but milliseconds later, when it is their turn to build a block, they unexpectedly go offline. This fault should only happen sometimes, but it is possible. The gist of the Liveness fault is that it occurs when a Preconf's slot is missing, and the transaction was not previously included onchain. Therefore, the Preconf and the user mutually agree on the slashing amount. The penalty can be based on the risk of an accidental Liveness fault and the Preconf tip amount.

On the other hand, Safety faults do not occur because the Preconf slot was missed but when the promise is inconsistent with transactions included on-chain. In other words, a Safety fault occurs when a Preconf makes a promise that is inconsistent with their deliverable. These Safety faults are fully slashable because an honest Preconf should never trigger this kind of fault.

So, Proposers seeking to become Preconfs must agree to these two slashing conditions.

The Tip Mechanism in Preconfirmations

Tips provide an incentive for Preconfs to include user transactions. The tip mechanism triggers by signing Preconfirmation promises, whereby users pay tips to the Preconf to honor their promises. The user sends a Preconfirmation request to the first Preconf, and they receive a promise. A transaction with a promise from the next Preconf can be instantly included and executed on-chain by any Proposer ahead of that Preconf. The Preconf must honor any remaining promises on their slot using the inclusion list.

So, Preconf can create a Rollup Block as a Layer-1 transaction and include a tip. This incentive usually gets the block included in the next slot. Furthermore, they must communicate these constraints to the Block Builders, as they are tasked with communicating Preconfirmation transactions. Hence, they must run full nodes with extremely high bandwidth and uptime for the Rollups.

To sum up, Preconfirmations can improve transaction execution and are timely promises given to a user in exchange for an economic incentive—tips.

Preconfirmations on Layer-1 Transactions

So far, we've only touched upon Preconfirmations in a Layer-2 Rollup context. However, researchers are developing different solutions depending on whether the Preconfirmation is for Layer-1 or Layer-2 transactions.

For Layer-1 transactions, researchers have proposed Inclusion Lists and Execution Tickets as in-protocol implementation. Execution Tickets bifurcate block proposing and building. In this scenario, the Layer-1 Proposer role is offloaded to the market and not given to the Validators. So, a Validator would no longer act as a Proposer but mainly work on simple attestations.

Unfortunately, Execution Tickets aren't available yet, so a more immediate solution is needed. One such solution includes using a Gateway. In this case, the Proposer can delegate their rights to being a Preconf to a Gateway. The Gateway would do the heavy lifting, communicating with the users while maintaining full nodes with high uptime.

Ethereum Foundation Researchers have also proposed Inclusion Lists to improve censorship resistance.

PBS Block Building

Some experts believe that the way block building works needs to be changed and that the Proposer/Builder Separator (PBS) option will become the dominant way to engage in block building. PBS works by having Builders talk to Proposers. It's a one-way flow of information, with blocks traveling from the Builder to the Proposer.

However, Block Builders can exert monopoly power to block buildings. Thus, Preconfirmation promises will have to go upstream to restrict how the Builders build their blocks.

So, if Preconf promises a user to include their transaction at the top of the block, the Preconf needs to communicate this to the Builders. Then, at the end of the slot, when it's time to build the final block, the Builder needs to respect this constraint so that the first transaction goes through as it was previously promised to the user.

Centralized Preconfirmations vs. Decentralized

The concept of Based Rollups, which leverage Layer-1 Preconfirmations for Layer-2 blocks, is still new and debatable. Presently, Layer-2 Rollups are more into centralized sequencers, and Based sequencer adoption may be slow in coming. So, it's only logical to consider that centralized sequencing will persist for now, even amongst the calls for decentralization.

Centralized and decentralized sequencing is quite similar, but one difference is that the Preconf is fixed in a centralized setting.

Again, with Preconfirmations, a user and a Preconf exist. First, the user makes a request to the Preconf, and the Preconf offers a promise for Preconfirmation. An example could be that a trade on a DEX will execute at a specific price and position within the block. But every slot is the same entity. For example, with Arbitrum, it might be that Offchain Labs persist at every slot. Whereas in a decentralized setting, slot rotation occurs. Metis is the first L2 with a decentralized sequencer, complete with automatic sequencer rotation.

When using decentralized Preconfirmations, the Preconf changes at every slot. So, the user must look into the future to see who will be the next Preconf since they change.

The user needs to communicate with the correct Preconf who will be in the current slot. They make a request and get a promise as a response.

Slashing to Enforce Preconfirmation Promises

Slashing works differently depending on whether the Preconfirmations are centralized or decentralized. With centralized Preconfs, platforms can promise to include transactions on a first-come, first-served basis, ensuring no users get "sandwiched" or "front-runned." So, users know up front that the Preconfs will provide protection, and they won't extract MEV.

What's called "reputational slashing" exists for centralized Preconfirmations that don't keep their promises. Take Optimism Labs or Offchain Labs, for example. Since they have billions of dollars behind their reputations, it would be unwise not to honor their Preconfirmations. Otherwise, disgruntled users would take to reputation-savaging them on social media. So, if the centralized entity doesn't honor Preconfirmations, its reputation will be slashed.

However, in a decentralized situation, users can't trust the Preconfs based on reputation. In a decentralized setting, the incentive to honor Preconfirmations is instead stake, which the protocol can slash. That is why there has to be a stake or restake involved.

Commit-Boost

While preconfirmations bring promising enhancements to transaction efficiency and security in the Ethereum ecosystem, the process involves intricate coordination and potential risks, particularly for validators. This is where Commit-Boost comes into play.

Commit-Boost is an open-source tool designed to help validators manage various commitments, including preconfirmations, securely and efficiently. It provides a standardized platform that reduces complexity and mitigates risks, ensuring that validators can handle their commitments without facing fragmentation or excessive development burdens. With Commit-Boost, validators can manage different commitments through a single, modular system, enhancing transparency and safety in the process.

As preconfirmations become more integral to Ethereum's transaction process, the need for a reliable validator sidecar like Commit-Boost becomes evident.

Preconfirmations - Summary

To sum up, Preconfs represent a promising breakthrough for Ethereum. They aim to improve transaction speeds while maintaining security and upholding decentralization principles. This innovation encourages developers to find new ways to implement Preconfs to address Ethereum's scalability challenges and enhance user experience and transaction processing speeds.

Additionally, with the introduction of re-staking, preconfirmations have the potential to aid Layer 2s in further decentralizing. They also unlock new revenue streams, making them a valuable addition to the Ethereum ecosystem.

Update (23/July/2024): Proper attribution was provided to sources, and corrections were made about the chronology of Preconf development. Thanks to Murat Akdeniz (Primev), Uri Klarman and @mteamisloading for their comments and contributions.

*Update (7/Nov/2024): Clarifications based on Four Pillars Research and inputs from Rahul Saxena *

About Luganodes

Luganodes is a world-class, Swiss-operated, non-custodial blockchain infrastructure provider that has rapidly gained recognition in the industry for offering institutional-grade services. It was born out of the Lugano Plan B Program, an initiative driven by Tether and the City of Lugano. Luganodes maintains an exceptional 99.9% uptime with round-the-clock monitoring by SRE experts. With support for 45+ PoS networks, it ranks among the top validators on Polygon, Polkadot, Sui, and Tron. Luganodes prioritizes security and compliance, holding the distinction of being one of the first staking providers to adhere to all SOC 2 Type II, GDPR, and ISO 27001 standards as well as offering Chainproof insurance to institutional clients.