# EOF: Ethereum’s Gateway to RISC-V Execution *Danno 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](https://en.wikipedia.org/wiki/List_of_backward-compatible_games_for_Xbox_One_and_Series_X/S), 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. ### Apple’s Model: Continuity Through Innovation In contrast, Apple’s Macintosh line has navigated multiple ISA transitions with remarkable finesse: from Motorola 68k to PowerPC, then to Intel x86, and now to ARM-based Apple Silicon. Each shift prioritized interoperability, ensuring older software remained functional through emulation or transpilation. In the Motorola-to-PowerPC transition a RISC emulator was used to run 68k code. Later transitions introduced Rosetta (and Rosetta 2 for Intel-to-ARM), a transpiler that dynamically converted prior-architecture binaries to the current ISA. Apple further streamlined the process with “Universal Binaries,” containers holding equivalent code for multiple architectures, with the system selecting the appropriate version at runtime. This approach minimized disruption, empowering developers and users to transition at their own pace. ### Ethereum’s Choice: Apple’s Path, Not Consoles’ For Ethereum, transitioning to a RISC-V-based execution environment demands Apple’s compatibility-driven strategy, not the hard break model of video game consoles. A forced migration to RISC-V, requiring developers to rewrite smart contracts and users to adapt to a new paradigm, would risk alienating the ecosystem of Layer 2s and alternative chains. EOF, with its structured bytecode and metadata, serves as Ethereum’s Rosetta, enabling safe and efficient transpilation of existing EVM contracts to RISC-V while supporting native RISC-V development. By adopting this approach, Ethereum can evolve into a RISC-V-powered future without sacrificing the interoperability that defines its strength. ## The RISC-V Endgame: Ethereum’s Execution Environment To chart the path to RISC-V, let’s work backward from a future where all Ethereum execution occurs on RISC-V, then work backwards to the current state. ### End State: Full RISC-V Execution Imagine Ethereum in 2030, where: * All Execution is RISC-V: Every smart contract executes natively on a RISC-V-based virtual machine (RVM). The EVM is retired, and nodes run RISC-V bytecode directly. * Performance Gains: RISC-V’s simplicity and modularity enable faster execution, lower gas costs, and easier hardware acceleration. * Developer Ecosystem: Developers write contracts in high-level languages (e.g., Solidity) that compile to RISC-V bytecode, with robust tooling and libraries. * Standardization: RISC-V is the canonical ISA for Ethereum, with standardized extensions for cryptographic operations and blockchain-specific tasks. ### RISC-V Backend, EVM or RISC-V Front End (2027-2029): But we don't get there in a single giant leap. Before we shut out all EVM bytecode (both inside and outside of an EOF container) we live in a hybrid world. And there is also the possibility this is the endstate too, non RISC-V code is charged a premium that goes up with time. * Ethereum nodes support dual execution: EVM for legacy contracts and RVM for new RISC-V contracts. * Developers can deploy RISC-V contracts, which are compiled to RISC-V bytecode and executed natively. * A Rosetta-style transpiler converts all EVM in an EOF container to RISC-V at runtime for legacy contracts, ensuring compatibility. * This is for EOF contracts that are not compiled as "universal binaries" and contain code for both architectures. * A full intrepreted EVM is available for EVM contracts not in an EOF container that do not meet the requirements for transpilation, at a significant execution cost. * EOF is mandatory for new contracts, providing a clean interface for both EVM and RISC-V execution. * Developer tooling adds native RISC-V output as an option, when direct execution is preferred over transpilation. ### EOF Adoption and Transpiler Maturation (2025-2027): Even then it will take a while to spec out how RISC-V is even integrated into the Ethereum stack. That leasts us to the post-Fusaka world with EVM in EOF containers and as plain bytecode. * Ethereum fully adopts EOF, which introduces a structured bytecode format with metadata, versioning, and subroutine isolation. * EOF containers enable safer transpilation by clearly separating code, data, and stack, reducing edge cases and undefined behaviors. * Developers begin writing EOF-compliant contracts, which are easier to transpile to RISC-V. Developer tooling outputs EVM code in an EOF container first as an option, and later as a default. * Early RISC-V prototypes emerge, with nodes optionally supporting RVM for testing. ### Current State: Legacy EVM (2025): That brings us to today. * All Ethereum execution occurs on the EVM, using its original, un-structured bytecode. * Developers write Solidity or Vyper contracts that compile to EVM bytecode, unaware of RISC-V. * No container format exists to express the notion of a "universal binary" * No VM restrictions exist to prevent "JIT bombs" or other transpilation problems. ## The Role of EOF in Transpilation EOF containers are the grease on the skid for this transition, particularly in enabling Rosetta-style transpilers. The current EVM bytecode is a mess: it lacks versioning, has ambiguous jump destinations, and allows dynamic code modification, making transpilation error-prone. EOF addresses these issues by: * **Structuring Bytecode**: EOF introduces containers with distinct sections for code, data, and metadata, eliminating dynamic jumps and self-modifying code. * **Versioning**: EOF’s versioning allows nodes to identify and handle different bytecode formats, ensuring compatibility during the transition. * **Subroutine Isolation**: EOF’s subroutines improve code modularity, making it easier to map EVM opcodes to RISC-V instructions. * **Metadata**: EOF includes metadata about stack and memory usage, enabling transpilers to optimize RISC-V output without exhaustive analysis. These features make transpilation safer and more efficient. For example, a transpiler can map EOF’s structured opcodes to RISC-V instructions with predictable behavior, avoiding the pitfalls of legacy EVM’s unstructured jumps. This is akin to how Rosetta 2 leverages Mach-O binary metadata to translate x86 to ARM efficiently. Without EOF, transpiling EVM to RISC-V would be like translating a handwritten manuscript with missing pages—possible, but fraught with errors. ## Seizing the RISC-V Future with EOF Ethereum stands at a pivotal juncture, with the opportunity to evolve its execution environment from the legacy EVM to a RISC-V-based future that promises performance, scalability, and zero-knowledge optimization. The EVM Object Format (EOF) is the critical enabler of this transition, acting as Ethereum’s Rosetta to ensure seamless compatibility through structured bytecode and efficient transpilation. By emulating Apple’s interoperability-driven approach rather than the disruptive console model Ethereum can preserve its vibrant ecosystem of Layer 2s and alternative chains while embracing RISC-V’s potential.
Last changed by  
 
ipsilon Ipsilon -- Execution Research
636

Read more

EOF - solidity libraries compatibility (initial) report

This document describes EOF impact on existing most popular libraries. We prepared prototypes of changes to 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. ⓘ Note: The prototypes make use of local paths in configuration and depends in local build of solidity compiler branch rebased on this 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/2025
Osaka Testnets Plan

:::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/2025
EOF bootstrapping

Options 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/2025
EOF Fusaka Options

The 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
Read more from ipsilon
Published on HackMD