This document describes EOF impact on existing most popular libraries. We prepared prototypes of changes compile the libraries source codes. Unresolved issues we described and proposed possible solutions. "Required changes to source code" does not contain unresolved issues but sometimes contains TODO comments added to the source code. This is a prototype prepared to verify how EOF impacts these libraries source code and contains local paths in configuration and depends in local build of solidity compiler branch rebased on the branch The first section will be for specific projects, followed by a categorical list of the kinds of changes authors will need to make. Uniswap V4 (core) Required changes to source code: 3 files +9 -6 lines changed
4/27/2025Danno Ferrin, 25 April 2025 Architectural transitions are a familiar chapter in computing history, from the CPUs powering general-purpose computers to the tightly controlled ecosystems of video game consoles and mobile devices. For Ethereum, a hypothetical shift to RISC-V presents a similar challenge: how to evolve without fracturing its vibrant ecosystem. Two contrasting models define the extremes of this transition: the abrupt generational leap of video game consoles and the seamless, compatibility-focused approach of Apple’s Macintosh transitions. By leveraging the Ethereum Object Format (EOF), Ethereum can chart a sustainable path toward RISC-V execution, emulating Apple’s strategy to ensure continuity for Mainnnet, Layer 2s, and other Ethereum-equivalent chains, maximizing compatibility as well as performance. Lessons Learned From Other Transitions But how do we get to RISC-V bliss? Lets see how two other systems handled such transitions: Video Game Consoles and Macs. The Video Game Console Model: A Hard Break Video game consoles, like the PlayStation or Xbox, epitomize the direct-replacement approach. Each generation marks a sharp divide: games written for one system often won’t run on its successor, even if they share a brand. Backward compatibility when offered is typically limited, relying on emulation for a subset of titles, or requiring an upgrade fee to use the features of the new system. This model prioritizes a clean slate, forcing developers to rewrite software and users to invest in new hardware and games. For Ethereum, adopting this approach would be disastrous, creating high-friction “cleavage planes” where users and developers might abandon the ecosystem, as the cost of staying outweighs switching to competing platforms.
4/27/2025:::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/2025