:::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/2025Options Here are the options for EOF bootstrapping which are considered in combination with TXCREATE opcode and the InitcodeTransaction, as specced in EIP-7873. Current status (EIP-7873 with legacy EVM code enabling TXCREATE opcode) is good, but there was feedback that some features (improvements on multichain deployments and having a default deployment method) would still be nice to have and there are alternatives to consider. The doc attempts to gather these in one spot and list their differences. For the reference, EIP-7873 specifies that TXCREATE calculates new_address as keccak256(0xff || sender32 || salt)[12:]. NOTE that (1.) and (2.) are previous designs which are kept here only for reference, as they both have been superseded by the baseline (3.) (* obsolete previous design) Creator Contract predeploy (* obsolete previous design) EIP-7698 - eof creation tx with to: nil and EOF initcontainer prepended to input calldata in tx.data Allowing TXCREATE in legacy EVM, disallowing to: nil for InitcodeTransactions (current EIP-7873)
4/15/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/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