Skip to content

Commit ca816ca

Browse files
CPerezzgballet
CPerezz
and
gballet
authored
Add EIP: Contract Bytecode Deduplication Discount (#10585)
* Add draft EIP: Contract Bytecode Deduplication Discount This proposal introduces a gas discount for contract deployments when the bytecode being deployed already exists in the state. The mechanism extends EIP-2930 access lists with an optional checkCodeHash flag to enable deterministic deduplication checks without breaking consensus. Key features: - Access-list based deduplication via checkCodeHash flag - Avoids GAS_CODE_DEPOSIT * L costs for duplicate deployments - Solves database divergence issues across different sync modes - Becomes particularly relevant with EIP-8037's increased gas costs This EIP is extracted from the original EIP-8037 proposal to allow independent review and adoption. * Address PR review comments and switch to implicit deduplication Major changes: 1. Remove checkCodeHash flag - make deduplication implicit via access lists 2. Add co-authors Wei-Han and Guillaume Ballet 3. Fix grammar: behaviour -> behavior, formalise -> formalize 4. Update snap-sync description for technical accuracy 5. Clarify edge cases for same-block deployments 6. Move Same-Block Deployments section from Rationale to Specification 7. Add rationale explaining why implicit design avoids chain splits Reviewer feedback addressed: - @weiihann: Remove explicit checkCodeHash flag, use implicit checking - @gballet: Chain split concerns resolved by implicit design - @gballet: Grammar and technical accuracy fixes - @weiihann: Simplify empty code handling - @weiihann: Clarify same-block deployment edge cases The implicit design provides several advantages: - No protocol changes to access list structure - Avoids chain split risks from unknown transaction fields - Simpler implementation - any address in access list contributes - Automatic optimization without explicit opt-in flags * Address additional review comments from Guillaume - Simplify deduplication logic to more concise form - Remove pre-fork/post-fork language from chain split rationale - Clarify that only gas accounting changes at fork activation Co-authored-by: Guillaume Ballet <[email protected]> * Fix section structure: move Example Transaction under Reference Implementation * Address review: change 'explicit' to 'implicit' and remove redundant sections * Fix markdown linting: add blank lines before lists * Address review: fix author name and change explicit to implicit --------- Co-authored-by: Guillaume Ballet <[email protected]>
1 parent dee539a commit ca816ca

File tree

1 file changed

+216
-0
lines changed

1 file changed

+216
-0
lines changed

‎EIPS/eip-8058.md‎

Lines changed: 216 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,216 @@
1+
---
2+
eip: 8058
3+
title: Contract Bytecode Deduplication Discount
4+
description: Reduces gas costs for deploying duplicate contract bytecode via access-list based mechanism
5+
author: Carlos Perez (@CPerezz), Wei Han Ng (@weiihann), Guillaume Ballet (@gballet)
6+
discussions-to: https://ethereum-magicians.org/t/eip-8058-contract-bytecode-deduplication-discount/25933
7+
status: Draft
8+
type: Standards Track
9+
category: Core
10+
created: 2025-10-22
11+
requires: 2930
12+
---
13+
14+
## Abstract
15+
16+
This proposal introduces a gas discount for contract deployments when the bytecode being deployed already exists in the state. By leveraging EIP-2930 access lists, any contract address included in the access list automatically contributes its code hash to a deduplication check. When the deployed bytecode matches an existing code hash from the access list, the deployment avoids paying `GAS_CODE_DEPOSIT * L` costs since clients already store the bytecode and only need to link the new account to the existing code hash.
17+
18+
This EIP becomes particularly relevant with the adoption of EIP-8037, which increases `GAS_CODE_DEPOSIT` from 200 to 1,900 gas per byte. Under EIP-8037, deploying a 24kB contract would cost approximately 46.6M gas for code deposit alone, making the deduplication discount economically significant for applications that deploy identical bytecode multiple times.
19+
20+
## Motivation
21+
22+
Currently, deploying duplicate bytecode costs the same as deploying new bytecode, even though execution clients don't store duplicated code in their databases. When the same bytecode is deployed multiple times, clients store only one copy and have multiple accounts point to the same code hash. Under EIP-8037's proposed gas costs, deploying a 24kB contract costs approximately 46.6M gas for code deposit alone (`1,900 × 24,576`). This charge is unfair for duplicate deployments where no additional storage is consumed.
23+
24+
A naive "check if code exists in database" approach would break consensus because different nodes have different database contents due to mostly Sync-mode differences:
25+
26+
- Full-sync nodes: Retain all historical code, including from reverted/reorged transactions
27+
- Snap-sync nodes: initially, only store code referenced in the pivot state tries, and those accumulated past the start of the sync
28+
29+
Empirical analysis reveals that approximately 27,869 bytecodes existed in full-synced node databases with no live account pointing to them (as of the Cancun fork). A database lookup `CodeExists(hash)` would yield different results on different nodes, causing different gas costs and breaking consensus.
30+
31+
This proposal solves the problem by making deduplication checks implicit and deterministic through access lists, ensuring all nodes compute identical gas costs regardless of their database state. (Notice here that even if fully-synced clients have more codes, there are no accounts whose codeHash actually is referencing them. Thus, users can't profit from such discounts which keeps consensus safe).
32+
33+
## Specification
34+
35+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
36+
37+
### Implicit Deduplication via Access Lists
38+
39+
This proposal leverages the existing EIP-2930 access list structure without any modifications. No new fields or protocol changes are required.
40+
41+
### CodeHash Access-Set Construction
42+
43+
Before transaction execution begins, build a set `W` (the "CodeHash Access-Set") as follows:
44+
45+
```
46+
W = { codeHash(a) | a ∈ accessList, a exists in state, a has code }
47+
```
48+
49+
Where:
50+
51+
- `W` is built from state at the **start** of transaction execution (before any state changes)
52+
- **All** addresses in the access list are checked - if they exist in state and have deployed code, their code hash is added to `W`
53+
- Empty accounts or accounts with no code do not contribute to `W`
54+
55+
### Contract Creation Gas Accounting
56+
57+
When a contract creation transaction or opcode (`CREATE`/`CREATE2`) successfully completes and returns bytecode `B` of length `L`, compute `H = keccak256(B)` and apply the following gas charges:
58+
59+
**Deduplication check:**
60+
61+
- If `H ∉ W`: Bytecode is new
62+
- Charge `GAS_CODE_DEPOSIT * L`
63+
- Persist bytecode `B` under hash `H`
64+
- Link the new account's `codeHash` to `H`
65+
- Otherwise, link the new account's `codeHash` to the existing code hash `H`
66+
67+
**Gas costs:**
68+
69+
- The cost of reading `codeHash` for access-listed addresses is already covered by EIP-2929/2930 access costs (intrinsic access-list cost and cold→warm state access charges).
70+
- No additional gas cost is introduced for the deduplication check itself.
71+
72+
### Implementation Pseudocode
73+
74+
```python
75+
# Before transaction execution:
76+
W = set()
77+
for tuple in tx.access_list:
78+
warm(tuple.address) # per EIP-2930/EIP-2929 rules
79+
acc = load_account(tuple.address)
80+
if acc exists and acc.code is not empty:
81+
W.add(acc.codeHash)
82+
83+
# On successful CREATE/CREATE2:
84+
H = keccak256(B)
85+
if H in W:
86+
# Duplicate: no deposit gas
87+
link_codehash(new_account, H)
88+
else:
89+
# New bytecode: charge and persist
90+
charge(GAS_CODE_DEPOSIT * len(B))
91+
persist_code(H, B)
92+
link_codehash(new_account, H)
93+
```
94+
95+
### Same-Block Deployments
96+
97+
Sequential transaction execution ensures that a deployment storing new code makes it visible to later transactions in the same block:
98+
99+
1. Transaction `T_A` deploys bytecode `B` at address `X`
100+
- Pays full `GAS_CODE_DEPOSIT * L` (no prior contract has this bytecode)
101+
- Code is stored under hash `H = keccak256(B)`
102+
103+
2. Later transaction `T_B` in the same block deploys the same bytecode `B`:
104+
- `T_B` includes address `X` in its access list
105+
- When `T_B` executes, `W` is built from the current state (including `T_A`'s changes)
106+
- Since `X` now exists and is in the access list, `W` contains `H`
107+
- `T_B`'s deployment gets the discount
108+
109+
> While this only tries to formalize the behavior, it's important to remark that this kind of behavior is complex. As it requires control over tx ordering in order to abuse. Builders can't modify the access list as it is already signed with the transaction. Nevertheless, this could happen, thus is formalized here.
110+
111+
### Edge Case: Simultaneous New Deployments
112+
113+
If two transactions in the same block both deploy identical new bytecode and neither references an existing contract with that bytecode in their access lists, both will pay full `GAS_CODE_DEPOSIT * L`.
114+
115+
**Example:**
116+
117+
- Transaction `T_A` deploys bytecode `B` producing code hash `0xCA` at address `X`
118+
- Transaction `T_B` (later in same block) also deploys bytecode `B` producing code hash `0xCA` at address `Y`
119+
- If `T_B`'s access list does NOT include address `X`, then `T_B` pays full deposit cost
120+
- Deduplication only occurs when the deploying address is included in the access list
121+
122+
This is acceptable because:
123+
124+
- The first deployment cannot be known at transaction construction time
125+
- Deduplication requires implicit opt-in via access list
126+
- This scenario is extremely rare in practice
127+
- The complexity of special handling is not worth the minimal benefit
128+
129+
## Rationale
130+
131+
### Why Access-List Based Deduplication?
132+
133+
The access-list approach provides several critical properties:
134+
135+
1. Deterministic behavior:
136+
The result depends only on the transaction's access list and current state, not on local database contents. All nodes compute the same gas cost.
137+
138+
2. No reverse index requirement:
139+
Unlike other approaches, this doesn't require maintaining a `codeHash → [accounts]` reverse index, which would add significant complexity and storage overhead.
140+
141+
3. Leverages existing infrastructure:
142+
Builds on EIP-2930 access lists and EIP-2929 access costs, requiring minimal protocol changes.
143+
144+
4. Implicit optimization:
145+
Any address included in the access list automatically contributes to deduplication. This provides automatic gas optimization without requiring explicit flags or special handling.
146+
147+
5. Avoids chain split risks:
148+
Since no new transaction structure is introduced, there's no risk of nodes rejecting transactions with unknown fields. The same transaction format works before and after the fork, with only the gas accounting rules changing at fork activation.
149+
150+
6. Forward compatibility:
151+
All nodes enforce identical behavior. Wallets can add addresses to access lists to optimize gas, but this doesn't change transaction validity.
152+
153+
7. Avoid having a code-root for state:
154+
At this point, clients handle code storage on their own ways. They don't have any consensus on the deployed existing codes (besides that all of the ones referenced in account's codehash fields exist).
155+
Changing this seems a lot more complex and unnecessary.
156+
157+
## Backwards Compatibility
158+
159+
This proposal requires a scheduled network upgrade but is designed to be forward-compatible with existing transactions.
160+
161+
**Transaction compatibility:**
162+
163+
- No changes to transaction structure - uses existing EIP-2930 access lists
164+
- Existing transactions with access lists automatically benefit from deduplication post-fork
165+
- Transactions without access lists behave identically to current behavior (no deduplication discount)
166+
167+
**Wallet and tooling updates:**
168+
169+
- RPC methods like `eth_estimateGas` SHOULD account for potential deduplication discounts when access lists are present
170+
- Wallets MAY provide UI for users to add addresses to access lists for deduplication
171+
- Transaction builders MAY automatically detect duplicate deployments and include relevant addresses in access lists
172+
173+
**Node implementation:**
174+
175+
- No changes to state trie structure or database schema required
176+
- No changes to transaction parsing or RLP encoding
177+
178+
## Reference Implementation
179+
180+
### Example Transaction
181+
182+
Deploying a contract with the same bytecode as the contract at `0x1234...5678`:
183+
184+
```json
185+
{
186+
"from": "0xabcd...ef00",
187+
"to": null,
188+
"data": "0x608060405234801561001...",
189+
"accessList": [
190+
{
191+
"address": "0x1234567890123456789012345678901234567890",
192+
"storageKeys": []
193+
}
194+
]
195+
}
196+
```
197+
198+
If the deployed bytecode hash matches `codeHash(0x1234...5678)` (which is automatically checked because the address is in the access list), the deployment receives the deduplication discount.
199+
200+
## Security Considerations
201+
202+
### Gas Cost Accuracy
203+
204+
The deduplication mechanism ensures that gas costs accurately reflect actual resource consumption. Duplicate deployments don't consume additional storage, so they shouldn't pay storage costs.
205+
206+
### Denial of Service
207+
208+
The access-list mechanism prevents DoS attacks because:
209+
210+
- The cost of reading `codeHash` is already covered by EIP-2929/2930
211+
- No additional state lookups or database queries are required
212+
- The deduplication check is O(1) (set membership test)
213+
214+
## Copyright
215+
216+
Copyright and related rights waived via [CC0](../LICENSE.md).

0 commit comments

Comments
 (0)