RainterpreterNPE2

Inherits: IInterpreterV2, ERC165

Implementation of a Rainlang interpreter that is compatible with native onchain Rainlang parsing.

There are MANY ways that eval can be forced into undefined/corrupt behaviour by passing in invalid data. This is a deliberate design decision to allow for the interpreter to be as gas efficient as possible. The interpreter is provably read only, it contains no state changing evm opcodes reachable on any logic path. This means that the caller can only harm themselves by passing in invalid data and either reverting, exhausting gas or getting back some garbage data. The caller can trivially protect themselves from these OOB issues by ensuring the integrity check has successfully run over the bytecode before calling eval. Any smart contract caller can do this by using a trusted and appropriate deployer contract to deploy the bytecode, which will automatically run the integrity check during deployment, then keeping a registry of trusted expression addresses for itself in storage. This appears first in the contract in the hope that the compiler will put it in the most efficient internal dispatch location to save a few gas per eval call.

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

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
`<none>`	`uint256[]`	stack 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.
`<none>`	`uint256[]`	writes 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.

supportsInterface

See {IERC165-supportsInterface}.

function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool);

functionPointers

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 virtual returns (bytes memory);

RainterpreterNPE2

Functions

eval2

supportsInterface

functionPointers