Proposer-Commitment Infrastructure in Ethereum
aka “commitment issues”
Background / Overview
Over the past year or so, we have seen the emergence of research in the area of proposer commitments in PBS design, whereby various mechanisms have been explored for allowing the proposer to provide certain commitments of transaction inclusion/execution and to communicate those commitments to block builders. Examples of such commitments may be inclusion lists, blockspace futures or preconfirmations, though there is space for more types of commitments in the future.
While many of the mechanisms explored involve changes to the protocol to allow for generalized proposer commitments, (e.g. PEPC and its variations), it’s not clear that these mechanisms will ever actually be implemented, and if they do, it will likely take some time. For this reason, a number of out-of-protocol solutions have been developed which will allow validators to install software that would allow them to opt-in to providing various types of commitments.
Below we describe the out-of-protocol solutions that are in development, and explore what sort of solution space they open up for different types of Ethereum users.
What are the Use Cases for Proposer Commitments
Inclusion Lists
The thinking around inclusion lists on Ethereum has evolved significantly over the past year or so, from an initial simple design, to a more robust committee-based design like COMIS, and finally FOCIL. Currently the Ethereum community is collectively deliberating on the trade-offs between PBS with Inclusion Lists (i.e. FOCIL), or Multiple Concurrent Proposers (i.e. BRAID). These proposals affect the part of the Ethereum roadmap known as “the Scourge”, though it’s likely too early to tell exactly how exactly this will evolve over time.
FOCIL (or “Fork Choice enforced Inclusion Lists”) is a proposal from Robust Incentives Group for a type of inclusion list managed by a committee of attesters. In this system, a new committee shares its local perspective of the mempool before a specific time in the slot. The slot proposer gathers these perspectives and combines them into a unified list, which is then included in the proposed block. The validity of the block, determined by the fork-choice rule, depends on whether this combined list aligns with the attesters’ aggregated view of the transaction lists shared by each committee member. Attesters will only support the block if it matches this aggregated view to a degree that is parameterized by the protocol (i.e. the block has to be close enough to what each attester was expecting for them to vote for it). FOCIL is fully compatible with the current PBS pipeline, so if FOCIL is implemented as part of a future hard fork, it will not require any validators to use any other form of sidecar except mev-boost. In the meantime however, there already exists an out-of-protocol implementation of Inclusion Lists via a project call IL-boost, which is a Commit-Boost module that allows a proposer of a slot to create a list of transactions that it wants to be included in the block produced for its slot while still outsourcing block construction via MEV-Boost.
BRAID is a proposal from Special Mechanisms Groups that based on the proposal for Multiple Concurrent Proposers, requires that there be a number of different proposers that are all building a block off what they believe to be the head of the canonical chain, and based on transactions in the current public mempool. These separate blocks then are merged into one block by taking the union of all transitions from each of the blocks built by the selected proposers, which are then ordered deterministically by some defined ordering rule. BRAID / MCP is still compatible with inclusion preconfirmations, and therefore will work for rollups that use Vanilla Based Sequencing (i.e. leader-based). The one caveat is that we don’t necessarily know exactly what the ordering rule is going to be, which could have a big impact. For instance, gas-fee priority ordering will mean that transactions that are underpriced will not be included, so that inclusion is probabilistic based on priority fee. Interestingly, emergent market structures could potentially result in more demand for additional sidecar to allow validators to communicate with block builders.
Preconfirmations
Preconfirmations are a way for a validator that has been selected to be a proposer in an upcoming slot to make a commitment to include a transaction in the block that they propose. Initially this came about as a way to optimize based rollups. Rollups that are based-sequenced, such as Taiko or Puffer for example, suffer from the dependency on Ethereum’s block 12 second time. This is not a great UX considering most other centralized rollups can give users confirmation of transaction execution with a second or two, or even milliseconds.
In order to improve UX, preconfirmations allow the L1 proposer to offer a preconfirmation of transactions inclusion on L2 within milliseconds. To do this, the rollup needs to adopt a leader-based sequencer design, where the L1 proposer acts as the sequencer for a rollup, as opposed to Taiko’s current leaderless design, where searchers and builders act as sequencers in a competitive race to land the next block on-chain. A leader-based approach was proposed by LimeChain entitled Vanilla Based Sequencing, which deterministically identifies which L1 validator will be the sequencer for the rollup during each L1 slot, which in turn allows them to offer preconfirmations on transaction inclusion.
Another compelling advantage of preconfirmations is the ability for L1 validators to offer preconfirmations on “super-transactions”, which are bundles of transactions across different based rollups, that are included atomically on the respective rollups. Much of the the work on using based sequencing and preconfirmations for composability is being undertaken by teams in the shared sequencing space, with Espresso having published some research which articulates well how they plan to use based preconfirmations, and as well as plans from Radius to also used based sequencing and preconfirmations.
While there are some concerns around the centralization risk of preconfirmation gateways, whereby all L1 validators simply delegate to a limited number of entities that handle preconfs for them, there is a lot of work being done in the area, and many of the concerns are being proactively tackled head-on by the community, (see this research from Primev as an example).
Blockspace Futures
Selling blockspace derivatives is something that has been explored for some time. Recently, this has become a renewed area of interest as more rollups have started adopting eip-4844 to use blobs instead of calldata. Despite the advantages of eip-4844 in terms of a significant reduction in the cost of DA, there remains some challenges. Some of the biggest users of blobs have relatively low blob inclusion rates, and some based rollups, such as Taiko, are not able to effectively optimize the cost of posting to the base layer. This opens up a space for blockspace futures, particularly in relation to the blob market, and a proposal for how to implement this has been published by Primev.
There is also the possibility of blockspace futures to other actors who wish to hedge against volatile gas costs, by paying a fixed up-front fee for the guarantee that they can post their transaction when they need to without worrying about what the gas cost will be at the time, and having more certainty of inclusion during times of volatile gas prices on L1. Recent research from Blocknative suggests that both priority fee and base fee volatility could increase substantially in the future, making the ability to hedge on gas prices a lot more appealing. The demand for these forms of blockspace futures will likely come from applications that submit bundles of user intents / orders, which could include trading bots like Banana Gun or Alfred, or batch auction OFAs, DEX aggregators, AA bundlers, intent solvers, or even bridges.
Some of the teams that are building solutions to leverage proposer commitments to create a market for blockspace futures include Tai-yi from Luban, and XGA from Manifold Finance, both described in more detail below.
Overview of Solutions being Developed
Commit-boost (sidecar)
Commit-Boost is a new sidecar that validators install, similar to mev-boost. What is unique about Commit-Boost is that it provides a modular framework for installing specific modules that allow the validator to offer specific types of commitments when that validator is selected as a proposer. These proposer commitments can include Inclusion Lists, Preconfirmations, Blockspace Futures etc. This means that validators in theory shouldn’t need to install any other type of sidecar, but instead can simply install Commit-Boost and subsequently modules for various types of commitments. In fact, validators can replace Commit-Boost with their current MEV-Boost installation, and continue to use it to outsource block building to third party builders. A number of teams are already developing modules for commit-boost, including some of the projects discussed below, including Tai-yi.
The main motivation behind the development of Commit-Boost is to create a single piece of software that is modular and extensible and removes the need for validators to install various other pieces of sidecar software with their nodes. The objective is to reduce the fragmentation within the ecosystem in terms of the number of sidecars that exist. The rationale is that the greater the number of different pieces of software that are installed alongside consensus clients, the greater the burden of testing network upgrades, which greatly increases the complexity for future hardforks, causing a major headache for client teams. By offering a single modular sidecar, other teams can create modules for it rather than creating and distributing an entirely separate package.
Currently,, Commit-Boost is being shipped with with two core modules, the PBS module which implements the Builder API, allowing it to talk to mev-boost relays and hence function as mev-boost does today, and the signer module which implements their new Signer API, which allows modules to request signatures for various commitments. Commit-Boost also includes safety mechanisms to help validators manage opsec risk across commitments including telemetry to capture key events and extensions on modules such as PBS to enable additional flexibility. There are other types of custom modules that can be installed, some of the first custom modules being developed include a preconfirmation module and a module for out-of-protocol Inclusion Lists called il-boost.
Commit-Boost is being developed as an open-source, public good that is being developed with contributions from multiple teams across the ecosystem and is being funded by grants from various organizations, and it aims to be as much as possible a community maintained and governance software project. There are now over 70 teams contributing to its development, including receiving development support from teams such as Consenys’ Web3 Signer.
Tee-boost from Flashbots (sidecar)
TEE-Boost is a change to MEV-Boost which allows validators to accept TEE proofs directly from block builders. TEE proofs are essentially proofs that a block is valid and contains a payment to the validator. This fulfills the main part of the role that relays currently play, and which in theory, should remove the necessity for relays.
How it works is that at the start of every epoch, block builders would provide TEE attestations which validators would then verify in order to know which block builders provide TEE-proofs. Builders then provide a proof with every block that is built. Builders can sign the block bid with a key that is generated inside the TEE, which the validators can use to verify that the block builder is running software that leverages the TEE to build only-valid blocks.
The benefit of this approach is that the validators no longer need the relay to verify that a block builder’s block is valid, because each builder supplies a TEE proof with every getHeader response that its block is valid. This means that validators are still protected as they know the block is valid, and that there is a payment to them in the block, and the builder is still protected because the validator only sees the proof, and not the full block contents. This satisfies the requirements that the relay is currently fulfilling, making the relay’s role redundant.
Flashbots are very interested in developing this solution further, though there are still a number of open research questions to address. Two of the more prominent research questions are around multiplexing and data availability. These are two features that relays provide that TEE-boost doesn’t deal with out of the box. For example, how do builders and validators register in order to produce and receive blocks? How do we do this in a way that doesn’t leak validators IP addresses? Right now this is being facilitated by the relays, insofar as the validators register with the relays (of which there are only about 7), and the relays are the only ones to see the validators IP addresses.
Another open question is around how TEE-boost will replace the current escrow service that relays provide, that gives guarantees to validators around releasing the block on time. With relays, once the validator returns the signed block header, the relay releases the block to the network. With TEE-boost, the block builder is fully responsible for releasing the block, and if they don’t, the validator incurs a missed slot penalty.
Overall, TEE-boost is a very interesting design that has the potential to remove the current dependency that the ecosystem has on relays. While it doesn’t mean that it will remove the role of the relay completely, it could greatly reduce the dependency we have, which can only be positive for the ecosystem.
Mev-commit (P2P network)
Mev-commit is a network that is being built by Primev, and which they described as “a credible commitment network used for preconfirmations & more”. Mev-commit is a peer-to-peer network and a blockchain that allows anyone to submit bids for transaction inclusion / execution on other networks. Providers can then provide commitments to those bids, which are subject to slashing if those commitments are not subsequently met.
Anyone can submit a bid on the mev-commit network, such as searchers, solvers, rollups, or end users (i.e. wallets, AA bundlers etc.). Anyone can act as a provider to provide commitments on those bids. Providers could be block builders, relays, rollup sequencers, or individual proposers.
To submit a bid, a bidder needs to have made a deposit to the mev-commit network and they can then make bids up to one tenth of that deposit amount, and they also need to run (or have access to) a mev-commit node. The bids are then sent over the mev-commit P2P network and are picked up by providers, who can choose to issue a commitment. Anyone can be a provider by registering and staking ETH in the mev-commit registry.
Bids are basically a list of transaction hashes (and as of v0.6.0, the entire transaction payload as well), a block number on the target chain which specifies the target for inclusion of the transaction(s), and some values that specify a decay, which means that the bidder pays less the longer it takes for the commitment to be issued. The decay function is to counter the incentive for providers to wait as long as possible to issue commitments so that they can build the most valuable block possible, the decay function acts as an incentive to issue the commitments sooner rather than later.
The transaction hashes can be for transactions that are submitted on any chain, either via the chain’s public mempool or otherwise. Once the transactions have been included on the respective chain, an oracle service updates the mev-commit chain to confirm the transaction inclusion (and any other required conditions) and release payment, or alternatively to apply slashing to the commitment provider in the case that the commitment was not honored.
Mev-commit is an exciting project that can be used to build all sorts of commitment based dapps and features. It has some very interesting features that make it stand out. For one, because bids reference transaction hashes of transactions submitted to other chains, it can be used with a variety of different networks. It will be interesting to see if they will allow individual bids to reference transaction hashes and block heights on heterogeneous networks, which could open up interesting possibilities for cross-chain MEV. The other interesting feature about mev-commit is its privacy. Bids and commitments are encrypted by default, and they need to be ex-post “opened” by either the provider or the bidder, after the block on the respective network has been confirmed. Bidders may choose a subset of providers to allow visibility into their bids, by encrypting the bids in such a way that they can only be decrypted by those providers. This privacy prevents leakage of signal value which is critical for certain use cases.
There are some trade-offs to consider with mev-commit, when deciding to use it for obtaining or offering commitments. For one: it currently relies on a centralized oracle. This means that there are somewhat strong security assumptions with regards to the commitments. Moreover, it means that the only networks that can be supported are those in which the oracle has been deployed to. That being said, Primev have stated that they are “actively looking into decentralizing the oracle role through existing decentralized Oracle protocols and evaluating creating a service where this can be decentralized”. Currently the mev-commit chain is highly centralized, with all validators being run by mev-commit, though it’s highly likely that this will become more decentralized over time. On the other hand, it’s highly efficient, boasting a block time (and therefore commitment time) of 200ms.
The other things to consider, which may or may not impact your specific use case, is all bids need to be collateralized to 10x, which may present a barrier to entry to certain users and is not particularly capital efficient. Another potential barrier to entry is that bidders and providers need to run a node on the mev-commit network. It’s worth pointing out however, that unlike other designs, validators don’t actually need to install a sidecar. Bidders can be searchers, solver, rollup provers etc. who are already fairly sophisticated actors, and so running a node on the mev-commit network is probably not a huge lift, whereas for the validators, the system uses the existing mev-boost implementation, relying on the relay as the control agent (assuming the validator is connecting to at least one relay that has opted-in to mev-commit).
Bolt from Chainbound (sidecar)
Bolt is a system being developed by Chainbound that allows Ethereum validators to offer commitments, which as of today can be inclusion preconfirmations, and which in the future can also be other types of proposer commitments, partial block auctions, blockspace futures etc.
Bolt consists of a piece of software that is installed as a sidecar alongside the validator’s beacon node. The bolt-sidecar acts as a proxy to a fork of mev-boost that has implemented an API that is specific to Bolt, called the constraints-API. The constraints-API allows the validator to communicate any commitments that the validator has made to the relays and block builders, and also allows the block builders to communicate proofs that they have honored those commitments back to the validator.
End users (i.e. wallets, searchers, rollups etc.) can request commitments (i.e. preconfirmations) from the validator through the commitments-API, which is exposed via the Bolt RPC server, which in turn communicates with the bolt-sidecar that is installed by the validator.
If the proposer misses a slot, or if the proposer does produce a block, and block does not contain the transactions that the proposer committed to, then that proposer is temporarily prevented from issuing any further commitments for a period of time. Currently, there is no slashing in Bolt, though slashing may be enabled in the future. When a proposer fails to include a committed-to transaction in the block, a dispute may be opened via the “challenger” contract. The dispute can be opened within 24 hours of the commitment having been issued, and must be accompanied by a commitment that was signed by a proposer. The proposer then has a certain amount of time to supply a proof to repudiate the dispute, which their bolt-sidecar should do automatically.
Any proposer can opt-in to Bolt by registering in Bolt’s registry smart contract, and by providing collateral via an AVS, though this is not implemented for the initial proof-of-concept version. Future versions will also allow proposers to delegate the issuance of preconfirmations to third parties, which could allow them to integrate with preconfirmation gateways or other entities.
What’s interesting about Bolt is that it’s entirely permissionless, and beautifully simple. Any validator can register with the smart contract to start providing preconfirmations, and in the future, other types of proposer commitments. The only other requirement for now is that proposers need to install an additional sidecar, and a modified version of mev-boost. It remains to be seen if this presents a disincentive to validators to opt-in to the Bolt system. That being said, Bolt has also developed a version that runs as a module in commit-boost, which should make it even easier for validators to onboard.
Tai-yi (from Luban)
Tai-yi is a proposer commitment system focussed specifically on preconfirmations. Tai-yi is being built by Luban, and is focussed on providing preconfirmation infrastructure to Ethereum validators.
Tai-yi leverages Commit-Boost and re-staking, along with it’s smart contracts on Ethereum to allow validators to opt-in to providing preconfirmations. Tai-yi’s system is slightly different from other systems insofar as it doesn’t require the transaction originator to specify the transaction data at the time of obtaining the preconfirmation, but allows them to instead specify the transaction data closer to the time of inclusion. In this way Tai-yi’s system resembles something more like blockspace futures.
To request a preconfirmation, the user sends a request with block height and gas limit, as well as pre-payment and after-payment amounts. This request is sent to the preconfer, which is some sophisticated entity that the proposer has delegated to handle preconfirmations for them, such as a preconfirmation gateway. The preconfer runs some validation logic on the transaction, and then sends it to the proposer to sign, then the preconfer signs it, and returns a preconf promise to the user.
The user then has until 6 seconds into the respective block to supply the transaction data. If the user doesn’t supply the transaction data, the preconfer can void the commitment, receiving the pre-payment, but not the after-payment, and avoiding being slashed. There is a nice detail here that disincentivizes the preconfer from not executing the user transaction even if the user has shared the calldata with the preconfirmer, which is that the function also exhausts the amount gas specified in the initial request, meaning the preconfer is no better off for not executing the user’s transaction. If the user has supplied the transaction data, the preconfer is incentivized to include it in order to obtain the after-payment, and to avoid being slashed.
After six seconds into the block, the preconfer shares the entire list of preconfirmation commitments for the block to the relays that have opted-in to commit-boost, so that they can share the commitments with the block builder, ensuring that the transactions are included in the block.
Security is handled through an elegant escrow design. The preconf tip doesn’t go directly to the preconfer, but is instead accumulated in an escrow contract. For the preconfers to withdraw the tips from the escrow contract, they have to submit a proof of inclusion for every respective transaction. If the preconfer doesn’t withdraw within a certain timeframe, then they are penalized.
This system ostensibly works very well, although it does require that the users put up a deposit before they can request preconfirmations. The reason for this is that a user could grief the proposer by withholding transaction data, after all, if the preconfer does not have the transaction data, it cannot include the transaction in the block, hence violating the commitment it made, and leaving itself open to being slashed. To avoid this, the preconfer can void the preconfirmation commitment if the transaction data hasn’t been made available up to six seconds into the block, and this incurs slashing to the user’s deposit. This requires certain trust assumptions on the user’s side, as a preconfer can simply claim that the transaction data was not made available, even if it was, and it would not be possible to prove otherwise. However, rational actors will not do this because they would forgo the preconfirmation after-payment.
Tai-yi’s approach of allowing users to specify transaction data closer to the time of execution is quite interesting. One interesting side-effect is that this opens the door for a secondary market for preconfirmations, which again, makes the system resemble short-term tradeable blockspace futures, which might make it interesting to parties that wish to hedge gas price volatility.
XGA (Manifold Finance)
XGA, or eXtensible Gas Auctions, is a protocol developed by Manifold Finance, who are working with the mechanism design and research team 20 Squares to develop a platform that allows various participants to purchase inclusion preconfirmations from proposers. Similar to Tai-yi, bidders don’t have to specify the transaction to be included until the last moment, making the preconfirmations more like blockspace futures. However, the actual mechanics of this work are quite interesting, as XGA has a unique design.
The auction itself is carried out on a dedicated rollup that is based on Optimism. Participants in the auction can include L2 rollups that bid for L1 blobspace, as well as searchers. From the rollups perspective, they are looking for stronger guarantees of inclusion of the blob transactions, as builders don’t always include blobs because it causes latency to broadcast the block with them included, and so using inclusion preconfirmations as blobspace futures affords more certainty and consistency with inclusion.
The other components of XGA are a custom consensus client sidecar that works with Vouch from Attestant, and a special XGA relay. The sidecar is a modified version of mev-boost, and is backward compatible with mev-boost, and what it does is give the XGA relay priority over other relays when accepting blocks, but also gracefully falls back to other normal relays in case there’s any issue.
To participate, users buy a forward contract on the auction, and upon winning the auction and obtaining preconfirmation via said forward contract, users are free to submit the transaction to the XGA relay. Once the transaction that is submitted is within the gas limit defined by the position obtained via the auction, the transition will be included in the respective block.
Another difference between XGA and other solutions is that users do not need to post any collateral. The auction is permissioned for extra safety, and relies on social collateral, (i.e. play nice or have permissions revoked). This works well because the users in this case are relatively small in number as they are rollups and specialized MEV searchers. There is also an insurance program for proposers in case there is ever any fault with the XGA relay that may cause a missed slot or some slashing, though this is unlikely to happen in practice.
XGA’s market based solution for allocation of blockspace should in theory allow for optimal price discovery and the lack of collateral allows for an easier onboarding of participants. For more information on the details and mechanics of the protocol, check out the following links:
Conclusion
It’s clear that the landscape for proposer commitments is changing quickly. The humble mev-boost sidecar that has served as a critical component of the Ethereum ecosystem for over 2 years now is going to be complemented, or even replaced, by other sidecar software that provides more functionality to the proposer. The demand for blockspace futures from searchers and rollups, as well the demand from based rollups for faster L1 confirmations will provide the initial demand, but there are already other use cases being developed as well, not too mention other potential proposals such as PEPC-DVT and PEPC-Boost.
While this poses a certain risk in terms of increasing complexity in the ecosystem with regards to the number of different sidecars and pieces of software that need to be rigorously tested in future hard forks, there are efforts to effectively address this risk, for example with the commit-boost project. It will be interesting to see the adoption of node operators and staking pools as well as adoption among solo validators. As always, Ethereum continues to evolve in new and interesting ways.
My thanks to the following people for reviewing and giving their feedback:
Nicolas Racchi, Evan Jaewon Kim, Drew Van der Werff, Francesco Mosterts, Francesco Mosterts and Sam Bacha
