[Celo 2.0] Ethereum alignment

[carterqw2]

tldr;

One of 2023 goals is to align closer with Ethereum. We want to rewrite our client in a way that will allow for quicker updates to new versions, reduce the maintenance effort for the Celo blockchain team, and make it easier for Celo developers to leverage tools on Ethereum and other EVM compatible chains. We plan to do this in three parts:

• Stage 1: Clean up celo-blockchain
• Stage 2: Create a checkpoint
• Stage 3: Implement on Erigon

Background

Our 2023 vision for Celo is to be the best platform on which to launch projects that further the regenerative economy. To meet this ambitious goal, the blockchain team’s H1 roadmap includes:

• Deeply aligning with the Ethereum roadmap
• Scaling horizontally by being a rollup-friendly chain
• Making Celo the fastest EVM L1

This post will focus on the first pillar; how we plan to make it easier for Celo developers to take advantage of what the Ethereum ecosystem offers.

Overview

EVM compatibility is a guiding principal for cLabs, and we want to make sure that the exciting features on the Ethereum roadmap (like proto-danksharding and danksharding) are available for Celo developers as soon as possible. Ultimately, we want to re-implement the Celo client on top of Erigon in order to:

• Allow for quicker updates to new versions, and enable our team to bring new features and fixes to the Celo community faster
• Reduce the maintenance effort for the Celo blockchain team
• Make it easier for Celo developers to leverage tools on Ethereum and other EVM compatible chains
• Make it easier for us to contribute upstream to Ethereum and give back
• Split up consensus and execution layers to make experiments with a different consensus implementation easier, as was mentioned before we’ve been exploring Narwhal as a potential candidate

This is an ambitious goal, and our team has broken down the work into three stages:

• Stage 1: Clean up celo-blockchain and make client as lean as possible
• Stage 2: Create a checkpoint to make syncing more efficient
• Stage 3: Implement a new client architecture on top of Erigon

Every stage requires a hard fork, with the first one tentatively scheduled for summer 2023 - more details to follow as soon as a date is set.

Stage 1: Clean up celo-blockchain

In the upcoming months, we’re focused on not only better aligning existing features to match Ethereum, but also removing features that aren’t being utilized. Don’t worry, you won’t lose your favorite apps.

We will also be evaluating existing features to reduce “diff” between Celo and Ethereum. Each distinct change will be introduced as a CIP (see section below).

Stage 2: Create a checkpoint

Once we have a leaner protocol, we will introduce a checkpoint mechanism. This is an important part of the Ethereum 2.0 design, based on the concept of “Weak Subjectivity”, well described in the Vitalik’s blog post and especially relevant in the context of introducing a new and faster client on Stage 3.

• Instead of syncing from genesis, the client would sync from the latest checkpoint (in this case, the point when the changes to the protocol from Stage 1 were introduced)
• This allows us to simplify the client code, ignoring deprecated features and “flattening” its history

Note: This will not affect archive nodes, which can run a two stage-client - old blocks will be consumed from the old version of the client, and newer blocks will be consumed from the new one.

Stage 3: Implement on Erigon

At this point, we have a cleaner version of the protocol (Stage 1) and that doesn’t need to be aware of the deprecated features to sync (Stage 2). We can then implement a new client, using existing modern technologies and approaches.

After doing some initial research, we’re planning to implement the new client on top of Erigon but this might change in future. We’re excited about the significant client improvements, including:

• Increased disk I/O efficiency due to ETL, flat DB schema, and use of a single accounts/state trie instead of three tries in geth
• Staged sync - it is a more performant version of geth’s Full Sync providing significant speed up of the full sync by batch-processing of blocks in stages and taking advantage of certain I/O optimizations that become possible because of that
• Better utilization of hardware resources and performance of archive nodes - the new client requires less disk space which is especially relevant for archive nodes
• Improved JSON-RPC daemon running in a separate process provides additional RPC methods and is generally easier to extend
• Easier upgrades from upstream - Erigon’s modular architecture makes it much easier to extend, the codebase is less monolithic and more maintainable which carries additional benefits of quicker upstream merges meaning that new features and bug fixes will be available on Celo faster

CIP’s

This is the current list of planned CIP’s:

• Remove Tobin Tax celo-proposals#364 | Removes an unused feature and a source of potential confusion for users and simplifies the protocol.

• Remove minimum client version celo-proposals#361 | Removes an unused mechanism of checking for incompatible client versions, hard forks ensure that incompatible versions won't be on the same fork, making additional version checks unnecessary.

• Community rewards go to reserve if undercollaterized celo-proposals#363 | In the light of the Mento Labs spin-off as an independent entity, and conversations around moving cStables and the Reserve out of Celo governance, it makes sense for the Reserve not to directly receive funds designated for the Community Fund. Additionally, the protocol gets simplified by reducing the number of conditional actions.

• [Review] Restore opcode gas costs from Ethereum celo-proposals#367 | To protect ourselves from possible attacks of underpriced operations and keep the execution layer as close as Ethereum to be able to merge new versions from upstream as soon as possible.

• [Review] Remove full node incentives celo-proposals#366 | Removes additional complexity and keeps our execution layer as close to Ethereum as possible as the feature has never been used.

• Remove freezable check on epoch rewards celo-proposals#368 | Removes a check that was supposed to be used only in the beginning, which makes that check an unnecessary cost now that the network is stable.

• [Review] Re-add header fields with values used in Ethereum 2.0 celo-proposals#370 | Restores fields that were removed before to keep our execution layer as close to Ethereum as possible.

• [Review] Add GASLIMIT opcode celo-proposals#374 | Restores the removed opcode to keep the execution layer as close to Ethereum as possible.

• [Review] Restore BaseFee opcode/header field celo-proposals#384 | Restores the missing field to keep the execution layer as close to Ethereum as possible and simplifies the codebase that currently relies on smart contracts.

• [Draft] Deprecate Celo Native transaction and Celo envelope transaction | In favor of a new generic envelope transaction. We’ll be keeping the ability to pay for gas with tokens.

• [Idea] Separate devp2p protocols by domains | Currently the three protocols eth, istanbul, proxy are tightly coupled that makes it harder to maintain.

• [Idea] Split block format into “Execution” and “Consensus” | Following the Ethereum 2.0 design splitting up execution and consensus layers, this change introduces corresponding changes to the block format. That would allow to “localize” Celo-specific changes in the consensus layer, minimizing the difference of the execution layer with Ethereum.

All CIPs will be reviewed with the community following our CIP approval process. We’ll continue to update the above list as we add new CIP’s - in the meantime, feedback is always welcome. Please leave comments and share your thoughts, and we look forward to a meaningful collaboration with all of you!