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.
While EIP-2930 introduced accessLists as a mechanism for SLOAD
pre-warming to reduce gas costs by informing the EVM upfront about which storage slots a transaction will access,
the practical use is limited and uncommon due to the savings versus penalties involved. In order to break even for
each address included 24 storage keys are required per address, and there is a 100 gas saving per key at 25+;
in contrast the penalty for including an unused key is 1900 gas, so break-even where one key is unused is 43 keys.
This situation makes the break-even and risk-reward ratio of accessLists rarely appealing in practice for regular
transactions, where a prior transaction could lead to a different branch being taken and a slightly different set of
storage slots being accessed. Furthermore, a very high number of SLOADs is required to start breaking even.
For some clients, data loading takes >70% of block execution time. This
happens in part due to sequential transaction execution and iterative
search of effectively random access data.
While NVMe drives have massive throughput and IOPS; this is their
concurrent throughput operated through multiple queues and they do not
have this performance if data is accessed completely sequentially with
one request waiting for the prior to complete i.e. stacking individual
IOPS latency end to end will not give anything close to maximal
throughput that these drives can deliver (which is different from the
HDD world where heads needed to seek to different physical locations for
each read). This is a similar situation with network attached storage or
cloud data disks; however the latency here is even more amplified than a
local direct CPU attached NVMe drive (i.e. via network card).
If nodes had a somewhat clearer picture of what data to pre-load for the
block's execution; that can be done in parallel, hiding much of the
latency from accessing that data when discovered from executing the
transaction. Very much in a similar way to instruction pipelining on a
CPU hiding memory access latencies; the data access for transactions
could be pipelined. This can lead to faster/cheaper block execution and
would facilitate data dependency hints for parallel Tx execution in the
future, like on other emerging chains that were developed with more
modern hardware in mind.
We shall update EIP-2930 parameters:
| Constant | Value |
|---|---|
ACCESS_LIST_STORAGE_KEY_COST | 320 |
ACCESS_LIST_ADDRESS_COST | 512 |
As stated in the introduction the gas cost benefit analysis does not
encourage the users of the chain to provide accessList hints, even
though the mechanism is already in protocol (and a call to
eth_createAccessList will give them, or a wallet the correct list
to include). So we propose a reduction in the pricing of those data
access lists to make them more inline with calldata.
Levelling the playing field between small call_data and access_lists
costs, (and incentivise access_lists provisioning from transaction
senders as they are needed for transaction execution in a faster
manner), the price model updates would look as follows:
Use STANDARD_TOKEN_COST * tokens_in_access_lists, where
tokens_in_access_lists = bytes_in_access_lists * 4, making it as
expensive to send as plain small call data. So we will get:
32*4*4 = 512 for addresses (instead of 2400, 4.6 times less)
20*4*4 = 320 for storage keys (instead of 1900, 5.9 times less)
This means users pay for on-chain data inclusion as usual call_data. It
changes the original
EIP-2930 logic
of "covering the bandwidth costs", which was not described in detail and
is potentially outdated.
It should be noted that this is not the first time EIP-2930 additions have been proposed. In EIP-3521, a reduction was already proposed, but it focused only on ACCESS_LIST_ADDRESS_COST.
Current
| Inst | Type | Access List | Keys for address | OP Price | AccessList Key Price | AccessList Address Price | Total gas per OP |
|---|---|---|---|---|---|---|---|
SLOAD | Cold | Not included | - | 2100 | 0 | 0 | 2100 |
SLOAD | Warm | Not included | - | 100 | 0 | 0 | 100 |
SLOAD | Warm | Included | - | 100 | - | - | 100 |
SLOAD | Cold | Included | 1 | 100 | 1900 | 2400 | 4400 |
SLOAD | None | Included | 1 | 0 | 1900 | 2400 | 4300 |
SLOAD | Cold | Included | 10 | 100 | 1900 | 240 | 2240 |
SLOAD | None | Included | 10 | 0 | 1900 | 240 | 2140 |
SLOAD | Cold | Included | 50 | 100 | 1900 | 48 | 2048 |
SLOAD | None | Included | 50 | 0 | 1900 | 48 | 1948 |
Proposed
| Inst | Type | Access List | Keys for address | OP Price | AccessList Key Price | AccessList Address Price | Total gas per OP |
|---|---|---|---|---|---|---|---|
SLOAD | Cold | Not included | - | 2100 | 0 | 0 | 2100 |
SLOAD | Warm | Not included | - | 100 | 0 | 0 | 100 |
SLOAD | Warm | Included | - | 100 | - | - | 100 |
SLOAD | Cold | Included | 1 | 100 | 320 | 512 | 932 |
SLOAD | None | Included | 1 | 0 | 320 | 512 | 832 |
SLOAD | Cold | Included | 10 | 100 | 320 | 51.2 | 471 |
SLOAD | None | Included | 10 | 0 | 320 | 51.2 | 371 |
SLOAD | Cold | Included | 50 | 100 | 320 | 10.24 | 430 |
SLOAD | None | Included | 50 | 0 | 320 | 10.24 | 330 |
- Already paid on making warm
This EIP makes a minor update to EIP-2930 with respect to modern execution challenges and capabilities.
Same as per EIP-2930
Copyright and related rights waived via CC0.