...
EIP | Status | T-shirt Size | PR | Besu POC or Champion? | Notes |
|---|---|---|---|---|---|
Driver? EOF | CFI | XL | Danno Ferrin | Let's us ship faster and include more EIPs while giving Verkle more time to build and test. Shippable state in Besu right now. Mega EOF branch is nearly up to date. Engineering work mostly worked out. Validation rules to be updated. Tests to be updated. Testnets need implementations from Vyper/Solidity → needs spec freeze. Need compiler support. Timing → Q3 for testnet rollout Fork gated on time for fuzzing finding nothing. Running week(s) without issue. | |
| Driver? Verkle Tries | CFI | XXL | Karim Taam, Stefan Pingel, Gabriel Fukushima | The longer we delay the transition, the bigger the headache. Tons of value to users and devs, but more complexity. | |
| EIP-2537 - BLS Precompile | CFI | S | Justin Florentine | Ship - updated to use Gnark? Signature aggregation for smart contract wallets | |
| EIP-3074 - AUTH and AUTHCALL | CFI | M/L | TBD | Should talk to wallet providers Danno - View unsafe as no revocation. No inclusion without it. Justin - Hesitations from MM team and Consensys | |
| EIP-4444 - History Expiry | CFI | S/M | Matt Nelson, Gary Schulte | Need to implement Portal proxy in Besu. Entirely optional! | |
| EIP-6110 - In-Protocol Deposits | CFI | S | 5055 5295 5752 | Fabio Di Fabio, Simon Dudley | Ship - reference implementation ready |
| EIP-6913 - SETCODE OpCode | CFI | S | Daniel Lehrner | Lukewarm - small improvement on status quo | |
EIP-7002 - Execution layer triggerable exits | CFI | M | 6783, 6801, 6883 | Lucas SaldanhaTBD | Should talk to some staking providers first |
EIP-7212 - Precompile for Secp256R1 | CFI | S | Matt Nelson | ||
EIP-7251 - Maximum Effective Balance Increase | CFI | NA | - | CL only | |
EIP-7377 - EOA Upgrade / Migration Transactions | CFI | ?? | Gary Schulte | ||
EIP-7547 - Inclusion lists | CFI | L or XL | Justin Florentine | ||
EIP-7549 - Move committee index outside Attestation | CFI | NA | - | CL only |
Verkle vs. EOF
EOF First, Verkle Second (Pros & Cons)
Pros
- Ready to ship this year. Verkle is not
- Necessary step to safely increase the code limit sizes
- EOF can be safely codesize uncapped
- EOF storage and verkle tree → Compatible by chunking into 32bytes and storing in sequence
- Jumpdest validation is what causes issues
- 31 byte in verkle may be overfitting to legacy EVM impl.
- Good for zk
- Dynamic jumps
- Only have static jumps in EOF
- Static register reallocation
- Stack height validation requirements
- Cross-compilation
- No-code introspection in EOF
- More time to work on Verkle
Cons
- "Small feature fork scope" might not allow for EOF
- Consensus risk (long period of testing?)
- Layer 2 zk development will take time to adopt
Verkle First, EOF second
Pros
- Shorter migration and less state to migrate !!!
- Less complexity of adding EOF EVM and adding risk
- Verkle functionality improvements (getting the stuff faster)
- More time for L2s to adopt EOF
- Verkle not mandatory for immediate fork coverage
Cons
- More time to work on Verkle if we ship second