#45 - Preconfirmations
Exploring The Credible Promise of Future Execution
Stanford Blockchain Review
Volume 5, Article No. 5
📚Author: Raghav Agarwal, Longhash Ventures
🌟Technical Prerequisite: Advanced
Introduction
Blockchains have ushered in a new era in global human coordination by enabling permissionless access and decentralization. Thoughtfully crafted incentive mechanisms and cryptographic techniques facilitate the flow of value among all participants within an open ecosystem. However, all participants are not equal and sophisticated actors continue to extract value from unsophisticated end users. Significant improvements have been made to enhance the user experience and democratize the MEV landscape but Ethereum continues to be a dark forest, offering sub-optimal user experience due to the extractive techniques of different monsters.
We believe that preconfirmations are the next natural step in the evolution of blockchain design space intended to level the playing field for all participants and improve the user experience. We contend that preconfirmations will be essential in bridging the gap between execution experience between web2 applications and dapps that exists today. In this article, we begin by defining preconfirmations. Next we describe the various approaches being proposed and designed, their respective tradeoffs, and the impact on the future of execution in web3.
Preconfirmations
In everyday life, people are so familiar with preconfirmations that they hardly notice it. For example, when making an online payment or placing a BUY order on a platform like Robinhood, users expect their request to be fulfilled once they see a confirmation on their screen. The entity processing the order might face numerous challenges to complete the request, but users remain unaware of these complexities.
In blockchain transactions, preconfirmation serves as a reliable and timely promise from a provider (someone who executes such as a validator or block builder) to a bidder (the entity needing transaction execution). This promise, offered in exchange for an economic incentive, ensures better transaction execution. This promise could mean different things depending on whether it is a promise of transaction inclusion, execution or success. Depending on who is responsible for block building, preconfirmations can be provided to end users or intermediaries like searchers, solvers, bots, AA bundlers, or even rollup sequencers. By quantifying and reducing the execution risk associated with transaction ordering and blockspace contention, preconfirmations enhance the user experience and allow users to accrue more value by providing timely execution.
Various methods have been proposed to achieve preconfirmations. For the purpose of simplicity, we analyze Ethereum L1 and its growing ecosystem of L2s but many of these concepts can be applied to other PoS alt L1s as well. We categorize preconfirmations based on two characteristics:
Whether the implementation is out-of-protocol or in-protocol
Whether the pre-confirmation is being provided for L1 transactions, L2 transactions or L2 blobs
Based on these two axes, we can divide the whole space as:
Preconfirmations for transactions on L1
The current state of Ethereum
More than 90% of the blocks on L1 currently are finalized through mev-boost [1]. Validators auction off the right to build a block to the builder who bids the highest in an auction. Users, trading bots and searchers (special users who run algorithms to construct profitable transactions) submit their transactions via RPC nodes to mempool or directly to builders. Builders construct the most profitable block possible by aggregating transactions from the public mempool and private orderflow and then bid in an open auction to win the right to build the block. The auction is facilitated by relays who ensure that the highest bidding block wins and the validator cannot steal the MEV from the builder and keep all the MEV rewards for themselves.
Challenges
MEV-Boost has enabled the separation of the proposer and builder role but a number of challenges still persist:
Value extraction from end users: In order to win the auction, builders are heavily incentivized to extract the maximum value from the block. This usually comes at a cost to the end user who ends up with the most value extracted from their transactions. Builders do need to maintain a balance here because they are competing with each other for private orderflow and excess execution tax could drive away their orderflow. However, blocks built by builders do result in more value being extracted from the end user.
Transaction execution risk: Searchers and end users cannot guarantee their transaction's inclusion in the current block, nor can they specify transaction ordering or target block number. Solvers on intent-centric platforms like UniswapX also face execution uncertainty. To remain competitive, solvers either vertically integrate by running their own builder or secure exclusive deals with builders to ensure their transactions are prioritized, creating an entry barrier for new solvers.
Block builder concentration: The block builder market is highly concentrated, with the top three builders creating over 90% of the blocks. A key reason for this concentration is access to private order flow. To avoid malicious builders, who might unbundle transactions and capture MEV profits, searchers only share their order flow with reputable builders. This creates a chicken-and-egg problem: builders need private order flow to gain market share, but searchers only trust builders who already have a significant market share. Another way to access private order flow could be through having an affiliated HFT trading arm.
Validator timing games: In order to maximize the MEV in the current implementation, validators engage in “timing games”, a strategy where block proposers intentionally delay publication of their block for as long as possible to maximize MEV capture [2].
Lower censorship resistance: Since most proposing validators outsource block building to specialized entities (or risk losing the MEV), they do not have any say in what transactions to include. Proposers do not retain any authority by which transactions can be forcibly included.
Lack of trustless coordination across intermediaries: The relationship between searchers/channels and builders is based on trust and hence, most searchers are unwilling to share their orderflow with new or small builders. The validators connecting with censoring relays need to trust that the relays are verifying and censoring only OFAC transactions [3]. Builders also trust relays to not steal their MEV and propagate data in a timely manner.
In order to overcome these challenges, we need a coordination mechanism amongst all the intermediaries (users, bots, searchers, builders, relays and validators) to enable trustless and reliable communication in a timely manner. Preconfirmations could solve a number of above mentioned challenges by serving as a coordination mechanism, and several approaches have been proposed to implement it. For transactions on L1, we look at Inclusion Lists, Execution Tickets and mev-commit by Primev.
Inclusion Lists (IL)
ILs allow proposing validators to force include certain transactions in the current or subsequent block. The idea was proposed by Mike, Vitalik, Francesco, Terence, Potuz, Manav in late 2023. The motivation behind IL is to address the limitations faced by validators in absence of a forced inclusion mechanism. Without IL, validators must either entirely outsource block building or forgo MEV by building the block locally. IL enables proposing validators to outsource block building while still ensuring the inclusion of specific transactions.
Design of Inclusion Lists
The proposer for slot N broadcasts a signed block and an inclusion list for slot N+1. The transactions in the IL will be included in slot N or slot N+1, otherwise the N+1 block will be invalid. Slot N validators only consider the block for validation if there is at least one inclusion list for that slot. For slot N+1, the proposer incorporates a signed summary from slot N proposer and the payload is considered valid if it satisfies the inclusion list summary, and the consensus conditions are met with a proposer signature of the previous block.
Implications
ILs are likely to improve censorship resistance (CR) to a certain degree by allowing validating proposers to have a say in the block building process
While CR is improved to a certain extent, validators are likely to continue outsourcing their block building to builders to maximize their revenue. They could decide to include transactions in the presence of an incentive structure where they could sell inclusion guarantees to users or searchers. MEV actors are likely to engage in off-chain deals in the absence of a defined mechanism for validators to give preconfirmations to users and searchers.
Depending on the implementation details, the legal implications remain uncertain. The proposer in Slot A could push all controversial transactions (OFAC sanctioned transactions) to Slot B. The proposer in Slot B might include only the bare minimum transactions required for block validity, further pushing the remaining controversial transactions to Slot C. Determining who is responsible for the included transactions and the legal implications of this process is challenging at this stage.
IL are likely to include additional complexity at the protocol level
The proposal is currently in the draft stage. IL also forms the basis of execution tickets and the original based preconfirmation architecture proposed by Justin Drake which we discuss later in this article.
Execution Tickets (ET)
ET was originally introduced as Attester-Proposer Separation (APS) by Justin Drake, and later published in an ethresearch article by Mike Neuder. Currently, validators are responsible for two primary tasks:
Proposing the beacon block during the beacon round
Build the execution payload of the block during the execution round. This is usually outsourced to block builders using mev-boost
Validators are selected randomly for both tasks through a single lottery based on the amount of staked ETH. However, the task of building execution payloads can exert centralizing pressure on validators, as they may vertically integrate with builders and leverage low-latency connections. ET is being proposed as a solution to bifurcate these two responsibilities, protecting validators from centralizing forces and enabling more solo validators to participate as beacon block validators, thereby boosting decentralization.
Design of Execution Tickets
The existing PoS lottery will be used to select validators randomly to propose beacon blocks. However, a separate primary lottery market will be created to allow entities to purchase ETs. The ticket owner will have the permission to propose the execution block for the slot (which they can do themselves or outsource via mev-boost). An execution block proposer will be selected at random from all the ET holders [4].
Implications
ETs promote decentralization amongst beacon block validators because MEV part of the rewards are separated which previously benefited big staking pools more than smaller ones. However, ETs are likely to introduce more centralization among ET holders, potentially leading to liveness risks. Pricing ETs is challenging and currently only feasible for block builders. As a result, the existing centralization of block builders could extend to the ET markets [5].
ETs enable more MEV to be captured by the protocol. Revenue from ticket sales is intended to be burned, applying deflationary pressure on ETH’s supply, increasing ETH’s value, and thereby enhancing network security, assuming no new vectors of the attacks are introduced.
Big validator entities might not view ETs favorably because by they will no longer have an edge over smaller validators and is likely to impact their revenue
If multi-block MEV is prevalent (if a ticket holder wins multiple blocks in a row), the advantage gained from controlling successive blocks could lead to significant centralization. Controlling multiple consecutive blocks can yield disproportionately higher rewards than the sum of the individual blocks’ values. Impact of multiblock MEV requires more research to better quantify its impact.
ETs are still at an early stage and require a lot of research from an implementation POV before being actually adopted by Ethereum. The pricing mechanism must be designed thoughtfully to capture as much value as possible for the protocol while still being attractive and viable for proposers.
IL and ET improve censorship resistance and separate the roles of proposing beacon blocks and building execution payloads. However, they fall short of enabling the entire MEV supply chain to coordinate effectively. They also do not sufficiently reduce the likelihood of off-chain deals and vertical integration. Mev-commit could address some of these issues.
Mev-commit by Primev
Mev-commit is a P2P network designed to enable all MEV intermediaries to coordinate efficiently and trustlessly. It features a fast chain, a fork of geth, where commitments about the execution of Ethereum transactions can be recorded along with the logic to reward/slash providers. It allows bidders (such as Searchers, Solvers, Telegram Bots, AA Bundlers, Wallets, Transaction aggregators and end users) to specify their preference for transaction execution and get a commitment from execution providers (such as block builders, validators). These preferences could be something like:
Ensure that txn A is included in block number X
Precise blockspace entry (top 10% of block or bottom of block)
Include txn A only if txn B has been executed
Include txn B after txn A only
The gas price of the txn should be lower than X
Multi block commitments (execute 3 txs in the next 3 blocks, 1 each block)
Commitment from sequencers of two different rollups for a pair of cross-chain txn to go through simultaneously
Design of mev-commit
The process overall can be summarized in the following steps:
Bidders submit their bid to the mev-commit network (bidders have pseudonymous identity for privacy protection) in an encrypted mempool
Bids are received and evaluated by providers, who decide if they want to issue a cryptographic commitment against the bid or not
The commitment provided is recorded on the mev-commit chain
Bids/commitments written to mev-commit chain get revealed at time of execution and an oracle will check the target block (once it is confirmed) to see if the commitment is satisfied by the committing actor
If yes, the provider is awarded with the bid amount and if not, the provider is slashed
The provider is slashed or rewarded only if that provider participated in the block’s confirmation. If Block Builder A and Block Builder B commit to a bid and the target block is built by Block Builder A, the oracle will reward or slash Block Builder A.
Implications
Mev-commit opens up a whole new design space for what is possible on blockchains:
Better execution experience
Dapps can guarantee execution of transactions to users in return for additional fees. Dapps can also build complex logic on top of mev-commit to capture some of the MEV and give it back to users.
Dapps can enact preconf sponsors that will see user transactions and bid for preconfs on their behalf to enable instant transaction UX
Solvers can be more aggressive in the solutions, giving users better deals as gas price is set and position in block is set.
EIP-4337 paymasters can contribute pre-confirmation bids and gas fees for transactions from any originator, promoting greater flexibility and adaptability for users
In case ETs and IL are adopted at the protocol level, mev-commit can facilitate users/searchers to coordinate with ET holders and proposing validators to get preconfirmations for their transactions.
Decentralization of Builder market
Programmatic robust deals: Some searchers will be willing to share deal flow with new builders as they don’t need to trust the builder and will be able to receive a private commitment backed by reputation and a stake. Some searchers will still be selective with their order flow but mev-commit will make it more democratized. Searchers can develop their own deals with custom logic on the mev-commit chain and receive real time commitments.
New use cases
Multi-transaction flash loans: Flash Loans currently cannot span across multiple transactions and the loan needs to be paid off in the same transaction as currently there is no way to enforce loan payback. Builders on mev-commit can allow multi-transaction flash loans by ensuring that the built block is sound in terms of the loan being paid back, otherwise their stake can be slashed.
Builder pooled decentralized flashloan system: Multiple builders and sponsors can pool funds (maybe re-staked assets) supplemented by protocol revenue. This pool of funds can be used for providing flashloan monitored by protocol rules rather than relying only on liquidity from pools of lending protocols like Aave.
Commitment games: The mev-commit chain could be used to deploy dapps offering execution related commitment games where ethereum transactions can be committed to faster than ethereum blocks
Risks
Validator staking/opt-in contracts on mainnet introduce smart contract risk. This risk can be mitigated through audits and rigorous testing.
Since mev-commit introduces its own chain and oracle solution, validators must trust the correctness of execution on the mev-commit chain and slashing transactions managed by oracle service. Decentralization of the chain and oracle will be important to mitigate this risk.
Validators will be required to only propose blocks from a mev-commit opted-in relay. As more and more relays opt-in, this risk will decrease as validator's relay picks will not be disrupted.
The Primev team has been building mev-commit for two years now and is currently live on testnet with many validators and builders testing it for mainnet readiness.
Preconfirmations for transactions on L2
The current state of rollups
Most rollups handle sequencing and execution, while relying on Ethereum L1 for data availability and settlement. Currently, rollups use centralized sequencers to accept and sequence transactions. A validator/prover then generates the final state based on these sequenced transactions and posts it on the L1 bridge contract.
Centralized sequencers can provide users with soft commitments about transaction inclusion before L1 verification. Users cannot enforce these soft commitments (via programmatic slashing or arbitration) but they can trust the sequencer’s commitments since they are responsible for selecting and sequencing. This soft commitment can be termed as preconfirmation. However, if the validator/prover fails to post the final state on L1, as seen with Degena and Proof of Play’s Apex, this trust is compromised. Centralized sequencers offer preconfirmations but also pose risks of censorship, single points of failure and MEV extraction. Decentralizing sequencers is challenging, especially in maintaining preconfirmations for users.
Based rollups
In order to leverage the existing L1 MEV supply chain to build and propose L2 blocks, Justin Drake formally proposed based rollups in March 2023. The idea was first introduced as “Total Anarchy” by Vitalik in the article “An Incomplete Guide to Rollups” in 2021 where total anarchy meant that anyone could submit a batch at any time. Justin Drake followed up his proposal with the concept of based preconfirmations in November 2023 for preconfirmations in the absence of centralized sequencers.
Design of based rollup
As defined by Justin Drake, “A rollup is said to be based, or L1-sequenced, when its sequencing is driven by the base L1. More concretely, a based rollup is one where the next L1 proposer may, in collaboration with L1 searchers and builders, permissionlessly include the next rollup block as part of the next L1 block.” [5]
Basically, L1 builder or L1 searcher can play the role of L2 block builder by picking the transactions from L2 mempool, building the L2 block and including it in the L1 bundle. Since most of the MEV flows to the L1 validators, L1 proposers are incentivized to include rollup blocks on the L1.
Implications
Decentralization and Liveness: Based rollups inherit decentralization and liveness from L1 relying on the battle tested infrastructure of Ethereum. They are not subject to short-term sequencer censorship during the timeout period and the possibility of mass exit triggered by a sequencer liveness failure is eliminated.
Simplicity: Based sequencing is simple because it requires no sequencer signature verification, no escape hatch, and no external PoS consensus.
MEV Capture: Based sequencing allows MEV to be captured by L1 and thus strengthens the L1 economic security. However, this poses a dilemma for rollups, as they must sacrifice MEV for the sake of security, decentralization, simplicity, and alignment with L1. Rollups face a trade-off between capturing MEV value and potentially gaining more market share by prioritizing these benefits.
Lack of fast preconfirmations: Leveraging L1 for sequencing makes it difficult to provide fast preconfirmations using the existing protocol design.
Public mempool: Based sequencing reintroduces a public mempool to L2s which allows for sandwich attacks and frontrunning, which does not exist in other rollups.
Taiko is the first based rollups to launch mainnet and a few others like Aztec are considering becoming a based rollup. You may read details about Taiko’s based rollup design here. We will continue to focus more on based preconfirmation.
Based preconfirmations
Based preconfirmations allow rollups to leverage L1 sequencing without sacrificing the benefits of preconfirmation offered by centralized sequencers. To enable effective based preconfirmations, following requirements must be met:
Provider forced inclusions: The provider should be in a position to include transactions for which preconfirmation has been given. The approach depends on who the provider is.
If proposing validators offer preconfirmation, they need a mechanism to include transactions in the block. This can be done by building the block themselves rather than outsourcing it through mev-boost. Alternatively, they need a coordination mechanism with builders to ensure accountability. This can be achieved through approaches like IL or ET, which require protocol-level changes, or through crList, which necessitates changes to mev-boost.
If block builders provide preconfirmation, they can enforce execution if they win the bid in the mev-boost auction. Builders can guarantee execution, but they cannot be certain of winning the bid. If bidders get preconfirmation from enough builders, they can be fairly certain that their condition will be fulfilled. Currently, bidders receiving preconfirmation from the top three builders have more than 90% probability of execution.
Any other entity which joins as a provider to offer based preconfirmations as long as they validator participation
Slashing: To ensure that provider adheres to the conditions promised as preconfirmation to the bidder
Off-chain mechanism to allow users to acquire preconfirmation. These commitments must be visible and understandable to others to ensure credibility.
Some of the notable proposals are:
Justin Drake’s proposal for based preconfirmation: Justin’s original proposal has undergone changes based on the community feedback. The proposed design allows rollups to use Ethereum L1 for shared sequencing and preconfirmations without requiring a hard fork. According to the latest proposal, instead of relying on IL, ET will be used. With ETs every rational L1 execution proposer will opt to become a sequencer so that the even the L1 EVM can enjoy preconfirmations. It also requires changes to mev-boost, so that the sequencer can communicate constraints (e.g. top-of-block or top-of-blob constraints) to relays and builders.
Nethermind Research and Flashbots proposal: It builds upon Justin Drake’s design to allow based rollups to accrue some MEV to rollups itself. It proposes an auction mechanism which charges some amount for the right to be a preconfirmer for a based rollup. This amount is then paid back to rollup ensuring the value generated by the rollup is first sent to the rollup. Just like Justin Drakes’ proposal, this approach also needs to figure out the method by which proposing validators will force inclusion of transactions on L1. They have also proposed a possible implementation for Taiko.
Mev-commit by Primev: mev-commit by Primev, currently on testnet, is built to support coordination amongst all MEV intermediaries on L1. Primev could stand up a preconfirmation provider on mev-commit for any based rollup as reflected in their proposal to Taiko. Since builders can directly provide preconfirmation, there is no need for a new force inclusion method as required by all other solutions. Users could get preconfirmation from multiple builders to increase the chances of their condition being met.
BFT preconfirmations by Espresso: Is offered by the Espresso decentralized sequencer. Espresso intends the sequencer to engage the participation of Ethereum validators through restaking contracts for shared security with the Ethereum L1. The participating validators come to consensus on the state of rollup using HotShot consensus. HotShot’s low latency can be used to offer preconfirmation. Users can trust a rollup server that has executed the transaction before a proof is generated.
Proposer-promised (“PP”) preconfirmations by Espresso: Unlike BFT preconfirmations that require agreement among the entire validator set, PP preconfirmations only require approval from individual validators. Each rollup is also empowered to customize the PP preconfirmation ordering and slashing conditions to meet their individual needs. Espresso gives preconfirmations for the transactions in their rollups, but needs to secure L1 confirmation as well which can be achieved via IL, ET or mev-commit.
Conclusion
Preconfirmation is an inevitable aspect within the broader field of blockspace monetization and technological improvements in transaction execution. While introducing OneBalance, Stephane Gosselin also talked about the importance of preconfirmation in helping solvers manage their settlement risk. Conversations with builders, searchers, solvers, and other ecosystem participants indicate that preconfirmations are likely to gain momentum in the near future.
Before widespread adoption, it is essential to conduct thorough research, auditing, and testing. Ensuring efficient price discovery of commitments and preventing centralization is vital. As Lin Oshitani highlighted, naive implementations of based preconfirmations can lead to negative externalities [7]. We are excited to see many validators already participating in the mev-commit testnet, which helps them better understand the economic impacts, benefits, and risks associated with preconfirmations.
Extensive research is already underway, spearheaded by the Ethereum Foundation and the broader community. Numerous teams and researchers have published their findings and proposals on this topic. Drew Van der Werff proposed Commitment Boost, an idea to standardize the way proposers register, send and receive commitments. mteam from Spire Labs introduced Preconfirmation registry, a system for proposers (large operators as well as solo-stakers) to post collateral in ETH [. Chainbound recently announced Bolt, a protocol that allows Ethereum proposers to offer commitments about their block contents. Primev proposed a solution for blob preconfirmation using mev-commit and IL. As the number of L2s increase and the blob market becomes saturated, the solution will allow L2 sequencers to gain certainty about blob inclusion and mitigate latency issues of blocks with many blobs in the future.
We believe that out-of-protocol implementations will act as a catalyst for innovation and iteration, speeding up time to market similar to Flashbots' mev-boost. These implementations will help researchers refine designs and gather valuable feedback from all entities without overloading the L1.Vitalik recently mentioned in his blog, “Layer 1 could incorporate a "fast pre-confirmation" and "slow final confirmation" system. It could incorporate different shards with different levels of security. However, this would add a lot of complexity to the protocol. Furthermore, doing it all on layer 1 would risk overloading the consensus, because a lot of the higher-scale or faster-throughput approaches have higher centralization risks or require stronger forms of "governance", and if done at L1, the effects of those stronger demands would spill over to the rest of the protocol.” [8]
Each thing we enshrine in Ethereum, like SSF, ePBS etc, adds an extra round of attestations and could increase block times to 20-30 seconds. In such a scenario, preconfirmations become infinitely more valuable because it allows Ethereum to innovate without degrading UX.
The improved user experience and new use cases enabled by preconfirmations will drive demand. On the supply side, additional revenue from bidders, enhanced censorship resistance, and a robust blockspace market will be key factors. Preconfirmations stand out as one of the most promising innovations to address the inherent limitations of the Ethereum transaction supply chain. We are extremely excited about this emerging space and are thrilled to see the support from the Ethereum Foundation and the broader community. We believe that preconfirmations will play a crucial role in elevating the Ethereum transaction execution experience to be on par with rollups and empowering users to survive the dark forest of MEV while fostering sustainable blockspace market.
About the Author
LongHash Ventures specializes in bootstrapping Web3 ecosystems. LongHash Venture invests in early-stage Web3 protocols, and LongHashX Accelerator partners with ecosystems and protocols to accelerate early-stage founders.
Raghav Agarwal is a Senior Investment Analyst at LongHash Ventures focusing on research and investments. Raghav has previously worked as research analyst at D.E. Shaw and product analyst at Fidelity Investments. Raghav is a computer science engineer and holds a Master in Business Administration from Indian Institute of Management, Shillong.
[2] https://ethresear.ch/t/timing-games-implications-and-possible-mitigations/17612
[5] https://arxiv.org/pdf/2404.04262
[6] https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016
[7] https://ethresear.ch/t/strawmanning-based-preconfirmations/19695