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.