cLabs Proposal for Celo to transition to an Ethereum L2

[matt]

Celo Community –

This post is a call to action for feedback and discussion around a proposal for Celo to return home to Ethereum by transitioning from being an independent EVM-compatible Layer 1 blockchain to an Ethereum Layer 2.

The proposal – following months of research by the cLabs team as well as initial discussions among core Celo and Ethereum community members – details an architecture where the Celo blockchain initially leverages the OP Stack to become an Ethereum L2, with key differentiators including:

• Decentralized sequencer powered by Celo’s existing validator set running Byzantine Fault Tolerance consensus.
• Off-chain data availability layer, powered by EigenLayer and EigenDA, operated by Ethereum node operators, and protected by restaked ETH. EigenDA brings the design of danksharding to Ethereum early, enabling Celo to maintain its low fees.
• A design that retains Celo’s 1-block finality.

Migrating from an EVM-compatible L1 to an Ethereum L2 will be a technical upgrade that does not impact the Celo ecosystem’s mission to create the conditions of prosperity for all. In fact, we hope it can accelerate the path towards it. Through this proposed change, the Celo ecosystem can continue to foster a financially inclusive community and build openly in the spirit of Web3, bringing real-world use cases to the Ethereum ecosystem. At the same time, this proposal has the potential to substantially enhance the scope and impact of the Celo blockchain. In particular, key benefits to migrating to an L2 include:

• Further Ethereum alignment and EVM compatibility, fostering a seamless developer experience
• Stronger security assurances than Celo provides individually
• A trustless bridge to Ethereum, simplifying liquidity sharing between Celo and Ethereum

From a community standpoint, there would be no changes to existing dApps, no changes to mobile-first features (e.g. SocialConnect) nor the growing regenerative finance (ReFi) stack. Importantly, gas fees changes would be immaterial, a key contributor in achieving global financial prosperity and core to the Celo community’s mission (see “Potential Effects on Celo Community” below for more). Additionally, the Celo validator community would continue to play a key role in operating the network.

Introduction

The Celo Whitepaper was released in 2018, centered around addressing the biggest barriers to global crypto adoption as a means of payment. With the whitepaper being centered around a mission of global prosperity, Ethereum’s equally mission-driven vision appealed to the Celo co-founders and early team. However, from a technical perspective, limitations around scalability and consensus mechanisms proved to be a barrier to directly building on Ethereum, leading to the eventual launch of the Celo mainnet: the first carbon-negative, EVM-compatible proof-of-stake (PoS) Layer 1, launching on Earth Day 2020.

Even so, the Celo community has continued to monitor the progress of Ethereum, paying specific attention to the developments around Ethereum’s rollup centric roadmap. As such, the Celo community has been future-proofing later-stage ETH2 milestones (e.g., light clients, single-slot finality and usability) and deliberating how Ethereum’s advances could lead to an improvement of the Celo mainnet. In this forum post, we detail an upgrade proposal of the Celo mainnet based on Ethereum’s rollup advancements, specifying its mission value proposition, implications for the community and high-level technical design.

Why Now?

Celo’s technology inherits from and owes a lot to Ethereum. Our communities overlap, as do our visions for building a fairer financial system on decentralized technology. As L2 research has developed, it has become a viable path by which to allow Celo to align even more closely with Ethereum — by connecting trustlessly with it, and leveraging its economic security.

Two key advances make us believe the time is now:

1. Off-chain data availability solutions like EigenDA enable this to be achieved without necessitating steep increases in Celo’s transaction fees, in a way that still contributes to Ethereum (and Ethereum validators that opt into EigenLayer).
2. The OP stack has created an incredible, open reference architecture for optimistic rollups and chains.

It is cLabs’ belief that these advancements in the Ethereum-based L2 stack now have the necessary pieces in place for a Celo L2 migration to add significant value to its mission.

Upgrade Value Proposition

Through implementation of the L2 proposal, cLabs would expect to realize the following set of advantages:

1. Increased Cross-Community Collaboration – Historically, Celo’s technical roadmap has aligned closely to that of Ethereum, being early adopters of Ethereum Improvement Proposals (EIP) such as EIP-1559 (gas fee reductions) and EIP-4337 (account abstraction). While learning from proposals as they’ve been released, officially aligning to the Ethereum community offers the Celo ecosystem an opportunity to not only collaborate with the Ethereum community on existing EIPs, but also introduce our own, with near term examples being exploring standard for off-chain data availability and decentralized sequencers.

2. Enhanced Compatibility – While Celo has been an EVM compatible chain since inception, considerable work is needed on the backend to ensure that tooling and libraries maintain composability through upgrades of the Celo geth fork or core Web3 libraries. Migrating Celo to utilize the OP stack eliminates the need to monitor compatibility, making it easy for Celo developers to utilize the full gambit of Ethereum tooling / libraries.

3. Increased Security – Currently, Celo is secured by a set of 110 validators which in turn are elected by ~300M in locked CELO. While this offers a significant level of decentralization and economic security, moving to an L2 architecture can improve that security threshold multifold by anchoring the state on the Ethereum mainnet, while using a decentralized source for data availability. (See for example the OP Bedrock Explainer for an overview of optimistic security models).

4. Maintained Low Gas Fees – We expect no material change of gas fees. As the proposal is for an L2 solution with off-chain data availability, gas costs can be a lot lower than on other L2s which opt for on-chain data availability such as Optimism or zkSync era. More details on gas fees can be found in the Appendix.

Proposed Upgrade

The modular structure of the OP Stack and their interoperable vision of the future L2 ecosystem makes it a natural starting point upon which we can build the features prioritized by members of the Celo ecosystem. However, using Ethereum as the DA layer (as Optimism currently does) would be prohibitively expensive for many projects in the Celo ecosystem. Additionally, one of the defining features of Celo is its 1-block finality and absence of reorgs. Our goal with this design is to continue providing great UX for Celo users and developers with minimal changes to fees, finality, and Celo-specific features, while also providing as much increased security as possible. To do this, we propose creating a Celo L2 client based on the OP Stack with the following modifications or feature additions:

• Decentralizing the sequencer role by using Celo’s existing production-grade pBFT consensus (battle-tested over the last 3 years) and validator set to provide improved censorship resistance and liveness properties.
• Provide reorg resistance with Celo’s security guarantees by:
  • Slashing validators who share divergent blocks on the p2p network vs. on the DA layer in order to provide reorg resistance to unsafe L2 blocks
  • Reading only deposited transactions from finalized L1 blocks to minimize the effect of reorgs on Ethereum
• Use EigenDA for off-chain data availability (DA) to reduce transaction fees while providing increased security to Celo users and aligning more strongly with Ethereum.

The proposed system looks as follows:

Note that we expect that as the next-generation zk-L2-stack matures (e.g. proofing systems such as Nova), additional work will be able to upgrade Celo to a highly scalable validium-based zk-EVM. The Appendix provides a more detailed elaboration of the design and the above mentioned specific building blocks.

Potential Effects on Celo Community

In introducing this proposal, cLabs has carefully considered the changes that various members of the Celo community may see. These are outlined below:

1. Validators

Change – Validators have and will continue to play a critical role in the health of the Celo ecosystem. Validator responsibilities have traditionally included the ordering and processing of transactions, which is expected to continue. This proposal leverages Celo’s current validators and transforms them into the sequencers for the L2. Thanks to them, Celo will be based on one of the first (if not the first) decentralized sequencer and deliver 1-block finality on a L2. The one change for both validators and full node operators would be the need to also run an Ethereum node (or access to a trusted one) since any L2 node needs to observe the L1 (Ethereum) to derive the canonical chain.

2. Developers

Change – Developers should approach the upgrade with a similar mindset as if a hard fork upgrade was happening: no changes to what Celo offers them now, only some important improvements. First, besides having 1-block finality secured by Celo stake, there would also be a stronger (but slower) finality guarantee derived from Ethereum’s economic security and EigenDA security. Second, they’ll have access to a native bridge to Ethereum, increasing the composability of Celo dApps with Ethereum. Finally, an additional censorship resistance mechanism will allow Celo transactions to be posted directly into Ethereum to force their inclusion.

3. End users

No change – End users will not notice any change. Gas fees would have immaterial changes due to the data availability layer of the proposed L2 being managed off-chain, reducing costs to align closely with Celo L1 gas fees and significantly lower than alternative L2s such as Optimism and zkSync. In addition, end users will benefit indirectly through the adoption of Ethereum’s security model in addition to Celo’s battle-tested Proof-of-Stake system.

4. Holders of CELO

No change – CELO will keep its core functionality as a governance tool for the Celo blockchain, meaning CELO holders control:

1. the core contracts through voting on governance proposals and
2. the validator set through staking and elections.

Additionally, CELO will continue to be utilized for gas payments. A part of the gas fee will be used to pay for transactions on the L1 to anchor the Celo state on Ethereum. We expect this aspect to be immaterial compared to the total gas fees of Celo.

Finality of the Celo L2

Finality can be separated into two problems: (1) Finality of transaction ordering and (2) finality over the resulting state of applying transactions. Full nodes only care about the former, and have a subjective view of the latter (which is the type of finality verified when “validating” a block). Full nodes would always reject a block signed by Celo validators if the state root does not follow the protocol rules.

The proposed design for an L2 provides stronger guarantees on finality than the current Celo implementation. First, it delivers the same finality Celo offers today, which is a 1-block finality secured by Celo stakers. But it also provides an additional finality stage when blocks on Ethereum are finalized (every 2 Ethereum epochs). This additional finality will be much stronger and is derived from a combination of both Ethereum and EigenDA security.

Finality over the resulting state of applying transactions, would also have 2 stages: Celo finality, and later Ethereum finality when state roots are posted to Ethereum.

More details on the finality of the proposed system can be found in the Appendix.

Conclusion & Next Steps

In this forum post, we present an idea of how the Celo community could improve and further develop Celo as a blockchain over the next year, why we believe this is crucial and beneficial for the most important stakeholders of Celo and the ecosystem overall, and how it could be implemented at a high level.

While cLabs has taken the first step in formally proposing Celo to transition to an L2, it takes an engaged community to discuss, analyze, and refine this proposal together to come to a decision on whether to proceed forward.

The next steps we see are:

• We’d love to hear feedback, questions, comments on this post
• Join the Governance Call on Friday, July 21 at 8am PDT / 5pm CEDT.
• Following the governance call (as early as Saturday, July 22): Indicative on-chain governance proposal would be released for engagement (‘temperature check’).
• Further research and work on refining the proposal
• Eventual implementation via hard forks, if the community and validator set agree

Note that in the long term, we see this proposal as an intermediate step in continuously improving the technical ground Celo as a blockchain is built on. This work is all complementary to the Celo 2.0 roadmap that cLabs set out in January which is working to make Celo a great place for other chains to roll up to. We also expect that as next generation zk-SNARK proving systems mature (e.g. Nova), additional work will be able to upgrade Celo to a highly scalable validium-based zk-EVM.

We sincerely welcome your engagement and are looking forward to your comments!

[matt]

Appendix: Design Proposal

This Appendix specifies each of the deviations from the OP stack highlighted in the Section “Proposed Upgrade” of the forum post. It also discusses the reasoning behind these proposals in more detail. This Appendix assumes an understanding of the OP Stack and their terminology. We recommend reading Optimism’s Bedrock Explainer and then diving into their excellent technical specifications for additional context.

Decentralized Sequencer

In this section, we will outline our proposal for modifying the OP Stack’s sequencer role to leverage Celo’s existing PBFT consensus mechanism and validator set as a decentralized sequencer.

In Optimism, the sequencer is responsible for:

• Gathering pending transactions into an “unsafe” block (more details on unsafe blocks and block finality in Finality and Reorgs in Optimism Bedrock.
• Signing and propagating this block to other L2 full nodes through the p2p network.
• Extracting the TransactionBatch (ordered list of transactions, plus some metadata) from the block and sending it as transaction calldata to the BatchInbox address on the L1. (For the sake of clarity, we omit details about how data is compressed and sent in channel frames.)

When deriving the canonical L2 chain from L1 inputs, full nodes filter data sent to the BatchInbox address on the centralized sequencer’s well-known public key, ensuring that only the correct TransactionBatches are included.

In the event of transaction censorship, users can always deposit transactions on the L1 which are then force-included when full nodes derive the L2.

In our design, the rotating block proposer would become a rotating transaction sequencer. At a high-level, the proposer for a round would:

1. Propose an L2 block including an ordered TransactionBatch.
2. Go through PBFT consensus to obtain signatures from ⅔ of sequencers (current Celo validators) over the TransactionBatch, submit the signed TransactionBatch to the DA layer (see Off-chain Data Availability with EigenDA below for more DA-specific details). (Note: we are also exploring the option of submitting the entire L2 block or even the TransactionBatch and signed state root, which is discussed in more detail in Light Clients & Bridging below.)
3. Obtain a DA Certificate from the DA layer and post this certificate to Ethereum, likely maintaining the TransactionBatch structure but simply replacing the full transaction data with this pointer to the DA layer. (Note: we are continuing to examine and find mitigations for the case where malicious DA nodes prevent specific validators from storing data and obtaining DA Certificates. One option we are considering here is to require validators to actually submit the previous block to EigenDA instead of their current proposed block, and to include the received certificate in the header of the block they propose.)

Full nodes deriving the L2 chain would need to then confirm and filter data batches based on who the authorized sequencer (elected block proposer) is for a given L2 block and whether 2/3rds of the elected sequencers have signed each transaction batch

1-Block Finality

Celo currently promises 1-block finality, but to be specific, this really means that there is a large imposed cost to prevent malicious actors from rewriting chain history (ignoring some other nuanced changes Celo has made to prevent reorgs even during equivocation). When thinking about finality, it may be helpful to reframe this as “resistance to chain reorgs” more generally. In order to provide reorg resistance at Celo-economic security in our design, we need to address two sources of possible reorgs: 1) avoid those caused by Ethereum reorgs and 2) impose sufficiently high costs to those caused by discrepancies in what the decentralized sequencer shares over the p2p network and posts to the L1. Once DA Certificates posted to Ethereum are finalized, those blocks benefit from additional economic security guarantees, with data secured by restaked ETH in EigenDA (data availability) and DA Certificates (consensus) by Ethereum’s finality guarantees. We will first look at the status quo of finality and reorgs in Optimism before digging into our proposed mitigations.

Finality and Reorgs in Optimism Bedrock

Optimism L2 blocks have three levels of finality:

• “Unsafe”: blocks are shared by the sequencer over the p2p network and can be reorged with no penalty.
• “Safe”: blocks are deterministically derived from inputs and TransactionBatches posted to not-yet-finalized Ethereum blocks. These blocks are susceptible to Ethereum reorgs.
• “Finalized”: blocks are derived from finalized blocks on Ethereum and can practically not be reorged without massive economic costs.

When deriving a safe block, a full node might already have an unsafe block stored for the same block height. In this case, the node will check if the newly derived block is the same, and in that case it will just update its “safe head”. If the two differ, then a reorg will occur on the L2 chain and the safe block will become the new head of the L2; that is, the unsafe portion of the chain reorgs.

Unsafe head reorgs could happen in the following scenarios:

• If the sequencer shares an unsafe block on the p2p network but misses the “sequencing window” to post the corresponding TransactionBatch to Ethereum. As a result, there won’t be a valid TransactionBatch for that height, and the safe head will reorg to use a generated empty TransactionBatch.
• If the sequencer distributes an unsafe block on the p2p network but posts a different TransactionBatch for the same block height to Ethereum, the safe head will reorg to use the data on Ethereum.

Safe head reorgs can occur in the following situations:

• If an L1 block is reorged, then the corresponding sequencing epoch’s blocks will need to be updated to account for the changes in the L1 Origin (specifically, to L1 Attributes Deposited Transaction). Note: this situation can also cause an unsafe head reorg.
• If Ethereum reorgs such that a TransactionBatch posted either no longer exists or now falls outside of the sequencing window, then the corresponding (previously safe) L2 block will become an empty block.

Mitigating Ethereum Reorgs

Essentially, we need to mitigate Ethereum reorgs that affect L1 deposited transactions (L1 Attributes and user-deposited transactions) to prevent reorgs on Celo L2.

To do this, we propose modifying the L1 Origin used to follow only finalized blocks on Ethereum. In other words, that means constructing L1 Attributes from the most recently finalized block, as well as waiting until user-deposited transactions have finalized before including them as L2 transactions. Because of the way that finalization currently works on Ethereum (i.e. an entire epoch is justified and finalized at once, as opposed to individual blocks being continually finalized), we will need to modify how sequencing epochs in Celo are derived from L1 blocks; for instance, perhaps they will need to map to Ethereum epochs instead of L1 blocks. As long as we rely on finalized L1 inputs when deriving L2 blocks, we should be able to practically avoid L2 reorgs.

Only using finalized data has the potential downside of relying on out-of-date data when calculating gas fees as well as increasing the time for user-deposited transactions to be included in the L2. In addition, we may need to diverge further from the OP Stack in terms of how L2 sequencing epochs are derived, since an entire Ethereum epoch will be finalized at once. We plan to continue exploring the implications of this.

Mitigating Sequencer-Caused Reorgs

These reorgs are caused by the sequencer failing to post the expected data batch (and/or posting a different data batch) to L1 within the sequencing window. That is, this may occur either when the sequencer fails to post any batch when one was expected or posts a different TransactionBatch corresponding to an unsafe L2 block shared over the p2p network. (Note that a different batch can include posting a batch when the consensus slot was missed, resulting in an empty block over the p2p network).

To address unsafe head reorgs with a decentralized sequencer, we must impose on-chain slashing conditions on sequencers that either fail to post the shared data within the sequencing window or post a TransactionBatch that differs from that shared over the p2p network. In the event of validators double-signing a TransactionBatch for the same block height, all participating validators should have their stake slashed (similar to how double signing is handled in Celo today).

One other mitigation strategy we plan to investigate further is allowing the unpermissioned submission of DA Certificates for a block height. For instance, it may be possible to simply add a derivation rule to accept the first posted batch for a given block height that has the required 2/3rds BLS signatures of the sequencers. This would prevent validators from maliciously causing a reorg by simply not posting their batch, as any honest node could submit the signed batch or block.

Additionally, monitoring validators’ sequencer performance can allow Celo voters to play a role in ensuring that responsible validators remain elected. By adding these slashing conditions, we would obtain “Celo-security” level resistance to unsafe head reorgs.

Off-chain Data Availability with EigenDA

In the OP Stack, the DA layer (Ethereum) provides both 1) transaction ordering (consensus) and 2) availability of the full transaction data. Together, these two roles are necessary to deterministically derive the Optimism L2 from L1 data alone. Without (1), there is no canonical system state in the first place. Without (2), there is no way for full nodes to actually derive the L2 chain, meaning that it’s also impossible to verify or disprove proposed state roots.

For Celo L2, we propose using off-chain data availability to keep transaction costs low. In order to fulfill the responsibilities above, we propose sending the full transaction data to EigenDA and storing ‘pointers’ (DA Certificates) to the full data batches on the consensus layer (Ethereum). An L2 full node would then be able to look up the stream of pointers on Ethereum associated with TransactionBatches and “dereference” them by querying EigenDA for the full data.

EigenDA is a data availability service built on top of EigenLayer. EigenDA node operators can opt-in and receive payment to store erasure encoded blobs of data for a specified length of time; if node operators are found (through Proof of Custody) to misbehave by not storing data that they have attested to storing, their stake is slashed. EigenDA is stated to achieve DA rates that meet or exceed danksharding, enabling Celo L2 to keep transaction fees low. For more information about EigenDA, we recommend watching this talk about it.

In our design, some node (likely the sequencer, though this is an area of continued exploration):

1. constructs the transaction batch for an L2 block signed by 2/3 of the validators
2. prepays the DA node operators for storing the batch for the required amount of time*
3. splits and encodes the data batch into erasure-encoded blobs using EigenDA’s encoding software and submits this to the nodes
4. aggregates DA node signatures over the hash of the data verifying that the data has been stored
5. upon receiving a quorum of signatures, posts the aggregated signature to Ethereum as a DA Certificate mapped to the L2 block

*We are continuing to explore the minimum length of time required for block data storage to still leverage the higher security provided by this design. One option here includes checkpointing blockchain state at regular intervals.

When full nodes are syncing with Celo, they can obtain the DA Certificates posted to Ethereum within a sequencing window and check that the data batch hashes match those shared in the p2p network. In the event that there is a discrepancy for the same block height, the full node can request it from the DA nodes and treat this as the canonical block data after verifying the BLS signatures on the block. If there are two distinctly signed tx batches, these two batches can be submitted on-chain to slash validators that have double-signed at that block height.

Off-chain vs. On-chain Data Availability

We should note that as long as we are not using Ethereum for full transaction data availability, there is a potential system liveness concern if the DA nodes decide not to serve data. As long as the data is still available on the p2p network, the hashes could be checked against those posted on Ethereum, but proving DA node misbehavior on-chain is a known shortcoming of the system that may require social consensus to remediate. (Proof of Custody ensures that they store the required data but not that they serve the data requested by anyone.)

CELO tokens as native currency on L2

The OP Stack uses ETH to pay gas fees on L2. If the Celo blockchain chooses to become an L2 based on the OP Stack, the CELO token must be the native currency and be used to pay gas fees on L2. Alternative fee currencies (e.g. ETH) will still be available in the same way they currently are on the Celo blockchain. All of this is important to maintain compatibility with existing Celo applications and preserve the Celo token economics.

Paying gas fees on L2 in a different currency than on L1 can have implications in places where both layers interact. So these interactions must be checked and adapted if necessary:

L2 transaction costs: On Optimism, transactions incur an L1 data fee in addition to the normal gas fee. This fee is used to cover the costs of making the transaction data available on L1. The calculation of the data fee needs to be adapted for multiple reasons:

• Using EigenDA for data availability has a different cost structure than using Ethereum as a DA layer (see Off-chain Data Availability with EigenDA).
• Reading L1 gas prices only from finalized blocks increases the time between reading L1 gas prices and writing to L1, thereby increasing the risk of significant price changes (see 1-Block Finality).
• Using different gas currencies on L1 and L2 adds exchange rate risks.

Luckily, there are also factors at play that mitigate these difficulties:

• By using EigenDA, the L1 costs for data availability are greatly reduced (and with it the exchange rate and L1 gas price volatility risk).
• EigenDA can be configured to use CELO tokens to pay data provider nodes, avoiding all risks related to CELO/ETH conversion.
• The sequencer has a strong incentive to make transaction data available even if the cost of doing so goes somewhat beyond the earned data fees, because it will be slashed if it fails to provide the data (see 1-Block Finality). It is sufficient that the economics work out on average.

It is too early to decide on a specific formula for the data fee, but the rough structure will be

celo_data_fee = tx_data_size * eigenda_data_price

eth_data_fee = eigenda_certificate_size * L1_gas_price

total_data_fee (in CELO) = celo_data_fee + eth_data_fee * exchange_rate * safety_margin

Celo already successfully uses oracles to convert between different gas currencies and the native CELO token, so retrieving an exchange rate between ETH and CELO via a similar mechanism should not be a problem.

Purchasing guaranteed L2 gas on L1: Optimism allows depositing transactions on L1 to force execution of these transactions in L2. The L2 gas required for execution is paid for by burning ETH on L1 at a price which is determined by an EIP-1559 market. Since this market sells gas directly, without going through the L2 gas price, the L2 gas currency is not involved at all. So no changes are necessary due to using CELO tokens as a gas currency on L2.

Light Clients & Bridging

The above proposal creates 1-block finality by letting the decentralized sequencer sign transaction batches and forcing it to publish the same signed batch. This lets full nodes quickly derive the block state from trusted (with Celo-level security) data.

In contrast to full nodes, light clients and bridges can’t derive the state themselves and have to rely on state created by another party. In classic Celo blockchain, the validators signed the block, not only the transactions contained in the block, allowing light clients and full nodes to rely on the signed state. Without this, they have to wait for a state root to be published and the challenge period to pass without a successful challenge.

The desirable property of having a trusted state root available quickly could be brought back by letting the decentralized sequencer sign a state root in addition to the transaction batch. This would allow light clients and bridges to work on a state with the same latency and security guarantees as today’s Celo blockchain. The sequencer executes the transactions as part of its operations anyway, so no overhead for transaction execution would be added.

The specifics of this approach have not been worked out yet, but there is ongoing work being done in the Celo ecosystem outside of cLabs to verify Plumo proofs (Celo’s zk-SNARK-based light client) on Ethereum cheaply using a Halo2 proof on BN254. The reorg resistance provided by the transactions 1-block finality might even allow publishing and signing the state root along with the transaction batch, but this needs further examination of potential failure cases.

Analysis of System Properties & Tradeoffs

In addition to open questions highlighted throughout the proposal, we want to take a look at the system’s properties according to L2BEAT’s criteria as well as when comparing it to Celo as it is today.

Analyzing this design against L2BEAT’s risk criteria:

• State Validation: in development; once it has landed on OP, we plan to modify their state validation mechanism. Note that the consequences of this are different than for OP, since we plan to use an off-chain DA layer.
• Data Availability: off-chain with EigenDA, combined with on-chain DA Certificates. EigenDA is secured by ETH restakers under the hood, and Proof of Custody makes it possible to slash DA nodes that are not actually storing the data.
• Upgradeability: planned to be upgradeable, since we will be following the OP Stack.
• Sequencer Failure: users can force transactions to be included in the L2 by depositing these transactions on L1. As with OP Stack, there is a delay as long as the sequencing window. Note that since Celo L2 would operate with a decentralized sequencer, L1 deposits would only be necessary if a third of the 110 elected (and independent) sequencers failed.
• Proposer Failure: cannot withdraw. Initially at least, we will follow the OP Stack which has this property. In the future, we can revisit including a mechanism that allows anyone to propose a state root after a set period of proposer inactivity (as Arbitrum does).

Comparing the Celo L2 proposal to Celo today:

• Transaction fees: should not increase significantly, though more research is needed to understand what this will be specifically when using EigenDA (since this has not landed in production yet).
• Finality: 1-block finality is still supported by Celo-level security. Once DA Certificates posted to Ethereum are finalized, there is additional economic security (from EigenDA) backing those blocks.
• Security: Celo will be able to leverage the security of ETH staked in EigenDA. Note that since EigenDA is an opt-in service, we will need to re-evaluate the specific security of the system once we better understand EigenDA and EigenLayer usage. That said, there is initial excitement around EigenLayer and we are hopeful that this will be a great way to improve Celo security while strengthening Ethereum alignment.
• Bridging: better bridging between Ethereum and Celo should be enabled by this proposal. Note that withdrawals (Celo → Ethereum) relies on state root proposals and the fraud proof system.

[TomerBa]

I’m so happy to see this proposal coming up, me and many other Celo community members have “grown up” in the Ethereum community, and obviously still are part of it, this connection widen the network affect of both sides and creates a win win situation

The future is made of interconnected networks, grateful to see us going in the right direction.

Defiantly in favor

[Olek]

Yes, I think going back to an L2 is the best thing although I think an official bridge is even more important to increase the number of users and volumes on DeFi applications.

[orkhan]

It’s really the right move at the right time, and we’re going to vote yes.

[untangled-finance]

As a RWA credit protocol our mission is not only to extend crypto collateral universe but to enable freer global capital flows. A native bridge will enable liquidity to flow more freely with between Ethereum and Celo and other chains.

Projects like ours can choose Celo to be our stable home knowing that we can attract liquidity from wider crypto ecosystem. We can be in a mission aligned ecosystem, among likeminded projects whilst still enjoy liquidity de-fragmentation. What not to love? We are fully supportive of this proposal.

[edlovecrypto]

What would It mean for the Connect the World Ramp providers? Would we start giving support tô stablecoins and Native tokens in other L2s?

[Patrick]

Please share view access to the linked Google Docs.

Would sequencers rewards be the same as validator rewards are now?

Would sequencer ‘downtime’ be punished using the same formula as today’s validators?

What sort of adjustments to infrastructure do you anticipate validators turned sequencers would require?

[LuukDAO]

As a long-time Celo advocate and builder - I’m beyond excited to see this being brought forward.

By aligning more closely to Ethereum, we’ll be able to align our interests further and attract even more talent and resources together. I already received some excellent feedback on this from Talent I have wanted to attract for months.

This is a big step for Celo and Ethereum! You have my support.

[Markus]

This is a great direction, benefiting the Celo, Mento & Ethereum communities, and it has my full support.
From my perspective, the combination of enhanced security and sustained low gas fees holds significant importance, particularly for end-users, e.g. those utilizing Mento stable assets. Furthermore, the increased alignment with Ethereum is a great add-on, fostering liquidity and encouraging more developer engagement from a larger community.
The ability to pay for transactions in stable currency on an Ethereum L2 supports DeFi, ReFi and a seamless experience in enduser applications.

[matt]

Hi @Patrick the google doc links were simply internal reference links within the article - have updated them now to point to the correct sections of the forum post (no new info available, just easier to find the relevant sections)

[Alesh]

Excited about this proposal.

Question: Was Arbitrum explored when looking at OP?

Playing devil’s advocate, Arbitrum seems to be leading in terms of TVL and developer activity at present? However, this could change in the future.

[mariano]

Hi @Patrick. It’s too soon to answer some of these questions with confidence.

For infrastructure, sequencer would need access to an ethereum node. Better to run it. Besides that, probably some process like the op-batcher and op-proposer that send batches or state root commitments to eth/eigenDA but those should be light ones.

For rewards and uptime. Intent is for them to be the same or similar. But it is true that sytem would have some extra “costs”. Paying for fees on the DA layer and for gas on ethereum. The proposed design attempts to minize these costs. Still i think there are many variables in the economic model and how better tune them for this use case it’s still an open question.

Hope this helps.

[mariano]

Yes. It was.

I don’t think TVL matters too much when choosing which tech to be based on. The tech itself does and how easy is to extend it, modify it to build the kind of system you want.

On tech i think they’re roughly at par; with some differences. But then OP has made a great work modularizing their tech and make it open source and available for anyone to use. The OP stack is very well documented and it makes it easy for you to reason about the system and how to extend it.

[Erayda]

If we are going to migrate to Ethereum L2, why did we accept ChainLink’s heavy conditions? There was no need for that. This makes me think that this transition was a sudden decision. And it might indicate that the team hasn’t been very transparent about the reasons that make this L1>L2 transformation necessary.

[marcus]

This is really great news and I’m excited to read more into the technical implementation. Also great to see Celo leading the way on the innovation front as well. An exciting and logical step for Celo!

[kalatsong]

I have the same question!

[Jimii]

This is a welcomed change!

My question would be why now after the ‘deal’ with Chainlink.

And also, were any other considerations made about which L1 to move to. A while back, the Helium network successfully migrated to Solana.

I’d vouch for Solana, given its speed, cost and infra considerations for scalability.

[papa_raw]

This is a lot to take in. Gotta read over a few times to get a full sense of the architecture. But in general: this is a great idea. Pushing Celo back towards the Ethereum ecosystem has a lot of promise imho.

[rleifke]

I think this is great idea!