I just read the summary of the last ACDC made on twitter by lightclient (excellent work by the way), and if it is true that focusing on the transition to Verkle Trees blocks everything else for at least 12 months and probably 24, then I propose to make at least 1 if not 2 intermediate forks both to add some much-needed features and above all to get EOF through first, which seems to me technically much simpler to implement.
1 Like
EIP-7002 is appearing in a lot of comments here, so it feels like a good opportunity to share a deep dive on EIP-7002 I published recently: EIPs For Nerds #2: EIP-7002 (Execution Layer Triggerable Exits). The article is an attempt to aggregate several perspectives on EIP-7002 I’ve come across (e.g., @TheDZhon’s “execution-layer exits are akin to account abstraction” comment inspired an entire section of the article) and provide a holistic overview of the advantages and potential drawbacks of implementing EIP-7002.
All feedback and comments are welcome.
2 Likes
There is some community push for increasing gas limit. As core devs know this has major drawbacks in latency (network and processing) and storage. Current storage cost is mainly in Blocks and Receipts and not in State. So I propose to prioritise EIP-4444 if we want to consider increasing gas limit in the foreseeable future.
1 Like
I recently published an in-depth explainer on EIP-7251 for those interested in learning more about the proposal to increase MAX_EFFECTIVE_BALANCE from 32 ETH to 2048 ETH and implement in-protocol validator consolidation: EIPs For Nerds #3: EIP-7251 (Increase MAX_EFFECTIVE_BALANCE).
The article explains how EIP-7251 modifies aspects of the consensus protocol like validator activations, deposits, withdrawals, and slashing penalties to enable validator consolidation–while preserving the Beacon Chain’s existing security properties. It also addresses regarding increased slashing risk for large validators and (potential) regulatory issues arising from implementing EIP-7251’s auto-compounding rewards feature. All comments/feedback are welcome.
6 Likes
thanks for writing this Emmanuel! it pulls everything together in a really comprehensive way! 
2 Likes
We at OpenZeppelin are also interested in EIP-7212 since we’re already considering to add a Solidity implementation
3 Likes
Hallo, Paolo from Erigon, We would like to know if there is any opposition in principle to the implementation of EOF by other teams, we believe that EOF is fundamental but we would not like to waste time on a feature that will never be implemented due to the opposition of other development teams. It is not a question of when EOF will be implemented but whether it will ever be implemented.
2 Likes
Following the discussion in the last Execution Layer Meeting (#179), I’d like to discuss EIP-5806. In particular, I’d be open to answerring any questions. I’d also like to have a better understanding of what are the next steps in the development of this EIP.
1 Like
i’d also like to add reduce transient pricing for common cases by charles-cooper · Pull Request #8158 · ethereum/EIPs · GitHub (draft, benchmarks underway) for consideration
As an Ethereum validator and user, I’d like to see Verkle trees and anything else that unblocks state expiry and stateless clients prioritized above all else. I prefer a delay in the next hard fork over shipping other EIPs. PeerDAS is also very interesting, as long as it does not interfere with shipping Verkle trees. And increasing the max validator size is great for solo validators as well.
As an EVM developer, I am opposed to EOF. I am not convinced of the value in creating a new version of the EVM while still forever maintaining past versions. Even if it’s an order of magnitude more efficient, unless there is a plan to disable, remove, or (impossibly?) migrate older code, my main concern is the developer overhead for working with multiple versions of the EVM as well as the increased risk of client bugs.
Upgradeability of EOF contracts could limit this to a small number of versions, but older versions will always exist and will also stop receiving improvements, and minor improvements in efficiency of EOF execution will not be sufficient to encourage a large scale migration.
4 Likes
EOF is not a new version EVM. It is a container format around the existing EVM model and a number opcodes to fix several issues related to technical debt: static jumps, code validation, subroutines, removing code introspection, and removing gas introspection. The core model of the EVM remains the same, and Legacy EVM and EOF can freeley call each other with the exact same semantics. Your traces will look mostly the same (new opcodes aside) and the same techniques you use to develop will be the same. To most smart contract developers it will be nothing more than toggling a switch in solidity or vyper, and your code will also be a little smaller once you do.
The biggest immediate advantage that EOF unlocks it the ability to safely uncap or significantly raise the smart contract size limit (but the block gas limit will always be a mainnet cap). Because of JUMPDEST analysis we have to limit the sizes or open the legacy EVM up to significant DOS attacks. Code validation fixes this.
As for the legacy EVM, deprecating it is totally in my roadmap. But first we need to get EOF out and used before we can ramp up discussion about deprecating new deployments and examining ways to migrate legacy EVM code, if such migrations are required. This would start with closing off deployments of new legacy contracts, or possibly making them progressively more expensive. I see this only ocuring at create transactions, factory contracts (like pools) would necessarily remain as-is.
2 Likes
Quick update:
On ACDE#180, EL teams agreed to move forward with Verkle Tries as the main feature of the Osaka upgrade.
Additionally, EL + CL teams have agreed to include EIPs 6110, 7002 and 7549 in the Prague/Electra upgrade (Meta EIP PR). EL teams had previously signalled desire to include EIP-2537 as well.
On ACDE#181, EL teams are expected to determine which other EIPs should be included in Prague/Electra.
In image form, here’s where we’re at:
6 Likes
Hi Ethereum magicians, I recently published an in-depth explainer on EIP-7251 for those interested in learning more about EIP-6110’s proposal to introduce on-chain validator deposits and deprecate the Eth1-Eth2 bridge in favor of a simple, secure, and more efficient system for delivering deposits to the Beacon Chain: EIPs For Nerds #4: EIP-6110 (Supply Validator Deposits On-Chain).
The article provides historical context for the Eth1-Eth2 bridge and Eth1Data polling mechanism (which underpin the Beacon Chain’s existing deposit processing mechanism) and explores the impact of maintaining both components on node operator UX and the Beacon Chain’s economic security (among other things). It also explores EIP-6110’s approach to reforming the validator deposit process and analyzes the advantages and potential drawbacks of replacing the existing deposit processing workflow with an in-protocol deposit processing mechanism.
All comments/feedback are welcome.
2 Likes
Assuming ~2 million validators is still best estimate for when finality delays/issues start popping up frequently enough, and we’re closing in on 1 million currently - within what timeline do you think something like 7251 is absolutely needed? so if it’s not in Pectra, how big a deal would that be? factoring in EIP-7514 which’ll buy some time now
I hereby would like to propose EIP-7664 ( EIP-7664: Access-Key opcode ) for inclusion in Pectra.
It’s a very minimal new opcode, that serves as alternative to functionality that gets broken with EIP-3074: the ability for a contract to enforce data to be declared statically in a transaction.
2 Likes
Reviewing and implementing EIP-2537 reminded me that it was not the only long forgotten but implemented BLS12-381 EIP.
There is also:
- ERC-2333 - BLS12-381 Key Generation: ERC-2333: BLS12-381 Key Generation
- ERC-2334 - BLS12-381 Deterministic Account Hierarchy: ERC-2334: BLS12-381 Deterministic Account Hierarchy
- ERC-2335 - BLS12-381 Keystore: ERC-2335: BLS12-381 Keystore
Discussion thread: ERC-2333, ERC-2334, ERC-2335: BLS12-381 Key Generation, Deterministic Account Hierarchy, Keystore
Those are all in stagnant status, but in practice they are required to stake and are implemented by all consensus clients already for the past 4 years.
They probably deserve a mention in one Ethereum upgrade, if only to tell hardware providers that “no they aren’t stagnant, they really are THE standard”.
2 Likes
I noticed this issue while looking through EIPs on the Ethereum Improvement Proposals website, too! And it’s not the only stagnant EIP that’s been implemented by clients.
For example, I found EIP-1186: RPC-Method to get Merkle Proofs. EIP-1186 is the standard method for creating Merkle proofs for Ethereum state trie nodes, and I believe most (if not) all Ethereum L2s (and execution clients) have implemented it. Still, the website shows it hasn’t been finalized yet.
I’m sure there are some others I must have forgotten, but there are definitely one or two EIPs/ERCs that are stagnant but have been widely implemented. Probably helps to push them through if folks have tacitly agreed to adopt a common standard.
EIPs for Pectra - Erigon’s stand
The members of the Erigon Team have considered the Pectra candidates, over and above the already included ones.
The EIPs have been categorized as “Favour”, “Neutral”, and “Against”. The following is a summary of our perspectives on these EIPs:
| EIP | Comments |
|---|---|
| [Favour] EOF |
- Speeds up EVM by eliminating the need for the jump destination analysis - Opens the way for potential future improvements such as EVMMAX |
| [Favour] EIP-3074: AUTH and AUTHCALL opcodes |
- A good step towards account abstraction and working around things like sponsored transactions - Better than alternative EIPs in the direction |
| [Neutral] EIP-2935: Save historical block hashes in state |
- Good for light clients - a step towards including ETH protocol within the state - Not urgent - Likely to be modified later to include changes/hacks for Verkle |
| [Neutral] EIP-7212: Precompile for secp256r1 curve support |
- Has applicability for the listed protocols (Apple’s secure enclave, passkeys, android keystore, etc.) and may welcome developers to build efficient apps around them - May not be popular enough yet, viz. a viz Ethereum application |
| [Neutral] EIP-7547: Inclusion lists |
- We do support the idea of having a feature to work around the possible censorship of transactions - Given the practical scenario of proposer-builder separation, this is a welcome step. We also don’t necessarily think that MEV alone can lead to exclusion of transactions |
| [Against] 5806: Delegate Transaction |
- The storage problem could create a bad UX |
| [Against] 5920: PAY opcode |
- This goes against the assumptions of most smart contracts, where something is supposed to be triggered in response to an incoming value transaction |
| [Against] EIP-6404, EIP-6465, EIP-6466 SSZ-(Transaction /Withdrawals /Receipts root) |
- The change in the formats introduces unnecessary additional complexity for the hard fork in terms of data formats, associated tests and many challenges of debugging |
| [Against] EIP-6913: SETCODE instruction |
- Goes against Ethereum’s principles in general - Introduces challenges in UX as it makes it possible to change contracts even beyond known upgrade patterns |
| [Against] EIP-6914: Reuse validator indices |
- Messes up the flow in the code for maintaining the state and indices, especially for historical indices |
| [Against] EIP-7377: Migration Transaction |
- Allowing EOAs to deploy smart contracts onto their accounts is a convoluted task, considering factors like security and upgradeability of general complexities of smart contracts. Potentially dangerous with not many upsides |
| [Against] EIP-7545: Verkle proof verification precompile |
- This should be done in the same upgrade as Verkle (Osaka). Otherwise, it can bind us to a potentially suboptimal early design |
| [Against] EIP-7609: Decrease base cost of TLOAD/TSTORE |
- The updated costs are too low |
3 Likes