Add EIP: Incentivize Access List Provisioning

EIPS/eip-7704.md

@@ -0,0 +1,147 @@
+---
+eip: 7704
+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-7704-align-incentives-for-access-list-provisioning/20025
+status: Draft
+type: Standards Track
+category: Core
+created: 2024-05-12
+requires: 2930
+---
+
+## Abstract
+
+To facilitate future developments of parallel data load, we need to
+encourage as many transactions as possible that contain as complete and
+valid access lists. Current access list pricing does not sufficiently incentivize their inclusion, and this EIP aims to address this gap.
+
+## 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).