Written by the Besu Maintainers.
To streamline Prague planning from the Besu client team, our maintainers propose the following scope...
Scope
EOF (Danno)
Besu supports adding EOF to the Prague hard fork.
The EVM Object Format is a collection of smaller changes aiming at paying down a significant amount of technical debt that the EVM has accrued over nearly a decade, and prepare the EVM so that "calcification" can occur on a robust foundation. EOF does not fundamentally change the execution of the EVM, instead it introduces a container format and migrates key instructions to new formats that resolve long standing problems such as eliminating dynamic jumps and the associated JUMPDEST analysis. An incomplete bullet point list of benefits
- EOF contracts will typically be smaller than legacy contracts (~1%-3% in typical cases and 20% in extreme cases).
- EOF contracts can safely have unlimited size, while doing the same for Legacy EVM code would require over 10% more code storage
- EOF contracts can reliably be AOT compiled to traditional or ZK languages because of code validation, stack validation, and static jump operations
- EOF contracts enable eliminating Code observability and Gas observability, paving the way for a full ZK migration of the execution layer.
There are so many cool features an entire website is needed to explain them.
// Team ipsilon is launching https://evmobjectformat.org/ next week
EF Devops is aiming to get a dev net started in March, which Besu aims to join. We anticipate being fully ready with the full EOF spec by then, as our current prototype has the core and most difficult features already implemented. This spec is derivative of the "Big EOF" spec, of which Besu, Nethermind, Geth, and EthereumJS were all participating with on the "Shandong" dev net in early 2023.
EOAs & Next Steps
pros, cons, next steps
The following two EIPs as currently written are unsuitable for fork scheduling.
* EIP-5003 - AUTHUSURP
This EIP provides the same category of functionality seen in EIP-7377, except in the form of an opcode driven by external data. From a UX perspective this introduces unique risks not present in 7377. A transaction may or may not result in an account migration depending on smart contract logic. The process of upgrading in 7377 is unambiguous and direct: the account will be migrated if the transaction reaches consensus. Furthermore wallets can appropriately detect such actions and warn users as needed, whereas a smart contract activated migration can be constructed to make such warnings unreliable. Shipping EIP-7377 would be better, as would waiting for better EOA evolution alternatives.
* EIP-3074 - AUTH and AUTHCALL
EDIT: NONCE CONSIDERATION
This EIP was considered and rejected for the London hard fork, almost three years ago. There was a call for a security audit, which has not been done. Many of the security concerns have not been addressed, and the recent change to add nonce support still permits eternal authorizations. Furthermore wallet providers such as MetaMask are hesitant to provide support for this feature. Unlike constructions like Permit2, ERC-20 allowances, and ERC-4337 smart contract wallets, the side effects of 3074 authorizations impact all users of the EVM, not just contracts that opt into such semantics.
Inclusion Lists (Justin)
pros, cons, next steps
Do we want to move this to the CREEP section? Or are we ready to champion?
Grab bag (TO-DO)
- EIP-2935: Save historical block hashes in state 2
- EIP-3068: Precompile for BN256 HashToCurve Algorithms
- EIP-3074: AUTH and AUTHCALL opcodes 1
- EIP-5806: Delegate transaction
- EIP-5920: PAY opcode 1
- EIP-6404: SSZ Transactions Root 18
- EIP-6465: SSZ Withdrawals Root 9
- EIP-6466: SSZ Receipts Root 7
- EIP-6493: SSZ Transaction Signature Scheme
- EIP-6913: SETCODE instruction
- EIP-6914: Reuse validator indices 10
- EIP-7212: Precompile for secp256r1 Curve Support 1
- EIP-7377: Migration Transaction
- EIP-7545: Verkle proof verification precompile 1
- EIP-7553: Separated Payer Transaction
- EIP-7557: Block-level Warming
- EIP-7594: PeerDAS - Peer Data Availability Sampling
- EIP-7609: Decrease TLOAD/TSTORE pricing for common cases 1
- EIP-7623: Increase calldata cost
- EIP-7664: Access-Key opcode
No-Brainers
EIP-2537 - BLS Precompile
EIP-7212 - Precompile for Secp256R1 - //Danno - The question is at a rollup address or at a mainnet address, or both?
Anti-Goals (or, creep)
Verkle (Karim)
Pros, cons, why not now?