Introduction
Celo displays the potential for blockchain to empower individual freedom. While this post is primarily meant to discuss how ZK Stack can serve Celo, we’d also like to express our admiration for the accomplishments of cLabs, Celo Foundation, and its ecosystem of users and applications. The team at zkSync is deeply aligned with your vision, and for additional context, we recommend all to read our recently published ZK Credo.
Here, we will outline why the modular and open-sourced ZK Stack is the optimal L2 stack for Celo’s transition to Ethereum. More specifically, while much of Celo’s original proposal* was focused on plans to use the OP Stack as the first step before a validium design, we would like to skip that first step — we can take Celo straight to a ZK-Validium design with ZK Stack 
For further context to the below — the zkSync team has met with Celo at EthCC and other recent events, and our heads of product, engineering and BD have engaged with the Celo team in weeks prior to ensure this post can be presented in the most effective way to engage with the Celo community.
We hope to trigger an honest, open discussion amongst the Celo and zkSync communities regarding the tradeoffs between the ZK Stack, the OP Stack, Polygon CDK and other options to enable Celo as an Ethereum-aligned blockchain.
We welcome all members of the team and community to share their opinions.
Key Benefits for Celo
As a premise to the more detailed discussion below — we find the following five points as key benefits for Celo’s choice of building with the ZK Stack:
1. Mobile-first alignment
Celo can adjust its account system to incorporate hardware signers using mobile devices, this would be enabled through work directly with the Clave team, the creators of EIP 7212*. Not only will a user be able to associate their phone number with one or more public addresses via Celo’s identity layer, but Celo can expand this offering so that the security of the account itself can be tied to the user’s own hardware.
2. Battle tested rollup tech
Analyzed monthly, zkSync leads all L2 rollups of any type on a TPS basis. As one of the only live ZK rollups with a working proof system this establishes us as far and away the most battle tested and complete L2.
3. Security as a priority
Everything that passes through the team at zkSync is held to the highest possible security standard. The zkSync Era testnet ran for a full year with 500,000 active accounts, 30,000 smart contracts deployed and nearly 9 million transactions without any major issues. We used this time to run top-tier audits and stress test the network before opening to projects or users. You can find out more on our commitment to security on our site.
4. No licensing fees
We build and operate open-source software. We do not require additional fee sharing or other upfront costs for external teams to build using our stack.
5. Ecosystem adoption and users
We’re just 6 months old, but we can let the stats speak for themselves:
- growthepie.xyz*
Our ecosystem efforts are just now starting to come to fruition as evidenced by the announcements this week:
- Pudgy Penguins on Walmart powered by zkSync*
- Government of Buenos Aires moves towards decentralized identity for all of its citizens. Powered by zkSync*
What is the ZK Stack?
The ZK Stack is a modular, open-source framework that is both free and designed to build custom Hyperchains (ZK-powered L2s and L3s) based on the code of zkSync Era — the first Hyperchain.
At its core, the ZK Stack offers two key features: sovereignty and seamless connectivity. The builders possess full rights to the code and enjoy full autonomy to customize and shape many aspects of their chains. Hyperchains operate independently but are interconnected by a network of Hyperbridges, enabling the ideal interoperability landscape — trustless, fast, and cheap cross-chain transactions.
If this is the first you’re hearing of the ZK Stack, we suggest you also read our initial post presenting it here: https://blog.matter-labs.io/introducing-the-zk-stack-c24240c2532a, or take a look at the dedicated section in our documentation.
At a high level, we’ve found that the following points are most relevant for the non-Ethereum ecosystems we work with that are looking to pivot to build an L2 with ZK Stack:
(1) Boojum proof system*
-
The new prover is currently running in shadow mode, meaning it is already proving all transactions in parallel to our existing version. A full transition to this system is planned to take place without a regenesis in November.
- Note: This transition is unique to Era’s approach — we have decoupled the what is being proved from the how these proofs are generated, meaning the proof system can be continuously upgraded without obstructing protocol liveness.
-
The requirements to run the Boojum proof system are deliberately consumer friendly for the purpose of more accessible path to decentralizing this piece of our system:
CPU: ~8 physical cores
RAM: 16GB of RAM(if you have lower RAM machine enable swap)
Disk: 30GB of free disk
GPU: 1x Nvidia L4/T4 with 16GB of GPU RAM -
The readiness of this system compared to other options on the market is especially important when considering choosing paths to build on Ethereum. With the Era L2, we have a functioning scaling solution that relies on math for security. This is imperative for providing the utmost reliability in scaling Ethereum and will be followed with continued progress towards more milestones necessary for Era to become a fully decentralized, credibly neutral L2.
(2) Native Account Abstraction (AA)
To quote Vitalik: “Good user experience is not about the average case, it is about the worst case”
User experience in the space is still one of the biggest obstacles to greater adoption.
-
All accounts are smart contracts on Era. This opens a wide variety of designs for developers to most importantly improve blockchain UX and build unique blockchain-augmented features for apps. These are features that users are accustomed to in Web2, but were previously only possible through custodial services in Web3.
With native AA we are breaking out of this shell.
- Some examples include: Paymasters (below), new account signers by Clave* (also below), session keys, and account admin controls for recovery, backups and/or a dead-man switch.
- For more content on native AA on zkSync, we recommend the post linked in the following footnote post, as well as the post on zkSync by the Argent team.
Custom Signers:
With accounts supporting EIP1271, applications can use different signers to control accounts — for example, the Clave platform allows anyone to use the secure element of their mobile phone as the main signer for their public address.
Paymasters:
All transaction types have a pre-defined field for Paymaster addresses, meaning paymasters work for both externally owned (EOA) and smart contract account (SCA) types. Paymasters allow application developers flexibility in customizing payment mechanisms. Most frequently they are used by zkSync Era apps to pay gas in stablecoins, or supplement gasless transactions (see the gas in USDC tutorial here).
- Note: EIP4337 adds this functionality to the app layer. This requires a separate mempool managed by relayer services (at added costs) and implies Paymasters cannot be used for both EOAs and SCAs. On Era there is a unified mempool for both EOA and SCAs.
(3) Interoperability & Hyperbridges
- Features that are still in development — hyperbridging refers to the ability for multiple hyperchains to achieve native interoperability by using the same proof system and shared bridge contract on L1.
(4) Future-proof through modular design
- The ZK Stack is deliberately modular so that it can support unique options for developers when defining data availability, sequencer characteristics, as well as proof generation (more on this below).
Celo’s Priorities & ZK Stack
This section is meant to align how the ZK Stack can be optimized for Celo’s priorities (based on our understanding from the forum post and conversations with cLabs).
Please note that we are not aware of Celo’s expectations regarding timelines for each development.
A) Validium Rollup (ZKR with Custom Data Availability on EigenDA)
The zkSync team has already built a custom zk-rollup using a Validium design for DA when working on a pilot with a large financial institution.
After building its own L2 client with the ZK Stack, Celo will be able to post data off-chain to the EigenDA service — or any arbitrary non-Ethereum DA provider. This is supported through the modular design of the stack. If Celo wanted, it could even explore building within the zkPorter architecture and use the CELO token to secure this DA layer.
Note — since Celo would be running it’s own instance of Boojum, the team could technically increase batch sizes. There is also the potential to offer inter-block recursion, so the network could choose to aggregate more batches in a period of time, yet still post a single proof. Celo could also build highly specialized L3s on top of its L2.
Our current payment for posting to Eth is shared amongst all transactions in a smaller sized batch and the fee is still lower than many other L2s — there remains capacity to increase batch sizes depending on configuration of Boojum.
All of the mentioned decisions regarding a Validium are feasible on the ZK Stack, however they are dependent on Celo’s priorities and timeline.
B) Decentralized sequencer
The detailed design provided in the original Celo forum post, which ensures Celo can use its existing pBFT consensus and maintain single block finality on the OP Stack, can also be made compatible for the ZK Stack.
With the new prover live, decentralizing the sequencer is next up on our development roadmap. We aim to be the first Layer 2 to implement a live decentralized sequencer design. This initial development will be live this fall on testnet.
C) Finality
The discussion around finality in the proposal specifically decouples the finality between transaction ordering and the new state of the chain after including transactions.
Again, the same proposed design of the Celo L2 client can be built with the ZK Stack. However, the ZK Stack can be considered more efficient than others options when it comes to finality of the new state of the chain being posted to Ethereum. This is because the Boojum system generates validity proofs and posts proofs to Ethereum very quickly.
Competing stacks either use fraud proofs (or have no live fraud proofs, but are meant to in the future). Due to the 7-day dispute period, as part of the fraud proof design, true finality cannot be trusted until this period is complete. There are a number of discussions on public forums we are sure the Celo team is aware of when it comes to tradeoffs between validity and fraud proofs.
D) CELO tokens as native currency on L2
This design can be implemented by nodes running the Celo L2 client. Specifically — the operators would need to be able to swap Celo to ETH (or simply ensure they are funded with ETH) prior to paying for submitting transactions to the L1.
A contingency in this design that we would be happy to discuss is specifically the process of providing liquidity and ensuring efficient quotes for the CELO/ETH pair. This is a problem increasing amount of non-ETH protocols are exploring and there are interesting design choices to be decided.
E) Cross-community collaboration, tooling and libraries
Regarding tooling and technical alignment, Era (and therefore the ZK Stack) is compatible with WEB3 API, and most of the geth methods - this means that any EVM wallet will also work out of the box. On top of that we support Hardhat and Foundry, and continuously work to integrate the most useful tooling in the EVM space (as well as providing other alternatives with enhanced features - as an example, our in-memory node that provides extended debug/tracing capabilities)
Additional Questions from zkSync
As Celo would require a hardfork into this system in order to ensure projects wouldn’t have to re-deploy their contracts:
- Does the team have a plan for how they’d migrate into an EVM equivalent system?
- Would the team consider potentially recompiling and redeploying contracts?
If the Celo team is interested in this proposition, we would be very excited to discuss more in-depth design details and/or comparisons to other stacks being considered.
Thank you for reading and we look forward to all constructive discussion and questions!
