The team at zkSync has been following discussions across different forum posts regarding Celo’s L2 stack decision. Recently most of the key discussion points were consolidated quite well in the roadmap update. The purpose of this post is to address these broader topics in regards to the ZK Stack, with the goal of educating the Celo community on how ZK Stack features can help you reach these milestones.
Before diving in, we strongly recommend everyone reads our initial post — this is divided into a section discussing ZK Stack benefits and a section directly applying how these features may serve CEL2.
As @valentin referenced in the original timeline post, we would be glad to join any community calls on CEL2 in late November. In addition to addressing questions in the comments below, we are also open to address questions in an AMA format with our BD, product and/or engineering teams.
Additionally, the Matter Labs engineering team will be at DevConnect and will host a session with cLabs to walk through the ZK Stack in person — for any core developers or projects interested in joining please feel free to reach out via TG (@mylesro).
We also invite you to other community events at DevConnect — please use this calendar for all zkSync events.
You can join us for some free coffee or local goods at the zkBazaar and Cafe. These experiences will display the first ever live use of a smart contract wallet directly secured by a mobile device (presented by the Clave team). This may be especially interesting in the context of Celo’s Social Connect protocol.
Using broader forum discussion and most recently the CEL2 Roadmap Update, this post will address the following priority topics (in no order):
-
Data availability
-
Celo token and ERC20 gas
-
Decentralized sequencer, consensus & 1-block finality
-
Transaction fees
1) Data Availability with the ZK Stack
How can Celo maintain an off-chain DA layer? Can it use EigenDA? What does ZK Stack offer for data availability?
The zkSync team has previously run a Validium mode for a ZK Stack partner, and plans to release this implementation to the public within the next 2-3 weeks.
The Validium option will allow any operator of a hyperchain to use their own private server as a DA layer. This can be made configurable so that any external DA layer can be utilized, including Celestia or EigenDA.
We would be glad to work with cLabs to test this implementation and coordinate with a separate DA provider once released.
It is also worth noting that we have plans to expand DA options to include a design we call zkPorter (or if you are familiar, this has been referred to as a Volition). In this DA model, applications and/or users have the choice to pick whether they want to pay for full ETH security on their data, or if they’d like it to be routed to a separately run zkPorter service.
More on Data Availability can be found in this section of our documentation.
2) Non-ETH Gas and CELO Native Token
Can we implement Celo as a native token? How does native AA make it easier for Celo to be used as a gas token?
The stack also addresses the deliverable of Celo Token-Duality. It will be customized to include non-ETH native tokens, and this can be done to include the CELO token. We are currently developing a similar implementation with another Alt-L1 that is customizing their own Layer 2 as an early ZK Stack partner.
In order to enable ERC20 gas and richer transactions, Celo will require some form of a Paymaster to play the role of handling gas payments and swapping these to ETH. The details of this implementation for Celo are fully customizable and require the community and cLabs’ input — you can implement a Paymaster for each individual dApp, or (for example) you can customize the entire chain itself so all transactions rely on a specific Paymaster built to enable cUSD-denominated gas.
Most importantly, though, the ZK Stack is specially designed so that it is easier to execute transactions using ERC20 tokens. This is because the ZK Stack has implemented native Account Abstraction. This is unlike any other L2 Celo is considering and is an important distinction from EIP-4337 Account Abstraction.
The ZK Stack treats both EOA and Smart Contract Accounts (SCAs) the same — and because they use the same mempool when submitting transactions, they can also both access Paymasters:
The above works because the ZK Stack has a dependency field in all transactions to include a Paymaster address. Ideally, ETH L1 would also include this feature, but it is not the easiest feat to make ETH protocol changes. This is just one benefit of having native Account Abstraction.
The experience is broken if Celo aims to enable this support for EOAs since this is not possible with EIP 4337. The Paymaster functionality in 4337 for Smart Contract Accounts requires a separate third-party operator and mempool:
All of the above is to show that the existing user and developer experience can remain intact when adding ERC20 gas payments to Celo’s chain. We are aware this is a necessity for many Celo applications, like Opera’s MiniPay. If you want to play around with this, you can build a custom paymaster using USDC in our tutorial today.
3) Decentralized Sequencer, Consensus Design and Single Block Finality with ZK Stack
Although these subjects are split between CEL2 milestones 3 and 5 in the roadmap, they are together addressed with plans actively in development on the ZK Stack. We will be sharing more information on this topic fairly soon.
4) Transaction Fees
In specific response to Valentin’s post that mentions the requirement of sub-cent transaction fees, and response’s (e.g. from @hhe) questioning the ability to execute this, we would like to discuss design options that can make this possible with the ZK Stack.
The stack is meant to be optimized for specific use cases; some apps may want more sovereignty, privacy or speed, while others prioritize the cheapest possible fees. For micropayment applications that require sub-cent fees, we can commit to working with those applications to set up testing environments to demonstrate how the stack can be optimized for this.
As we mentioned above, we will soon release the Validium DA option which you can customize to test the role of what a future DA solution may require for fees (in its current state, EigenDA is not live and fees are not determined).
If using a DA solution alone does not provide the fees that the app requires, you can explore customizations on the prover side of the stack. With the new Boojum proof system live, ZK Stack builders can utilize the power of recursive ZK proofs and batch size customization. The current design for fees splits the transaction cost of a proof across all transactions in the batch. This is set up so you can significantly expand batch sizes, and the more transactions that are included in the batch the lower you can bring down costs.
Our team is more than happy to set up a full production grade testnet with live Boojum provers for the cLabs teams’ own testing purposes.
Moving Forward
We are excited to work with the foundation, community and cLabs team to educate everyone on the ZK Stack and hope this post addresses a few of the key topics.
Again, if you are in Istanbul we encourage anyone from the Celo community to stop by one of our events!