-
Notifications
You must be signed in to change notification settings - Fork 5.4k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
79 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 GitHub Actions / EIP WalidatorHTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn`
Check warning on line 32 in EIPS/eip-7830.md GitHub Actions / EIP WalidatorHTML comments are only allowed while `status` is one of: `Draft`, `Withdrawn`
|
||
|
||
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). |