Skip to content

Commit 334471d

Browse files
OlegJakushkinOlegJakushkin
authored
Add EIP: Incentivize Access List Provisioning
Merged by EIP-Bot.
1 parent 2ba7edf commit 334471d

File tree

1 file changed

+145
-0
lines changed

1 file changed

+145
-0
lines changed

‎EIPS/eip-7707.md‎

Lines changed: 145 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,145 @@
1+
---
2+
eip: 7707
3+
title: Incentivize Access List Provisioning
4+
description: This EIP proposes updating gas cost parameters for access lists to incentivise their use and improve transaction execution efficiency.
5+
author: Ben Adams (@benaadams), Oleg Iakushkin (@OlegJakushkin)
6+
discussions-to: https://ethereum-magicians.org/t/eip-7707-align-incentives-for-access-list-provisioning/20025
7+
status: Draft
8+
type: Standards Track
9+
category: Core
10+
created: 2024-05-12
11+
requires: 2930
12+
---
13+
14+
## Abstract
15+
16+
This EIP reduces the gas cost of access list data, incentivizing the inclusion of complete and valid access lists in transactions to improve data load efficiency for execution layer clients.
17+
18+
## Motivation
19+
20+
While [EIP-2930](./eip-2930.md) introduced `accessLists` as a mechanism for `SLOAD`
21+
pre-warming to reduce gas costs by informing the EVM upfront about which storage slots a transaction will access,
22+
the practical use is limited and uncommon due to the savings versus penalties involved. In order to break even for
23+
each address included `24 storage keys` are required per address, and there is a `100 gas` saving per key at `25+`;
24+
in contrast the penalty for including an unused key is `1900 gas`, so break-even where one key is unused is `43 keys`.\
25+
\
26+
This situation makes the break-even and risk-reward ratio of `accessLists` rarely appealing in practice for regular
27+
transactions, where a prior transaction could lead to a different branch being taken and a slightly different set of
28+
storage slots being accessed. Furthermore, a very high number of SLOADs is required to start breaking even.\
29+
\
30+
For some clients, data loading takes `>70%` of block execution time. This
31+
happens in part due to sequential transaction execution and iterative
32+
search of effectively random access data.\
33+
\
34+
While NVMe drives have massive throughput and IOPS; this is their
35+
concurrent throughput operated through multiple queues and they do not
36+
have this performance if data is accessed completely sequentially with
37+
one request waiting for the prior to complete i.e. stacking individual
38+
IOPS latency end to end will not give anything close to maximal
39+
throughput that these drives can deliver (which is different from the
40+
HDD world where heads needed to seek to different physical locations for
41+
each read). This is a similar situation with network attached storage or
42+
cloud data disks; however the latency here is even more amplified than a
43+
local direct CPU attached NVMe drive (i.e. via network card).\
44+
\
45+
If nodes had a somewhat clearer picture of what data to pre-load for the
46+
block's execution; that can be done in parallel, hiding much of the
47+
latency from accessing that data when discovered from executing the
48+
transaction. Very much in a similar way to instruction pipelining on a
49+
CPU hiding memory access latencies; the data access for transactions
50+
could be pipelined. This can lead to faster/cheaper block execution and
51+
would facilitate data dependency hints for parallel Tx execution in the
52+
future, like on other emerging chains that were developed with more
53+
modern hardware in mind.
54+
55+
## Specification
56+
57+
We shall update [EIP-2930](./eip-2930.md)
58+
parameters:
59+
60+
| Constant | Value |
61+
| - | - |
62+
| `ACCESS_LIST_STORAGE_KEY_COST` | 320 |
63+
| `ACCESS_LIST_ADDRESS_COST` | 512 |
64+
65+
66+
## Rationale
67+
68+
As stated in the introduction the gas cost benefit analysis does not
69+
encourage the users of the chain to provide accessList hints, even
70+
though the mechanism is already in protocol (and a call to
71+
`eth_createAccessList` will give them, or a wallet the correct list
72+
to include). So we propose a reduction in the pricing of those data
73+
access lists to make them more inline with calldata.\
74+
\
75+
Levelling the playing field between small `call_data` and `access_lists`
76+
costs, (and incentivise `access_lists` provisioning from transaction
77+
senders as they are needed for transaction execution in a faster
78+
manner), the price model updates would look as follows:
79+
80+
Use `STANDARD_TOKEN_COST * tokens_in_access_lists`, where
81+
`tokens_in_access_lists = bytes_in_access_lists * 4`, making it as
82+
expensive to send as plain small call data. So we will get:
83+
84+
- `32*4*4 = 512` for addresses (instead of 2400, 4.6 times less)
85+
86+
- `20*4*4 = 320` for storage keys (instead of 1900, 5.9 times less)
87+
88+
This means users pay for on-chain data inclusion as usual `call_data`. It
89+
changes the original
90+
[EIP-2930](./eip-2930.md) logic
91+
of "covering the bandwidth costs", which was not described in detail and
92+
is potentially outdated.
93+
94+
It should be noted that this is not the first time [EIP-2930](./eip-2930.md) additions have been proposed. In [EIP-3521](./eip-3521.md), a reduction was already proposed, but it focused only on `ACCESS_LIST_ADDRESS_COST`.
95+
96+
### Examples
97+
98+
Current
99+
100+
| Inst | Type | Access List | Keys for address | OP Price | AccessList Key Price | AccessList Address Price | Total gas per OP |
101+
|------|------|-------------|------------------|----------|----------------------|-------------------------|------------------|
102+
| `SLOAD` | Cold | Not included | - | 2100 | 0 | 0 | 2100 |
103+
| `SLOAD` | Warm | Not included | - | 100 | 0 | 0 | 100 |
104+
| `SLOAD` | Warm | Included | - | 100 | - | - | 100 |
105+
| `SLOAD` | Cold | Included | 1 | 100 | 1900 | 2400 | 4400 |
106+
| `SLOAD` | None | Included | 1 | 0 | 1900 | 2400 | 4300 |
107+
| `SLOAD` | Cold | Included | 10 | 100 | 1900 | 240 | 2240 |
108+
| `SLOAD` | None | Included | 10 | 0 | 1900 | 240 | 2140 |
109+
| `SLOAD` | Cold | Included | 50 | 100 | 1900 | 48 | 2048 |
110+
| `SLOAD` | None | Included | 50 | 0 | 1900 | 48 | 1948 |
111+
112+
113+
Proposed
114+
115+
| Inst | Type | Access List | Keys for address | OP Price | AccessList Key Price | AccessList Address Price | Total gas per OP |
116+
|-------|------|---------------|------------------|----------|----------------------|-------------------------|------------------|
117+
| `SLOAD` | Cold | Not included | - | 2100 | 0 | 0 | 2100 |
118+
| `SLOAD` | Warm | Not included | - | 100 | 0 | 0 | 100 |
119+
| `SLOAD` | Warm | Included | - | 100 | - | - | 100 |
120+
| `SLOAD` | Cold | Included | 1 | 100 | 320 | 512 | 932 |
121+
| `SLOAD` | None | Included | 1 | 0 | 320 | 512 | 832 |
122+
| `SLOAD` | Cold | Included | 10 | 100 | 320 | 51.2 | 471 |
123+
| `SLOAD` | None | Included | 10 | 0 | 320 | 51.2 | 371 |
124+
| `SLOAD` | Cold | Included | 50 | 100 | 320 | 10.24 | 430 |
125+
| `SLOAD` | None | Included | 50 | 0 | 320 | 10.24 | 330 |
126+
127+
128+
\- Already paid on making warm
129+
130+
## Backwards Compatibility
131+
132+
This EIP makes a minor update to
133+
[EIP-2930](./eip-2930.md) with
134+
respect to modern execution challenges and capabilities.
135+
136+
## Security Considerations
137+
138+
139+
Same as per
140+
[EIP-2930](./eip-2930.md)
141+
142+
143+
## Copyright
144+
145+
Copyright and related rights waived via [CC0](../LICENSE.md).

0 commit comments

Comments
 (0)