chore(l2): separete ProverServer and ProofSender (#2478)

**Motivation**

<!-- Why does this pull request exist? What are its goals? -->
Currently the ProverServer component have the responsibility for both
act as a server for the ProverClient (i.e., send blocks to prove and
receive proofs) and send proofs to the L1 contract to verify blocks.
This tasks can be parallel and decoupled one from the other.

**Description**

<!-- A clear and concise general description of the changes this PR
introduces -->
A new struct `L1ProofSender` is created that periodically checks if
there're new proofs to send to the L1, removing that job from the
`ProverServer`. Also, components were renamed for better clarity.
Note that the config names were not changed as there's a WIP PR (#2501)
doing a full refactor of it

<!-- Link to issues: Resolves #111, Resolves #222 -->

---------

Co-authored-by: Javier Rodríguez Chatruc <49622509+jrchatruc@users.noreply.github.com>
Co-authored-by: Javier Chatruc <jrchatruc@gmail.com>
Co-authored-by: Ivan Litteri <67517699+ilitteri@users.noreply.github.com>

Author: 3 people

crates/l2/Makefile

@@ -21,7 +21,7 @@ down: down-local-l1 down-l2 down-metrics## 🛑 Shuts down the localnet
 
 clean: clean-contract-deps ## 🧹 Cleans the localnet
 
-restart: restart-local-l1 deploy-l1 restart-l2 ## 🔄 Restarts the localnet
+restart: restart-local-l1 deploy-l1 purge_prover_state restart-l2 ## 🔄 Restarts the localnet
 
 ## Same as restart but for testnet deployment. The local database is cleaned and the contracts are deployed again.
 restart-testnet:
@@ -243,10 +243,5 @@ else
 endif
 
 purge_prover_state: ## 🧹 Removes the L2 state, only use to start fresh.
-	@echo "Are you sure you want to delete the directory: $(PROJECT_PATH) ? [y/n]"
-	@read answer; \
-	if [ "$$answer" != "y" ]; then \
-		echo "Operation canceled."; \
-	fi; \
 	rm -rf $(PROJECT_PATH); \
 	echo "Directory deleted."

crates/l2/configs/sequencer_config_example.toml

@@ -49,4 +49,5 @@ l1_private_key = "0x39725efee3fb28614de3bacaffe4cc4bd8c436257e2c8bb887c4b5c4be45
 # Set it to 0.0.0.0 to allow connections from other machines.
 listen_ip = "127.0.0.1"
 listen_port = 3900
+proof_send_interval_ms = 5000
 dev_mode = true

crates/l2/docs/prover.md

@@ -20,26 +20,26 @@
 
 ## What
 
-The prover consists of two main components: handling incoming proving data from the `L2 proposer`, specifically the `prover_server` component, and the `zkVM`. The `prover_client` is responsible for this first part, while the `zkVM` serves as a RISC-V emulator executing code specified in `crates/l2/prover/zkvm/interface/guest/src`.
+The prover consists of two main components: handling incoming proving data from the `L2 proposer`, specifically from the `ProofCoordinator` component, and the `zkVM`. The `Prover` is responsible for this first part, while the `zkVM` serves as a RISC-V emulator executing code specified in `crates/l2/prover/zkvm/interface/guest/src`.
 Before the `zkVM` code (or guest), there is a directory called `interface`, which indicates that we access the `zkVM` through the "interface" crate.
 
-In summary, the `prover_client` manages the inputs from the `prover_server` and then "calls" the `zkVM` to perform the proving process and generate the `groth16` ZK proof.
+In summary, the `Prover` manages the inputs from the `ProofCoordinator` and then "calls" the `zkVM` to perform the proving process and generate the `groth16` ZK proof.
 
 ## Workflow
 
-The `Prover Server` monitors requests for new jobs from the `Prover Client`, which are sent when the prover is available. Upon receiving a new job, the Prover generates the proof, after which the `Prover Client` sends the proof back to the `Prover Server`.
+The `ProofCoordinator` monitors requests for new jobs from the `Prover`, which are sent when the prover is available. Upon receiving a new job, the Prover generates the proof, after which the `Prover` sends the proof back to the `ProofCoordinator`.
 
 ```mermaid
 sequenceDiagram
     participant zkVM
-    participant ProverClient
-    participant ProverServer
-    ProverClient->>+ProverServer: ProofData::Request
-    ProverServer-->>-ProverClient: ProofData::Response(block_number, ProverInputs)
-    ProverClient->>+zkVM: Prove(ProverInputs)
-    zkVM-->>-ProverClient: Creates zkProof
-    ProverClient->>+ProverServer: ProofData::Submit(block_number, zkProof)
-    ProverServer-->>-ProverClient: ProofData::SubmitAck(block_number)
+    participant Prover
+    participant ProofCoordinator
+    Prover->>+ProofCoordinator: ProofData::Request
+    ProofCoordinator-->>-Prover: ProofData::Response(block_number, ProverInputs)
+    Prover->>+zkVM: Prove(ProverInputs)
+    zkVM-->>-Prover: Creates zkProof
+    Prover->>+ProofCoordinator: ProofData::Submit(block_number, zkProof)
+    ProofCoordinator-->>-Prover: ProofData::SubmitAck(block_number)
 ```
 
 ## How
@@ -76,7 +76,7 @@ Then run any of the targets:
 
 ### Dev Mode
 
-To run the blockchain (`proposer`) and prover in conjunction, start the `prover_client`, use the following command:
+To run the blockchain (`proposer`) and prover in conjunction, start the `Prover`, use the following command:
 
 ```sh
 make init-prover T="prover_type (pico,risc0,sp1) G=true"
@@ -137,12 +137,12 @@ Then run any of the targets:
 
 #### Run the whole system with a GPU Prover
 
-Two servers are required: one for the `prover` and another for the `proposer`. If you run both components on the same machine, the `prover` may consume all available resources, leading to potential stuttering or performance issues for the `proposer`/`node`.
+Two servers are required: one for the `Prover` and another for the `sequencer`. If you run both components on the same machine, the `Prover` may consume all available resources, leading to potential stuttering or performance issues for the `sequencer`/`node`.
 
-- The number 1 simbolizes a machine with GPU for the `prover_client`.
+- The number 1 simbolizes a machine with GPU for the `Prover`.
 - The number 2 simbolizes a machine for the `sequencer`/L2 node itself.
 
-1. `prover_client`/`zkvm` → prover with gpu, make sure to have all the required dependencies described at the beginning of [Gpu Mode](#gpu-mode) section.
+1. `Prover`/`zkvm` → prover with gpu, make sure to have all the required dependencies described at the beginning of [Gpu Mode](#gpu-mode) section.
    1. `cd ethrex/crates/l2`
    2. `cp configs/prover_client_config_example.toml configs/prover_client_config.toml` and change the `prover_server_endpoint` with machine's `2` ip and make sure the port matches the one defined in machine 2.
 
@@ -153,10 +153,10 @@ The important variables are:
 prover_server_endpoint=<ip-address>:3900
 ```
 
-- `Finally`, to start the `prover_client`/`zkvm`, run:
+- `Finally`, to start the `Prover`/`zkvm`, run:
   - `make init-prover T=(sp1,risc0,pico) G=true`
 
-2. `prover_server`/`proposer` &rarr; this server just needs rust installed.
+2. `ProofCoordinator`/`sequencer` &rarr; this server just needs rust installed.
    1. `cd ethrex/crates/l2`
    2. `cp configs/sequencer_config_example.toml configs/sequencer_config.toml` and change the addresses and the following fields:
       - [prover_server]
@@ -184,14 +184,12 @@ prover_server_endpoint=<ip-address>:3900
 
 ## Configuration
 
-Configuration is done through environment variables. The easiest way to configure the ProverClient is by creating a `prover_client_config.toml` file and setting the variables there. Then, at start, it will read the file and set the variables.
+Configuration is done through environment variables. The easiest way to configure the `Prover` is by creating a `prover_client_config.toml` file and setting the variables there. Then, at start, it will read the file and set the variables.
 
-The following environment variables are available to configure the Proposer consider looking at the provided [prover_client_config_example.toml](../configs/prover_client_config_example.toml):
-
-The following environment variables are used by the ProverClient:
+The following environment variables are available to configure the `Prover`, consider looking at the provided [prover_client_config_example.toml](../configs/prover_client_config_example.toml):
 
 - `CONFIGS_PATH`: The path where the `PROVER_CLIENT_CONFIG_FILE` is located at.
-- `PROVER_CLIENT_CONFIG_FILE`: The `.toml` that contains the config for the `prover_client`.
+- `PROVER_CLIENT_CONFIG_FILE`: The `.toml` that contains the config for the `Prover`.
 - `PROVER_ENV_FILE`: The name of the `.env` that has the parsed `.toml` configuration.
 - `PROVER_CLIENT_PROVER_SERVER_ENDPOINT`: Prover Server's Endpoint used to connect the Client to the Server.
 

crates/l2/prover/src/lib.rs

@@ -1,12 +1,12 @@
 pub mod backends;
 pub mod errors;
-pub mod prover_client;
+pub mod prover;
 
-use ethrex_l2::utils::config::prover_client::ProverClientConfig;
+use ethrex_l2::utils::config::prover::ProverConfig;
 use tracing::warn;
 
-pub async fn init_client(config: ProverClientConfig) {
-    prover_client::start_proof_data_client(config).await;
+pub async fn init_client(config: ProverConfig) {
+    prover::start_prover(config).await;
     warn!("Prover finished!");
 }
 

crates/l2/prover/src/main.rs

@@ -1,6 +1,5 @@
 use ethrex_l2::utils::config::{
-    prover_client::ProverClientConfig, read_env_file_by_config, toml_parser::parse_configs,
-    ConfigMode,
+    prover::ProverConfig, read_env_file_by_config, toml_parser::parse_configs, ConfigMode,
 };
 use ethrex_prover_lib::init_client;
 use tracing::{self, debug, error, Level};
@@ -26,7 +25,7 @@ async fn main() {
         return;
     }
 
-    let Ok(config) = ProverClientConfig::from_env() else {
+    let Ok(config) = ProverConfig::from_env() else {
         error!("Failed to read ProverClientConfig from .env file. It is '.env.prover' by default");
         return;
     };

crates/l2/prover/src/prover_client.rs renamed to crates/l2/prover/src/prover.rs

@@ -1,7 +1,7 @@
 use crate::{prove, to_calldata};
 use ethrex_l2::{
-    sequencer::prover_server::ProofData,
-    utils::{config::prover_client::ProverClientConfig, prover::proving_systems::ProofCalldata},
+    sequencer::proof_coordinator::ProofData,
+    utils::{config::prover::ProverConfig, prover::proving_systems::ProofCalldata},
 };
 use std::time::Duration;
 use tokio::{
@@ -12,23 +12,23 @@ use tokio::{
 use tracing::{debug, error, info, warn};
 use zkvm_interface::io::ProgramInput;
 
-pub async fn start_proof_data_client(config: ProverClientConfig) {
-    let proof_data_client = ProverClient::new(config);
-    proof_data_client.start().await;
+pub async fn start_prover(config: ProverConfig) {
+    let prover_worker = Prover::new(config);
+    prover_worker.start().await;
 }
 
 struct ProverData {
     block_number: u64,
     input: ProgramInput,
 }
 
-struct ProverClient {
+struct Prover {
     prover_server_endpoint: String,
     proving_time_ms: u64,
 }
 
-impl ProverClient {
-    pub fn new(config: ProverClientConfig) -> Self {
+impl Prover {
+    pub fn new(config: ProverConfig) -> Self {
         Self {
             prover_server_endpoint: config.prover_server_endpoint,
             proving_time_ms: config.proving_time_ms,
@@ -66,13 +66,13 @@ impl ProverClient {
 
     async fn request_new_input(&self) -> Result<ProverData, String> {
         // Request the input with the correct block_number
-        let request = ProofData::request();
+        let request = ProofData::block_request();
         let response = connect_to_prover_server_wr(&self.prover_server_endpoint, &request)
             .await
             .map_err(|e| format!("Failed to get Response: {e}"))?;
 
         match response {
-            ProofData::Response {
+            ProofData::BlockResponse {
                 block_number,
                 input,
             } => match (block_number, input) {
@@ -102,14 +102,14 @@ impl ProverClient {
         block_number: u64,
         proving_output: ProofCalldata,
     ) -> Result<(), String> {
-        let submit = ProofData::submit(block_number, proving_output);
+        let submit = ProofData::proof_submit(block_number, proving_output);
 
         let submit_ack = connect_to_prover_server_wr(&self.prover_server_endpoint, &submit)
             .await
             .map_err(|e| format!("Failed to get SubmitAck: {e}"))?;
 
         match submit_ack {
-            ProofData::SubmitAck { block_number } => {
+            ProofData::ProofSubmitACK { block_number } => {
                 info!("Received submit ack for block_number: {}", block_number);
                 Ok(())
             }

crates/l2/sequencer/errors.rs

@@ -1,6 +1,7 @@
 use crate::utils::config::errors::ConfigError;
 use crate::utils::error::UtilsError;
 use crate::utils::prover::errors::SaveStateError;
+use crate::utils::prover::proving_systems::ProverType;
 use ethereum_types::FromStrRadixErr;
 use ethrex_blockchain::error::{ChainError, InvalidForkChoice};
 use ethrex_common::types::{BlobsBundleError, FakeExponentialError};
@@ -60,6 +61,20 @@ pub enum ProverServerError {
     JsonError(#[from] serde_json::Error),
 }
 
+#[derive(Debug, thiserror::Error)]
+pub enum ProofSenderError {
+    #[error("Failed because of an EthClient error: {0}")]
+    EthClientError(#[from] EthClientError),
+    #[error("Failed to encode calldata: {0}")]
+    CalldataEncodeError(#[from] CalldataEncodeError),
+    #[error("Failed with a SaveStateError: {0}")]
+    SaveStateError(#[from] SaveStateError),
+    #[error("{0} proof is not present")]
+    ProofNotPresent(ProverType),
+    #[error("Unexpected Error: {0}")]
+    InternalError(String),
+}
+
 #[derive(Debug, thiserror::Error)]
 pub enum BlockProducerError {
     #[error("Block Producer failed because of an EngineClient error: {0}")]