Skip to content

Commit

Permalink
Add discussion url
Browse files Browse the repository at this point in the history
  • Loading branch information
axic committed Dec 2, 2024
1 parent 1c5565a commit adb5311
Showing 1 changed file with 79 additions and 0 deletions.
79 changes: 79 additions & 0 deletions EIPS/eip-7830.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
---
eip: 7830
title: Contract size limit increase for EOF
description: Raise the limit for only EOF contracts to 64 KiB
author: Alex Beregszaszi (@axic), Danno Ferrin (@shemnon)
discussions-to: https://ethereum-magicians.org/t/eip-7830-contract-size-limit-increase-for-eof/21927
status: Draft
type: Standards Track
category: Core
created: 2024-11-29
requires: 170, 3540, 3860
---

## Abstract

Revise the contract size limit for EOF contracts to be 64 KiB instead of the existing 24 KiB limit. Legacy contracts are unaffected.

## Motivation

The contract size limit was introduced as a measure against DoS attacks. `JUMPDEST`-analysis is required for legacy contracts, and many of the algorithms performing it are not linear and/or have unknown unknowns. This is one of the reasons for the hesitance of a limit increase.

For contract developers the limit poses annoying problems, given modern contracts with good error reporting would consume more space. They are forced to work with workarounds, like "libraries" (using `DELEGATECALL`), splitting an application across regular contracts (and `CALL`-ing across), or working with proxies (e.g. the "diamond pattern"). All these solutions have resulted in suboptimal patterns, bugs in deployed contracts, and loss of funds.

With EOF the `JUMPDEST`-analysis is removed from runtime and a validation process is peformed once during deployment. The initcode cost [EIP-3860](./eip-3860.md) introduced accounts for this validation too. Therefore with EOF there are no known problems for increasing the limit, because the overheads are already accounted for.

Storage cost is already paid per contract byte.

## Specification

[EIP-170](./eip-170.md) specifies `MAX_CODE_SIZE` as 24576 bytes, and [EIP-3860](./eip-3860.md) specifies `MAX_INITCODE_SIZE` as `2 * MAX_CODE_SIZE` (49152 bytes).

<!-- TODO: if profiling analysis shows we need to charge more for EOF analysis, this is where we can specify it. Either globally or for 0xef00 contracs -->

Check warning on line 32 in EIPS/eip-7830.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

HTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn`

warning[markdown-html-comments]: HTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn` --> EIPS/eip-7830.md | 32 | <!-- TODO: if profiling analysis shows we need to charge more for EOF analysis, this is where we can specify it. Either globally or... | ::: EIPS/eip-7830.md | 63 | <!-- https://docs.google.com/spreadsheets/d/1C2dd5sVnZNKXOpRknHhxt6MnTTN50c3b9d6ZU2rvqDQ/edit?usp=sharing --> | ::: EIPS/eip-7830.md | 71 | <!-- TODO --> | = help: see https://ethereum.github.io/eipw/markdown-html-comments/

Check warning on line 32 in EIPS/eip-7830.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

HTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn`

warning[markdown-html-comments]: HTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn` --> EIPS/eip-7830.md | 32 | <!-- TODO: if profiling analysis shows we need to charge more for EOF analysis, this is where we can specify it. Either globally or... | ::: EIPS/eip-7830.md | 63 | <!-- https://docs.google.com/spreadsheets/d/1C2dd5sVnZNKXOpRknHhxt6MnTTN50c3b9d6ZU2rvqDQ/edit?usp=sharing --> | ::: EIPS/eip-7830.md | 71 | <!-- TODO --> | = help: see https://ethereum.github.io/eipw/markdown-html-comments/

Starting `FORK_BLOCK`, for EOF initcode/code (code starting with the `0xEF 0x00` bytes) the limit is changed:`MAX_CODE_SIZE` is set to 65536 bytes (64 KiB). This means `MAX_INITCODE_SIZE` becomes 131072 bytes (128 KiB).

## Rationale

The 64 KiB limit is over 2x of existing limit, while it is not a significant increase, it is the realistic increase given the limitations of initcode. In EOF deployment the to-be-deployed code is stored as a section ("subcontainer"), which has a size limit of 64 KiB, therefore it is not possible to deploy larger contracts without introducing a large or variable-length-encoded size field.

A further increase can be proposed with applying these changes to EOF.

This increase still fits within the gas schedule, limiting the size to less than what gas limits allow. In [EIP-170](./eip-170.md) the gas limit was first set "by setting the cap at a value slightly higher than what is feasible with current gas limits." At that time the gas limit had not exceeded 5M gas.

A simple analysis shows contract deployements for 64 KiB contracts to be between 14M and 16M gas, roughly close to the current 15M target.

| | Cancun | This EIP | 30M Gas | Max Initcode |
|---------------------|----------:|-----------:|-----------:|-------------:|
| **Initcode bytes** | 200 | 200 | 200 | 65,536 |
| **Deployed Bytes** | 24,576 | 65,536 | 137,656 | 65,536 |
| **Zero byte ratio** | 10% | 10% | 10% | 10% |
| **Initcode Cost** | 4/16 | 4/16 | 4/16 | 4/16 |
| | | | | |
| **Intrinsic Gas** | 53,000 | 53,000 | 53,000 | 53,000 |
| **Calldata Gas** | 366,685 | 972,893 | 2,043,880 | 1,939,866 |
| **EIP-3860 Gas** | 49,552 | 131,472 | 276,200 | 262,144 |
| **EVM Execution** | 100,000 | 100,000 | 100,000 | 100,000 |
| **Code Deposit** | 4,915,200 | 13,107,200 | 27,580,000 | 13,107,200 |
| | | | | |
| **Total Cost** | 5,484,437 | 14,364,565 | 30,000,181 | 15,462,210 |

Note that the Max 30M gas contract size of 135 KiB is outside the limits of what is proposed in this EIP and is included to show what it would take to exceed current gas limits.

<!-- https://docs.google.com/spreadsheets/d/1C2dd5sVnZNKXOpRknHhxt6MnTTN50c3b9d6ZU2rvqDQ/edit?usp=sharing -->

## Backwards Compatibility

This is a backwards compatible change. Existing contracts are unaffected, and only new deployments see the effect.

## Security Considerations

<!-- TODO -->

Given the analysis cost is paid as part of deployment, the size of contract should have no effect on the runtime.

A more thorough analysis may be needed to detemine whether the proposed limit poses any risk because of client storage architectures.

## Copyright

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

0 comments on commit adb5311

Please sign in to comment.