Ethereum vanilla clients

[arnaubennassar]

The goal for this discussion is to come up with a proposal that enables sequencing and syncing EVM flavoured CDKs using existing execution clients or a version/fork that is as unmodified as possible.

Today we use cdk-erigon as an executionc client, the problem with the existing soulution is that implements some features that should exist on the cdk client in order to:

• re-use functionality on different configurations of the CDK (either EVM or not)
• make it easier to integrate other clients into the stack (such as reth)

A non exhaustive list of things that cdk-erigon does and should be decoupled from it, and where to find specs/docs/code/discussions:

• Sequencing: triggering the sequencing process, today this is essentially an endless loop that happens on the sequencer node through configuration. While this is a very straight forward solution, it doesn't play well with future decentralisation of the sequencer, or other solutions being built on the industry such as rollup boost or based rollups. WIP discussion
• Global Exit Root injection: this goes hand by hand with current protocol, as only the sequencer can do that through the block creation. This is achieved through EVM modification. In order to go vanilla here, there is an exisiting PoC that consist of the AggOracle and the sovereign contracts. However, this PoC is limited since it doesn't have (yet) any prover supporting it, although there is a PoC using SP1
• Data distribution: as of today, cdk-erigon is in charge of sharing the necessary data to reconstruct the state with other cdk-erigon nodes. Specially when this data is part of the "trusted state". This is done using the DataStreamer protocol. Recently, the CDK client has dropped the DataStreamer interface in favor of the JSON RPC when it comes to sonsume data from the execution client. The main problem for cdk-erigon owning this functionality, is that it forces other execution clients to implement it if they want to be part of the stack + non EVM flavors could also benefit from this if implemented on CDK. WIP discussion
• DA syncing: by default, cdk-erigon syncs from the sequencer (as explaoned on the data distribution bullet point). However, in case of a misbehaving sequencer, cdk-erigon implements a mechanism in which it can re-construct the state by consuming data posted on a DA backend instead. This is a core functionality of any rollup (in fact, is necessary even to be a stage0 rollup / validium as per l2Beat framework . However this is treated more like a manual recovery functionality, than anything else. The fact that this is implemented on cdk-erigon is not only bad for re-usability, but for modularity. As we expect the CDK stack to support many DA backends (4844, call data, DAC, Celestia, Avail, ...). Involved in this discussion
• Batch building: today cdk-erigon takes care of grouping blocks into batches, batches are a concept that obviously doesn't exist on vanilla clients

Other topics that are worth mentioning:

• Tx pool: while it's possible to re-use the existing implementation on vanilla clients, the centralised nature of the sequencer craves for another mechanism that enables MEV protection, allow lists and other features
• Forced transactions: today the AggLayer protocol doesn't consider force inclusion, but this should change in the future, and is certainly an area to explore in terms of integration with the execution clients. Involved in this discussion
• 1559 and fee mechanisms

The op-geth vs geth diff is a fantastic resource to understand the challenge of using a 100% vanilla client to build a rollup, it's worth studying before jumping into this discussion