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
Citing Lukasz as the topic of āincreasing the gas limitā is more prevalent than ever, thinking of recent pushes like https://pumpthegas.org/ .
Furthermore, thereās already an EIP for increasing the blob count, which might also need a block size reduction as a prerequisite.
In addition, parts of the community have expressed clear demands to increase the gas limit and/or increase the blob count, and they must not be ignored (thinking of the upcoming year(s)).
While the current max block size doesnāt leave much room for such increases, EIP-7623 proposes to increase the calldata costs for calldata-heavy transactions, thus reducing the max block size from 3.5 MiB (incl. blobs) to 1.9 MiB.
The goal of the EIP was to keep the impact on users as small as possible while still achieving the goal of reducing the max. possible block size. Find the latest analysis on the EIP here:
https://nerolation.github.io/eip-7623-impact-analysis/index2.html
The changes needed are very small. Same for the impact (99% of user wonāt feel any difference) and the majority of those 1% that are affected are users that put messages into tx (so there are better alternatives than Ethereum L1 anyway). Some non-DA use cases that are affected are big proofs like STARKs (~30% more gas) or on-chain merkle-proofs.
In my opinion, EIP-7623 paves the way for further scaling and should be included in Pectra.
3 Likes
Extending on SSZ EIPs:
- EIP-7495: SSZ StableContainer (dependency of EIP-6493)
- EIP-7688: Forward compatible consensus data structures (unlocks forward compatible CL verifiers)
Furthermore, light client EIPs:
- EIP-7657: Sync committee slashings (synergizes with max-eb)
- EIP-7658: Light client data backfill (unlocks decentralized beacon node syncing)
2 Likes
@radek I think the window for proposing EIPs in Pectra is pretty close to finished. If you would like to see this included, you will need to find a champion to present on ACD this week.
1 Like