IInterpreterV2

Git Source

Exposes the function pointers as uint16 values packed into a single bytes in the same order as they would be indexed into by opcodes. For example, if opcode 2 should dispatch function at position 0x1234 then the start of the returned bytes would be 0xXXXXXXXX1234 where X is a placeholder for the function pointers of opcodes 0 and 1. IExpressionDeployerV3 contracts use these function pointers to "compile" the expression into something that an interpreter can dispatch directly without paying gas to lookup the same at runtime. As the validity of any integrity check and subsequent dispatch is highly sensitive to both the function pointers and overall bytecode of the interpreter, IExpressionDeployerV3 contracts SHOULD implement guards against accidentally being deployed onchain paired against an unknown interpreter. It is very easy for an apparent compatible pairing to be subtly and critically incompatible due to addition/removal/reordering of opcodes and compiler optimisations on the interpreter bytecode. This MAY return different values during construction vs. all other times after the interpreter has been successfully deployed onchain. DO NOT rely on function pointers reported during contract construction.

function functionPointers() external view returns (bytes calldata);

eval2

The raison d'etre for an interpreter. Given some expression and per-call additional contextual data, produce a stack of results and a set of state changes that the caller MAY OPTIONALLY pass back to be persisted by a call to IInterpreterStoreV1.set. There are two key differences between eval and eval2:

eval was ambiguous about whether the top value of the final stack is the first or last item of the array. eval2 is unambiguous in that the top of the stack MUST be the first item in the array.
eval2 allows the caller to specify inputs to the entrypoint stack of the expression. This allows the eval and offchainDebugEval functions to be merged into a single function that can be used for both onchain and offchain evaluation. For example, the caller can simulate "internal" calls by specifying the inputs to the entrypoint stack of the expression as the outputs of some other expression. Legacy behaviour can be achieved by passing an empty array for inputs.

function eval2(
    IInterpreterStoreV1 store,
    FullyQualifiedNamespace namespace,
    EncodedDispatch dispatch,
    uint256[][] calldata context,
    uint256[] calldata inputs
) external view returns (uint256[] calldata stack, uint256[] calldata writes);

Parameters

Name	Type	Description
`store`	`IInterpreterStoreV1`	The storage contract that the returned key/value pairs MUST be passed to IF the calling contract is in a non-static calling context. Static calling contexts MUST pass `address(0)`.
`namespace`	`FullyQualifiedNamespace`	The fully qualified namespace that will be used by the interpreter at runtime in order to perform gets on the underlying store.
`dispatch`	`EncodedDispatch`	All the information required for the interpreter to load an expression, select an entrypoint and return the values expected by the caller. The interpreter MAY encode dispatches differently to `LibEncodedDispatch` but this WILL negatively impact compatibility for calling contracts that hardcode the encoding logic.
`context`	`uint256[][]`	A 2-dimensional array of data that can be indexed into at runtime by the interpreter. The calling contract is responsible for ensuring the authenticity and completeness of context data. The interpreter MUST revert at runtime if an expression attempts to index into some context value that is not provided by the caller. This implies that context reads cannot be checked for out of bounds reads at deploy time, as the runtime context MAY be provided in a different shape to what the expression is expecting.
`inputs`	`uint256[]`	The inputs to the entrypoint stack of the expression. MAY be empty if the caller prefers to specify all inputs via. context.

Returns

Name	Type	Description
`stack`	`uint256[]`	The list of values produced by evaluating the expression. MUST NOT be longer than the maximum length specified by `dispatch`, if applicable. MUST be ordered such that the top of the stack is the FIRST item in the array.
`writes`	`uint256[]`	A list of values to be processed by a store. Most likely will be pairwise key/value items but this is not strictly required if some store expects some other format.

IInterpreterV2

Functions

functionPointers

eval2