⚠️ Draft Standards Track: Core

EIP-7707: Incentivize Access List Provisioning

This EIP proposes updating gas cost parameters for access lists to incentivise their use and improve transaction execution efficiency.

Authors	Ben Adams (@benaadams), Oleg Iakushkin (@OlegJakushkin)
Created	2024-05-12
Discussion Link	https://ethereum-magicians.org/t/eip-7707-align-incentives-for-access-list-provisioning/20025
Requires	EIP-2930

Abstract
Motivation
Specification
Rationale
- Examples
Backwards Compatibility
Security Considerations
Copyright

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 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 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 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.

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 with respect to modern execution challenges and capabilities.

Security Considerations

Same as per EIP-2930

Copyright

Citation

Please cite this document as:

Ben Adams (@benaadams), Oleg Iakushkin (@OlegJakushkin), "EIP-7707: Incentivize Access List Provisioning [DRAFT]," Ethereum Improvement Proposals, no. 7707, May 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7707.