Written by the Besu Maintainers.
To streamline Prague planning from the Besu client team, our maintainers propose the following scope...
Scope
EOF
Besu advocates for 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. Generally speaking there are four major themes addressed
- Making EVM code O(n) to JIT and AOT compile
- Eliminating Code Introspection
- Eliminating Gas Introspection
- Make “Quality of Life” improvements easier
The last bullet point enables features in future forks and L2 usages of the evm. L2s can more safely perform wholesale changes to their gas schedule. Experimental and non-conforming EVM features (such as new opcodes) can be signaled with extra header fields. And because JUMPDEST analysis has been replace with deploy time code validation the contract size limit could be safely increased or even uncapped. Team Ipsolon has launched https://evmobjectformat.org/ for a more comprehensive list of features.
Besu's implementation of EOF is nearly complete, awaiting the finalization of a few final details.
EOAs, AA, & Next Steps
* EIP-3074 - AUTH and AUTHCALL
Besu supports adoption of EIP-3074
This EIP was considered and rejected for the London hard fork, almost three years ago, citing security issues. There was a call for a security audit at the time, which has not been done. The EIP would benefit from such an assessment. A major recent update to the nonce handling rules allows for a user to revoke authorizations with a single action. This recent specification change has removed the major safety concerns team members have had.
- EIP-7553: Separated Payer Transaction
- Another tool to help enhance EOA UX, easy to reason about and implement new TX types and test
ePBS (TBD)
SSZ
- EIP-6404: SSZ Transactions Root 18
- EIP-6465: SSZ Withdrawals Root 9
- EIP-6466: SSZ Receipts Root 7
- EIP-6493: SSZ Transaction Signature Scheme
Aesthetics and consistency with the CL is not necessarily a reason to engage on a large bucket of work on the EL.
No-Brainers
EIP-2935: Save historical block hashes in state 2
- Implemented, not complex, brings value after Verkle. Shipping this in Prague will allow us to simplify Osaka for Verkle.
EIP-2537 - BLS Precompile
EIP-7212 - Precompile for Secp256R1 - //Danno - The question is at a rollup address or at a Mainnet address, or both?
No Opinion
- EIP-7545: Verkle proof verification precompile 1
- EIP-7377: Migration Transaction
- EIP-7609: Decrease TLOAD/TSTORE pricing for common cases 1
- EIP-7623: Increase calldata cost
- Happy with costing changes, leaving to the economists
- EIP-3068: Precompile for BN256 HashToCurve Algorithms
- EIP-5920: PAY opcode 1
- EIP-7557: Block-level Warming
- Need to better understand the code complexity
- Might add complexity to the state DB that may add more data, memory, etc. Need to understand the impact to our code.
- EIP-7664: Access-Key opcode
- Could be significant EVM work. Do we have an alternative?
- Not sure of necessity
Anti-Goals
- EIP-6913: SETCODE instruction
- Code immutability is questionable.