Introduction
This post only focuses on zk-rollups. Thank you to Cooper Kunz and c-node for feedback which influenced edits made to the original draft. Thank you to @joshs, @pacu and @aquietinvestor for their review.
Zcash community –
This post is to solicit discussion and feedback around the possibility of Zcash deprecating the Zcash Layer 1 (L1) blockchain, and seeing the Zcash protocol become a Sovereign Rollup. In this design, Zcash will become a lightweight blockchain that sovereignly operates its own execution environment via a network of nodes, and posts state updates to another L1 blockchain for data availability.
This idea comes after my spending time working in the Ethereum/Modular blockchain space, specifically working on sequencer layers (block producers for rollups). In this post, I will outline some designs, discuss their tradeoffs, and share why I feel having Zcash become a sovereign rollup is the best path forward for the project and the ZEC token.
The post will focus on:
- Why Zcash should move away from being a L1
- The various architecture pieces for rollups and different designs
- Sovereign versus Smart Contract rollups
- Competitive landscape
- ZEC utility
- Path forward and call to action
This post does not suggest any change in Zcash’s mission to bring transactional privacy to cryptocurrencies. On the contrary, this move might make Zcash more accessible across a growing internet economy where developers are interested in a world of interoperable application-specific, sovereign blockchains. Positioning ZEC as the digital cash within this ecosystem is a strong narrative that could reignite attention to the project, and it also enables ZEC to have significantly less sell pressure and more utility. Other key benefits include:
- More accessibility for ZEC
- Stronger security for the Zcash payment protocol
- Opportunities to make design tradeoffs that L1s cannot enable
- More opportunities to collaborate with builders in a growing modular blockchain ecosystem
This post is originally inspired by Josh Swihart’s question in this Zcon town hall thread.
Background
Zcash is a L1 blockchain that is designed to enable private payments. It uses a Proof-of-Work (PoW) consensus algorithm, but is exploring a move to a hybrid Proof-of-Stake/Proof-of-Work model.
This initial research is beneficial because it gives Zcash strong finality guarantees. Finality is the assurance that your transaction will not be reverted. Proof-of-Stake (PoS) protocols offer stronger finality guarantees because the economic security is derived collateral put up by validators. If they maliciously try to revert a transaction, their stake will be slashed and they lose their money. Stronger finality can improve things like bridging. PoS is also argued to give the Zcash token more utility and have normal users earn rewards via DPoS/liquid staking protocols.
While this research is promising, I believe a move to a sovereign rollup has better long-term benefits for scaling, interoperability, and network effects, while still maintaining the decentralization and liveness of an external L1 (i.e. Celestia).
Regarding scalability, L1 blockchains are inhibited by the throughput they enable. In some of the proposed PoS algorithms, block times and finality are 10 seconds. That’s really fast! But, to maintain decentralization of the L1 protocol, you need to ensure that block sizes are low enough so you have enough validators able to participate in consensus and block production and also ensure that non-consensus participants can run a full node to verify the state of the blockchain. For a transparent blockchain with shielded payment pools, maintaining decentralization for block production and node operators is important because block producers can be pressured to not include shielded transactions. Additionally, liveness and dynamic availability are key properties that also require decentralization.
So even if you have fast block times and finality, you’re still bottlenecked by the amount of data the L1 can effectively process. This creates scalability issues in the event that Zcash sees more adoption. We saw some of these issues play out during the spam attack. Changing the consensus algorithm to PoS (in my opinion) does not solve these issues.
Additionally, Zcash was recently vulnerable to a 51% attack. While I understand a move to PoS might strengthen Zcash security short-term, I’m skeptical that the project can continue to bootstrap its own economic security as an independent Layer 1 protocol. To my knowledge, the current Proof-of-Stake algorithms ECC is reviewing wouldn’t see Zcash be victim to reorgs via an attack on the L1, but more rather liveness failures (which could lead to a socially led reorg via a fork).
What are rollups?
Rollups are Layer 2 (L2) blockchains that take transaction execution off the L1 blockchain offchain. This means they create “another blockchain” to handle execution. This blockchain can be a permissioned server, a permissioned, federated group of nodes, or a decentralized network.
So, we’re just taking execution offchain? Not quite. First, let’s go through how a transaction would happen in a PoS Zcash.
- User initiates a transaction with a client. I.e. Sending a shielded love note through Ywallet
- User generates a proof and the transaction is sent to the mempool
- Validator wins the right to build a block. Takes transactions in the mempool, orders them into a block, and proposes the state update to the network
- Validators review proposed block, accept the state update and finalize + settle the transactions
- Data is available for full nodes to download
In the modular ecosystem, the thesis is that you can break down these roles into different protocols. These protocols all have their own fancy term. We’ll focus on zk-rollups as Zcash already leverages zero-knowledge proofs.
- Execution (VM): the virtual environment within a blockchain where transactions are processed. It also determines rules for how the blockchain updates its state
- Sequencer: the role of including and ordering transactions in rollup blocks, and proposing them (aka block producer)
- Prover: the role of taking a proposed block, executing them, and compressing transaction data into a proof that proves that execution was done correctly
- Data availability: the role of receiving and storing the transaction data or state changes
- Settlement layer: the role of verifying a validity proof for execution of the rollup’s state transition function
So a now a transaction would look like:
- User submits transaction and generates proof (within the limits that the execution layer enables)
- The sequencer operator/protocol takes that transaction (w/ proof), orders it in a block and proposes it
- The prover takes the sequencer block, executes it, and creates a proof proving correct execution and the latest state update
- The state change and validity proof is sent to the L1 for data availability
- The settlement layer reads the proof to verify the latest state update [1]
Sovereign versus Smart Contract rollups
This section can be largely debated, and I’m not going to dive into definition wars here. To be honest, it’s all a bit fuzzy. A good way to look at it is that smart contract rollups are generally scaling solutions for Ethereum, and sovereign rollups are similar to L1s and appchains.
But we carry on!
Smart contract rollups are probably what most of you all are familiar with. These are how rollups operate on Ethereum.
Smart contract rollups verify their state updates with a smart contract that lives on the L1. After transactions are ordered into rollup blocks, and executed, a prover will submit a zero-knowledge proof to the L1, and a smart contract will read that proof and verify that the transactions were executed correctly. This is a great model if you want to directly align your protocol with a L1.
However, in this model, the community outsources its sovereignty to token-weighted voting governance processes. This is antithetical to decentralization, in my opinion, and creates perverse incentives for people who own massive amounts of the token supply. Tl;dr? The richest people make all of the decisions. So if you want to upgrade the chain, per se, who makes that decision? The people with the most tokens, not individual node operators. [2]
The section above is currently under review due to feedback mentioned in a response to this post.
So sovereignty?
Sovereign rollups operate similarly to smart contract rollups. The difference is that individual nodes are the ones that agree on the updated state of the blockchain.
So instead of a verifier in an L1 smart contract, nodes verify the zk-proof for each block, verify DA, and agree on the updated state of the rollup. There’s a couple benefits to this:
Currently, running a Zcash node is very difficult because it takes a lot of data. In sovereign rollups, you don’t need to download the full state of the rollup. You can use various models, like Data Availability Sampling and ZKP compression techniques, to make verifying the state of the Zcash protocol easier.
This means that it would be easier for people to run Zcash “nodes”, and increase decentralization of the protocol.
Also, when upgrading the protocol, the sovereign rollup would operate the same as a L1 protocol versus smart contract rollups. Development teams would propose new software updates, and nodes would agree to these updates by updating their node software to match the update. Super simple.
There are other arguments around economic sovereignty as well, but I want to focus solely on decentralization and how the protocol is upgraded.
Censorship resistance
In either of these models, you’re outsourcing some censorship resistance properties to other protocols. Let’s analyze some of the tradeoffs here:
Sequencer censorship
The sequencer is the role of receiving and ordering transactions within rollup blocks. They handle block production for rollups.
All rollups today use a centralized server that handles block production. If the sequencer wanted to, it could effectively censor any transaction that it wants [3]. This isn’t good!
But, you can work around this via a few different mechanisms:
- Use your data availability layer for sequencing. Likely the strongest for censorship resistance, but doesn’t give you pre-confirmations which lead to better speed
- Use an external consensus protocol for sequencing. There are protocols like Espresso and Astria that allow rollups to share a sequencer via a fast, decentralized protocol
- Build your own consensus protocol for sequencing which could lead to more token utility
- Use a centralized sequencer for pre-confirmations, but allow users to directly submit transactions to L1 if they need to
This design space is very large and all rollups today are looking to decentralize their sequencer operator.
It’s also been said that a centralized prover network can lead to censorship. You can decentralize the prover network as well, and people are exploring how you can build a single consensus protocol for sequencing and proving.
Layer 1 censorship
Let’s say we live in a world where the entire L1 is censoring the rollup and not allowing it to post its latest state update.
Let’s look at a few ways you could avoid this scenario. You could simply opt to using the most decentralized L1s for data availability, Bitcoin or maybe Ethereum. But, Ethereum has had issues with censorship due to the OFAC sanctioning of Tornado Cash, so having the rollup be managed by an L1 smart contract would not (in my opinion) be an optimal design for a Zcash rollup.
Sovereign rollups have more flexibility here because even if the L1 has censored the rollup entirely, the network of nodes can fork and choose a new DA layer. While I assume this would be a difficult process, it is much more preferable than having to reconstruct your design entirely because you can no longer operate with a smart contract on a censoring L1.
So in either model, you can mitigate against censorship by decentralizing the sequencer or enabling users to bypass the sequencer. But, this is going to be the standard across all rollups, so it doesn’t make the sovereign rollup design unique. An additional benefit for being a sovereign rollup is that you can fork DA layers in the event of censorship.
Again, I don’t think this is a major concern for this post, but wanted to clarify it anyways. It should also be noted that this type of censorship can be applied to Zcash anyways because validators would simply just produce blocks containing public transactions if a shielded transaction ban was applied in some way.
For the sake of brevity, I won’t dive any deeper into censorship resistance in this post, but it’s worth noting that censorship would have to be enforced across the entire shielded set because you can’t censor what you can’t see.
Competitive landscape
There are a few projects that are building privacy preserving Layer 2 solutions, but the space is still relatively small [4]. Today, there are no projects building privacy-preserving sovereign rollups.
In this space, it’s my hypothesis that Zcash would be more widely accepted if it could interoperate among a number of blockchains where sufficient liquidity already exists. To do this, it could create bridges with other rollup networks, perhaps using some zk-proof mechanism, to be able to leverage ZEC across a number of protocols. Or, it could leverage a shared sequencer protocol to guarantee cross-chain atomicity (inclusion is guaranteed, execution is guaranteed if users trust an honest builder or proposer) and cross-chain pre-confirmations with other rollups using the same sequencer. Other connected protocols could leverage ZSAs to privatize their assets for a specific use case.
And by having a more flexible design, Zcash could make design decisions that optimize for performance, and leverage a decentralized DA layer as a fall back network.
For example, Zcash could have near instant finality if it used a fast sequencer for pre-confirmations, which would improve its payment UX. If the sequencer started censoring users, the protocol could use the Layer 1 temporarily for block production and simply fork out the malicious sequencer through a protocol upgrade. DA Layers like Celestia already have similar block times to Zcash today, so this downgrade in performance would be no different than using an L1 Zcash.
This flexibility could see Zcash make different design tradeoffs and trust assumptions to improve performance, while still maintaining the security of the L1 protocol it’s integrated with.
This could give the protocol a competitive advantage when competing with Penumbra and Namada. Both protocols would offer similar execution environments to a Zcash rollup (assuming the Zcash rollup has added functionality via ZSAs, programmability, etc.), but the tradeoffs Zcash makes could see it optimize for different things that might be more desirable to a broader user base.
But what about other privacy-centric rollups? Again, the design space is so large that we could make different design choices to theirs and simply compete with them in the market.
What if Penumbra and/or Namada’s route of a L1 is best in the end?
Maybe it is. Maybe we lose. But in this direction, we at least try something novel and risk getting it right. More risk, but more reward!
ZEC utility
In the sovereign rollup model, the ZEC token would be the native token to the rollup/blockchain. We could use it to pay for gas for Zcash and ZSA transactions, and also use it to secure decentralized sequencer/prover networks [5]. Any network secured with the token would likely be a proof-of-stake model, which would decrease sell pressure on Zcash, give the token more utility, and have stakers earn rewards. You can also do delegated proof-of-stake, or liquid staking, to ensure normal users can stake their ZEC within specific pools or validators.
Moving to a rollup model is an extremely interesting proposition of the ZEC token. Moving to a sovereign rollup would drastically lower Zcash’s security budget (even more than a move to PoS). Validating blocks is expensive, and inflation might have to be the mechanism for which this cost is paid. This will certainly be the case in Zcash PoW, but I’d also argue it for PoS.
Moving to a sovereign rollup model could easily mitigate security concerns from the 21m supply cap. You could even implement fee mechanisms that burn tokens in certain environments leading to a deflationary narrative for Zcash. This narrative, along with significantly reduced sell pressure, could reverse the negative impacts of Zcash’s token issuance model.
In a world where ZEC can be used to pay for things in a vast rollup economy, and also be the gas token that powers private stablecoin sends and private swaps via a ZSA protocol? And that token is also paying out rewards to stakers? And the token supply is deflationary if the network is being used frequently?
Oh my!
A path forward
I’m interested in hearing feedback from the community around this idea. Note that I did not include any specific recommendations on design, as I am not a member of a Zcash development organization.
As a next step, I’d love to discuss some of these ideas on an upcoming Arborist call and simply hear feedback. I would also like to invite some more technically capable people to discuss some of the tradeoffs outlined here. I’ll also try to address any questions/feedback in this forum post.
I’m planning on attending Zeboot, and want to moderate a research discussion around this topic. It’d be great to host a livestream and/or Twitter Spaces with Zcash researchers and members of the modular blockchain community to discuss potential design tradeoffs here.
After analyzing feedback, I will work with members of the modular ecosystem in creating a formal proposal with a proposed architecture with concrete next steps included.
If there is negative feedback, or a lack of feedback, I will discuss other options to bring privacy to the modular blockchain ecosystem.
Thank you all for reading. I look forward to discussing this with you all.
Disclaimer: I work for Espresso Systems who are building the Espresso Sequencer, which is mentioned in this post. In this post, I am not advocating for any adoption of the sequencer, I am simply using it as an example I’m familiar with.
[1] Sovereign rollups don’t have a settlement layer, they just gossip the headers. I used the term settlement layer for familiarity: Setting up a Celestia light node | Celestia Docs (use their GPT and ask “What does “gossip the headers” mean?”)
[2] Aztec are currently reviewing ways to not solely rely on token voting for upgrades: https://forum.aztec.network/t/the-empire-stakes-back-again/2351
[3] Some L2s on Ethereum today fully inherit the security of the L1. This means that users can bypass the sequencer and have their transaction sequenced by the L1. When I say “effectively”, I mean that there is a high fee market on the L1, and many users can not pay the gas to get their transaction sequenced by the L1, leaving them effectively stuck in the L2: https://twitter.com/EspressoSys/status/1686851505339453440/video/1
[4] I would consider Aztec a competitor in the privacy rollup landscape, but perhaps not a direct competitor because the sovereign rollup design is quite different.
[5] I believe that using ZEC as the gas token is the most important thing we can do for its utility. Further discussions around design tradeoffs for token utility and interoperability are needed for sequencer and prover network design choices.
.
