Access List

An Access List is a feature introduced in Ethereum's EIP-2930 that allows a transaction sender to declare the exact set of state keys—specifically, account addresses and storage slots—that the transaction will access. By providing this list upfront, the protocol can waive the cold storage access penalty for those pre-declared items. This mechanism transforms what would be a costly 2,100 gas cold access into a cheaper 100 gas warm access, providing predictable and often reduced total gas costs for complex transactions involving multiple contract calls.

The primary technical motivation for Access Lists is to mitigate the gas cost unpredictability introduced by EIP-2929, which increased the cost of accessing cold storage. Without an Access List, the first time a transaction touches a new storage slot or address, it incurs a high cold access fee. By pre-declaring these accesses, the transaction effectively 'warms up' the slots, locking in lower costs. This is particularly beneficial for complex DeFi interactions, batched transactions, and smart contract wallets that may call multiple external contracts in a single execution.

In practice, an Access List is constructed as an array of objects, where each object contains an address and an optional array of storageKeys. Wallets and developers can simulate a transaction first to see which storage slots it touches, then generate and attach the corresponding list. While it adds a minor gas overhead for the list itself, the net effect is often a reduction in total cost for suitable transactions. This tool provides a direct way for sophisticated users to optimize gas expenditure through explicit state declaration.

An access list is a feature introduced by EIP-2930 that allows a transaction sender to specify a list of addresses and storage keys they plan to access. By declaring these interactions upfront, the Ethereum Virtual Machine (EVM) can perform a one-time warm-up of these storage locations. This mechanism directly addresses the gas cost irregularities introduced by EIP-2929, which increased the cost of accessing cold storage (first-time access) while reducing the cost for warm access (subsequent access within the same transaction). The access list essentially pre-pays to warm the specified slots, making the final gas cost more predictable and shielding users from unexpected mid-execution price increases.

The primary function of an access list is gas optimization and cost predictability. Without an access list, a complex transaction that touches many new storage slots could see its gas cost rise dynamically as it executes, potentially leading to an out-of-gas error. By specifying an access list, the transaction pays a fixed, upfront cost to warm all declared slots. While this adds a base cost to the transaction, it often results in an overall net reduction in total gas used, especially for transactions that perform multiple reads or writes to the same pre-warmed storage locations. This is crucial for smart contract interactions involving complex state changes, such as multi-step DeFi operations.

From a technical perspective, an access list is a JSON-like array included in the transaction payload. Each entry contains a address and an array of storageKeys (the 32-byte slots). Wallets and developers can generate these lists by simulating a transaction first to see which storage slots it accesses. It's important to note that an access list is optional; transactions can be sent without one, but they forgo the gas savings and cost certainty. Furthermore, an incorrectly specified access list that omits a needed slot does not cause the transaction to fail—it simply means that slot will be accessed as cold, incurring the higher gas fee at the point of use.

In the Ethereum Virtual Machine (EVM), cold storage access refers to the first read or write to a specific storage slot within a transaction, incurring a higher gas cost (e.g., 2,100 gas for a cold SLOAD). A subsequent access to the same slot within the same transaction is a warm access, which is significantly cheaper (e.g., 100 gas). This two-tiered pricing model, formalized in EIP-2929, was introduced to mitigate the risk of denial-of-service attacks that could exploit previously cheap storage operations.

The mechanism relies on an internal accessed addresses and accessed storage keys list maintained during transaction execution. When the EVM first touches a storage slot, it is marked as 'accessed' and moved from the cold to the warm state. This state is reset at the start of each new transaction. The primary purpose is to reflect the real-world cost of loading data into memory or cache; the first access is expensive, but cached data is cheap to reuse.

Access lists, introduced in EIP-2930, allow transactions to pre-declare which storage slots they will interact with. By including these slots in an access list, the transaction pays the cold access cost upfront, making all subsequent accesses warm. This can lead to overall gas savings for complex transactions that repeatedly interact with the same state, as it avoids paying the high cold access fee multiple times for slots accessed in different parts of the execution.

For developers, understanding this distinction is crucial for gas optimization. Code patterns that minimize first-time accesses to disparate storage locations and instead batch operations on the same data can reduce costs. For example, a function that loops through an array of user balances stored in separate slots will incur a cold access charge for each new user, making it gas-inefficient compared to using a mapping or a different data structure.

The cold/warm mechanic interacts with other opcode pricing. For instance, transaction CALL operations to new contract addresses also follow a similar pattern, with the first call being a cold address access. This creates a holistic gas model where the cost of execution is tied to the 'working set' of state a transaction touches, incentivizing smaller, more predictable state footprints and enhancing network security and performance.

An access list is a feature of EIP-2930 that defines a set of addresses and storage keys a transaction intends to interact with. By declaring these accesses upfront, the transaction pays a one-time warm storage access cost, rather than the more expensive cold access cost for each interaction during execution. This mechanism was introduced to mitigate the gas cost increases and unpredictability caused by EIP-2929, which raised the cost of accessing previously untouched state. The primary benefit is more predictable gas estimation for complex transactions involving multiple contract calls.

The structure of an access list is an array of objects, where each object contains an address and an array of storageKeys. For example, a transaction interacting with a Uniswap pool might include the pool's contract address and the specific storage slots for its reserves in its access list. This pre-declaration signals to the Ethereum Virtual Machine (EVM) that these state items should be loaded into a "warmed" state before execution begins. Transactions without an access list are still valid but will incur the full, higher cold access cost for each first-time state read or write.

From a practical standpoint, access lists are most beneficial for transactions that interact with multiple contracts or specific, known storage slots, such as complex DeFi operations or batched calls. Wallets and developers can use the eth_createAccessList RPC method to simulate a transaction and generate an optimal list. While adding an access list increases the intrinsic calldata cost of a transaction, this is often offset by the significant savings on execution gas, leading to lower total costs for suitable operations. This design represents a key evolution in Ethereum's fee market, balancing security with economic efficiency for power users.