# Execution Layer Rollout plan

## Scope and overall goals

In this document, we state the different phases for deploying the necessary artifacts from the EL that will allow a prover to create proofs of executions. These zkEVM proofs will then be used in a modified consensus layer client for verifying the correctness of an execution payload.

# Deliverable: Stateless input generation

This is the input to the stateless function. At a high level, one needs:
- ChainID
- Block
- Merkle Patricia Trie Multi Witness

The first two are readily available in all clients. The last is what we want stateful EL clients to implement. While we have optional proofs, this is better served via an RPC endpoint, since the one who is creating the proof for block N is most likely not going to be the block builder for block N.

## Phase 0 - Implement debug_executionWitness

**Goal:** To generate the execution witness for recent blocks and expose it via a RPC endpoint.

**Description:**

- While this has not been standardized in EEST, we recommend using reth as a reference implementation [here](https://github.com/paradigmxyz/reth/blob/3e96557e693bf92b1193b19625b457c0bbad9be0/crates/rpc/rpc/src/debug.rs#L515). Phase 1 of the guest program also makes note of this current lack of standardization.

# Deliverable: Guest program

The guest program is the function that gets proven in a zkEVM. This is commonly referred to as the stateless program.

## Phase 0 - Compile to target

**Goal:** If targeting RISC-V, compile an empty program to [RV64IM-None](https://github.com/eth-act/zkvm-standards/tree/main/standards/riscv-target)

**Description:**

- Compilation pipeline should use a Dockerfile, so that it can eventually be plugged into [Ere](https://github.com/eth-act/ere)
- Depending on your programming language, this phase may be trivial.
- The output should be an ELF

## Phase 1 - Create a stateless validation program

**Goal:** To create a program that is able to validate the state transition function using MPT witnesses.

**Description:**

- The exact program API and the standardization on inputs is blocked by it not being in the [execution specs](https://github.com/ethereum/execution-specs/issues/1590)
- While this is not standardized, we remark that the input should be a Block and the ExecutionWitness. See [here](https://github.com/paradigmxyz/reth/blob/b3c00ed602f2a8805974f25be714a3bea26901e9/crates/stateless/src/lib.rs#L64).
- This must be tested against the Ethereum Execution Spec Tests(EEST). The ExecutionWitness will be generated outside of the spec tests until a reference implementation is added.

## Phase 2 - Compile the stateless validation program to target

**Goal:** To compile the stateless validation program made in phase to the relevant target using the workflow created in phase 1

**Description:**

- This step may prove to be challenging as the state validation program may use dependencies or primitives that are not compatible with the target. Example of this is the standard library in Rust when compiling to bare metal targets.

> Note: So far, none of the above phases have required knowledge of zkVMs. At this point in time, it should be possible to run the ELF using qemu-virt

## Phase 3 - Integrate zkVM IO

**Goal:** To allow input to be passed to the program when executed in zkVM environment

**Description:**

- It is first recommended to implement stdout as a first step, to allow one to print to the console when running the zkVM emulator.
- Normal programs will read from stdin via system calls. In a zkVM environment, this is not the case. The exact mechanism that is used to get input is somewhat zkVM specific. [Here](https://github.com/eth-act/zkvm-standards/pull/8)
- We recommend testing this out on a simpler program and not the stateless validation program at first

> For testing, we advise using the emulator that comes packaged with the zkVM, since creating proofs would take too long.

## Phase 4 - Integrate zkVM precompiles

**Goal:** To allow particular functions to be accelerated when in zkVM environment

**Description:**

- These can be viewed as software accelerators. For a list of the available functions, see [here](https://github.com/eth-act/zkvm-standards/blob/main/standards/c-interface-accelerators/zkvm_accelerators.h)
- We recommend testing this out on a simpler program first and not the stateless validation program at first

> For testing, we advise using the emulator that comes packaged with the zkVM, since creating proofs would take too long.

## Phase 5 - Distribution

**Goal:** To emulate the end-to-end workflow for an execution layer(EL) client.

**Description:**

- Builds should be reproducible, we would prefer Dockerfiles so that we can integrate it easily into [Ere](https://github.com/eth-act/ere)
- Note that block builders and Cl clients will download the ELF precompiled from some location. In almost all cases, this will be the EL's release page.
- Since we have chosen to not standardize on the memory layout and precompile calling convention, each zkVM will have its own ELF.
- An EL will eventually need to create these ELFs for the supported zkVMs.
- We recommend the following naming scheme for each elf: `<EL_NAME>-<EL_VERSION>-<ZKVM_NAME>-<ZKVM_SDK_VERSION>` -- an example of this is `geth-v1_14_1-sp1-v3_2_0`
- All ELFs must be signed using minisign