Using Halo/Halo 2 for short-term improvements to Zcash's Scalability

One of the stated goals around the ECC’s work on Halo and Halo 2 is to bring scalability to Zcash. However, as brought up by many in the community, it is currently unclear what that roadmap looks like and how exactly will the ECC’s work on recursive composition of SNARKs without trusted setups will be integrated in a future Zcash upgrade.

Even though the work around Halo/Halo 2 is currently in-progress, I think there might be ways for Zcash users to get use of out of this cutting-edge research sooner than later.

Here are a few potential uses of Halo/Halo 2 that the Zcash community might appreciate:

  • L2 scalability for both transparent and shielded transactions: Recursive SNARKs are a great tool for compression as seen by the work of Mina, Matter Labs, etc. For Zcash, in particular, it can be used to aggregate multiple transactions into 1 transactions that ascertains the validity of all the aggregated transactions. Of course, in order to solve the data availability problem, Zcash would need to provide opcodes that make it easier to store data on-chain (perhaps through ZTEs). Pretty much, what I’m suggesting is using Halo/Halo 2 for zk-rollups. That way Zcash users don’t need to wait for a risky L1 upgrade in order to get the scalability benefits of Halo/Halo 2. Not to mention, the current scalability schemes that are in production right now on Ethereum are mostly zk-rollups.
  • Improve full node syncing speed and requirements: Currently, in order to be a full node, one needs to sync the entire Zcash chain from start to finish. There are indeed a few optimization modes that clients can use depending on their trust assumptions but these are kind of suboptimal. Instead, Halo/Halo 2 can be used to provide proofs that full nodes are on the correct chain and increase the speed at which they need to sync up their nodes. A side effect of using Halo/Halo 2 in this way is that it could help increase the number of nodes running on the network which has other benefits. An unknown to this is that it might require that full nodes need specialized equipment to produce these proofs and verify them.
  • Improve light node syncing speed and requirements: This ties into the previous point but instead of syncing up to an entire chain, light clients might perhaps be satisfied with a recent proof that ascertains the validity of the chain from genesis to a recent block. Again, it is unknown what it would take to run Halo/Halo 2 verifiers on a resource-constrained device.

Any feedback is appreciated.


Great ideas! Hope we’ll have teams applying for Zgrants to tackle these ideas.

@Mikerah would you like working on your ideas?


I was literally about to describe these kinds of uses to @gmale in Slack, and then refreshed the forum and saw this post :smile:

It’s already very easy to store data on-chain (too easy, some would argue), so I don’t see this as a blocker. I’d personally prefer that this not be stored on-chain though.

Note that people can start building fast-sync nodes now using FlyClient, which is already deployed. It provides a weaker guarantee of chain correctness than a recursive proof would, but a stronger guarantee than current light clients rely on.


My team at HashCloak is quite small and we lack a lot of funding to work on these ideas. Considering that Halo/Halo 2 is in the realm of the ECC, I think the people in the best position to work on this would be the ECC.


Data for zk-rollups need to be in a format that lends itself to be easily verified. There might be a way to make this easier through an upgrade. If this were to be done, then there would be a community wide understanding that this feature is to be used to this use case. That being said, considering the lack of data availability layers in the blockchain space (LazyLedger is working on this), it makes sense to have a Zcash-centric solution this i.e. just store the data on Zcash.

I’m aware. Didn’t the original demo of Halo include recursively checking flyclient blocks or was it simply Bitcoin blocks?

Did @gmale also ask about where recursive proofs would be used?


@Mikerah I was responding in another thread and that made me think about how we might move beyond lightwalletd, which falls under your 3rd potential use:

Improve light node syncing speed and requirements

It seems like Halo 2 would make it easier to create side chains because no trusted setup is required. The idea of a very lightweight, private, single-purpose side chain is very interesting for light clients.


We’ll actually have an update on how Halo 2 can be integrated into Zcash in a future NU later this quarter.


How will NU5 improve Zcash’s ability to scale when compared to XMR/BTC?


I have not found a more suitable topic for my message. But if there is one, please move it there.

I have seen messages from one of the blockchain development teams mentioned at the beginning of the topic, which promises its users a lightweight chain.

Today, the Zcash blockchain is experiencing a load that we have never encountered before. As a result, the chain size increases daily by 600 - 1000 MB of data. And although today it’s still 50+ gigabytes, we don’t know how long it will last. Potentially, the blockchain can reach a similar volume with the Ethereum network in about 1.5 years, which cannot be logical from the point of view of the layman.

This in general cannot but upset me for some reasons.
I have a couple of computers with nodes on Zebra and Zcashd. At this rate of growth in the volume of the chain, the question of stopping one of the nodes will arise in about six months. I will keep one node in principle at any volume. However, I do not know how many people are willing to incur additional costs. We don’t have thousands of nodes all over the world so that we can’t be indifferent in this problem.

My question is, does Halo2 solve this problem in the long run?


How is Aleo different from ZK projects like Zcash? One of the key differences in AleoHQ is that we support recursion… :eyes: