# CDK 2.0 Interface and package definition

This is a proposal on how to organize modules for CDK development in cdk repository.

Following the ideas in Go stdlib but going into practical development, the packages [structure guidelines from Ben Johnson](https://www.gobeyond.dev/packages-as-layers/) makes the most sense.

Please read through it to get a sense of the idea, also [other articles from the same author](https://www.gobeyond.dev/standard-package-layout/) and the [sample repo](https://github.com/benbjohnson/wtf).

These patterns helps to remove dependencies, loosely coupling components by abstracting the services, in the same way the stdlib works.

The proposal is to use the [Golang standard project layout](https://github.com/golang-standards/project-layout).

**For the size and amount of tooling that we need to have will be better to stick to the Standard Project Layout, but adopting the service abstraction pattern.**

We've discussed about what components makes sense to separate in CDK and I think that's answered by the protocol itself and the components usage. Some components need to scale horizontally, while other components are already separate services.

The high level architecture is presented in this linked document https://hackmd.io/47t9mOBFRXGUqP3RWpuI1Q?view

This is a draft picture of this the components in this architecture:


## Packages
This is an overview of the different packages:

### CDK

`pkg/cdk`

This is the *root* package that will contain business model types and services interfaces.

- `EventProcessor`
- This is the interface that defines the methods.

## DataAvailavility

`pkg/dataavailability`

- `DataAvailabilityService`
- The interface that all `DataAvailability` implementations should follow in order to work with the CDK, it can be used for reading and writing to a DA.
- `DataAvailabilityReader`
- The interface that all DA implementations should follow to read from a DA protocol.
- `DataAvailabilityWriter`
- The interface that all DA implementations should follow to write to a DA protocol.
- `DataAvailability`
- Struct that represents a DA layer

### SequencerManager

`pkg/sequencermanager`

Package in charge of driving the execution engine, cdk-erigon, maybe it can manage the process itself.

### RPCproxy

`pkg/rpcproxy`

- Package in charge of ensuring the HA of the sequencer endpoints by proxying requests to and from the Sequencer RPC
- The persistence of this service will be based in local storage, tech TBD.
- Also will take care of ACLs and control what gets in the pool.
- Ideally it should implement a caching system.

### SequenceSender

`pkg/sequencesender`

Package that will read from the Sequencer Datastream and send the data to the DA layer

- `ConsensusManager`
- This package will manage different types of consensus: rollup, validium
- `L1Writer`
- This is the component that will write the data to L1. Implements `DataAvailavilityWriter`
- `CelestiaWriter`
- This is the component that will write the data to Celestia. Implements `DataAvailavilityWriter`

### Syncer

`pkg/syncer`

Package that manages the syncronization from different origins, Virtual State (DA), Trusted State and Verified state, and resolve the correct source in case something happens, reorgs, etc.

The persistence of this component will be based in local storage, tech TBD.

- `Syncer`
- This is the interface that defines how a syncr should work, it stitch together an `EventSyncr` and a `DataAvailabilityService`
- `EventSyncer`
- This is the interface that defines how to retrieve events from any source.
- `L1EventSyncer`
- This is the component that will download events from the root chain.
- `TrustedSequencerEventSyncer`
- This is the implementation of an event syncer that will download events from the trusted sequencer.
- `DataStreamServer`
- This component generates a `DataStream` with the data in the component.
- `L1Reader`
- This is the component that will read the data from L1. Implements `DataAvailavilityReader`
- `CelestiaReader`
- This is the component that will read the data from Celestia. Implements `DataAvailavilityReader`
- `Resolver`
- This is the component implementing the logic to resolve conflicts with different state sources.

### AggregatorManager

The aggregator component is currently very specific in zkevm, but in CDK 2.0 we're going to abstract it.

Different provers will need different aggregation backends, in this generalized version we're going to treat the specific aggregators as a black box, it's going to send batches and wait for proofs, and it's going to send the proofs to the the Settler.

### SettlementManager

The settle components will provide an interface to settle proofs to different settlement destinations, AggLayer, L1, ?