Add EIP: Access-Key opcode

EIPS/eip-XXXX.md

@@ -0,0 +1,145 @@
+---
+eip: XXXX
+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:
+
+> 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.
+
+### Global read-only values
+
+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-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:
+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. 
+
+## 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.
+
+### 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.
+
+## 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).