There was a recent comment made by Gregory Maxwell regarding Confidential Transactions vs ZCash pruning and performance:
CT is currently faster to verify, though its pretty close in that metric. The rest of what you said holds. The size difference isn’t quite so clear cut: not every CT transaction needs a proof (only ones that split coins do), and 80% of the CT proof size can be used to communicate private metadata to the far end.
CT+CJ (and CT+OWAS, which isn’t well known yet) is also fundamentally pruning compatible while ZC depends on ever-growing accumulators to track spendable/spent coins. This, even more than the new cryptographic assumptions made by ZC, is why I think that the CT+CJ approach is interesting, important, and more practical-- even though it provides a smaller anonymity set.
Thanks, @anonymous. I agree with Greg that Zcash, in the current protocol, depends on ever-growing accumulators to track spendable/spent coins.
In practical terms, I don’t think it is an urgent problem, though. Making some generous assumptions about how many transactions people would make with Zcash (i.e. that they would basically max out its current transactions-per-second limitations), I think it would probably be at least several decades, if not a century, before the size of the accumulators became a critical problem.
Note that as far as I understand, the spent-notes accumulator is basically equivalent, in terms of its scaling consequences, to the current Bitcoin blockchain. Greg is, if I understand correctly, contrasting Zcash with a possible future optimization in which pruning is added to Bitcoin.
I think we should go ahead and deploy Zcash-1.0 using the current protocol and then work on scalability improvements. Note that the accumulators are only one of many kinds of scalability issues that Zcash will face if it grows big enough and lives long enough, and maybe not the first one we would start running up against.
In parallel with our deployment of Zcash-1.0 there are several other research efforts for widening the performance and scalability bottlenecks: the CT-derived ideas that Greg is mentioning in the quote you gave, various ideas we have about how to widen Zcash in the future, plus more ambitious and far-flung ideas about replacing various sorts of growing data structures with SNARK-proofs that the new, fixed-size, data-structure is valid according to what it ought to contain if you used a growing-sized data structure to validate it.
I believe you will come to realize eventually that the main issue with scalability is not the block chain storage size but the fact that verification MUST be centralized. Once you come to that realization, you will eventually end up with my conclusion as to the only possible solution. A recent discussion about how Satoshi’s PoW design does not solve the Byzantine Generals Problem[1] is relevant to capitulating to this realization. Note also the irreparable flaw in Segregated Witness.
As for " ambitious and far-flung ideas", I am interested in the asymmetry of proving and verification time in zk-snarks w.r.t. to smart contracts. Afaics, a smart contract can be run externally and proved, then the verifier has a much lower cost. Since 2014, I was pointing out the Ethereum did not solve the fundamental issue of scaling verification for long-running scripts (and still hasn’t and I assert aren’t even headed in the direction of solving it with shards, consensus-by-betting, and Casper).
Zooko mentioned Bitcoin pruning is a “future optimization” and I wanted to point out that it is a feature in the latest release (linked below).
Also he makes the excellent point that we’ll run into a variety of scaling constraints. One thing to keep in mind is that usage patterns of Zcash may be notably different than Bitcoin, so we also shouldn’t assume we’ll hit the same scaling issues in the same order.
