Written by the Besu Maintainers.
Besu reaching Quorum...
Cancun is just hitting public testnets and Core Devs are setting their sights on Prague, the next EL update to Ethereum. Scoping is underway from the Besu Maintainers and we wanted to share some thoughts. Besu's team is a little different than many client teams in that we are part of the Hyperledger Foundation. We have a set of maintainers that represent themselves and the project, not necessarily their employers. To that end, we wanted to share our team's take on the Prague fork and what we would like to see.
How the sausage is made
When the decentralized Besu team discusses scope for forks, we like to take a champion-based approach. Maintainers that want to propose or progress scope/EIPs must be the evangelizer, both to the other team members and to the Core Dev community. Below, the champions will break down what they want to see in the next fork and why. Let's get the items we have a complete consensus on out of the way first.
Verkle or Velocity...?
The Besu team is in favor of shipping a Prague fork that excludes Verkle in its current form. This is not to delay Verkle, but to give it more time to bake and for the Besu client to participate in the Kaustinen testnet. We know delaying the transition will cause headaches but view current UX improvements and a more stable transition as paramount. We do want to keep up velocity of shipping improvements on Mainnet and see delaying the next fork to a soft 2025 as unacceptable.
We are the Champions (or, Scope)
In keeping up with velocity, our maintainers propose the following scope...
EOF (Danno)
To streamline Prague planning from the Besu client team, our maintainers propose the following scope...
In-Favor
EOF
Besu advocates for 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.
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 // 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 (Gary, Danno
, Justin)
pros, cons, next steps
- EIP-7377 - EOA Upgrade / Migration Transactions
- EIP-3074 - AUTH and AUTHCALL
- EIP-5003 - AUTHUSURP
- EIP-3607 - Reject transactions from senders with deployed code
- EIP-5806 - Delegate txs
Gotta figure this one out ^^^
//TODO text and decision Danno is cool with anything in 7377, 3607, and 5806 from "ship" to "ship later" to "no opinion", or even "unsuitable"
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.
...
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.
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.
- 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-3068: Precompile for BN256 HashToCurve Algorithms
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
Deposit Flow Updates (Fabio)
pros, cons, next steps
EIP-6110
Have to discus EIP 7002 and decide vs 6110
Inclusion Lists (Justin)
pros, cons, next steps
Do we want to move this to the CREEP section? Or are we ready to champoion?
SETCODE (Daniel)
pros, cons, next steps
Do we have consensus on this one?
// Danno would vote no, but doesn't feel strong enough to actively oppose.
EIP-4444 - History Expiry (Matt)
pros, cons, next steps
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)
...