How native transaction assertions could enforce a transaction's final outcome
The Ethereum Foundation report examines native transaction assertions as a way to guarantee a transaction’s final outcome. It finds that current defenses like Clear Signing and simulation fall short, and proposes EIP‑7906 to let on‑chain code verify net state changes before finalizing a transaction.
मुख्य बातें
- Signed transactions can still produce unintended results due to code or state changes after signing.
- Blind signing attacks (Bybit, BadgerDAO) and outcome mismatches (Aave/CoW) illustrate the risk.
- Native assertions would let a transaction include a rule that checks net state changes and reverts if violated.
- EIP‑7906 introduces three new opcodes (TXTRACE, TXDIFF, EVENTDATACOPY) to expose post‑execution diffs.
- Adoption requires wallets to embed assertions and protocols to enforce them on protected functions.
- Requested swap value
- $50.4M
- Price‑impact warning
- 99.9%
The problem of transaction certainty
The Ethereum Foundation’s Trillion Dollar Security initiative asks whether a user’s signature can reliably guarantee the economic result they expect. While a signature authenticates the call data, the actual outcome depends on the contract code and blockchain state at execution time. The report cites three high‑profile failures – the Bybit contract‑upgrade attack, the BadgerDAO token‑approval exploit, and an Aave/CoW collateral swap that turned a $50.4 M request into a $36 k receipt – to illustrate both intent and outcome mismatches.
Why existing defenses fall short
Current mitigations such as Clear Signing, transaction simulation, and wallet‑level guards each address a slice of the problem. Clear Signing relies on accurate calldata decoding, while simulation can be invalidated by front‑end malware or state changes before inclusion. Guard contracts can only check pre‑selected variables; they cannot observe the full set of net state changes produced by a transaction. As the report notes, a guard may verify a balance stayed the same but cannot ask the EVM what else changed, leaving many attack vectors unchecked.
Native transaction assertions as a solution
The authors propose native transaction assertions that embed a user‑defined rule within the transaction itself. After the action steps run, a read‑only POST_TX frame evaluates the rule against the net differences in balances, storage slots, newly deployed code, and emitted events. If the rule fails, the entire transaction reverts while still being recorded on‑chain and charging gas, preventing free‑loading attacks. The rule’s source must be independent of any compromised front‑end, ideally coming from a wallet policy or protocol‑level requirement.
Design sketch: EIP‑7906
One concrete design, EIP‑7906, builds on the frame‑transaction model of EIP‑8141. It adds three opcodes – TXTRACE (enumerates net changes), TXDIFF (fetches start/end values for a specific address or slot), and EVENTDATACOPY (copies event data). These opcodes operate only inside the POST_TX frame, ensuring they cannot alter state. Because the assertion is optional, wallets would need to enforce its inclusion for user‑initiated transactions, and protocols could require it for protected functions, rejecting any call that lacks the correct assertion.
Implications and next steps
If adopted, native assertions could raise the security baseline for both end‑users and DeFi protocols, enabling finer‑grained delegation limits and workflow guarantees. However, the approach introduces new complexity: wallet developers must generate appropriate assertions, and contracts must be updated to verify them, which may be challenging for already‑deployed immutable code. The Foundation invites feedback from the ecosystem to refine the design before any network upgrade.
Overall, the report highlights a critical gap in Ethereum’s transaction model and offers a concrete, though still experimental, path toward closing it.