...
To streamline Prague planning from the Besu client team, our maintainers propose the following scope...
...
In-Favor
EOF
Besu advocates for adding EOF to the Prague hard fork.
...
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.
ePBS (TBD)
Pricing Changes
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.
Grab bag (TO-DO)
- EIP-3068: Precompile for BN256 HashToCurve Algorithms
- EIP-5806: Delegate transaction
- EIP-5920: PAY opcode 1
- EIP-6913: SETCODE instruction
- EIP-6914: Reuse validator indices 10
- EIP-7553: Separated Payer Transaction
- EIP-7557: Block-level Warming
- EIP-7594: PeerDAS - Peer Data Availability Sampling
- EIP-7664: Access-Key opcode
No-Brainers
...
The Besu team views the need for 3074 as an opportunity cost. If we do not ship something in Prague, we run the risk of not supporting AA for the next 2-3 years. While this necessarily creates complexity in censorship resistance workstreams, the learnings from implementing AA sooner will allow us to have a better, more informed design where AA transaction validation logic is baked-in. This is a feature, not a bug. Keeping UX on Ethereum stunted for 2-3 years in order to solve some niche MEV challenges via ePBS seems like a poor trade-off.
- EIP-7553: Separated Payer Transaction
- Another tool to help enhance EOA UX, easy to reason about and implement new TX types and test
Supported Grab-Bag EIPs
- 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
- Besu team to run Benchmarks and help with understanding libraries, gas costing, and existing tooling
- EIP-7623: Increase calldata cost
- Happy with costing changes, smaller blocks, lower latency/state, chain ops
- Small implementation in the EL
Neutral/No Opinion
- EIP-7664: Access-Key opcode
- Could be significant EVM work. Do we have an alternative?
- Not sure of necessity
- Might provide better security UX
- 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.
No Opinion
- EIP-7545: Verkle proof verification precompile 1
- EIP-7377: Migration Transaction
- Good migration path for AA, but not instead of an encompassing AA solution like 3074
- EIP-7545: Verkle proof verification precompile 1
- EIP-7609: Decrease TLOAD/TSTORE pricing for common cases 1
- EIP-7623: Increase calldata cost
- Happy with costing changes, leaving to the economists
Anti-Goals (or, creep)
Verkle (Karim)
...
Opposed
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.
Opposed Grab Bag EIPs
- EIP-6913: SETCODE instruction
- Code immutability is questionable.
- EIP-5806 Delegate Transaction
- Weakly Opposed - EIP-5920: PAY opcode 1
- Might break some assumptions of existing smart contracts
- Ether can get stuck in a smart contract that cannot send it
- Users may create issues with stuck Ether and