alt-da support

[emilianobonassi]

Is there support for alt-da derivation? it seems just a few pieces of it. this will unlock many rollups being using alt-da for fpm and in general for other integrations like risc0 and op-succinct

[samlaf]

We are trying to add support to kona for eigenda, so currently exploring best ways to do this.

Background Info

Celestia wrote a fork. This has been invaluable in helping us understand how to do altda integrations, so want to thank Diego for making this public.

However, their approach (embedding the altda provider inside the calldata and blob data sources) does the opposite of what the kona book's custom da-provider section recommends (doing the wrapping the other way around, with an altda_data_source wrapping the ethereum_data_source).

The approach in the book seems concordant with @refcell's latest answer here:

Kona is built so that trait abstractions provide a way to add new implementations through separate crates. The changes you've made here should go in a new crate, in a new repository that pulls in kona crates as dependencies. This way, new implementations don't need to be merged into kona, but can live outside of the kona repository while still building ontop of kona. See hilo for example, which pulls in kona-derive and kona-driver as dependencies, and builds off the trait abstractions in kona to use the derivation pipeline and driver.

Proposed Architecture

It seems like op's prefered approach is that each altda team maintain their own crate, which would import kona modules, and implement:

1. an AltDA DataAvailabilityProvider for the client's derivation pipeline
2. an altDA wrapper around the Fetcher to deal with AltDA hints and oracle requests.

These crates would then need to be upstreamed and used (guarded by feature flags) in the different OP implementations such as hilo, op-succinct, kailua.

Here's an example of how this could work in Kailua. Their client's driver code could look like

let dap = EthereumDataSource::new_from_parts(chain_provider.clone(), blob_provider, &cfg);

#[cfg(feature = "eigenda")]
let dap = {
    let eigenda_blob_source = EigenDABlobSource::new(eigenda_blob_provider);
    EigenDADataSource::new(dap, Some(eigenda_blob_source))
};

#[cfg(feature = "celestia")]
let dap = {
    let celestia_blob_source = CelestiaBlobSource::new(celestia_blob_provider);
    CelestiaDataSource::new(dap, Some(celestia_blob_source))
};

And their host's main code would start the server and client using the altda function (or perhaps these functions could use trait-based dependency injection instead... see discussion section below):

#[cfg(not(any(feature = "eigenda", feature = "celestia")))]
start_server_and_native_client(cfg.kona.clone())
    .await
    .expect("Proving failure");

#[cfg(feature = "eigenda")]
eigenda_kona::start_server_and_native_client(cfg.kona.clone())
    .await
    .expect("Proving failure");

#[cfg(feature = "celestia")]
celestia_kona::start_server_and_native_client(cfg.kona.clone())
    .await
    .expect("Proving failure");

Op-Succinct currently uses their own fork of kona, which would make this approach not work. Hopefully this fork is temporary until kona provides a multi-block derivation?

Discussion / Worries

The client DAP trait seems very clean, but forking the start_server_and_native_client here seems a bit problematic and a headache to maintain with rebases and potential code changes. Are there better approaches, potentially trait-based like for the client side?

Have not thought about this enough to have a good suggestion here, but perhaps the PreimageServer, start_native_preimage_server, etc. that use the Fetcher struct could use a trait instead, such that we could pass a Fetcher wrapper that would also implement altda hints/requests.