It’s worth noting that ZEC Sapling z2z’s large size is in part due to the fixed memo field per output, which doesn’t have any effect on the chain privacy that zk-SNARKs provide. Without that (still having encCiphertext for in-band note distribution but without the 512-byte memo), ZEC would be down around 17 on your chainsize chart.
(There are also other transaction-size inefficiencies that we plan to address in later upgrades, but I presume other chains have similar inefficiencies, whereas ZEC is AFAIK the only listed coin that has built-in memo fields; subtracting them out provides a more accurate comparision of the underlying tech.)
As for a potential Halo2-based Pollard protocol, it will sit on the same privacy row as Sapling (being derived from it). I don’t know what the proof size will end up being yet, but we can do some rough estimation to guess where it would end up on the chainsize axis.
The base transaction without proofs and without memo field contributions will be around 800 bytes for 2-in 2-out, and there will be probably a few kB of proofs on top of that. Then we can make some more assumptions to guess the chainsize position:
- Assuming Halo2 without recursion, Pollard would end up further to the right than Sapling (guessing probably >30).
- Assuming Halo2 with recursion (which is the end goal), and assuming that aggregation is only performed during block mining, you’d end up with a single Halo2 proof per block. (I don’t know what assumptions your graph makes about Grin, but I’ll presume it’s similar.) Without per-transaction proofs, you could likely fit 1000 2-in 2-out Pollard transactions into a block (here I am counting memo field size towards the 2MB block size limit), which would bring the per-transaction proof cost down from a few kB to a few bytes, which on your graph we can basically ignore. So that would place Pollard around 8.
As a side-note, it would be nice to have similar notes about the what assumptions went into the other datapoints (besides 2-in 2-out). I noted unknown Grin assumptions above, and similarly IDK what goes into the Liquid datapoint.