This EIP builds on top of Frame Transactions to introduce a mechanism of front-running protection using a simple commit-reveal scheme for transaction frame payloads.
It introduces two new frame modes called "COMMIT" and "REVEAL". The "COMMIT" frames serve as both user commitment and an inclusion guarantee in block N-1, and "REVEAL" executes the payload in block N.
This approach avoids any enshrined cryptography, new consensus participant roles, or slowdowns on the critical path during block building.
Current Ethereum transactions expose their full contents in the mempool before they are ordered or included in a block. This puts users in a vulnerable position and enables privileged participants, often known as "MEV searchers", to perform attacks against users, such as front-running, sandwiching, back-running, censorship, and others.
The outsize profitability of these attacks has in turn led to an extreme concentration of block building power in the hands of a small number of the most efficient value extractors.
Simply by introducing a delay between transaction inclusion and revelation of transaction payload, we make these attackers lose most of their advantage over regular users. Existing proposals to address this issue introduce encryption to the P2P mempool directly; see EIP-8184 and EIP-8105.
Such advanced mechanisms, when operating in sub-slot timelines with in-protocol encryption, may achieve some better properties; however, the complexity of such solutions may prevent them from being adopted by a rapidly scaling Ethereum blockchain.
APPROVE mechanism.The purpose of this proposal is to minimize the user exposure to the most common, efficient and practical value extraction strategies while remaining pragmatic with regard to some more sophisticated potential extraction vectors.
| Name | Value | Description |
|---|---|---|
| REVEAL_DEADLINE | 2 | Seconds into the slot by which revelations must be broadcast to get guaranteed inclusion |
COMMIT_GAS_RESERVATION | 1_000_000 | Gas reserved per COMMIT frame |
MAX_COMMITS_PER_BLOCK | block_gas_limit // COMMIT_GAS_RESERVATION | Maximum COMMIT frames per block |
A COMMIT frame is a new mode in the EIP-8141 frame transaction format:
mode = 0x03: COMMIT.target = 0x00: No contract is called during commitment.gas_limit = 0: The frame itself does not execute EVM code.data = commitment_hash: 32-byte keccak256 hash of the execution payload.A frame transaction containing one or more COMMIT frames MUST have the following structure:
This means the included transaction is valid and execution gas is paid in advance in the current block. There is no need for the verifying frames to reveal any direct information about the execution payload sender.
A reveal frame is broadcast to the mempool as a separate EIP-8141 frame transaction:
The reveal frame uses the same structure as a regular frame payload, but with a distinct mode value:
All REVEAL frame transactions MUST be included in the top of block N, before any other transactions.
A transaction cannot mix REVEAL frames with any other frame modes.
When a frame transaction containing COMMIT frames is included in block N-1:
APPROVE.COMMIT_GAS_RESERVATION is charged to the gas payer at the maximum possible next-block base fee, calculated as max_next_base_fee = base_fee * 1.125 (see EIP-1559).FRAME_TX_INTRINSIC_COST), including the calldata costs for the commitment hash data, is charged normally to the gas payer.REVEAL frames execute with a gas budget of COMMIT_GAS_RESERVATION.refund = escrowed_amount - (gas_used * block_N_base_fee). Since the escrow was charged at the maximum possible base fee, this always covers block N's actual base fee.If a commitment is not consumed by any revelation in block N:
COMMIT_GAS_RESERVATION for that commitment is burned at max_next_base_fee as escrowed in block N-1.Inclusion of REVEAL transactions is enforced through fork-choice by the slot's regular attestation committee, following the same model as EIP-7805 (FOCIL) inclusion list enforcement.
During the first REVEAL_DEADLINE seconds of slot N, all validators listen on the mempool and independently record which COMMIT frame indices received valid revelations. Each attester maintains its own local view of observed revelations.
At attestation time, each attester evaluates block N against its local observation record. For every commitment index where the attester observed a valid revelation before the deadline, block N MUST include the corresponding revelation. If block N omits any revelation the attester observed, the attester MUST NOT attest to that block, causing it to lose fork-choice weight and making it non-canonical.
The builder is therefore incentivized to include all revelations it has seen, since omitting any risks losing attestations.
The execution order of revelations in block N is determined by RANDAO. The shuffle seed is independent of commitment inclusion in block N-1 or revelation payload contents, preventing users or builders from manipulating the execution order.
At most MAX_COMMITS_PER_BLOCK of COMMIT frames MAY appear across all transactions in the block. This cap ensures that all revelations fit within the block gas limit of block N.
Block N MUST begin with a contiguous sequence of REVEAL transactions, followed by any number of regular transactions. No other transactions MAY precede or be interleaved with REVEAL transactions.
Revelations MUST appear in the randomized order determined by the Revelation Shuffle.
For every commitment in block N-1 that received a valid revelation broadcast on P2P within REVEAL_DEADLINE seconds, block N MUST include the corresponding revelation. This is enforced through fork-choice: attesters who observed a timely revelation MUST NOT attest to a block that omits it.
All REVEAL frames must correspond to an existing unconsumed COMMIT frame hash.
If a block is not created for slot N, the COMMIT frames do not expire and must be included in the block at slot N+1, until a valid block is produced. The original REVEAL transaction remains valid and will be included when a valid block is produced. This guarantees there is no risk in revealing the payload once block N-1 is confirmed.
In order to allow REVEAL transactions with gas limits larger than COMMIT_GAS_RESERVATION, a REVEAL frame can indicate multiple COMMIT frames that will be consumed.
A variable gas reservation would leak information about the transaction's gas requirements. By fixing the reservation at 1M gas and allowing multi-commitment consumption, the actual gas limit is hidden within a range of [0, k * 1M] where k is the number of commitments. The 1M figure balances cost: large enough to accommodate most DeFi transactions in a single commitment, small enough that users needing more gas can split across a manageable number of commitments without excessive non-reveal penalty.
Same-slot execution requires the builder to commit to transaction ordering before seeing execution results, creating a potential for invalid transactions to occupy block space. Two-slot separation allows the revelation to be validated before inclusion.
While this increases a perceived inclusion delay, in the optimal case the users may consider their transactions "included" already in block N-1. Revelation of the payload in block N is a technicality as the REVEAL payload executes before any transactions created after block N-1 was finalized.
Paymasters must explicitly support COMMIT transactions to provide gas sponsorship for commit-reveal flows.
While targeted front-running attacks are not possible without advance knowledge of transactions' execution payloads, attackers can still pre-fill block N-1 with multiple front-running transactions wrapped in a COMMIT frame.
When block N arrives, they can decide which front-runs to reveal and execute to maximize their profits.
While this cannot be fundamentally prevented by our design, it is significantly mitigated by setting a low MAX_COMMITS_PER_BLOCK, high COMMIT_GAS_RESERVATION, and a more randomized shuffling.
The blockchain state that appears as a result of executing all MAX_COMMITS_PER_BLOCK and their corresponding REVEAL frames may be full of value extraction opportunities, such as arbitrage, liquidations, unclaimed assets, etc.
This appears to be an inherent property of a blockchain and cannot be fully mitigated. Even if the entire block payloads were encrypted in block N, the first transaction of block N+1 would have a great advantage in extracting the accumulated value. One could argue that this is the expected behavior of the system and does not require fixing.
However, in a future update, this value can be captured by the protocol as well. For example, this can be achieved by auctioning off the position below the REVEAL block to the "highest bidder" (or "highest burner").
The users of COMMIT transactions do get another, less intentional advantage over regular transactions.
They get to observe the world for the entire duration of slot N-1, including the plaintext transactions in block N-1, and get to make a strategic decision on whether to publish their REVEAL frame or to forego the "escrowed" COMMIT_GAS_RESERVATION fee.
We argue this is not inherently unfair to other users, as the execution payload is not known to anyone in this case, so it might as well not exist.
All the COMMIT transaction therefore does here is it grants users a top spot in the upcoming block. This is different but not necessarily worse than the current priority fee-based ordering of transactions in the block.
With RANDAO-based shuffling, users cannot usually predict the order of their transactions, but the block builder can as soon as it generates the RANDAO.
A stronger shuffling scheme could use a Shuffle Committee, for example a set of N randomly selected validators who contribute verifiable randomness only after the REVEAL_DEADLINE.
The "gas payer" used in the VERIFY frame may reveal information about the sender of the COMMIT transaction.
This may be largely mitigated if the "gas payer" is a public, well-known contract with a big and diverse set of users.
Copyright and related rights waived via CC0.