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.