pull down to refresh
yes, I do know of the nullifier set
in fact, when we analyzed zCash as a sidechain, one of the arguments I presented was : "every now and then, we can just start over with a new zCash-L2, and abandon the old one when the nullifier set gets too big"
So - it sounds great.
OK, I also wanted to ask that: if you thought it was a sound strategy to just have a bunch of ephemeral blockchains we can abandon, but I guess Thunder is already proposed as that.
That brings me to the next question: why not use Zcash sidechains as the payment scaling solution instead of Thunder?
(I know you'll say you don't make the rules and it is a possibility, but what is your opinion?)
Well, thunder has been tested and optimized for throughput.
Maybe other L2s would also be tested and optimized for similar levels of throughput.
In current Zcash (both Orchard, Ironwood and previous pools) nodes have to keep a live index (that is searched for every transaction) of a random nullifier in order to prevent double spends, like a UTXO set that never shrinks, only increases on every transaction. Of course this scales horribly.
These are the stated reasons from Sean Bowe on why he is working on Tachyon, and he says this is a problem they always knew they had to solve one day.
More information: https://ggutoski.github.io/shielded-csv-tachyon/