--- eip: 7707 title: Incentivize Access List Provisioning description: This EIP proposes updating gas cost parameters for access lists to incentivise their use and improve transaction execution efficiency. author: Ben Adams (@benaadams), Oleg Iakushkin (@OlegJakushkin) discussions-to: https://ethereum-magicians.org/t/eip-7707-align-incentives-for-access-list-provisioning/20025 status: Stagnant type: Standards Track category: Core created: 2024-05-12 requires: 2930 --- ## Abstract 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. ## Motivation While [EIP-2930](./eip-2930.md) 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. ## Specification We shall update [EIP-2930](./eip-2930.md) parameters: | Constant | Value | | - | - | | `ACCESS_LIST_STORAGE_KEY_COST` | 320 | | `ACCESS_LIST_ADDRESS_COST` | 512 | ## Rationale 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](./eip-2930.md) 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](./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`. ### Examples 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 ## Backwards Compatibility This EIP makes a minor update to [EIP-2930](./eip-2930.md) with respect to modern execution challenges and capabilities. ## Security Considerations Same as per [EIP-2930](./eip-2930.md) ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).