Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add EIP: Hardfork Meta - Dencun #8369

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 75 additions & 0 deletions EIPS/eip-7564.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
---
eip: 7564
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
eip: 7564
eip: 7669

Copy link

@SirJosh1987 SirJosh1987 Apr 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eip:7669

title: Linear EVM memory limits
description: Adjust memory limits and gas limits of sub-calls to create a clear linear bound on how much total memory an EVM execution can consume
author: Vitalik Buterin (@vbuterin)
discussions-to: https://ethereum-magicians.org/t/eip-linear-evm-memory-limits/19448
status: Draft
type: Standards Track
category: Core
created: 2024-03-31
---

## Abstract

Add a hard memory limit equal to the gas limit of the current context. Make the maximum gas cost of a sub-call depend on the memory used in the current context. The two rules together ensure that a transaction with N gas can use at most N bytes of memory.

## Motivation

Today, memory pricing rules are complicated: we have the quadratic cost for expanding memory as well as the 63/64 rule for how much gas can go into a child call. This also makes it extremely hard to calculate a maximum possible amount of memory required to process a given EVM execution.

The rules in this post simplify these rules, and add a new hard limit: an EVM execution with N gas can require at most N total bytes of memory to process. This limit is tight: there are easy ways for an N-gas call to use `N - O(1)` bytes of memory.

## Specification

Change `memory_cost` from:

```python
memory_size_word = (memory_byte_size + 31) / 32
memory_cost = (memory_size_word ** 2) / 512 + (3 * memory_size_word)
```

To:

```
memory_size_word = (memory_byte_size + 31) / 32
memory_cost = 3 * memory_size_word
```

Additionally, if a memory expansion would lead to `memory_byte_size` strictly exceeding the current call's initial gas limit, revert with an error.

When making any type of call, change the maximum gas limit from the current [EIP-150](eip-150.md) definition:

```python
def max_call_gas(gas):
return gas - (gas // 64)
```

To:

```python
def max_call_gas(gas, memory_byte_size):
return gas - max(gas // 64, memory_byte_size)
```

## Rationale

With this EIP, there is a simple EVM implementation that can process an N-gas call using an N-byte bytearray as memory: allocate all bytes to the current context, when doing a child call use the remaining memory starting from the position `memory_byte_size` for the child call's memory, and so on recursively.

Having this clean invariant is useful for EVM implementations, especially EVM implementations in constrained environments (eg. ZK-SNARK provers).

The 3 gas per word memory expansion cost is retained because it is equivalent to MCOPY, and so the operation of clearing memory at the end of a child call (cheap in regular machines, but more expensive in ZK-SNARKs and other unusual contexts) can be implemented with the same logic as that used to implement the MCOPY opcode itself.

The 63/64 rule is maintained in order to maintain the current de-facto call stack depth limit of roughly `1 + log((gaslimit + 6300) / 6400) / log(64/63) = 537`.

## Backwards Compatibility

It is theoretically possible for EVM code that works today to fail to work under this new EIP, if that code accesses a high index in memory but is called with a low gas limit. However, almost all EVM execution consumes far more code than it uses bytes of memory. For example, for a call to cause even a single state change, it must have at least 5000 gas. This would allow it 5000 bytes of memory, which is greater than that used by almost all applications. More complex applications would have even higher limits.

## Security Considerations

No security concerns were raised.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Loading