Memory Copying in Contracts Deployed on Ethereum

Adoption of bulk memory copying as a native feature for the EVM has previously been explored with a proposal to add new opcode MCOPY.

To get a measure of contracts which currently perform copying and what savings they may see by being rewritten to use MCOPY, analysis of EVM execution traces for 1200 historical blocks starting from block 10537502 was performed.

Copies of single words were identified by examining values loaded from memory via MLOAD, tracking their existence as they are shuffled around the stack during execution of other opcodes and noting if these values are stored back to memory via MSTORE. When these tracked values are consumed (used as parameters to other opcodes) or duplicated via DUP, they are no longer considered.

The analysis also identified occurances of copies larger than a single word (where one invocation of MCOPY could replace multiple single-word copies). This is done by looking for multiple single-word copies which operate on source and destination offsets along consecutive 32-byte boundaries.

In addition, Solidity was augmented to use MCOPY for multi-word memory copying helper functions in place of currently-used MLOAD/MSTORE copy loops. This did not identify any cases of memory copying present after recompiling the Solidity contract test suite.

Cost Model

A linear cost model for MCOPY was calculated by fitting a line through Go-ethereum client benchmarks measuring varying copy sizes from 32 bytes to 10kb on an i5-6600K processor (32kb L1 cache).

Model gas_mcopy(n) = 2 + 2.56(n-1) where n is the number of EVM-words being copied (target gas rate of 20ns/gas, 0.3 seconds of execution for a gas limit of 15,000,000):

In general, the model somewhat overcharges because the benchmarks include the overhead of stack manipulation from Geth’s EVM (2 x PUSH, 1 x stack popping in MCOPY per benchmark iteration). Spikes in the 5000-6000 byte range can be discounted as noise.

Tracing Results

The occurance of multi-word copies is rare:

Copy size (EVM words) Number of occurances during the period traced
1 115673
2 4806
3 6132
4 185
5 14
6 283
7 142
8 1398
9 350
10 12
11 30
12 218
13 83
14 25
15 3
16 1
20 3
34 1
37 1
40 1
42 3

Adoption of MCOPY may be warranted if proposals similar to EVM384 (where copying has been identified as a significant source of overhead for EC pairing operations) are adopted. Until such use-cases become a reality or other sources of cost-reductions afforded by cheap copying are discovered, adoption of MCOPY is not necessary for the EVM. We are interested in collecting other potential use-cases where MCOPY can be applied.

Note: Scripts and utilities to reproduce the tracing and analysis are at https://github.com/jwasinger/evm-mem-copy-tracer

Last changed by  
 
ipsilon Ipsilon -- Execution Research
4859

Read more

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.

Mar 25, 2025
Explainer of `evmone` Codecov report for EOF tests

Based on report https://app.codecov.io/gh/ethereum/evmone/commit/26cdd854106cbcbb4d817cfd5e0d2b1ee41bcd21/tree/lib/evmone?flags%5B0%5D=eof_execution_spec_tests&flags%5B1%5D=ethereum_tests&dropdown=coverage . NOTE includes both EOF EEST tests and ethereum/tests (in the process of migration). File Coverage % Comment advanced_analysis.cpp 0.00%

Mar 20, 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

Mar 13, 2025
Potential scenarios of updating the new contract address schemes for EOF

Everything 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:

Jan 22, 2025
Read more from ipsilon
Published on HackMD