Optimism Documentation

This guide walks through implementing the data source traits that let you run kona-client, or a variation of it, on a verifiable backend of your choosing. Before starting, make sure you’re familiar with the two components being composed - the derivation pipeline and the execution engine - covered in understanding the OP Stack STF.

Backend Traits

Covered in the FPVM Backend section of the book, kona-client ships with an implementation of kona-derive and kona-executor’s data source traits which pull in data over the PreimageOracle ABI. However, running kona-client on top of a different verifiable environment, i.e. a zkVM or TEE, is also possible through custom implementations of these data source traits. op-succinct is an excellent example of both a custom backend and a custom program, implementing both kona-derive and kona-executor’s data source traits backed by sp1_lib::io in order to:

Execute kona-client verbatim, proving a single block’s derivation and execution on SP-1.
Derive and execute an entire Span Batch worth of L2 blocks, using kona-derive and kona-executor.

This section of the book outlines how you can do the same for a different platform.

Custom `kona-derive` sources

Before getting started, we need to create custom implementations of the following traits:

Trait	Description
`ChainProvider`	The `ChainProvider` trait describes the minimal interface for fetching data from L1 during L2 chain derivation.
`L2ChainProvider`	The `ChainProvider` trait describes the minimal interface for fetching data from the safe L2 chain during L2 chain derivation.
`BlobProvider`	The `BlobProvider` trait describes an interface for fetching EIP-4844 blobs from the L1 consensus layer during L2 chain derivation.

Once these are implemented, constructing the pipeline is as simple as passing in the data sources to the PipelineBuilder. Keep in mind the requirements for validation of incoming data, depending on your platform. For example, programs targeting zkVMs must constrain that the incoming data is indeed valid, whereas fault proof programs can offload this validation to the on-chain implementation of the host.

let chain_provider = ...;
let l2_chain_provider = ...;
let blob_provider = ...;
let l1_origin = ...;

let cfg = Arc::new(RollupConfig::default());
let attributes = StatefulAttributesBuilder::new(
   cfg.clone(),
   l2_chain_provider.clone(),
   chain_provider.clone(),
);
let dap = EthereumDataSource::new(
   chain_provider.clone(),
   blob_provider,
   cfg.as_ref()
);

// Construct a new derivation pipeline.
let pipeline = PipelineBuilder::new()
   .rollup_config(cfg)
   .dap_source(dap)
   .l2_chain_provider(l2_chain_provider)
   .chain_provider(chain_provider)
   .builder(attributes)
   .origin(l1_origin)
   .build();

From here, a custom derivation driver is needed to produce the desired execution payload(s). An example of this for kona-client can be found in the single proof implementation.

`kona-mpt` / `kona-executor` sources

Before getting started, we need to create custom implementations of the following traits:

Trait	Description
`TrieProvider`	The `TrieProvider` trait describes the interface for fetching trie node preimages and chain information while executing a payload on the L2 chain.
`TrieDBHinter`	The `TrieDBHinter` trait describes the interface for requesting the host program to prepare trie proof preimages for the client’s consumption. For targets with upfront witness generation, i.e. zkVMs, a no-op hinter is exported as `NoopTrieHinter`.

Once we have those, the StatelessL2BlockExecutor can be constructed like so:

let cfg = RollupConfig::default();
let provider = ...;
let hinter = ...;

let executor = StatelessL2BlockExecutor::builder(&cfg, provider, hinter)
   .with_parent_header(...)
   .build();

let header = executor.execute_payload(...).expect("Failed execution");

Bringing it Together

Once your custom backend traits for both kona-derive and kona-executor have been implemented, your final binary may look something like that of kona-client’s. Alternatively, if you’re looking to prove a wider range of blocks, op-succinct’s range program offers a good example of running the pipeline and executor across a string of contiguous blocks.

Overview

Kona - Introduction

Kona - Kona for Node Operators

Kona - Kona as a Library

Kona - RFC

op-reth - Introduction

op-reth - Running op-reth

op-reth - CLI Reference

op-alloy - Introduction

op-alloy - Building

op-alloy - Reference

op-revm

Custom Backends

Backend Traits

Custom `kona-derive` sources

`kona-mpt` / `kona-executor` sources

Bringing it Together

​Backend Traits

​Custom kona-derive sources

​kona-mpt / kona-executor sources

​Bringing it Together

Backend Traits

Custom `kona-derive` sources

`kona-mpt` / `kona-executor` sources

Bringing it Together