# Journaling the Implementation of Optional Execution proofs (EIP8025) for Prysm

This document details out the process of the implemenation of optional proofs (EIP8025) on Prysm CL client.

## Understanding what this implemenation entails;
Here are some resources providing broader details regarding this Feature independent of the "Prysm" implemenation.

1. https://hackmd.io/@kevaundray/BJeZCo5Tgx
2. https://github.com/ethereum/consensus-specs/blob/master/specs/_features/eip8025/zkevm.md
3. https://github.com/ethereum/consensus-specs/blob/master/specs/_features/eip8025/beacon-chain.md
4. https://github.com/ethereum/consensus-specs/blob/master/specs/_features/eip8025/validator.md
5. https://github.com/ethereum/consensus-specs/blob/master/specs/_features/eip8025/p2p-interface.md
6. https://github.com/sigp/lighthouse/issues/8327
7. https://github.com/sigp/lighthouse/pull/8316 [This is a similar implemenation but on the lighthouuse CL client]

## PR diff context file
from this pr: https://github.com/sigp/lighthouse/pull/8316, here are the changes introduced;

### 1. Core Data Structures & Types

#### `consensus/types/src/execution_proof.rs` & `execution_proof_id.rs`
* **Changes:**
* Introduces `ExecutionProof` struct containing:
* `proof_id` (u8): Identifies the ZK Prover/Verifier stack (e.g., 0=SP1, 1=Risc0).
* `slot` (Slot): Beacon slot.
* `block_hash` (ExecutionBlockHash): The EL payload hash.
* `block_root` (Hash256): The CL block root.
* `proof_data` (VariableList): The actual ZK bytes.
* Introduces constants `MAX_PROOF_DATA_BYTES` (approx 1MB) and `DEFAULT_MIN_PROOFS_REQUIRED` (2).
* **Goal:** Defines the payload that moves across the wire to prove validity.

#### `consensus/types/src/chain_spec.rs`
* **Changes:**
* Adds `zkvm_enabled` (bool) and `zkvm_min_proofs_required` (usize) to `ChainSpec`.
* Adds logic to determine if the current fork/epoch requires ZK proofs.
* **Goal:** Allows the node to toggle ZK mode on/off and configure how many proofs are needed for safety.

### 2. Networking (P2P & RPC)
These files handle how the proofs move between nodes. Prysm uses `libp2p` but handles topics/RPCs via its specific `p2p` package.

#### `beacon_node/lighthouse_network/src/discovery/enr.rs`
* **Changes:**
* Adds a `zkvm` key to the ENR (Ethereum Node Record).
* Logic to advertise `zkvm=true` if the node is configured to use execution proofs.
* **Goal:** Allows peers to discover other nodes that support/require ZK proofs.

#### `beacon_node/lighthouse_network/src/rpc/methods.rs` & `protocol.rs`
* **Changes:**
* Defines `ExecutionProofsByRoot` RPC method (Req/Resp).
* Request contains: `block_root`, `count_needed`, and `already_have` (proof IDs).
* Response contains: `ExecutionProof`.
* **Goal:** Allows a node to actively request proofs for a block if they missed them on gossip.

#### `beacon_node/lighthouse_network/src/types/topics.rs` & `pubsub.rs`
* **Changes:**
* Adds `execution_proof` gossip topic.
* Logic to subscribe to this topic if `zkvm_enabled` is true.
* **Goal:** Propagates proofs immediately upon generation to the network.

### 3. Core Logic: Data Availability & Verification

#### `beacon_node/beacon_chain/src/data_availability_checker.rs` (and submodules)
* **Changes:**
* **Crucial Logic:** A block is traditionally "available" if we have the Block Body + Blobs. This file updates that logic: If ZK mode is on, a block is ONLY available if `Block + Blobs + N ExecutionProofs` are present.
* Implements `verify_execution_proof_for_gossip`: Checks signatures/slots.
* Implements cache for `PendingComponents`.
* **Goal:** Prevents the CL from processing/fork-choicing a block until the ZK proofs confirm it is valid.

#### `beacon_node/beacon_chain/src/beacon_chain.rs`
* **Changes:**
* `process_gossip_execution_proof`: Entry point when a proof arrives via gossip.
* `process_rpc_execution_proofs`: Entry point when proofs arrive via sync.
* Orchestrates the interaction between receiving a proof and notifying the `DataAvailabilityChecker`.
* **Goal:** Integration point.
* This logic belongs in your central blockchain service handling routine. When a proof arrives, validate it, store it, check if the parent block is now "ready", and if so, trigger block processing.

#### `beacon_node/beacon_processor/src/lib.rs`
* **Changes:**
* Adds worker queues for `GossipExecutionProof` and `RpcExecutionProofs`.
* **Goal:** Verification of ZK proofs (pairing checks etc.) is CPU intensive. It must be done asynchronously so as not to block the main networking loop.

### 4. Sync & Request Manager
How to get proofs if you miss them.

#### `beacon_node/network/src/sync/manager.rs` & `network_context.rs`
* **Changes:**
* Updates the `BlockLookups` logic.
* When downloading a block, if we identify we are missing proofs, we trigger the `ExecutionProofsByRoot` RPC.
* Implements backoff/retry logic if a peer doesn't return proofs.
* **Goal:** Reliability. Ensures the node doesn't get stuck if gossip fails.

This would most likely be placed in the sync logic.

### 5. ZK Abstraction Layer (The Engine)
This is a new module to decouple the specific ZK Provers from the Beacon logic.

#### `zkvm_execution_layer/`
* **Changes:**
* **Registry Pattern:** `GeneratorRegistry` and `VerifierRegistry`.
* **Traits:** `ProofGenerator` and `ProofVerifier`.
* **Dummy Implementations:** Contains `DummyProofGenerator` for testing without running a real RISC Zero/SP1 prover.
* **Config:** `ZKVMExecutionLayerConfig`.
* **Goal:** Future-proofing. Allows adding new ZKVMs (e.g., a new Scroll or Nil prover) without changing the core Beacon logic.

### 6. Proof Generation (Altruistic)
#### `beacon_node/proof_generation_service/src/lib.rs`
* **Changes:**
* A background service that watches the head of the chain.
* If a new block arrives and we have a `Generator` configured (e.g., we have a GPU), we generate a proof and broadcast it.
* **Goal:** Liveness. Ensures proofs exist on the network.