Framework for selecting an L2 Stack

[tim]

Hi everyone!

As part of the technical roadmap for migrating Celo to an L2 on Ethereum (aka CEL2), the community needs to select existing codebases and projects as key building blocks of the new platform (e.g., an L2 stack or off-chain DA solution).

cLabs has developed a proposed framework for evaluating different L2 stacks that we’re sharing below as a draft for consultation. This framework extends cLabs’ original proposal, in which we outlined some value propositions for becoming an L2, and some constraints on the design.

We would love your input, suggestions and feedback, to make this framework more reflective of all the priorities and concerns of Celo stakeholders. Right now, ‘we’ reflects cLabs’ views, but we hope as this doc evolves we can incorporate the general consensus of the whole community.

Note that we are selecting codebases and sub-components here, so we feel it is less useful to directly compare metrics like TVL, transaction count, users, except as indicators of what a closer collaboration and/or shared bridge between the two ecosystems could look like in future. This exercise is not to select a “best L2 stack”: it’s to figure out which is the best fit for the specific technical and non-technical needs of the Celo L2 project.

Proposed Framework

These are the core criteria we propose:

Ecosystem and Project Alignment

1. Positive-sum platform growth opportunities – We seek opportunities for partnerships, shared platform growth and co-marketing that adds value to Celo and other stack participants.
2. Mission and values alignment – Celo’s mission is at the core of everything we do. We seek common ground between Celo mission and the mission of other contributors to the L2 stack that Celo adopts.
3. Ethereum community alignment – we believe in being active participants in the Ethereum community, and will factor in the opportunity to benefit from and contribute to Ethereum events, projects, standards and codebases.
4. Ongoing role for Celo node operator community – A decentralized community of validators launched Celo mainnet and while the validator role may change, we want to leverage the strengths of these organizations through new roles as L2 sequencers, validators, or DA providers.

Technical Considerations

1. Ethereum Compatibility – We want it to be very easy for Ethereum developers to deploy their apps on Celo, and for Ethereum tool providers to extend support to Celo, so that everyone building on Celo can utilize the full gamut of Ethereum tooling and libraries. We favor solutions that already have the confidence of key Ethereum ecosystem services.
2. Increased Security – We want the move to an L2 architecture to deliver security anchored on Ethereum mainnet, both in theory and proven in practice. This includes both the exit guarantees that an L2 offers today, and the stack’s roadmap towards hardening security according to Vitalik’s training wheels framework as well as the Risk Analysis framework used by L2BEAT.
3. Preserving single block finality – Payments use cases benefit from Celo’s single-block finality, so we look to retain this, potentially with a lower level of economic security, in tandem with a longer finality period for transactions requiring the economic security of settlement to Ethereum. This means we need to understand how in each L2 stack to mitigate Ethereum reorgs that affect L1 deposited transactions.
4. Maintaining comparably low gas fees – Many Celo apps and use cases are predicated on transaction fees of the order of 1 US cent for a simple transfer. We want to retain this, despite the additional costs of ETH gas.
5. Preserving token based gas currencies – We want to ensure it is feasible to continue to allow users to pay for gas with certain ERC20 tokens.
6. Opportunity to inherit new features – We will factor in whether Celo could inherit new features from the L2 stack, especially ones that improve user experience or simplify onboarding, an important theme for Celo.

Migration Feasibility

1. Least time and risk route to production – Our objective is to deliver CEL2 as soon as possible, minimizing implementation risk. We favor projects that have been audited and deployed and proven in production, vs projects whose designs are subject to ongoing change or whose implementations are not yet proven.
2. Simple migration, with minimal downtime – The migration from Celo to CEL2 is a complex upgrade of a decentralized production service. We want to avoid anything that necessitates complicating this process. We recognize that it is impossible to communicate with, coordinate or compel every wallet holder, tool developer or smart contract deployer.
3. Minimal downtime acceptable – We would accept a migration process that entails minutes of downtime, particularly if doing so reduces risk or time to delivery. However we feel the possibility or likelihood of hours or days of downtime is unacceptable.
4. Avoid subtle incompatibilities – We would carefully consider any differences in EVM implementation, account setup, RPC interface, and developer toolchain. We would look carefully at the impact of the migration on indexing and consumption of indexed data, and will seek to avoid data inconsistencies or discontinuities.
5. No breaking changes for deployed apps or contracts – We expect that developers experience a “hard fork like” change, where changes to behavior or interfaces can be clearly signposted and with a deprecation pathway. If the migration would break some or all existing smart contracts without developers taking action, that would have to be considered very carefully (since some developers may not be reachable, and some contracts affected may not be upgradeable).
6. No migration action required by Celo end users – We expect that Celo users need to take no action for the upgrade to succeed.
7. Commitment to developer collaboration – To deliver the project, we will need strong lines of communication with and timely support from the developers of the shared codebases.

Governance and Economic Alignment

1. Independence within Ethereum – It is important that the Celo community can fix, modify, and extend the codebase that comprises Celo, and that the platform can be maintained and governed, with minimal constraints. We strongly prefer using permissive open source codebases and avoiding complex licensing arrangements. At the same time, we prefer to evolve and improve Celo governance, and will avoid limiting Celo through governance using any token other than CELO.
2. Roadmap influence – We value indications that Celo will be able to influence and contribute to the roadmap and governance of components it will depend on.
3. Contribution Incentives – We value opportunities for Celo community developers to contribute to shared codebases, especially where incentivized by additional grants or funding from other foundations or protocols using those components, alongside Celo Foundation and Celo’s on-chain Community Fund.
4. Tokenomic implications – Implications for protocol token economics are an important consideration. We would weigh up if adopting a given stack would entail a transaction fee share agreement, or depend on the Community Fund purchasing tokens to use in e.g submitting or aggregating proofs, settlement, performing governance, etc. What token swap arrangements between protocols are proposed? What lock-ins does that create, and what control does Celo governance have to alter or remove those constraints later?
5. Bridging – what are the costs, unlock period and user experience of withdrawing funds to the L1, or depositing to the L2? Does the stack enable, or does it require (either mandated, or practically in terms of achieving an acceptable transaction cost), participation in a stack-wide bridge or shared-liquidity layer? Does that preclude using existing bridges like Hyperlane, Wormhole, or Axelar? What opportunities for new partnerships, mission-aligned apps, and liquidity exists among those bridge participants, now and in the future?

Next steps

Just to reiterate – we would love your input, suggestions and feedback, to make this framework more reflective of all the priorities and concerns of Celo stakeholders. Right now, ‘we’ reflects cLabs’ views, but we hope as this doc evolves we can incorporate the general consensus of the whole community.

We’ll also follow up with a summary of the available options, as we see them.

We’re running a little behind our own stated timeline for figuring this out, but hope we can get general consensus on the framework by mid Dec.

Once we feel we’ve reached general consensus on this framework, cLabs will begin work on evaluating each L2 stack against this framework. We of course welcome others to do so too, and will also invite further input from the teams working on the stacks. This work will likely run through mid-Jan.

cLabs will publish its recommendation for the approach we believe the community should support in moving towards the L2 codebase. After further discussion, we hope to make a further “temperature check” governance proposal to ratify this.

As a decentralized protocol, the L2 solution that Celo becomes is, of course, the implementation that validators choose to follow at subsequent hard forks, and the contract upgrades that CELO holders vote for by governance proposal. Our aim is to make sure cLabs and other contributors have the support of the community as we all proceed to build towards that point.

Please post your thoughts below, and join us for a L2 Discussion call on 13 Dec 2023 8a PST / 11am EST / 4p GMT / 5pm CET – save the date, call details to follow.

– cLabs team

[zhivkoto]

Hey @tim, Zhivko from LimeChain here (we used to contribute to Celo development in its early days in 2019).

Been following the CEL2 progress from a far and find this discussion fascinating. The framework you’ve proposed is already extensive enough.

The one thing I would probably double down on in terms of importance is the path to technical decentralisation, even though it’s kind of mentioned in .4 of Ecosystem and Project Alignment.

Optimistic and zk-rollups decentralise in different ways and specific projects have different visions for that. For example, in the OP Superchain ecosystem, sequencers will potentially have to be elected through governance and could potentially participate in shared sequencing for all of the OP ecosystem chains. Two questions that pop up instantly are 1) would Celo node operators be allowed to participate as sequencers and 2) do they have interest in supporting chains other than Celo, assuming shared sequencers. There’s always the option of using the OP stack without participating in the Superchain ecosystem however.

On the other hand, zk-rollups path to decentralisation is different. We’ve outlined a framework for decentralisation of zk-rollups, including tradeoffs for prover and sequencer design choices in Ethresear.ch. It essentially comes down to a free-for-all (on the one side) and elected leader (on the other side) spectrum, however there’s additional complexity considering coupling (or not) of provers and sequencers, allowing forks vs no forks etc.

It’s unlikely for the CEL2 network to launch fully decentralised from day one and some kind of training wheels are to be expected. The path to decentralisation however is important and it predefines the potential role of the current set of Celo node operators.

Will be following the proposals and eventual decision closely, and happy to jam more on the topic if needed

[tim]

Hey! Thanks for the input, and for sharing the link. Have you evaluated various designs/implementations of zk rollups with it? would be curious to see it applied.

It’s unlikely for the CEL2 network to launch fully decentralised from day one and some kind of training wheels are to be expected. The path to decentralisation however is important and it predefines the potential role of the current set of Celo node operators.

One of cLabs’ goals is definitely to prioritize retaining the decentralization of the Celo L1 on the transition to L2. In fact, I’ll try to adjust the post to clarify that. We talked a bit in the original sample OP Stack based design (leaving aside plans for Superchain) about how we could achieve a decentralized sequencer by adapting Celo’s current approach, but other designs are definitely possible.

On the question of shared sequencers – that’s also interesting and we’d love community input on that.

[zhivkoto]

We’ve evaluated Taiko’s design using the framework. Let me know if there’s a particular rollup that you would like to explore through it. I would assume Polygon zkEVM is under consideration, as there was a proposal?

[ericnakagawa]

Hi folks, the Celo L2 Stack Discussion call is happening Wednesday 8a PT / 5p CET.

Please subscribe to the Celo Signal Calendar or Celo Community calendars for the latest Engineering, Validator, and Governance community calls.

[tim]

Hey everyone – looking forward to tomorrow’s community call. We’ll be walking through the decision framework above, and getting input and suggestions – looking forward to a lively discussion! I hope we come out with a clear path to reaching consensus on the framework.

In anticipation of this, the cLabs blockchain team has begun work on technical evaluations. We’re focusing on learning first – understanding each stack and how it fits together, and familiarizing ourselves with the technology and its current state of production-readiness. Then we hope to understand more about governance, economics, shared bridging etc. Then we’ll come up with our evaluation of these options against the agreed framework, for the community’s input. Once again, our goal is to help find a stack that is best for Celo, not the best L2 stack out there.

Ahead of the call, I thought it might be helpful to summarize the actual stacks that we’ll be evaluating. They’re listed below in the order they joined the discussion. These summaries highlight our thoughts on some of the different design choices that these stacks have made, and areas where we’re particularly evaluating the fit with Celo’s goals. They should not be read as conclusive evaluations in any way. The teams behind each of these options have posted to the Celo Forum, and we’re expecting to engage with them a lot more in the coming weeks as we all explore more.

– cLabs team

OP Stack

cLabs’ original proposal described making CEL2 an optimistic chain (i.e fraud proofs and offchain DA) based on OP Stack, utilizing EigenDA for Data Availability (DA) and building our own decentralized sequencer that leverages Celo’s existing validators.

OP Stack is fully Ethereum compatible. It uses op-geth, which is a minimal modification over geth. This means it’s straightforward to extend it to support the Celo Protocol and will likely be one of the easier options to maintain as Ethereum evolves. It already embraces the consensus-execution separation that Ethereum follows (which Celo does not but aims to), and uses the “consensus” to encapsulate everything L2 specific. This makes a very good separation of concerns, and makes it easy to reason about the system in general.

We’ve found that OP Stack is well positioned as a framework for others to build their own L2 chain. It uses permissive open source licenses, and is well documented. It has excellent specifications, which speaks volumes to its maturity. We found it to be well architectured, allowing the cLabs team to quickly identify how it should be modified to support offchain DA and decentralized sequencing. OP Stack Hacks have proven to be a great-starting point for this. The collaboration with Espresso Systems around sequencer decentralization could directly benefit Celo’s efforts.

The OP Stack fraud proof system is still not in production, but is now deployed on the Goerli testnet. It adopts a multi-step process that only requires protocol rules to be compiled using the MIPs architecture. This makes it very powerful and easy to generalize. OP-Labs is also working with O(1) Labs and RISC Zero on a zk-prover that can prove arbitrary golang code compiled to an instruction set architecture (ISA) supported by the golang compiler (e.g. MIPS, RISC-V, or WASM). If such a prover were to become economical, this approach would offer the security benefits of zkEVMs combined with the benefits of the minimal diff on top of geth design.

Part of a decision to adopt the OP Stack is understanding under what constraints or conditions Celo would be able to join the OP Superchain, a network of chains connected by a shared bridge and with shared governance. Our understanding is that the design is early, and evolving rapidly, but OP token based governance controlling protocol code changes require further investigation.

Polygon CDK

Polygon proposes CEL2 to be built using the Polygon Chain Development Kit (CDK) as a Validium – a system with offchain DA (EigenDA or others) and validity proofs.

For the validity proofs, the Polygon team have developed two zkEVM libraries that could be integrated. Polygon Zero is an ambitious new Plonky2 based client module that is fully compatible with the EVM and Ethereum’s storage layout. This means that tools like LayerZero that depend on storage layout will work with CEL2 without any migration whatsoever. Our understanding is that Zero will soon be on testnet as its next step towards production readiness.

Alternatively Celo could integrate Polygon Hermez, a Type 2 zkEVM. This implementation is more mature, but bridges and apps that depend on Merkle proofs over the state root would need work to enable them to support the migration. By using a “ZK friendly” storage layout, e.g Poseidon Trees, these implementations can drive higher performance.

Based on our current understanding, modifying either of the zkEVMs to follow the Celo protocol could be challenging work, requiring very specialized skills, as it implies modifying the prover. This introduces new risks and would require the prover itself to be reaudited.

By using Polygon CDK, Celo would be able to be part of Polygon’s shared bridge solution, LxLy. This bridge works by aggregating ZK proofs from different CDK L2s. It reduces the cost of L1 gas per L2 transaction, without increasing the delay between submitted proofs. It also enables much faster communication between L2s sharing the bridge, enabling ecosystem synergies and simpler access to fast liquidity. However, we would need to explore the project’s maturity, its token economics, and other ecosystems signed up to it.

ZkStack by ZkSync

zkSync proposes CEL2 use the ZK Stack, turn Celo into a Hyperchain, connected to other Hyperchains with the zkSync Hyperbridge. Similarly to Polygon CDK, this would turn CEL2 into a Validium system (offchain DA + validity proofs).

ZK Stack proposes that Celo uses a new Type 2 zkEVM that is currently on testnet. This Type 2 zkEVM is actually a VM layered on top of their current zkSync Era VM, which is a Type 4. This allows developers to choose to use one or the other, or both together. For contracts built with the zkStack compiler using a variant of EVM semantics, the platform can deliver higher performance. For contracts that need full compatibility, the new Type 2 provides an “emulation layer”. Contracts deployed using common proxy patterns can later upgrade their implementation contract to the Type 4 to gain performance benefits while keeping the same API.

ZK Stack has native Account Abstraction (AA). That is, every EOA account can use account abstraction, which allows features including paying with alternative currencies, using alternative singing methods, paymaster paying for gas on behalf of the user, and many other things. This could potentially be a powerful complement to Celo’s existing usability features. In fact, we may be able to use native AA support to enable Celo’s own envelope transaction including support for paying for gas using approved tokens. One small risk however is that if Ethereum enshrines AA, it may do so in a way that is not perfectly compatible with ZK Stack, requiring future changes.

From first inspection, it appears to be relatively straightforward to adapt the stack to support the Celo Protocol. The state transition function is a VM contract, Bootloader, so customizing this contract should suffice; this could avoid having to modify the ZK prover itself. We plan to evaluate this further, and in particular the implications of this direction on participation in the HyperBridge.

HyperBridge is a shared bridge, similar to the one proposed by Polygon CDK, where Celo benefits from proof aggregation and fast communication between other Hyperchains, L2s using ZK Stack.

In terms of DA, ZK Stack appears to be able to be integrated with 3rd party off-chain DA services, including EigenDA and Celestia. Matter Labs also have long discussed a technology called zkPorter, a per-account Volition system, where some accounts use on-chain DA while other accounts use off-chain DA. This could enable higher transaction throughput in the platform by making low-value transactions low cost and low security.

Arbitrum Orbit

Hot off the press – we are adding Arbitrum as a fourth option based on their Forum post earlier today! Arbitrum Foundation proposes that CEL2 become an optimistic chain using their stack, similar in approach to how Celo would adopt OP Stack technology.

In terms of technological maturity, Arbitrum is the only one from the options that is considered a Stage 1 rollup by L2Beat, using Vitalik’s definition of stages. Arbitrum has the largest TVL of any L2, which is relevant insofar as it speaks of the trust earned by Arbitrum in the market.

Similarly to OP, it should be easily customizable to follow the Celo protocol. Our research of the technology is still in its early stages, but the codebase also comprises geth, and does not have the complexity of needing a ZK prover.

Aribtrum has a fraud proof system deployed and proven in production, and their next version of it, BoLD, would allow Celo to do decentralized validation for fraud proofs.

For Celo’s off-chain DA needs, the Arbitrum stack could be integrated with EigenDA, or it would be possible to use AnyTrust, the data availability committee technology currently deployed with Arbitrum Nova.

As with OP Stack, Arbitrum could be modified to use a custom decentralized sequencer built by cLabs. Arbitrum is also working alongside Espresso Systems on a shared sequencer for Orbit Chains.

Finally, Arbitrum recently announced Stylus, which is a technology to write smart contracts in programming languages like Rust, C++ and in the future others using WASM. This would enable smart contracts that are up to 10-100x more efficient than Solidity, valuable for a chain like Celo that anticipates very high future throughput needs. Stylus manages to be compatible with all existing contracts, since it exposes the same interface as a Solidity contract, and can be called or interacted with by other contracts in the same way.

Since Arbitrum is not released under a permissive open source license, adopting its stack would require Celo Foundation and Arbitrum Foundation to agree licensing terms, which would likely need to be explored in parallel and approved by the Celo community. This may influence token economics, governance, and collaboration opportunities.

Arbitrum does not appear to promote a vision of a Superchain as the other three stacks do – instead, Celo would use shared bridges through providers like Axelar, Hyperlane, LayerZero, Wormhole/Portal and others.

[tim]

Thanks everyone for joining the community call earlier. Appreciate all the comments and questions! I know we ran out of time, so if anyone wants to follow up, please post here

[ericnakagawa]

The L2 Stack Community Call was recorded and is available here.

[alchemydc]

Thanks Tim. I thought you did a great job getting us all on the same page WRT requirements and where your team is on the evaluation process.

I had some additional thoughts after the call, that I’ll share as they relate to each of the consideration layers:

Technical Considerations

Censorship Resistance
Perhaps add censorship resistance to the list of evaluation criteria? Maybe under the Security bullet point.

Specifically I think we should consider the lifecycle of a Celo TX post-migration, and enumerate dependencies on actors within each ecosystem that could/might censor or deny service.

For example, in the originally proposed cLabs architecture (using OP + Celestia DA), the sequencer (or sequencers, perhaps composed of existing Celo validators) would be in a position to censor transactions. But there would be no Optimism architecture components, or hodlers of OP tokens, for example, that would be able to apply censorship forces. It’s not clear to me if/how the Celestia DA layer is impacted by censorship resistance concerns.

Continuing this thought experiment, how might this change if CEL2 were built atop Polygon’s framework, the zkSync framework, or Arbitrum?

Governance and Economic Alignment

Independence within Ethereum
This is critically important. Looking at the original cLabs proposal through this lens, it seems that selecting the OP stack would “avoid limiting Celo through governance using any token other than CELO”. Governance decisions made by OP token holders might impact Superchain dynamics, bridging, etc. but not tunables of CEL2 itself.

How might this be different if we built CEL2 on Polygon, zkSync or Arbitrum?

Tokenomic implications
In addition to the questions you’ve identified, I think we should think carefully about how revenue is generated on L2’s and how might this revenue be modulated or constrained by the stack we choose itself. There are two primary sources:

1. TX fees
2. MEV

You’ve already identified that TX fee sharing might be a negotiating point (eg with Polygon, zkSync or Arbitrum). Notably, the proposal originally floated by cLabs would not be subject to any fee sharing (eg with Optimism), right?

With respect to MEV, it’s notable that OP and Arbitrum have very different ideologies. Building CEL2 on the OP stack, I expect that we would be able to choose our own destiny as to how MEV is handled. Is the same true on Arbitrum, which has taken the position that MEV is bug not feature?

Looking forward what’s next

DC

[Patrick]

Another parameter that I’d like to see taken into consideration is transaction per second. Both max recorded TPS and theoretical max TPS.

Are any of the teams/foundations behind the L2s under consideration offering engineering or financial support?

[techboiafrica]

Hey yall, happy to see this discussion kicking off! Apologies for the long post but we at Ocelot think it is THE discussion to be having as it affects not only technical direction but consequently, this discussion informs our community narrative as we migrate to the Ethereum ecosystem. So super excited to join and see where the discussion leads!

In these uncharted waters community alliances are important and decisions around architecture like rollups are crucial for establishing our momentum going forward. Basically, think a new kid at a new school. We have a lot of paths ahead of us and a lot of potential close friends, some whom will see our value sooner than others.

Ocelot has been following the development of Celo’s L2 migration with excited interest and we’re fully in support of the migration!

We’ve deliberated extensively over rollups. Our project “Mezcal” directly focuses on the areas of discussion relevant to this post. We’re happy to share our findings more in depth but in summary - through over a year of research and production we’ve come to appreciate the plethora of approaches available for rollups and the merits to each (please see technical overview below). It’s been difficult to establish as Tim put it “the best framework for Celo.” This is largely because the growth of Celo isn’t something that can be easily plotted after the migration and developer needs or future trends can be fickle. In reality, the only variable we began to focus on was architecture that would allow the community to stay as close to the “major capital flows” of the Ethereum ecosystem as possible. Which landed us experimenting with a multi-rollup integration development timeline.

For background, “Mezcal” is intended to be a developer playground project with the goal of better understanding the intricacies of migrating Celo from a layer 1 to a layer 2 through experimentation with testnets.

This is an approach designed to give the community the freedom of experimentation and exposure before committing to anything. We’ve been heads down with this project for some time, and after some recent meetings with various Celo stakeholders and leaders, we’re excited to share our advancements! (new forum post incoming)

With this understanding, we’d love to collaborate more deeply with the community around using the Mezcal project specifically for Celo’s future direction.

The approach of Mezcal and the overall idea of blockchain migration garnered a lot of attention and excitement within the web3 community last year, and this energy persists today. Migration represented an embrace of the space’s paradigmatic shift toward modularity and a march toward “mutually assured development” (MAD).

Here’s how Mezcal can help create clarity around the current Celo L2 framework discussion and how we can create active community advancement in understanding the merit and usefulness of different rollups:

[ First, It’s important to envision Mezcal as an experimental playground for CEL2 testnets that use live modular stack components. Please keep in mind the whole project’s original emphasis is to be a developer playground for the Celo community.

Next, it’s important to remind ourselves that with the rapid growth of cash in and cash out access to the Celo ecosystem in many regions of the world where the Ethereum community has failed to reach. Celo has a unique and drastically more concrete value add to many avenues of the Ethereum ecosystem. This reality will become more obvious to ETH stakeholders over time sure, however we can catalyse this development easily by being as available as possible to all corners of the Eth ecosystem with significant capital flows. This also consequently positions Celo in reach of the highest concentrations of active developers in the space. ]

Mezcal will soon be launched as a collection of ETH L2 testnets where each testnet covers a different L2 framework while settling on Ethereum Sepolia and taking DA from Celestia.

The frameworks will be the following:

• A vanilla OP-Stack rollup testnet that settles on Ethereum and gets DA from Celestia
• A vanilla Arbitrum Orbit rollup testnet that settles on Ethereum and gets DA from Celestia
• A vanilla Polygon CDK rollup testnet that settles on Ethereum and gets DA from Celestia

---

Due to our experience with Mezcal and its relevance to this forum post - we recommend considering Celestia for Data Availability (DA) for the following reasons (Disclaimer - Yaz [former devrel of Celo] is currently the Head of Devrel at Celestia Labs):

● Current Viability: Celestia is already live and operational, providing a robust and tested Data Availability solution. Rollups are already being deployed on Celestia such as Manta Pacific, Eclipse, Astria and Dark Frontier.

● Comprehensive Integration: Celestia has integrations with leading Ethereum rollup frameworks such as Arbitrm Orbit, OP-Stack, and Polygon CDK, ensuring compatibility and ease of implementation. More importantly, it provides lots of options for Celo to choose from given the modularity of Celestia architecture.

● Blobstream: Celestia’s Blobstream effectively streams DA to Ethereum L2s, ensuring L2s can scale with the demand of their users. Furthermore, with Ethereum fallback mechanism, Ethereum L2s can fall back to submitting their blobs directly to Ethereum.

● Data Availability Sampling: Celestia is the only Data Availability network that has Data Availability Sampling live on Mainnet. DAS beats committee-based solutions in terms of scaling rollups with the amount of users participating in a rollup, and stabilizing fees over time.

● Alignment with Celo’s Requirements: Celestia meets key criteria outlined in your proposal, such as security, Ethereum compatibility, and minimal migration risk, making it an ideal fit for Celo’s L2 migration. Furthermore, using Celestia for DA still allows Ethereum alignment for the Celo community as a Celo L2 can still settle on Ethereum.

The biggest shortcoming we see in the other DA options proposed is about the DAS beats committee-based solutions, which are essentially multisigs where users must trust a handful of nodes to provide DA. This also minimizes how scalable a DA solution can be due to the lack of Data Availability Sampling, which allows light clients to trustlessly verify that transactions are included in the block without downloading the whole block. The narrative around Data Availability Sampling and running light clients from your phone to verify what’s on the chain ties well with the Celo narrative of a mobile-first blockchain. in terms of scaling rollups with the amount of users participating in a rollup, and stabilizing fees over time. This is an area of the stack that we’ve given extensive thought to and are happy to collaborate more on.

The timeline will kickstart with the OP-Stack testnet. The invitation will be for the Celo community and core devs to modify these testnets to add Celo-specific features to them - given the core devs have the most familiarity with the Celo stack. We will have more information about Mezcal with an interactive website in early 2024.

In summary, the above contains our technical suggestions and more around creating a community-driven and well-understood migration that allows for extensive developer participation and discovery from multiple ecosystems - all for the benefit of scaling the Celo mission catalyzing as much of the Ethereum community around this mission as possible.

Much love and cheers to this new chapter!
Ocelot Stewards

[mariano]

Thanks @techboiafrica for your post, this is great! I’m currently leading the efforts from clabs on the technical assessments. I’ll try to keep this short and to the point to make it easier to follow

If i’d summarize your post. You write 2 things:

1. Project Mezcal to soon launch 3 tesnet (op, arb, polygon cdk) that settles on ethereum. As way to experiment for CEL2. All of them using Celestia
2. Recommendation to consider Celestia as the DA. Layer

For 1, couple of questions:

1. Are these tesnets going to implement the Celo protocol? That is, include features like alternative fee currencies? Celo token dual nature? Or would they just be plain ethereum VMs?
2. What would be the purpose/exepcted output of such experiments? What do you think community would be able to analyze/explore thanks to them?
3. You mentioned “soon”, but would be nice to have better idea on timing.

Reasoning behind my questions is that:

• Implementing the CELO protocol on this chains can be quite challenging. We’re in the process or understanding HOW to do that. And it takes quite some time. So i wonder how’re planning to do that, specially when you mention CDK, since that imply changing the prover too. So, doing this for all 3 chains it’s actually costly in terms of time and eng resources. [For context, we spent months working with OP stack and haven’t finished]
• If you don’t implement the CELO protocol and this are just regular EVM. I wonder what’s the purpose? How will this help the decision process? I mean, from user perspective, this would be similar to interacting with all this 3 chains that already have testnets/mainnets. The change, would be in an alternative DA layer, that could showcase (1) feasibility (2) costs (3) overall architecture and design of the integration. These are great; and if Ocelot can provide that, i think it’s great. But i’d argue you don’t want to incurr in the cost of doing a whole public testnet to do so. I’d say it’s more a technical research and discussion following by some form of testing.
• I ask about timing, because it is important. We know as a community that we have this tradeoff between spending enough time on research to make the right decision vs doing the change fast enough. I mean, if we wait 2 years to do the change we’d all probably agree that it’s a bad thing.

By now, i guess my thinking should be clear. As an engineer (or maybe as someone that tries to follow a “lean startup” approach). I think it’s important to clearly understand what’s our hypothesis, what are we trying to “get out of this”, and find the most time and cost efficient way of doing so.

On 2: Recommendation to consider Celestia as the DA. Layer

I think it’s a valid claim; and something that can be explored more. We started by doing an assessment of the different stacks. And which DA layer we use doesn’t seem to matter for that. Maybe un stack unlocks an alternative like AnyTrust on arbitrum or using zkPorter on zkSync. But we’re trying not to solve every question at once, since it can be daunting.

Nevertheless, would love to have a technical discussion on the pros/cons of the different DA options. I think again, as with the overall stack, the technical component is a part of it and not all; but something that is more concrete for us to talk about.

[YazKhouryTest]

Hi @mariano thanks for those awesome questions.

I will try to answer your questions:

1. They will be plain vanilla EVM deployments. Reason for that is because like you said, it is hard to make a rollup ourselves that follows all Celo features as those are hard to keep track of unless you are a core dev who knows all the different features. The idea here is to instead provide those vanilla testnets for the Celo community and cLabs to deploy on the Celo-specific features if they wish to do so while Ocelot covers running those rollups. It will be an invitation for collaboration there.
2. The purpose of those experiments is to play around with the different features each rollup framework has and to monitor how they settle on Ethereum, whether via fraud proofs or zk proofs (in the case of Polygon CDK). We can even explore cost calculations of using those rollups as part of the assessment as part of transaction flow. We are providing this for research purposes for the Celo community, a modular playground of different testnets for the community to explore. We can coordinate any upgrades to those testnets with the cLabs core devs directly for whatever you want to see upgraded and provide repos to use.
3. OP Stack testnet can be done super soon, even next week. We will most likely target early January however unless I can personally rush the team to do it soon. Will keep you posted.

On the different DA layers to choose, I (as Head of Devrel at Celestia and a steward at Ocelot) am biased to a solution that uses Data Availability Sampling because that is the best way to scale Celo. I just don’t think a committee-based solution is best aligned with Celo’s values as you sacrifice security on the DA layer side when you trust a small committee to ensure data is available. To add to this, any solution that uses restaking, is in Vitalik’s own words, Overloading Consensus, which is an attack vector on Ethereum as it risks issues to the consensus layer once validators start reusing their stake away from security for new DeFi or staking primitives. Furthermore, being able to sample data from your phone with a light client (sampling less than 1% of a block to verify up to 99.99% certainty what’s included in the block without download the block) ties in very nicely to Celo’s vision of a mobile-first blockchain.

[marek]

Hey @techboiafrica. It’s good to hear from you and Ocelot. I’m stoked to hear your excitement for CEL2 and I’m looking forward to seeing your Mezcal testnets to see what we as a community can learn from them

[karlb]

@YazKhouryTest

To add to this, any solution that uses restaking, is in Vitalik’s own words, Overloading Consensus , which is an attack vector on Ethereum as it risks issues to the consensus layer once validators start reusing their stake away from security for new DeFi or staking primitives.

I don’t read Vitalik’s post as a general discouragement of restaking. He closes with

We should instead preserve the chain’s minimalism, support uses of re-staking that do not look like slippery slopes to extending the role of Ethereum consensus, and help developers find alternate strategies to achieve their security goals.

[hhe]

Glad to see that Ocelot is pushing Celestia’s DA. The word on the street that I heard is that Celestia DA is more expensive than other DA solutions. It would be a good value add to the Celo community if you can provide a thorough comprehensive report on the tx cost (real, not theoretical) using Celestia DA with all 3 rollup stacks!

[gets]

The requirements for low fees and fast finality make being an Ethereum rollup infeasible, at least in the short term. In my opinion, these requirements put the question of using an alternative DA layer to Eth L1 central to the proposal of moving Celo towards an L2.

It may be the case that in 3+ years Ethereum manages to scale its data throughput to provide low enough costs to rollup transactions. In the interim however, I would strongly consider turning Celo into a validium, where data is not posted directly to Ethereum. Alternatively there needs to be further discussion with the community to see if the higher tx fees associated with being an Ethereum rollup are worth it to them. These fees typically range from $0.10-$1.00+ in times of high demand.

With regards to fast finality, it is unlikely that Ethereum will ever provide finality on the order of seconds. This means that even if data throughput on Ethereum were to scale, becoming a based rollup will remain out of the question.

There are however benefits to sharing a sequencer as in based rollups, namely safer and more efficient bridging, and the ability to perform atomic transactions, between chains that share an ordering layer. With restaking it is possible to build such a shared sequencer that meets Celo’s requirements and is still operated by the same set of actors as Eth L1.

This is what we are building at Espresso Systems. The Espresso Sequencer supports both validiums through it’s integrated DA layer, as well as rollups that post their data to Ethereum. In recent testnet benchmarks the Espresso Sequencer running on a 1000 nodes shows that it commits transactions in 2-3 seconds and sustains throughput of over 25MB/s in optimistic network conditions, satisfying the requirements of fast finality and fees far below a $0.01 per transaction in the case of validiums.

An important question for chains like Celo when considering joining a shared sequencer is what kind of utility the Celo token would provide under this new paradigm. At Espresso Systems we have sketched out a number of models that we’d love to look at with the Celo community if there is a mutual interest in exploring this subject further!

[YazKhouryTest]

Hi @mariano we just unveiled the first testnet for Mezcal here: https://twitter.com/ocelot_labs/status/1737911323533648086

You can check out the website at https://mezcal.wtf where it has links to RPCs, faucets, block explorer, and Metamask connection to get started!

[mariano]

Amazing! This is really great!

Any place where i can find the details of the integration? This is OP + celestia right? I’d imagine a single sequencer, that pushes to celestia and block derivation codes where changed. Is there a github repo to check out the code on how’s that done?

[YazKhouryTest]

It uses the following specifications found on the docs here: Introduction to OP Stack integration | Celestia Docs

The repo used to launch the testnet is here: GitHub - celestiaorg/optimism: The Optimism monorepo

We can create a github repo just for Mezcal though if you guys want to begin wanting to modify things in the repo for testing.

There’s also the initial blog post about the integration Modular data availability for the OP Stack

If you have more things you’d like to see happy to share or find right person to share them.

Our next steps are Arbitrum Orbit (which will also benefit from Blobstream Introducing Blobstream: streaming modular DA to Ethereum) and after that the Polygon CDK testnet for Mezcal. Will keep you posted in January when they’re launched.