This EIP introduces a new opcode to inspect the access-list keys of the executing address.
This EIP serves as a substitute of top-level-call detection to enable a smart-contract to enforce static declaration of attributes.
Previously, application-layer contracts, against common advice from account-abstraction proponents, used to rely
on the tx.origin to enforce a top-level call, such that the contract inputs are encoded as transaction input.
While the access-list of transactions directly affects the execution, it only affects the gas-costs.
This EIP enhances the access-list feature to provide the property of statically-defined contract-inputs,
without relying on top-level calls, the tx.origin behavior, or gas introspection.
This enables smart contracts to reliably enforce static declaration of inputs.
This is a step towards fulfilling the purposes as described in the Motivation of EIP-2930:
Introduces the access list format and the logic for handling the format. This logic can later be repurposed for many other purposes, including block-wide witnesses, use in ReGenesis, moving toward static state access over time, and more."
| Constant | Value |
|---|---|
ACCESS_KEY_OPCODE_GAS | 3 |
ACCESS_KEY_OPCODE_BYTE | 0x4B |
We add an instruction ACCESS_KEY (with opcode ACCESS_KEY_OPCODE_BYTE) which pops index from the top
of the stack as big-endian uint256, and pushes tx.access_list[address][index] back on the stack,
if address is present in the tx.access_list and index < len(tx.access_list[address]),
and otherwise pushes a zeroed bytes32 value.
The opcode has a fixed gas cost of ACCESS_KEY_OPCODE_GAS.
The intrinsic gas costs of the access-list contents of the transaction itself do not change.
Static declaration of contract-inputs enables advanced layer-two constructions and block-building techniques: data is available without EVM introspection, and contracts can reliably tell if the executing transaction declared critical properties to the block builder and verifying nodes.
Static-declaration of contract inputs is now independent of account-abstraction related changes, such as transaction bundlers, as well as in-protocol with 3074.
Akin to TLOAD, as described in EIP-1153,
the ACCESS_KEY opcode provides contracts with a view that is global
to the message-execution of the transaction in the EVM.
However, with ACCESS_KEY it is guaranteed to be read-only, and cannot change during the execution of a transaction.
Access-lists are under-utilized today: very few users utilize this to warm-up storage interactions for reduced gas costs. Generally the gas cost savings achieved with EIP-2930 are not applicable in as many use-cases.
With this EIP, the utility of the access-list functionality increases, without requiring additional resources from the EVM.
This EIP supports the transformation of applications to reduce statefulness, by supporting read-only application state to be provided to contracts without requiring the contract caller to support forwarding of data.
The access-list contents may contain witness-data, which the contract can verify and utilize statelessness.
The gas cost of ACCESS_KEY_OPCODE_GAS gas matches that of similar operations,
specifically the BLOBHASH opcode of EIP-4844:
this opcode also pop an index-like EVM word from the stack,
and pushes a full 32 byte EVM word back on the stack, based on a list of hashes embedded in the transaction.
The BLOBHASH functionality of EIP-4844 is not re-usable for the purposes of this EIP however,
as the intention is to have access to just the statically declared hash, and not the cost of a blob.
ACCESS_KEYAccess-lists currently only support a list of access-keys. The list is not enforced to be sorted, and thus supports indexed lookups.
This is not a LOAD opcode, as SLOAD or TLOAD are, since the opcode returns a key.
This enhancement of access-lists utility does not affect the access-list encoding, or the existing transaction types that support access-lists.
With EIP-2930, the access-list contents are already readily available in the transaction-context during EVM execution, and the RPC methods that trigger said execution.
This EIP thus does not require significant changes to the construction of the EVM context, nor any changes to RPC methods.
The block fee-recipient, and any other warmed-up attributes not declared statically in the transaction access-list, must not be considered to be part of the access-list.
The access-list attributes are already gas-metered in EIP-2930, and readily accessible in the EVM to determine storage gas-costs. In terms of denial-of-service risks, this EIP introduces no new significant data or data-processing costs.
The access-list is read-only, and thus forms a minimal risk to application-developers.
The access is scoped strictly to the contract that would otherwise perform a warm SLOAD,
and thus storage-layout abstractions do not leak between different smart contract applications.
Copyright and related rights waived via CC0.