Module Evm_node_lib_dev.Evm_context

start creates a new worker to manage a local EVM context where it initializes the index, and use a checkpoint mechanism to load the latest store if any. Returns a value telling if the context was loaded from disk (Loaded) or was initialized from scratch (Created). Returns also the smart rollup address.

kernel_path can be provided to cover the case where the context does not exist yet, and is ignored otherwise.

smart_rollup_address can be provided either when starting from a non-existing data-dir, or when starting a sandbox.

store_perm decides whether or not the worker can modify the Irmin context (it is most certainly an artifact of the past, made outdated by the Evm_ro_context module. Clearly, ~store_perm:`Read_only menas you want to use Evm_ro_context instead.

snapshot_source can be provided to automatically fetch and import the snapshot from a URL if the data_dir was not initialized before.

init_from_rollup_node ~omit_delayed_tx_events ~rollup_node_data_dir () initialises the irmin context and metadata of the evm using the latest known evm state of the given rollup node. if omit_delayed_tx_events dont populate the delayed tx event from the state into the db.

reset ~data_dir ~l2_level reset the sequencer storage to l2_level. Warning: b Data will be lost !

apply_evm_events ~finalized_level events applies all the events events on the local context. The events are performed in a transactional context.

Stores finalized_level with new_last_known_l1_level if provided.

Same as apply_evm_events, but wait for the result of the request

apply_blueprint ?events timestamp payload delayed_transactions applies payload in the freshest EVM state stored under ctxt at timestamp timestamp, forwards the Blueprint_types.with_events, and returns the transaction hashes of the created block. It commits the result if the blueprint produces the expected block.

apply_chunks ~signer chunks delayed_transactions works similarly to apply_blueprint, with the notable difference that it allows to start applying the chunks of a blueprint before their signatures (computed by signer) are ready.

apply_finalized_levels ~l1_level ~start_l2_level ~end_l2_level stores the finalization relationship between L1 level l1_level and the L2 level range from start_l2_level to end_l2_level. It updates the L1-L2 level mappings, records the finalized level ranges, updates metrics, and broadcasts notifications to subscribers about the finalization event.

It is only used for observers not tracking a rollup node (i.e not sequencer, observers tracking a rollup-node) since all actions described above are already performed by calling the apply_evm_events function when receiving events from the rollup node.

patch_kernel ?block_number kernel modifies the state of the block_number (defaults to current head) of the EVM node to replace its kernel with the provided kernel.

provision_balance address value modifies the state of the current head of the EVM node to increase the balance of address by value.

block_number can be provided to modify another block.

patch_sequencer_key public_key modifies the in memory state of the EVM node to replace the sequencer key with public_key. It does not modify the current head.

patch_state ~key ~value () writes value at key.

potential_observer_reorg evm_node_endpoint blueprint_with_events checks with the evm_node_endpoint if a reorganization happened, and return the reorganization level if it exists.

A reorganization can happen typically if the kernel flushed its delayed inbox in a blueprint.

Update the EVM context using the latest next block information received from the stream (timestamp + block number), and start a new internal state based on it for single transaction execution.

execute_single_transaction evm_state transaction time number tx_index executes a single Ethereum transaction within the current future block state. Returns the execution outcome as Transaction_receipt.t. Can be None if single execution was locked by a divergence or stream startup. Hash is exclusively used by OTel tracing, we take it as input to avoid recomputing.

Watcher that gets notified each time a new block is produced.

Watcher that gets notified each time a new receipt is produced.

Watcher that gets notified of new L1 levels its associated L2 levels.

check_history_mode ?switch ~store_history_mode ~history_mode () checks that the history mode are compatible, and returns the history mode the node should run in, depending on its stored mode store_history_mode, the one requested by the configuration history_mode and if it is allowed to switch.