But @ebfull , it isn’t like with Sapling. Sapling is brilliant but it was a very straightforwards approach: make one piece of Zcash go faster. It was like switching to a faster processor. Nothing else in Zcash needed to changed. That isn’t true here.
In order to take advantage of Halo, things need to change. Even to keep existing performance and not make Zcash slower, it seems things need to change. You aren’t saying you have gotten individual halo tx size and verification time down to something like sapling, right?
Cocktail napkin math, what are we talking about for size and time?
And what about Eran’s very real issues with batching ?
For everyone else reading this and wondering whats going on:
Halo isn’t a drop in replacement for our existing zero-knowledge proofs. Far from it.
What Zcash really?
Zcash is pretty simple. Take a bitcoin payment and instead of saying this previous payment(UTXO) is where I got the money I’m spending money from, you replace it with a zero-knowledge proof that the money exists. Since the proof hides which money you are spending, you get privacy. The proof is constant size and fast to verify. Because of this it is really not much different than an ECDSA signature in Bitcoin as far as the blockchain itself goes. So integrating it is merely (a lot of and very tricky) software engineering. I say this as the guy who worked this all out and did that engineering originally on the paper and prototype of Zerocash. This became Zcash and @ebfull and @daira rightly re-did that software from scratch much better. Eran was on that paper with me, I remember working out this stuff with him and what my co-authors and I invented has been the way Zcash has operated since. The downside of all of this is the snark we use (now groth16 then BCTV14b) requires a multi party setup assumption. Ideally you’d like to replace it with something else.
Whats Halo?
So that’s Halo right? Well, in a word, sorta. Halo isn’t just a zksnark without trusted setup. In fact, it is not really a zksnark in that an individual proof is not fully succinct. So proofs are big and take longer time to verify. If you just dropped those into Zcash, it would almost certainly get slower. We’d be less scalable. Consensus might even get tricky. The brilliant part of Halo is that if you take a bunch of those proofs, say a whole block full of halo shielded transactions, you can do some fancy things to combine them (either aggregation or recursion) and wind up with something that is not as expensive to verify as all of those individual halo transactions. But you have to change Zcash to have it do aggregation/recursion somewhere. that’s a consensus change in all likelihood. And doing recursion is computationally expensive, so its a tricky one.
Whats the problem?
But there’s this thing Eran and I and others cannot figure out: where do you do aggregation/recursion and how does it make zcash more scalable? And keep in mind, we are the people who worked out the original Zerocash design — fully succinct snark instead of a pointer to a UTXO and an ECDSA signature – that Zcash uses to this day. This doesn’t mean Halo for Zcash is impossible, but its a pretty good hint there a hell of a lot that needs to be worked out and it might not even work. These cannot be hand waved over. They need to be set out clearly.
Whats needed
@daira suggests batching, But as Eran points out, there are number of places where you need to verify transactions and batching is tricky to do. So, how do we deal with that and the other issues that pop up? We don’t need code or detailed specs, just something that would pass a white board discussion amongst experts. Like I did when I worked out the approach Zcash still uses and @ebfull did for Sapling’s optimizations. And those were simpler systems!
