Discussion topic for EIP-8272: Recent Roots for Frame Transactions · Pull Request #11726 · ethereum/EIPs · GitHub
Abstract
EIP-8141 frame transactions can reference recent roots without reading mutable storage during validation. A root source writes roots to a system contract, with each root keyed by (source_id, slot), where source_id derives from the writer address and a salt. A frame transaction may declare recent root references of the form:
(source_id, slot, root)
Before frame execution, clients check each reference against the transaction pre-state. The check succeeds only if the named root is stored for the named source and slot, and the slot is still recent. Validation code can then read the verified reference through transaction introspection.
Motivation
EIP-8141 validation must not read arbitrary storage controlled by another account or application in the public mempool. Some validation rules still need to depend on recent application state, such as privacy tree roots, wallet authorization roots, or account validation roots.
Recent root references let a transaction explicitly name recent roots in its signed transaction envelope. Each reference maps to one system-contract storage key and can be checked before validation code runs.
Privacy applications, for example, keep a tree of commitments and prove spends against a recent tree root. With this EIP, the application writes roots by slot, and spend transactions reference one of those roots directly instead of reading the application’s changing tree state during validation.
3 Likes
Hello @soispoke
I am trying to learn more about EIP-8272, and I have a quick question.
Now that EIP-8141 firmly has a concept of “canonical” contracts (paymaster, expiry verifier, deterministic factory) that basically have exceptions for the mempool validation rules, I am wondering what parts of the Recent Roots contract can’t be achieved with a similar “canonicalization”.
I was thinking, what if the Frame Transaction has a “Recent Root Validation Frame” (similar to existing “Expiry Verifier Frame”) with frame calldata (not elided any more afaik) interpreted as the recent_root_references array targeting a canonical RecentRoots contract.
Do you think a frame like that can have all the properties a privacy pool would need from EIP-8272?
Thanks!
1 Like
Hi @alex-forshtat-tbk!
Thanks for your feedback,
Yes I think this could work and is actually quite close to Clarify recent root references in EIP-8141 by nerolation · Pull Request #25 · soispoke/EIPs · GitHub by Toni, one important thing would be to make sure the recent roots frame runs before any frame that depends on it (e.g., [recent_roots?] [deploy?] [account validation] [execution...])
To me the the core trade offs are:
| Envelope field |
Recent Roots frame |
| Roots are part of the transaction and checked before any frame runs |
The check happens during frame execution, so the frame position matters |
| Requires a change to the transaction encoding and a new introspection opcode |
Reuses the existing EIP 8141 encoding and introspection opcodes |
| Clients can identify the references directly |
Clients must recognize the special frame and parse its calldata |
1 Like