Title: EIP_7923__Linear__Page_Based_Memory_Costing
Category: EIPs

Author: charles-cooper
Date: 2025-03-27T21:42:58.342Z

discussions-to for: Add EIP: Linear, Page-Based Memory Costing by charles-cooper · Pull Request #9556 · ethereum/EIPs · GitHub
adding the EIP link, now that it has been merged: EIP-7923: Linear, Page-Based Memory Costing

Author: sbacha
Date: 2025-03-28T03:49:07.939Z

Isn’t this advocating for removing the 63/64 rule?

Author: charles-cooper
Date: 2025-03-28T06:34:37.405Z

Bit off topic, but yes, I think that should be removed as well.

Author: charles-cooper
Date: 2025-03-28T09:54:14.616Z

Since memory access gets substantially more expensive after around 32MB, I considered several variants:

Thrash costing only, global memory limit is implied by gas limit (currently in the EIP)
No thrash costing, limit per message call. This has the disadvantage that the global limit has to be inferred from the call stack limits
No thrash costing, global memory limit. This has the disadvantage that the global memory limit may need to be kept small permanently, since CPU cache grows very slowly over time.
Thrash costing AND global memory limit. This has the disadvantage that developers may come up with valid use cases for using much more memory and be blocked by EVM limitations, but on the other hand, it can help nodes reason about DoS vectors invariant of gas limit (see EIP-7686: Linear EVM memory limits - #5 by qizhou).

I think all of these fall in the realm of ‘acceptable’ solutions. I personally prefer 1, 4 or 3, in that order.

Author: jhb10c
Date: 2025-03-28T20:48:20.491Z

63/64 rule is still necessary if for page-based memory since this does not limit the memory of child calls. Is there an alternative mechanism that should be done. Limiting maximum memory size on a transactions level based on gas limit?

Author: charles-cooper
Date: 2025-04-04T16:08:32.777Z

I think one of the motivations for this EIP actually is that the memory limit is invariant wrt the state of the call stack, so you don’t need to think about how allocation patterns across the call stack can affect memory usage. In this EIP, there is an implied limit of memory usage based on the gas limit, which in the current iteration of the draft, would be gas_limit * 4096 / 109, where 4096 is the number of bytes per page, and 109 is the cost to allocate a page.

Author: charles-cooper
Date: 2025-04-05T12:02:02.309Z

charles-cooper:


Thrash costing AND global memory limit. This has the disadvantage that developers may come up with valid use cases for using much more memory and be blocked by EVM limitations, but on the other hand, it can help nodes reason about DoS vectors invariant of gas limit (see EIP-7686: Linear EVM memory limits - #5 by qizhou).



I’ve added this transaction global limit in the latest commit: Add EIP: Linear, Page-Based Memory Costing by charles-cooper · Pull Request #9556 · ethereum/EIPs · GitHub

Author: benaadams
Date: 2025-04-11T04:50:53.353Z

Do you benchmarks also include clearing costs; as memory will have to be zeroed to not leak data between transactions

Author: charles-cooper
Date: 2025-04-11T06:05:58.836Z

Yes – that’s included in the 100 gas cost to allocate+zero a page.