diff --git a/EIPS/eip-7664.md b/EIPS/eip-7664.md new file mode 100644 index 00000000000000..4a2b3f8407ac9e --- /dev/null +++ b/EIPS/eip-7664.md @@ -0,0 +1,146 @@ +--- +eip: 7664 +title: Access-Key opcode +description: The access-key opcode enables contracts to read inputs that are statically declared in access-lists. +author: Diederik Loerakker (@protolambda) +discussions-to: https://ethereum-magicians.org/t/access-key-opcode/19395 +status: Draft +type: Standards Track +category: Core +created: 2024-03-27 +requires: 1153, 2930, 3074, 4844 +--- + +## Abstract + +This EIP introduces a new opcode to inspect the access-list keys of the executing address. + +## Motivation + +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](./eip-2930.md): + +> 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." + +## Specification + +### Parameters + +| Constant | Value | +|----------------------------|--------| +| `ACCESS_KEY_OPCODE_GAS` | `3` | +| `ACCESS_KEY_OPCODE_BYTE` | `0x4B` | + +### Opcode + +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. + +### Gas costs + +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. + +## Rationale + +### Static analysis of transactions + +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 [EIP-3074](./eip-3074.md). + +### Global read-only values + +Akin to `TLOAD`, as described in [EIP-1153](./eip-1153.md), +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-list utility + +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. + +### Witness data + +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. + +### Gas costs + +The gas cost of `ACCESS_KEY_OPCODE_GAS` gas matches that of similar operations, +specifically the `BLOBHASH` opcode of [EIP-4844](./eip-4844.md): +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](./eip-4844.md) 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. + +### Naming of `ACCESS_KEY` + +Access-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. + +## Backwards Compatibility + +### No transaction-type changes + +This enhancement of access-lists utility does not affect the access-list encoding, +or the existing transaction types that support access-lists. + +### Minimal impact on EVM transaction-context + +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. + +## Test Cases + +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. + +## Security Considerations + +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 + +Copyright and related rights waived via [CC0](../LICENSE.md).