IInterpreterStoreV1

Git Source

Tracks state changes on behalf of an interpreter. A single store can handle state changes for many calling contracts, many interpreters and many expressions. The store is responsible for ensuring that applying these state changes is safe from key collisions with calls to set from different msg.sender callers. I.e. it MUST NOT be possible for a caller to modify the state changes associated with some other caller. The store defines the shape of its own state changes, which is opaque to the calling contract. For example, some store may treat the list of state changes as a pairwise key/value set, and some other store may treat it as a literal list to be stored as-is. Each interpreter decides for itself which store to use based on the compatibility of its own opcodes. The store MUST assume the state changes have been corrupted by the calling contract due to bugs or malicious intent, and enforce state isolation between callers despite arbitrarily invalid state changes. The store MUST revert if it can detect invalid state changes, such as a key/value list having an odd number of items, but this MAY NOT be possible if the corruption is undetectable.

Functions

set

Mutates the interpreter store in bulk. The bulk values are provided in the form of a uint256[] which can be treated e.g. as pairwise keys and values to be stored in a Solidity mapping. The IInterpreterStoreV1 defines the meaning of the uint256[] for its own storage logic.

function set(StateNamespace namespace, uint256[] calldata kvs) external;

Parameters

get

Given a fully qualified namespace and key, return the associated value. Ostensibly the interpreter can use this to implement opcodes that read previously set values. The interpreter MUST apply the same qualification logic as the store that it uses to guarantee consistent round tripping of data and prevent malicious behaviours. Technically also allows onchain reads of any set value from any contract, not just interpreters, but in this case readers MUST be aware and handle inconsistencies between get and set while the state changes are still in memory in the calling context and haven't yet been persisted to the store. IInterpreterStoreV1 uses the same fallback behaviour for unset keys as Solidity. Specifically, any UNSET VALUES SILENTLY FALLBACK TO 0.

function get(FullyQualifiedNamespace namespace, uint256 key) external view returns (uint256);

Parameters

Returns