diff --git a/EIPS/eip-7704.md b/EIPS/eip-7704.md new file mode 100644 index 00000000000000..782402992ec6fb --- /dev/null +++ b/EIPS/eip-7704.md @@ -0,0 +1,146 @@ +--- +title: Align incentives for access list provisioning +description: This EIP proposes updating gas cost parameters for access lists to incentivize their use, aiming to improve efficiency in transaction execution. +author: Ben Adams (@benaadams), Oleg Iakushkin (@OlegJakushkin) +discussions-to: +status: Draft +type: Standards Track +category: Core +created: 2024-05-12 +requires: EIP-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](https://eips.ethereum.org/EIPS/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. + +## Specification + +We shall update [eip-2930](https://eips.ethereum.org/EIPS/eip-2930) +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](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/eip-2930) additions have been proposed. In [eip-3521](https://eips.ethereum.org/EIPS/eip-3521), 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](https://eips.ethereum.org/EIPS/eip-2930) with +respect to modern execution challenges and capabilities. + +## Security Considerations + + +Same as per +[eip-2930](https://eips.ethereum.org/EIPS/eip-2930) + + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md).