Celo Community, today I’m excited to unveil our CEL2 roadmap.
Guiding Principles: We are committed to the following principles in our work to deliver CEL2:
- Seeking early feedback from the community.
- Establishing an iterative process with a rapid feedback loop.
- Prioritizing the delivery of tangible results over pursuing perfect solutions.
- Effectively managing expectations.
- Mitigating uncertainty in the early stages and deferring actions requiring extensive research to later phases.
- Minimize upgrades / break as little as possible (e.g. ideally for anyone consuming Forno, no change should be needed for the upgrade)
Boundary Conditions: We are committed to ship an L2 which will fulfill the following conditions (which the Celo network currently already fulfills), as postulated in the original post:
- Sub-cent transaction fees.
- Gas fees payable with (select) ERC-20 tokens.
- 1-block finality.
Public Iterative Process: To deliver on our guiding principles of shipping fast and seeking community feedback early, we plan to launch public testnets early on, even if they might feature only a subset of what will constitute CEL2. We are working in the open, and we think this is particularly helpful as:
- The community can experiment early on with the L2 and get their hands dirty in code.
- Experiencing a subset of the most crucial features can yield greater value compared to a later release of the final design.
- Early feedback from the community can significantly influence key design decisions.
- The community can prepare early on for the migration process, testing and updating applications well in advance. While cLabs promises to do their best to enable any DApp to work on CEL2 without modifications, it is best for developers to be able to test that behavior early on themselves.
The following is a rough roadmap which consists of the following milestones:
|1||L2 Transition Foundations||Completed||Completed|
|S||Stack Selection||WIP||~2 months / Mid-December ‘23|
|2||L2 with Core Celo Features||WIP||~2 months / End of November ‘23|
|3||Celo Rollup||~2 months|
|4||Data Availability Layer||~1-3 months (high uncertainty)|
|5||Decentralized Sequencer||Further ~2-4 months|
|6||Pre-Mainnet||Further ~2-3 months|
The further we progress in this roadmap, the harder it is to give relevant time estimates of when a milestone will be finished. Our expectation is that we can launch the mainnet by the end of 2024. Let’s briefly go through each milestone, covering what they encompass and the decisions that need to be made at each step.
The primary objective of this milestone is to build the infrastructure needed to iterate on the L2 development project and continue the process (started prior to the Gingerbread hard fork) of reviewing the design and implementation of Celo-specific features, and planning how to revise or refactor them for the future architecture.
End of September 2023 (finished)
*Only engineering deliverables are listed in this section here and below - other relevant items (e.g., research, communication) are not represented.
- Design Documentation: Design discussions around changes needed for key Celo-specific features.
- Testnet: Exploratory engineer testnet based on OP stack, which is anchored on the Sepolia testnet.
- Celo Token-Duality: Just as in the Celo blockchain, CELO behaves both as a native and as an ERC20 token (i.e., native & ERC20 transfers possible, balance showing for native and ERC20). This means, CELO can be used for gas payments on the L2, but more work is needed to make CELO a fully native token (see Milestone 2). This is the only Celo-specific adaptation of the initial testnet.
- Documentation: Initial documentation on how to use the testnet.
- Block explorer: A simple block explorer to graphically investigate the testnet.
- Faucet: A faucet enabling the community to get funds to test and deploy on the testnet.
In parallel to Milestone 1, cLabs has been conducting research and evaluating the L2 stack technology under development across the web3 ecosystem – including (in alphabetical order) Arbitrum, Lina, OP Stack, Polygon, and ZKSync. While cLabs’ initial proposal for Celo to become an Ethereum L2 included a design outline based on OP Stack, using EigenDA for data availability, the space continues to advance fast, and Polygon and ZKSync have both directly engaged the Celo community on the forum.
Most of this roadmap document has been written in a stack-agnostic way, as far as possible, but executing on this plan depends on coming to a firm decision as soon as feasible. cLabs proposes to use the work set out below to help the community arrive at a decision on the L2 stack that can enable development to proceed.
Mid November 2023 - Publish draft decision framework for community consultation.
Late November 2023 - General consensus on decision framework, and forum discussions and community calls on stack options.
Early December 2023 - General consensus on preferred stack.
Mid December 2023 - Confirm stack selection via temperature check governance vote.
- Draft Decision Framework: a forum post outlining the criteria that cLabs feels should be evaluated, and how, as inputs into the decision around the L2 stack.
- Preferred Stack (Community Deliverable): ratification by the community of key technology stack choices for the Celo L2.
With this milestone cLabs plans to deliver the main differentiating features of the Celo blockchain early in the process, postponing the implementation of features that depend on 3rd-party entities to later stages.
End of November 2023 (in progress)
- Ultragreen Money: Use the FeeHandler contract to allocate the base gas fee to different purposes. Notably, 80% of gas fees are burned, and 20% used for carbon offsets.
- CELO as the Native Token: Bridging ETH from L1 will go to a WETH ERC20 contract on L2 instead of creating a native L2 token like in Optimism. Gas fees on L2 (that include L1 fees denominated in ETH) will be denominated in CELO*. *ETH/CELO exchange rate will not be included in the scope of the milestone as well as precisely calculated data fees.
- Gas Payment with ERC-20 Tokens: The Celo blockchain maintains a governable list of ERC-20 tokens that can be used for gas payments. This enhances user experience and simplifies the use of stable tokens (e.g., users of Opera MiniPay only ever hold stablecoins and never need to acquire CELO or other tokens to pay for gas). For this stage of the testnet, we enable a predefined list of ERC-20 tokens* as currencies for gas payments. *This list is not governable, as all governance issues are delayed to Milestone 6.
The objective for this milestone is to have a 100% Celo-compatible rollup. Per cLabs’ existing proposal design, this would be a version of OP that fully implements the Celo protocol but does not include certain modifications to the current L2 implementation, such as offchain DA and a decentralized sequencer. This rollup would not include consensus related features like validator elections, epoch rewards, and Celo’s random beacon.
As outlined in the original proposal, our primary objective with this design is to continue providing great UX for Celo users and developers. One of the key features of Celo is its 1-block finality and the absence of reorgs. We are planning to retain 1-block finality by reading deposited transactions only from finalized L1 blocks to minimize the effect of reorgs on Ethereum.
A good chunk of this milestone we’re planning to dedicate to getting more experience with migrating the state and getting clarity around the exact way we want to handle historical events as it might have a significant impact on infrastructure providers.
- 1-block Finality: An implementation that provides 1-block finality with a centralized sequencer.
- Initial Celo State Migration: Try importing state data from the existing Celo L1 chain. Note that we plan to regularly update the state, which will help us gain practical experience with the tools and address any potential challenges that may arise during the process of migrating the state from Celo to CEL2.
- Iterative Celo State Migration: Establish a process of regular state updates.
- Full Celo Feature Migration: In this milestone we will implement all other Celo features* that were missing in Milestone 2. *This does not include consensus related features.
- Governable Block Size.
- Governance (as it is today, an updated version of it is postponed till Milestone 6).
- How historical (pre-CEL2) events will be handled.
- What changes in the infrastructure layer will be needed to process pre-existing data (e.g. events).
Maintaining low gas fees represents a central objective for the proposed design. In our initial proposal, we explored off-chain data availability solutions like EigenDA as a means to achieve this goal without imposing substantial increases in Celo’s transaction fees. Data availability layer is a critical component in the efficiency of an L2 ecosystem, and, at this stage, it’s necessary to ensure that these associated costs do not significantly affect Celo’s transaction fees.
Delaying this milestone allows us the opportunity to do the required research and make a well-informed decision regarding the most appropriate solution for the data availability layer. Our aim is to thoroughly assess all potential options, including EigenDA, a custom DA layer and proto-danksharding, before committing to a specific technology. Furthermore, the decision made at this stage will have a considerable influence on the final design of the decentralized sequencer. Consequently, it makes sense for us to segregate these two steps and gather valuable insights from the process.
Again, even though at this step the testnet will still be using a centralized sequencer, we still can introduce protective mechanisms that will then be inherited in the final decentralized design.
~2 months Timeline is dependent on availability of DA solutions still in active development, e.g EigenDA testnet launch.
- Design documentation for the DA layer.
- Data availability layer that allows for sub-cent TX fees.
- A mechanism verifying data availability and penalizing for withholding it.
- Mechanism to charge “data availability fees”. OP stack charges a fixed fee to the user for DA; we need to adapt this mechanism to our DA solution.
- Which DA layer technology to use. Relevant questions are:
- speed of delivery
- costs (as in fees or for implementation)
- solutions that might be relevant by the time we face this decision: Celestia, EigenDA, Proto-Danksharding.
At this stage we introduce the final piece of the design - decentralized sequencing. There are quite some choices to be made. We want to invest some time into optimizing Celo’s BFT algorithm or replacing it with a new consensus protocol such as HotStuff 2 or Narwhal+Bullshark and adjusting the validators incentives to match their updated role in the system.
Proxy nodes have been an invaluable part of the validator setup, helping with uptime and providing additional security for validators. They allow the validator to run within a private network, and to communicate to the rest of the Celo network via the proxy. It’s a unique feature of the Celo blockchain and with the migration to L2, this piece of infrastructure now needs to be re-evaluated.
~ 2-4 months
- New/updated consensus implementation.
- Migrate Random Beacon solution.
- A more standard implementation for proxies or alternative DoS protection measures.
- Updated Celo stats website.
- Finalize the new validator setup and update technical specifications.
- Draft proposal to update validator rewards based on their role in the L2.
- Replacement of the Celo Istanbul consensus:
- HotStuff 2
- What to do with epoch snark data and ultra-light clients in general.
This marks a significant milestone, achieved through our previous steps’ diligent efforts. At this point, we have a testnet that incorporates the key characteristics of the eventual final design, although certain features, like Governance, had been postponed till a later stage. Now it is a good time to come back to them, perform a final cleanup and address various tasks that have been deferred.
~ 2-3 months
- Design and implement new governance, figuring out the split between execution layer-level governance and high-level protocol governance.
- Updated documentation.
- Document and publish the final migration plan.
- Extensive testing.
- Make sure that major infrastructure providers keep working after the upgrade.
- Communication with the community and providing help with the migration.
This marks the end of the project as we launch a fully fledged mainnet
Your involvement is greatly appreciated, and we eagerly anticipate your feedback!