From c4cff6c68f49c6ceb23ccc1d66b3beafdaa6241e Mon Sep 17 00:00:00 2001 From: Oleg Jakushkin Date: Sun, 12 May 2024 01:46:14 +0100 Subject: [PATCH 1/3] Create eip-7703.md 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. Co-authored-by: Ben Adams Co-authored-by: Oleg Iakushkin --- EIPS/eip-7703.md | 144 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 EIPS/eip-7703.md diff --git a/EIPS/eip-7703.md b/EIPS/eip-7703.md new file mode 100644 index 00000000000000..d4722c25b58db3 --- /dev/null +++ b/EIPS/eip-7703.md @@ -0,0 +1,144 @@ +--- +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. + +### 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). From 003a1189c5c9e62b51932b603044735cdba9acf2 Mon Sep 17 00:00:00 2001 From: Oleg Jakushkin Date: Wed, 15 May 2024 15:42:24 +0100 Subject: [PATCH 2/3] Refrencing eip-3521 --- EIPS/eip-7703.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-7703.md b/EIPS/eip-7703.md index d4722c25b58db3..782402992ec6fb 100644 --- a/EIPS/eip-7703.md +++ b/EIPS/eip-7703.md @@ -90,7 +90,9 @@ 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. +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 From 18b28bfb18333f0069f8ff1fa2466c08fee8c8b3 Mon Sep 17 00:00:00 2001 From: Oleg Jakushkin Date: Wed, 15 May 2024 23:49:28 +0100 Subject: [PATCH 3/3] Rename eip-7703.md to eip-7704.md renamed EIP file --- EIPS/{eip-7703.md => eip-7704.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-7703.md => eip-7704.md} (100%) diff --git a/EIPS/eip-7703.md b/EIPS/eip-7704.md similarity index 100% rename from EIPS/eip-7703.md rename to EIPS/eip-7704.md