:::success "plans are useless but planning is indispensable" - Dwight D. Eisenhower ::: Osaka-0 "Pectra" Theme is to ship what we had at the Pectra split, but merged against "main" in each client. All EIPs as speced when they were cut from pectra Depends on a stable Pectra base
4/18/2025The EVM Object Format (EOF) has ignited ongoing debate within the Ethereum community, aiming to modernize the Ethereum Virtual Machine’s (EVM) structure, add long-requested features, and enable future protocol upgrades. Initially targeting the "Shanghai" fork and refined through Cancun’s testing and Prague’s planning, EOF has garnered significant input from core developers, tool builders, and language teams (e.g., Solidity, Vyper). Yet, as its scope has expanded—from foundational changes like code/data separation to bold proposals like introspection bans—consensus on its final form remains elusive. This document, crafted as a "decision tree for EOF/EVM changes in Fusaka" at the request of Tim Beiko, facilitator of the All-Core-Devs Execution call (ACDE), seeks to reconcile these divergent views by presenting four clear options for how to proceed with EOF. This clarity is vital: feedback often arrives late and conflicted, surfacing after designs are built and tested on devnets or testnets, forcing stakeholders to balance innovation, complexity, and stability post-investment. The recent EOF devnet (eof-devnet-0) and ongoing testnet plans highlight this tension, showcasing EOF’s potential alongside its implementation challenges. To address this, we propose four distinct EOF options for Fusaka: (A) - Complete EOF: The current "Osaka" plan, a comprehensive overhaul with all proposed features. <br/> Historically referred to as "Mega EOF" (B) - Minimal EOF: A leaner version, rooted in the Shanghai-era proposal with minimal alterations.<br/>Historically referred to as "Big EOF" (C) - Baseline EOF: A middle ground, balancing features and feasibility while avoiding controversial bans.<br/>This option is new for this document. (D) - Introspecting EOF: The current "Osaka" plan, removing the Gas Introspection theme and not banning the EXTCODE* Opcodes.<br/>This option is new for this document.
3/25/2025Based on report https://app.codecov.io/gh/ethereum/evmone/commit/26cdd854106cbcbb4d817cfd5e0d2b1ee41bcd21/tree/lib/evmone?flags%5B0%5D=eof_execution_spec_tests&flags%5B1%5D=ethereum_tests&dropdown=coverage . NOTE includes both EOF EEST tests and ethereum/tests (in the process of migration). File Coverage % Comment advanced_analysis.cpp 0.00%
3/20/2025Everything started in a gh thread "EOFCREATE: Don't hash the init-container #162". The thread can be read later for full history and discussion so far. The problem at hand is how to obtain new addresses for EOF contracts created, and more generally - which deployment methods to offer. We have several scenarios we are thinking about. They are of wider scope (not only EOFCREATE), because the deployment-related issues with EOF seem to be larger than that. The structure of the document is that there are several technical options (marked A, B, ...) mixed and matched into few scenarios (marked 0, 1a, ...) which may make sense as ways to tackle our issues. NOTE that any magic prefixes to avoid incidental hash collisions (e.g. with CREATE scheme etc.) are not yet considered for reading simplicity. Scenario 0 - status quo Keep everything as is specced out now:
1/22/2025