Grant Application: Tensor-Core Accelerated Proving for Orchard/Ironwood

Community Grants Applications
1

Hey everyone, we’re putting in a Zcash Community Grants application for something we’ve been calling “tensor-accelerated Orchard proving,” and wanted to share it here for community feedback.

The short version: Zcash’s Orchard and Ironwood provers use the Pasta curves with a zero-trust setup (no more Groth16 trusted setups), which was a huge win for decentralisation but came with a MASSIVE performance penalty: proving times went from decimals to single-digit seconds, and throughput dropped to around 0.2 TPS on CPU. The bottleneck is the multi-scalar multiplication (MSM) and NTT inside the proving pipeline.

Not to mention there are no baseline SIMT provers for Orchard yet either, so we will write them too as a part of this grant.

The proposal is to take the WGMMA (warp-group matrix multiply-accumulate) optimisations from the TensorZKP paper and apply them to Pasta curves on Hopper H100s. The idea is to decompose each 255-bit Pallas field element into U8 sub-limbs, feed them through the tensor cores that normally do AI inference, then reconstruct clean field elements via Barrett reduction on the SIMT units.

The hard part: WGMMA gives you a dirty S32 accumulator with partial products, not a clean field element. The carry chain post-processing is the make-or-break step, since if the Barrett reduction is too expensive, it eats into the tensor core gains. We think the 8-limb Pallas layout keeps this manageable (~50% less sequential work vs 12-limb BLS curves), but we won’t know for sure until the kernel is running.

We’re targeting 1.5x-2x speedup on H100 GPUs, with an optional extension to consumer RTX cards if WMMA (the less-efficient but more available tensor core path) works out. If it doesn’t, and the bandwidth limits on consumer hardware might eat the gains… we’ll publish the bottleneck characterisation so the next person doesn’t waste time on the same dead end.

We already have a working baseline: a CUDA Pippenger MSM for BLS12-381 with per-stage profiling, and WGMMA sumcheck kernels using TMA descriptors. This grant would let us adapt that work to Pasta curves and deliver the optimised provers back to the ecosystem.

The full proposal is here: Grant Application - TensorZKP-based Orchard Prover to speed up zCash shielded transactions · Issue #355 · ZcashCommunityGrants/zcashcommunitygrants · GitHub

We’d love feedback on this.

Thanks in advance for any thoughts!

4 Likes
2

Do the H100 targeted gains reach the phones everyday wallet users prove on, or is the speedup mostly for server side and batch proving until the consumer RTX path lands?

3

Unfortunately, they do not (they are Hopper-specific, and moreso, CUDA-specific), but even if the consumer RTX path fails to reach full optimisation, the SIMT prover is still expected to massively boost proving times for consumers with RTX-series GPUs without even using Tensor optimisations.

This has the potential to make projects like the one grant I recently saw, Ursa Chat, much more feasible for people with GPUs by accelerating proving times by magnitudes.

4

However, as for benefits that directly affect end-users, when exchanges want to send you shielded ZEC, they cannot do so fast-enough. Most exchanges have maybe 10-30 TPS on that sending capacity tops. This allows THEM to boost that capacity, allowing ZEC to flow through ecosystems much faster.

Similarly, you cannot afford a H100, but massive quant firms and relay traders do. This can allow for much faster intent-based cross-chain interoperability (think like LayerZero, but ZEC-compatible) or Across/Relay protocol swaps, which rely on the relayer generating transactions and broadcasting them on-chain.

5

The exchange capacity answer is the one that lands for me, since a user receives shielded ZEC faster when the sender proves faster. If the gains concentrate server side, does that push wallets toward delegated proving, and what keeps local proving on a phone worth doing?

6

Privacy, mostly, but to be honest our team has not approached the specific tradeoffs of server vs client proving. Our field of work deals with improving proving in general. However, now to think about it, I guess delegated proving, already implemented via DPT (or ZK-MPC), could also potentially be improved with this prover optimisation, especially if they are sufficiently cross-compatible.

But that is a future roadmap entry at best, and not something we would like to focus as-is right now due to scope creep.

7

I did some research into this topic here

Zcash doesn’t obviously need proof acceleration for all existing protocols but it might have a role in batch proving for Tachyon Oblivious Sync server at scale. I think it is a bit early in the development of the oblivious sync server to discuss this.

2 Likes
8

Indeed, our optimisations are for the Pasta curves as a whole on H100 GPUs. As long as the curves are retained (which they are, as Tachyon still uses Pedersen commitments, Pallas curves and other existing methodology), I believe our work would be cross-compatible with Tachyon as well.

As I believe Tachyon performs the majority of the work at the application layer, not the fundamental cryptographic layer, I am inclined to believe that our contributions will not get lost with time as Tachyon is implemented.

9

Saying server versus client proving sits outside your scope makes this application more credible.

10

Speaking of use cases, a colleague recently showed me oracles that apparently power much of DeFi on other chains like Ethereum, they rely on fast transaction times in order to be able to submit information before they are outdated, as well as interactivity protocols like VDF powered true randomness. Right now, given a CPU-bound prover can achieve only 5-12 second shielded transaction creation, an oracle’s information is outdated by the time they send the transaction, making them effectively infeasible to do. Our approach may also solve, or at least, create the map to solve such issues by others building on our work.

EDIT: Never mind, shielded DeFi is like the worst idea ever, so disregard this. I don’t know why I decided to write this comment.

1 Like
11

This is very cool. I cannot help but feel that it is a bit early for Zcash to be able to benefit from GPU-accelerated proving, however.

A business must be sending a very large amount of transactions for GPU acceleration to be of benefit, and even then, it may only provide a marginal speed-up that is not worth the cost of renting GPUs.

At first thought exchanges sound like a potential user of GPU accelerated Zcash transactions, but they are very hard to convince to run any new or “unofficial” software, and many rely on proprietary HSMs for key storage, based on their existing Bitcoin key storage approaches. This is why most exchanges end up using T addresses.

I think this project would be more compelling if you had buy-in from an initial large Zcash user that has agreed to trial a GPU implementation, also if you could provide benchmarks illustrating the speedup possible, and if you completed the work first and applied retroactively for funding.

Thank you for participating in our community and I do hope that you build it. I am just not convinced that we have any users that would benefit from this optimization yet.

12

Based on community feedback, we do recognise that, which is why we are instead researching AMX-based optimisations on M-series and A-series Apple devices, based on the work of Peter Cawley. We are reasonably confident that we will succeed in demonstrating a speedup on general user devices, in which case, we will publish a paper and update this proposal. Thank you!

2 Likes
13

Based on We just achieved a double speedup over the SoTA (pasta_curves) for batched same-base MSM for Halo2 on Apple Silicon! , we are formally deciding to either amend this grant, or submit a new grant.

We are going with the former.

We just achieved a double speedup over the SoTA (pasta_curves) for batched same-base MSM for Halo2 on Apple Silicon!