# Erigon CDK

## Introduction

We're presenting the possible approach for the Erigon CDK architecture, the has some premises in mind, derived from the learnings of the legacy Edge and the production setups of the zkEVM.

### Goals / Requirements

- Easy to operate => single binary + local disk based DB
- Align the components with well known blockchain clients behaviour, principle of least surprise.
- Good Dev Experience + good Ops experience
- Built with decoupling and modularity in mind => decouple from execution client as much as possible:
- Multiple DA protocols
- Multiple settlement options (direct to L1 + aggLayer)
- Multiple execution / proving stacks: EVM type I & II, Miden, ...
- Try to be execution client agnostic (so we can use rETH or others in the future)
- CDK client components (sequence sender, aggregator, sync, ...) should talk to each other through interfaces instead of through the DB
- this will allow us to have gRPC implementations so we can easily enable 3rd party implementations, or doing implementation in other languages (rust)

## CDK Client

The goal is to have a single binary that exposes the CLI to the end user and orchestrates the execution of all components.

The motivation for this is to achieve devops friendliness by exposing only the flags options and configuration necessary to run the stack.

This application will read the configuration for the different CDK components from the indicated config files or from command line arguments, hidding the inherent complexity of the different underlying components.

We know that Erigon has many configuration parameters that doesn't apply to CDKs but we can not simply remove them, so this wrapper will allow to run it using only CDK related params.

cdk-erigon should be able to run as child processes orchestrated by the client, or as separete process in different machines as the operator requires but using this binary and its configuration as an entrypoint. On the other hand the rest of the components aka CDK client (except provers) will run in a single instance since they are all light weighted processess

## cdk-erigon

The goal is to acquire knowledge from the Gateway team and own the project in order to test it, and develop it further coordinating with the Gateway team.

- Strategy for Trusted State HA is to replicate the data in multiple private permissionless RPC nodes which can be promoted to trusted sequencer.
- Removal of zkCounters for Proofless setups.
- Decoupling non-esential components from the execution client, ie. Synchronizer

## Sequence sender

- Unify validium and rollup into single code base
- Unify the state storage to the CDK client storage

## TxPool Features

There's some requirements to develop some features regarding the tx pool:

- ACLs
- HA while upgrading the node (hotswapping)
- Transactions persistence in case of outages

The proposal is to drop the "TxPool Manager" project and adopt an Erigon native way of replication by enabling the p2p layer, replicating the txpool contents in a controlled permissioned set of nodes that can serve as hot-standbys and swappable in case of upgrades.

The ACLs implementation should be discussed and an elegant approach selected after some investigation, theses are some of the implementation options:

- ACLs within the Erigon's txpool
- A small proxy that forwads txs to the txpool after necessary checks, maybe investigate Erigon's work on separate txpool gRPC protocol.

## Aggregator

We'll integrate the existing zkEVM Aggregator https://github.com/0xPolygonHermez/zkevm-aggregator + can settle to agglayer (beethoven)

## Syncer

- Syncs from different sources:
- Trusted sequencer (data stream), note that this can be a locally (same infra) running execution client
- DA protocol (celestia, avail, ...)
- L1
- Can build a Data Stream (so can feed an execution client in case of trusted sequencer failure)
- Provide data to other components: anything needed by sequencer, sequence sender, aggregator
- current sequence sender and aggregator should be decoupled from data streamer
- consider if needs to be synced and stored continuosuly vs queried on demand

## Concerns

- data streamer being the backbone of the cdk