# EOF "Option D" Summary ## Summary * The `EXTCODECOPY`, `EXTCODEHASH`, and `EXTCODESIZE` opcodes are allowed within EOF containers. Their behavior is the same as when called from outside a container. * Restrictions on creating EOF contracts from existing facilities remains, with `EOFCREATE` and `TXCREATE` opcodes providing contract creation services. * The entire "Ban Gas Introspection" theme is removed. The `CALL`, `STATICCALL`, `DELEGATECALL`, and `GAS` opcodes are allowed within EOF containers. `CALLCODE` is not allowed as it is a deprecated instruction. <!--* The restriction on EOF contracts `DELEGATECALL`ing non-EOF contracts remains, with the same rationale.--> ::: spoiler Summary of EOF opcode changes The list of opcodes not permitted in EOF contracts now consists of 9 instructions, down from 16. * `CODESIZE` and `CODECOPY` instructions, as described in EIP-3540 * `CALLCODE` and `SELFDESTRUCT` instructions, as described in EIP-3670 * `JUMP`, `JUMPI`, and `PC` instructions, as described in EIP-4200 * `CREATE` and `CREATE2` instructions, as described in EIP-7620 The list of opcodes exclusive to EOF containers now consists of 15 opcodes, down from 19. * `SWAPN`, `DUPN`, and `EXCHANGE` instructions, as described in EIP-663 * `RJUMP`, `RJUMPI`, and `RJUMPV` instructions, as described in EIP-4200 * `CALLF` and `RETF` instructions, as described in EIP-4750 * `JUMPF` instruction, as described in EIP-6209 * `DATALOAD`, `DATALOADN`, `DATASIZE`, and `DATACOPY` instructions, as described in EIP-7480 * `EOFCREATE` and `RETURNCODE` instruction, as described in EIP-7620 One opcode added to code in and not in an EOF container: * `TXCREATE` instruction, as decribed in EIP-7873 ::: ## Changes to EIPs There is a small [PR implementing these changes](https://github.com/ethereum/EIPs/pull/9702/files?diff=unified&w=1). * EIPs 7069, 7698, 7761, 7880 are moved from their present state in Fusaka to "DFI" * EIP-3540 * Remove the ban of the `EXTCODESIZE`, `EXTCODECOPY`, `EXTCODEHASH`, and `GAS` opcodes from code in an EOF container. * The behavior of the `EXTCODE*` series of opcodes is extended to code in an EOF container, with all the same semantics. * EIP-7480 updates a rationale section to refer to new behavior, but otherwise remains the same. * EIP-7620 updates the motivation to align with new behavior, but otherwise remains the same. ## Changes to Testing Code * eofwrap will need to be updated to include the previously restricted opcodes as valid opcodes * eofwrap results will be inspected to ensure all existing tests for `*CALL` series opcodes are ported over to EOF. * eofwrap results will be inspected to ensure all existing tests for `EXTCODE*` series opcodes are ported over to EOF. * Tests for `EXTCODETYPE` and `EXTCODEADDRESS` will not be written. * Most EIP-7069 tests for `EXT*CALL` tests will be retired. Tests that validate they do not work in plain bytecode will be extended to cover EOF containers. * Gas testing will be added to the new EOF opcodes * Existing EOF gas testing will be removed, as the tests are complex. <!--Estimated at 12 to 32 hours of work. --> ## Changes to Client Code After finishing eof-devnet-1, these are the remaining changes. * Clients **MUST** update instruction dispatch to add previously restricted instructions so they are valid in an EOF conainer. * Clients **MUST** update other code that otherwise prevents the added operations from working inside an EOF container, if such code exists. * Clients **MUST** remove `EXT*CALL` instructions from their instruction dispatches. * Clients **SHOULD** remove code implementing `EXT*CALL` series opcodes and code exclusively supporting it. Estimated 8 to 12 hours per client, once test code is delivered. ## Changes to Testnet Plan The eof-devnet-1 plan remains as is. The current eof-devnet-2 plan will be significanty revised. Another devnet one to two weeks after eof-devnet-1 is launched will be launced adding the previously restricted bytecodes. The same devnet succes standards as for devnet-1 will be used. It is anticipated that this final eof-devnet will be complete before the May 20th fusaka-devnet-0 launch and will be included. This nets to at least two weeks removed from EOF work, shifting the readyness of EOF protocol changes "left" by at least two weeks. If EIP-7834 (metadata section) is moved to SFI, it would be added in a fusaka series devnet.
Last changed by  
 
ipsilon Ipsilon -- Execution Research
158

Read more

EOF - Solidity library compatibility (initial) report

This document describes EOF's impact on the most popular existing libraries. We prepared prototypes of changes required to compile their source code. We describe unresolved issues and propose possible solutions. "Required changes to the 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 depend on a local build of the experimental Solidity compiler branch enabling block deduplicator on EOF rebased on the parallel branch enabling the constant optimizer. The first section addresses issues found in specific projects, and is followed by a categorical list of the kinds of changes authors will need to make. This document is based on the EOF scope approved in March of 2025. However, based on the findings of this report and the community feedback aroud these changes, Team Ipsilon recommends changes to the spec to reflect "Option D - Introspecting EOF". The adoption of this option will remove most of the required code changes listed in this report. Uniswap V4 (core) Required changes to the source code:

4/28/2025
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, 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
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
Read more from ipsilon
Published on HackMD