Zcash NU7 into a JAM service

Community Collaborations
1

NU7 (ZSA + swap) for private stable coin transfers situated in a Zashi app (or Zashi-like app) is extremely important and timely.

This fall our team (a JAM implementation team) turned NU7 into a JAM service (JAM is a new protocol from the Polkadot ecosystem) to really put our JAM implementation to use. We were amazed at easy it was to make into a JAM Service given all the implementation work from QED-it following NU7 ZIPs.

Having a NU7 JAM Service could support completely different path for Zcash to get away from proof-of-work, get very high throughput and much faster “real” finality, etc. but at the very least can give a different home for testing Zcash NU7 functionality in the next 6-18 months. I am not aware of ZEC being “wrapped” in too many other places, but probably there can be a “tZEC” equivalent of “tBTC” that connects the dots somehow rather than us exporting NU7.

It would help to have collaborations with Zcash teams who want to explore very different “next gen” tech stacks with us, maybe culminating in a Zashi fork that connects to a NU7 JAM service.

3 Likes
Why I'm Against ZSAs
Should Zcash have privacy pools?
Executive Summary: Zcash NSM and Dynamic Fees Discussion
Why I Support ZSAs
2

This is cool technically but I keep coming back to one question: what’s actually in it for Zcash?

You’re talking about moving execution to JAM, which means Zcash’s privacy layer would depend on Polkadot validators. We’re already working toward our own PoS transition (Crosslink etc), so the question becomes: why use someone else’s validator set instead of building our own? What do we gain that’s worth that dependency?

And I’m not sure how this fits with Tachyon. Sean’s already addressing scaling and sync natively. Is this complementary to that work or kind of competing with it?

I guess what I’m really asking is whether this helps Zcash or whether it mostly helps JAM/Polkadot by importing our privacy tech. A Zashi fork connecting to JAM sounds like it could fragment the ecosystem rather than strengthen it.

Not trying to be hostile, the parallel ZK verification stuff is genuinely interesting. But the pitch needs to be sharper on why Zcash stakeholders should care. What do ZEC holders get that we couldn’t get by just improving Zcash itself?

Also curious how far this is from production and who would realistically fund and maintain it.

4 Likes
3

JAM is optimized to be a rollup host, and a Nu7+Tachyon rollup host specifically. It factorizes consensus (Zcash PoW=>Crosslink) from execution (Orchard=>Nu7+Tachyon) a bit differently to run an audit protocol across some number of cores. Fundamentally, because each core can validate a different part of a rollup’s state transition (verifying recursive proofs, in Tachyon), you win a lot of parallel zk proving across as many as 341 cores.

A Tachyon JAM service, combined with an updated Zashi wallet that interacts with a oblivious sync service, is extremely well-suited to generate proofs of validity + finality at high throughput. The rollup block builders will submitting work packages to JAM, because they are literally operating the oblivious sync mixnet.

We should develop a Zcash JAM testnet instance, running a Nu7+Tachyon service, targeting 10-100x throughput improvement via 341-core parallel execution over alternatives. If our testnet validation confirms these gains (as we would expect/hope!), the Zcash community could prioritize a JAM path over Crosslink. We could hope that Zcash rollups proliferate in 2026-2030 the way EVM rollups did in the 2021-2025 due to: faster finality, composability with other rollups (EVM rollups right next to Zcash rollups), and real privacy (Nu7+Tachyon).

Zcash JAM + Polkadot JAM + other JAM can form a “JAM Grid”, forwarding verifiably finalized work (concerning the validity+finality of the rollups each JAM instance hosts) to one another. And, of course JAM bring together multiple rollups (Zcash + EVM + …) together in the same JAM instance, or across instances.

I’m sure Polkadot would like CoreTime demand from Zcash rollups, but I don’t think Zcash should be an L2 to another eco’s L1. Zcash should have its own Zcash JAM instance, with its own validators staking ZEC instead of DOT, its own validator selection, inflation/burn/fee policy configured separately, and its own rollup ecosystem. Instead of using Polkadot’s validators, JAM open source tech can be used run Zcash’s own rollup network the way the Zcash community wants to. JAM DA becomes Zcash DA within the Zcash JAM instance for Zcash and non-Zcash rollups alike.

Right now our JAM NU7 Service is just validating work packages containing bundles of Orchard ZSA transactions (issuance of new assets, shielded transfers, swaps).

A JAM NU7+Tachyon Service PoC development path would be:
(1) Map Ragu Rust (Sean’s IVC accumulator implementation) into JAM refine PVM to generate proofs of validity
(2) Map Zcash oblivious sync into a JAM builder for Tachyon work packages
(3) Adjust Zashi wallet to generate IVC-native bundles

Re “funding”:

  • from the JAM ecosystem, JAM builders (15+ teams) are supported by milestone-based JAM prize, providing client diversity to all JAM instance and potential “oblivious” builder mixnet for Zcash rollups
  • from the Zcash ecosystem, ideally we could get whichever teams to do (1)+(2)+(3) to be well-supported enough to see a PoC to success.

Does this make sense? If not, what does?

4

Ok this makes more sense. If I’m understanding correctly: Zcash would run its own JAM instance with ZEC stakers, own governance, own fee policy. JAM becomes infrastructure you fork, not a chain you depend on. That addresses the sovereignty concern.

The part I’m still chewing on is what this unlocks beyond “faster Zcash.”

We’re getting ZSAs with NU7, so multi-asset shielding is coming regardless. But that capability is only as useful as the assets that actually flow in. Zcash doesn’t have DeFi, doesn’t have stablecoins, doesn’t have the liquidity that lives on Ethereum or elsewhere. If JAM Grid means real bridges to ecosystems where those assets actually exist, then ZSAs go from “cool feature” to “privacy infrastructure for everything.”

Is that the vision? And if so, what do those bridges actually look like?

1 Like
Why I'm Against ZSAs
Why I'm Against ZSAs
5

Bumping this. My bridge question never got answered @sourabhniyogi.

You addressed the sovereignty concern. Own JAM instance, ZEC stakers, own governance. Good. But then I asked what the bridges look like and the thread went quiet.

That’s the whole value proposition. ZSAs without liquidity are a feature nobody uses. If JAM Grid connects Zcash to ecosystems where assets actually live, that’s interesting. If it doesn’t, we’re just talking about faster Zcash.

So: what do the bridges actually look like? How does value flow between a Zcash JAM instance and other JAM instances or external chains?

A few more things while I’m here.

Zcash is already working toward PoS via Crosslink. Why should the community evaluate JAM as an alternative? What does JAM offer that Crosslink doesn’t? Has anyone mapped out the tradeoffs?

You outlined a dev path. Map Ragu Rust into JAM, map oblivious sync into a builder, adjust Zashi. Who actually does that? Your team? Zcash teams? What’s the timeline if funding appeared tomorrow?

You mentioned JAM prize for the JAM side and “ideally well-supported” for the Zcash side. Is there a grant proposal? A ZCG ask? Or is this exploratory until someone steps up?

Is this a serious proposal the community should evaluate against Crosslink? Or an interesting exploration that might become serious later?

Either answer is fine. Clarity helps everyone figure out where to put attention.

6

Oh thank you for the ping! I wanted a real proof of concept coded up but I’ll just jot down where we are =)

An EVM JAM service as the generic front door for stablecoin/RWA asset issuers to do their burn-and-mint pattern CCTP-style between chains, if the CEX-to-chain isn’t viable (the dominant “bridge”, if we are being honest about how normie non-cypherpunks think). For other cases, we hope tBTC, tZEC equivalents work with Hyperbridge type relayers that use each chains provenance to have actually trustless bridges. For better or worse, in this decade EVM is the QWERTY keyboard for those trustless bridges, as the “corp chains” data shows you.

Next gen privacy-preserving JAM services (Zcash’s Nu7/ZSA v6 protcol, Monero’s FCMP++) can use JAM’s “deferred transfers” to shield/unshield assets from that EVM service. At the end of the day a JAM instance needs a native asset for those deferred transfers: Polkadot JAM will use DOT, Zcash JAM could use tZEC, but it could also use zUSD as a better UX for normie non-cypherpunks. Now that we have 3 different services we’re trying to figure this exact question out.

The fact that you can shield centrally issued USD on Ethereum into Railgun should give everyone an expectation that a centrally issued USD going into a Nu7/ZSA protocol somewhere is basically inevitable.

JAM just so happens to be able to bring EVM + Zcash + Monero + Solana + … rollups in one place, which we gather will be a first like Tachyon and many other Zcash innovations.

For JAM-to-JAM transfers, you’ll need a BLS aggregate signature of proof-of-burn coming out one rollup JAM instance’s outgoing messaging queue and going into another JAM instance’s work package as an extrinsic or more likely a inter-JAM rollup messaging service. This is just an educated guess – the architect envisions a JAM grid of work report forwarding.

Our expectation is that Tachyon scalability designs, like EVM, will have multiple homes in scalable privacy-preserving rollup hosts with fast finality. Our asks:

  1. A tZEC and zUSD plan for ZCash rollup hosts that ideally creates demand for ZEC outside the “private transfers” use case;
  2. A privacy pools design from Zcash protocol engineers that goes into Tachyon/Nu8 to support the above

We look forward to building an Tachyon JAM service this Spring/Summer – its 100x easier to stand up a JAM rollup that hosts future Zcash (Nu7/ZSA vs Tachyon) than to support 100% of Zcash past (v4/v5/PoW/sandblasting etc) and the wild Crosslink.

You can call this exploratory, but I will be setting up a JAM DUNA to support JAM builders building sustainable JAM services this year, where unique privacy-first rollup services can compose with EVM/… rollups. There are 15+ teams (good guy indie types, with diverse talents) that will have “light clients” (in 10 languages) that probably composes the rollup block building and Tachyon oblivious syncing service with a business model that can work sustainably. The spirit is: alone, we can do so little, but together we can do so much =)

2 Likes