Add EIP: Commit-Reveal Transaction Frames

Merged by EIP-Bot.

Author: forshtat

EIPS/eip-8209.md

@@ -0,0 +1,237 @@
+---
+eip: 8209
+title: Commit-Reveal Transaction Frames
+description: A Frame Transaction extension allowing delaying and concealing execution frame payload
+author: Alex Forshtat (@forshtat), Shahaf Nacson (@shahafn)
+discussions-to: https://ethereum-magicians.org/t/eip-8209-commit-reveal-transaction-frames/28105
+status: Draft
+type: Standards Track
+category: Core
+created: 2026-04-01
+requires: 8141
+---
+
+## Abstract
+
+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.
+
+## Motivation
+
+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](./eip-8184.md) and [EIP-8105](./eip-8105.md).
+
+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.
+
+## Specification
+
+### Definitions
+
+- **Frame Transaction**: A transaction format defined in [EIP-8141](./eip-8141.md) that contains one or more frames.
+- **Frame**: A discrete unit of execution within a Frame Transaction, specifying a target, gas limit, and data.
+- **COMMIT Frame**: A frame that commits to executing a payload in a future block without revealing its contents.
+- **REVEAL Frame**: A frame that reveals and executes a previously committed payload.
+- **Gas Payer**: The entity responsible for paying gas costs, established via the VERIFY frame's `APPROVE` mechanism.
+- **Commitment**: The hash of an execution payload, stored on-chain during the COMMIT phase.
+
+### Design goals
+
+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.
+
+1. Make targeted front-running attacks impossible.
+2. Avoid new cryptographic primitives in the protocol.
+3. Avoid new protocol participant types.
+4. Minimize gas limit and sender metadata leaks.
+5. Allow multiple off-protocol implementations on top of basic protocol primitives.
+
+### Accepted trade-offs
+
+1. Increased inclusion delay for the execution frame.
+2. Accidental non-reveal triggers penalty for users.
+3. Back-running and "speculative front-running" remain possible if not mitigated separately.
+
+### Flow Overview
+
+1. The user creates a Frame Transaction with a single execution frame.
+2. The user hashes the payload of the execution frame.
+3. The user broadcasts the Frame Transaction with its execution frame payload replaced by the payload hash.
+4. The Frame Transaction gets included in block N-1, but only validation frames are executed in block N-1.
+5. The execution frame payload hash is saved in block N-1 by the protocol as a "commitment".
+6. The user has approximately 2 seconds to broadcast the execution frame payload once slot N begins.
+7. The execution frame is included in the beginning of block N, before transactions without prior "commitments".
+
+### Constants
+
+| 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 |
+
+### COMMIT Frame (Mode 0x03)
+
+A COMMIT frame is a new mode in the [EIP-8141](./eip-8141.md) frame transaction format:
+
+```
+frame = [mode=0x03, target=0x00, gas_limit=0, data=commitment_hash]
+```
+
+- `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:
+
+```
+frames = [verify_frame(s), commitment_frame_1, ..., commitment_frame_k]
+```
+
+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.
+
+### REVEAL Frame (Mode 0x04)
+
+A reveal frame is broadcast to the mempool as a separate [EIP-8141](./eip-8141.md) frame transaction:
+
+```
+frames = [reveal_frame1, ...]
+```
+
+The reveal frame uses the same structure as a regular frame payload, but with a distinct mode value:
+
+```
+[mode=0x04, target, gas_limit, data]
+```
+
+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.
+
+### Gas Reservation and Refund Mechanics
+
+#### At Commitment Time in Block N-1
+
+When a frame transaction containing COMMIT frames is included in block N-1:
+
+1. The VERIFY frame executes normally, establishing the gas payer entity via `APPROVE`.
+2. For each COMMIT frame, `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](./eip-1559.md)).
+3. The transaction's intrinsic gas cost ([EIP-8141](./eip-8141.md) `FRAME_TX_INTRINSIC_COST`), including the calldata costs for the commitment hash data, is charged normally to the gas payer.
+4. The transaction receipt records each commitment's index, the gas payer address, and the escrowed amount.
+
+#### At Revelation Time in Block N
+
+1. The `REVEAL` frames execute with a gas budget of `COMMIT_GAS_RESERVATION`.
+2. Gas is priced at block N's actual base fee. No priority fee is charged.
+3. After execution, the refund is calculated from the escrowed amount: `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.
+4. The refund is returned to the gas payer entity that was established during the VERIFY frame in block N-1.
+
+#### On Non-Reveal
+
+If a commitment is not consumed by any revelation in block N:
+
+1. The `COMMIT_GAS_RESERVATION` for that commitment is burned at `max_next_base_fee` as escrowed in block N-1.
+2. No EVM execution occurs - no state changes beyond the gas payment.
+3. The commitment expires and is not valid if revealed in any future block.
+
+### Inclusion Enforcement
+
+#### Fork-Choice Enforcement
+
+Inclusion of REVEAL transactions is enforced through fork-choice by the slot's regular attestation committee, following the same model as [EIP-7805](./eip-7805.md) (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.
+
+### Revelation Shuffle
+
+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.
+
+### Block Validity
+
+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](#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.
+
+### Missed Slots
+
+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.
+
+### Consuming Multiple COMMIT Frames with a Single REVEAL
+
+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.
+
+## Rationale
+
+### Fixed 1M gas reservation
+
+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.
+
+### Two-slot commit-reveal
+
+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.
+
+## Backwards Compatibility
+
+Paymasters must explicitly support COMMIT transactions to provide gas sponsorship for commit-reveal flows.
+
+## Security Considerations
+
+### Speculative Front Running
+
+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.
+
+### Back-Running Mitigations
+
+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").
+
+### Strategic Payload Withholding
+
+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.
+
+### Better Shuffling Randomness
+
+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`.
+
+### Metadata Leak via Gas Payer
+
+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
+
+Copyright and related rights waived via [CC0](../LICENSE.md).