Linear, Page-Based Memory Costing: Deconstructing EIP-7923 and EVM Gas Architecture

In the Ethereum Virtual Machine, resource metering has historically treated transient execution memory through an aggressive mathematical defense: a quadratic expansion formula designed in the protocol's earliest days to prevent denial-of-service vectors. Under this model, as memory grows, each additional word becomes quadratically more expensive to allocate.

While this pricing mechanism shielded early execution clients from unconstrained memory allocation, it increasingly diverges from the physics of modern server hardware and operating system memory management. EIP-7923 (Linear, Page-Based Memory Costing), co-authored by Charles Cooper and Qi Zhou, proposes a fundamental overhaul of this subsystem: replacing the polynomial formula with a linear, page-aligned cost schedule and introducing explicit thrash-cost accounting when footprints cross hardware cache thresholds.

This shift has profound architectural consequences for EVM execution client efficiency, call stack security invariants, and advanced zero-knowledge and post-quantum cryptographic workloads. Examining EIP-7923 requires deconstructing why the legacy model fails, how modern hardware processes memory, and the nuanced trade-offs between dynamic pricing and hard execution limits.

The Legacy Quadratic Pricing Model and Its Disconnect

Since the Ethereum Yellow Paper, the cumulative gas cost for allocating a 32-byte words of active memory within an execution frame has been governed by:

C_mem(a) = 3a + ⌊a² / 512⌋

The linear term (3 gas per word) accounts for the nominal overhead of tracking memory, while the quadratic component (⌊a² / 512⌋) serves as an escalating penalty intended to make massive allocations economically impossible within a single block's gas limit.

At low allocations, memory is virtually free. At 1 MB (~32,768 words), the quadratic penalty reaches over 2 million gas. At 8 MB, the gas cost exceeds 130 million gas, well beyond the standard block gas limit. The quadratic curve was an effective crude firewall, but it suffers from two major structural deficiencies:

• Micro-Accounting Interpreter Overhead: Because the quadratic equation evaluates memory at single-word (32-byte) granularity, EVM execution engines (such as revm, Geth, and Besu) must recompute expansion checks and polynomial arithmetic on nearly every memory-touching opcode (MLOAD, MSTORE, MSTORE8, CODECOPY, CALLDATACOPY). This generates continuous interpreter overhead even for ordinary, small-footprint contracts.

• Misalignment with Hardware Allocators: Modern operating systems and processor architectures do not allocate or page memory in 32-byte chunks. Virtual memory is managed in pages, typically 4 KB on modern x86_64 and AArch64 architectures. An operating system kernel allocates memory by assigning page table entries through mmap or brk calls, incurring page faults only when unmapped physical frames are touched. Quadratic word pricing models a cost curve that does not correspond to real hardware behavior.

The Hardware Reality: Cache Lines, Page Faults, and Latency Cliffs

To price computational resources accurately, gas schedules must reflect real physical bottlenecks. In physical execution, the marginal cost of memory access is not a smooth quadratic parabola. Instead, it is a discrete step-function dictated by the CPU memory hierarchy and virtual memory translation:

• L1, L2, and L3 CPU Cache Boundaries: Modern server processors (such as AMD EPYC and Intel Xeon validator nodes) maintain fast on-die caches. Reading data residing in L1 or L2 cache requires between 1 and 4 nanoseconds. Data residing in L3 cache (~32 MB to 64 MB per CCD) can be fetched in roughly 7 to 15 nanoseconds. When memory access patterns remain within these cache boundaries, throughput is exceptionally fast and predictable.

• The DRAM and TLB Latency Cliff: Once an active transaction's memory access pattern expands beyond the CPU cache (~32 MB to 64 MB) and scatters across main memory, cache hit rates plummet. Hardware profiling submitted during EIP-7923 discussions demonstrates that random memory access across a 256 MB or 4 GB range triggers data Translation Lookaside Buffer (dTLB) miss rates exceeding 95%, driving access latencies from 3.5 nanoseconds up to 40 nanoseconds. A single operating system page fault costs approximately 500 to 1,500 nanoseconds.

The legacy quadratic model severely penalizes allocations between 1 MB and 16 MB, regions that modern hardware handles with zero measurable latency degradation, while failing to accurately capture the true performance cliff that occurs when execution thrashes the CPU cache and page tables.

EIP-7923 Core Architecture: Linear Pages and Thrash Costing

EIP-7923 replaces word-level quadratic calculation with a page-based, virtualized memory model aligned with physical computing primitives. The specification introduces three structural components:

1. 4 KB Page Chunking: Memory is allocated in uniform pages (PAGE_SIZE = 4,096 bytes). Instead of calculating gas expansion per 32-byte word, clients track page allocation bitmasks. In the baseline specification, allocating a fresh 4 KB page is priced at a constant linear fee (for instance, 109 gas per page). Touching any byte within an already allocated page incurs no additional expansion gas.

2. 32-Bit Address Space Limitation: EVM memory addresses are explicitly constrained to 32 bits (maximum addressable range of 2³² - 1, or 4 GB). Any memory reference exceeding this boundary immediately triggers an exceptional halt, preventing 64-bit address overflow attacks in client memory bindings.

3. Thrash Costing: To reflect the physical latency cliff where cache misses and page faults dominate, EIP-7923 introduces a stepped pricing tier (THRASH_PAGE_COST). Once allocated memory passes the cache boundary (approximately 32 MB, or 8,192 pages), the cost per subsequent page allocated increases sharply, economically reflecting the cache eviction penalty inflicted upon the host node.

The Four Architectural Variants: Evaluating DoS and Flexibility

During core developer discussions on Ethereum Magicians and GitHub PR #9556, author Charles Cooper mapped out four distinct variants for managing memory growth past cache boundaries:

Variant 1: Thrash Costing Only (Gas-Implied Memory Limit)

In this variant, there is no explicit hard cap on total bytes. The maximum possible memory allocation is implicitly constrained by the block gas limit divided by the page cost. The advantage is architectural purity: the EVM avoids arbitrary protocol-level caps that require future hard forks to lift as server hardware evolves. However, client implementers face the challenge that an attacker could construct worst-case allocation patterns if gas limits rise significantly.

Variant 2: Limit Per Message Call (No Thrash Costing)

This variant restricts memory within each individual call frame without adjusting page gas costs. The primary flaw is that the transaction's global memory footprint must be derived from call stack depth, making it difficult to prevent multi-frame memory exhaustion without imposing tight call-depth restrictions.

Variant 3: Global Memory Limit (No Thrash Costing)

This variant imposes a strict global memory cap (for example, 32 MB per transaction) without a progressive thrash pricing tier. The downside is rigidity: because server CPU cache architectures improve slowly over time, an unpriced hard cap permanently blocks memory-intensive contracts from executing on-chain.

Variant 4: Thrash Costing Combined with a Global Memory Cap

The currently favored compromise combines stepped thrash pricing with an explicit transaction-wide ceiling: MAXIMUM_MEMORY_SIZE = 64 MB (16,384 pages). Exceeding this aggregate allocation halts the transaction. This provides node operators with an ironclad upper bound on physical RAM consumption during block processing, invariant of future block gas limit increases.

Cross-Frame Dynamics, Memory Isolation, and the 63/64 Rule

A vital consideration raised in community discussion (notably by researcher sbacha) centers on the interaction between linear memory pricing and the 63/64 call-forwarding rule established in EIP-150.

In the EVM, each call frame maintains an isolated, independent memory arena. When contract A invokes contract B, contract B receives up to 63/64ths of the remaining gas, but it does not inherit contract A's memory buffer. Both buffers exist simultaneously in the client's process memory while the sub-call executes.

Under the legacy quadratic model, attempting to chain memory allocations across deep call frames is self-limiting due to both base invocation costs and the polynomial penalty. Under flat linear costing, however, an adversarial contract could execute a chain of sub-calls up to the 1,024-depth limit, with each frame allocating an unpenalized volume of memory right below the single-frame thrash threshold.

To guarantee that linear memory pricing cannot be weaponized to trigger Out-Of-Memory (OOM) panics across validator nodes, EIP-7923 defines its allocation budget across the entire transaction context. Rather than evaluating memory within isolated frame boundaries, the page-counter tracks cumulative active pages allocated across the entire message call tree. This ensures that memory limits remain invariant to call-stack manipulation.

Ecosystem Impacts: Advanced Verification, Cryptography, and Parallelism

Modernizing EVM memory pricing from quadratic word-expansion to linear page-allocation directly unblocks several critical protocol developments:

• High-Performance Cryptographic Verification: Advanced zero-knowledge proof verification (such as large PLONK or STARK verifiers) and post-quantum cryptographic schemes (such as ML-DSA / FIPS 204 signatures in EIP-8355) require manipulating substantial scratchpad state, matrix evaluations, and polynomial expansion arrays ranging from 2 MB to 16 MB. Under quadratic pricing, these operations incur millions of artificial gas units solely for memory overhead. Linear page pricing aligns the execution cost with actual CPU cycles, making sophisticated verification economically viable directly within standard EVM contracts.

• Client Interpreter Optimization: Eliminating word-by-word polynomial arithmetic streamlines the inner execution loop of execution clients. Page-level bitmask checks allow interpreters to utilize native memory allocation primitives (such as pre-allocated virtual memory arenas) without simulating synthetic gas math on every memory access.

• Predictable Parallel Execution: As Ethereum Layer 1 and Layer 2 rollups adopt multi-threaded or parallel EVM engines, bounding memory consumption per transaction to a known, page-aligned limit (such as the 64 MB cap) provides schedulers with deterministic resource footprints, preventing concurrent worker threads from saturating system memory bandwidth.

Conclusion

EIP-7923 represents a long-overdue transition from an idealized mathematical abstraction to an empirical, hardware-informed cost model. By replacing quadratic word scaling with 4 KB page allocation, introducing thrash pricing past CPU cache boundaries, and enforcing a transaction-global allocation invariant, the proposal establishes a balanced, predictable foundation for modern EVM gas accounting.