As of 29 Mar 2025 Repositories ethereum/execution-spec-tests - main branch shemnon/execution-spec-tests - eof-fuzz branch holiman/goevmlab - main branch Required Tools The following tooling is needed, and we rely on the reader knowing how to install these tools

This meeting covered the following topics: Whether to include EOF in Pectra Spec updates Interoperability with other EIPs Chatham House Rule The meeting was conducted under the "Chatham House Rule" - anyone who comes to a meeting is free to use information from the discussion, but is not allowed to reveal who made any particular comment. Whether to include EOF in Pectra

Preimages Precompiles EVM's escape hatch Agenda This is not a cryptography presentation What are Precompiles (with mainnet examples) How do they work? Use outside MainnetL2 use and Alt L1 use

These are just the opinon of @shemnon and not binding on any other contributors. Tier list Tier 1: Removing items from Legacy EVM Opcodes Removed Stuff we need to get rid of (no replacement or replacements already exist) SELFDESTRUCT CALLCODE Code Introspection:

Add precomputedCalls as a third option to state and stateDiff. This would be a simple, gas-perfect, mapping of input data to output data with no calculations. It is an array of precomputedCall objects input - either a hex string or "*". The former must match the call exactly, and the latter matches all calls. output - the resulting output bytes as hex. If absent it is presumed to be zero bytes. gas - The gas to charge for the call. If there is not enough gas passed in as part of the call then standard OutOfGas handling applies. If absent MAX_GAS is presumed. (alternately, required) status - If the call should fail a 0x0 should be present. If it passes 0x1. For success calls output is the result, for failed it is the revert data. For each address only one wildcard is permitted, and only one input per mapping is permitted. (alternately, we could structure this as a map where input is key, but it would reduce readability) {

Pre-reads Mega-EOF - every possible feature in on version of EOF Big EOF contents (What was already iplemented for Shanghai)EIP-3540: EOF - EVM Object Format v1 history EIP-3670: EOF - Code Validation history EIP-4200: EOF - Static relative jumps history EIP-4750: EOF - Functions history EIP-5450: EOF - Stack Validation history Mega EOF Additions

Tier I - Breaking Changes Tier II - Address Feature Regressions Tire III - Address cost/size regressions Tier IV - New features EOF Evolution Model Compatible Changes Compatible changes don't require a new EOF version. Add new functionality or features without removing or altering other functionality or features

In general, replace CREATE3/CREATE4 with CREATEF, where the same executing contract is used for initcode, but a different code section other than 0 is used. Problem Using the factory pattern will require two levels of nesting if done in a EOF container. First there is the executing container, then there is the container that holds the exec code, then there will be the deployed contract itself. +-----------------------------+ | Factory Contract | | +-------------------------+ | | | Child contract initcode | | | | +----------------+ | |

Summary ECA aggregates and republishes EIPs and ERCsEIP and ERC are still expected to publish in some fashion Relies on "Curators" to make needed edits and participate in EIP/ERC/<future org> processes No gate-keeping, only lever is to refuse to aggregate and republish a doc No jurisdiction over EIP or ERC, similarly not subject to EIP or ERC Process

A proposal to move some propsoed EIP opcodes around to make for a more coherent layout in Cancun and Prauge. Opcodes under active consideration This list includes opcodes propsed either for EOF or Cancun. The old opcode is the current EIP proposed opcode Old Opcode New Opcode Name Description Immediate Arg

Objective Reformulate the EOF container to provide efficient access without validation, to support features such as banning code introspection and non-validated execution. Specification container := header, managed_body, unmanaged_body header := magic, version, kind_container, container_end_index, kind_code, num_code_sections, code_index+, kind_data, data_index, terminator managed_body := types_section, code_section+, data_section types_section := (inputs, outputs, max_stack_height)+ The types kind is removed with a container kind, where the

Executive Summary Because of a flaw in handling unsigned data as signed data a properly coded smart contract can create a function call that will return more gas than was passed in. This excess gas can be used to create a loop that is in effect infinite. Networks containing only Besu validators will halt when this code is executed on-chain or considered for block inclusion. This bug was patched in Hyperledger Besu version 22.7.1 and exists in versions 22.4.0 to 22.7.0. CVE-2022-36025 Gas Call Bug The origins of the bug comes from a mis-handling of unsigned data as signed data. As part of supporting EIP-4803 Limit transaction gas to a maximum of 2^63-1 Besu migrated the internal types of Gas from a UInt256 object to a native long field, which is a signed value that can support the full range of transaction gas. In instances where the gas needed to represent a higher value Besu clamped the values to 2^63-1, aka Long.MAX_VALUE. Because all EVM executions will have the intrinsic gas costs deducted this clamped value will always exceed any observed gas value. The original code used a conversion that would take any 64 bit or less value and place it directly to a signed long. Any 65-256 bit sized number would result in an exception that would be trapped out and clamped to the max value. But any value of exactly 64 bits would become a negative signed long value.