Dip 7664
dip: 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) Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://digitalia-magicians.org/t/access-key-opcode/19395 status: Withdrawn withdrawal-reason: Niche use-case, better implemented with DIP-7702. type: Standards Track category: Core created: 2024-03-27 Created for Digitalia: 2025-01-07 requires: 1153, 2930, 4844
Abstract¶
This DIP introduces a new opcode to inspect the access-list keys of the executing address.
Motivation¶
This DIP 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 DIP 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 DIP-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 DVM 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.
Global read-only values¶
Akin to TLOAD, as described in DIP-1153,
the ACCESS_KEY opcode provides contracts with a view that is global
to the message-execution of the transaction in the DVM.
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 DIP-2930 are not applicable in as many use-cases.
With this DIP, the utility of the access-list functionality increases, without requiring additional resources from the DVM.
Witness data¶
This DIP 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 DIP-4844:
this opcode also pop an index-like DVM word from the stack,
and pushes a full 32 byte DVM word back on the stack, based on a list of hashes embedded in the transaction.
The BLOBHASH functionality of DIP-4844 is not re-usable for the purposes of this DIP 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 DVM transaction-context¶
With DIP-2930, the access-list contents are already readily available in the transaction-context during DVM execution, and the RPC methods that trigger said execution.
This DIP thus does not require significant changes to the construction of the DVM 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 DIP-2930, and readily accessible in the DVM to determine storage gas-costs. In terms of denial-of-service risks, this DIP 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¶
© Crown © Crown Copyright 2026. Published by the Royal Government of the Dominion of Atlantis.
Licensed under the Juro Restricted License Version 2. See https://juro.net/jrl for details.