EIP-7707: Incentivize Access List Provisioning

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

---

Copyright and related rights waived via CC0.