Another important way to help people handle blockchain growth:
As a separate issue, the status of pruning in zcashd:
How does that help users who want for their own Zcash wallets to have the full privacy and security of a full node?
In Bitcoin, the principal argument for individuals and businesses to run nodes is self-interest aligned with the common good: Be Your Own Bank. Bitcoin Validators who enforce the consensus rules don’t need any direct financial compensation, because the security and privacy benefits of your own full node are payment enough—and the costs of running a Bitcoin Validator are so low.
Multiply and exponentiate this for Zcash. I sometimes run a zcashd but no bitcoind, because running your own node on your own hardware, under your physical control is critical for gaining the full privacy benefits of Zcash. And privacy is the reason to use Zcash. If you can’t run your own Zcash node, why bother?
I thought this chart was interesting. The ‘flood’ of ‘spam’ transactions seems trivial compared to other chains. Ive checked a few block explorers and they all seem to converge at 12.5k tx /day for current transaction throughput.
Pay per output is a good step forward towards actual tx cost balancing. It does not address what happens when transactions are 10x or 100x the current volume.
I am of the belief that running a full node is not for everyone and it cannot be a hard requirement if adoption is the goal. End users need key management, signing & shielding, and safe transmission of signed shielded transactions. Lightwalletd and the wallet threat model are good progress in supporting this.
Super users, companies, finance groups, miners, etc run nodes . They are not the AAA* user; they have specalized knowledge, higher costs for hardware, and higher volume with higher note counts.
There’s a reason for that: a succinct blockchain is easier to do in an account-based model, but account-based models are incompatible with the commitment-and-nullifier approach to privacy used by Zcash (originated by [Sander and Ta-Shma 1999]). The problem is that Mina’s approach requires the account tree to be public in order to perform updates. A complete redesign is needed to get privacy and blockchain succinctness simultaneously.
Let’s calculate the cost: you can buy a new 6 TB hard disk with a 5-year warranty for USD 80 (this is an “enterprise” drive rated for continuous operation, I’m not choosing a consumer drive here). 2.14 GiB/day will fill that disk in ~2611 days (~7.1 years) if it is only used for block data, giving an amortized cost of ~3 cents a day. Of course in practice you have to buy a disk in advance. It’s a bit more complicated because zcashd doesn’t actually support spanning block data across disks, but we could make it do so before that became a problem.
Given that around 1 billion people live on less than 1 USD/day, it’s true that many people around the world couldn’t afford to run a Zcash node (or any computer at all) given their other living costs. But most people in developed countries can, if they can afford a computer.
What do you think of the “private memory” [Khovratovich and Vladimirov 2019] approach used by Dusk? I have not rigorously analysed it; I do not vouch for its privacy properties. I don’t know if it could work with a succinct blockchain; but I don’t immediately see why it couldn’t. (Disclosure: I have some DUSKs that I picked up awhile ago on a whim, because ZK proof privacy is like catnip to me. Have not paid much attention to it. I am unhappy that it’s POS.)
On a brief search now for other potentially relevant ideas, I find BlockMaze [Guan, Wan, Yang, Zhou, and Huang 2019]. Need to read, and follow backwards/forwards references. On Ctrl-F, I note that your 2019 Halo paper is reference 29.
I tend to be reluctant to discuss this in public, outside of a strictly development forum. There is too much hype in this space; and although I have been gone from this forum for years, I have some rep elsewhere. By mentioning a few things off-hand, I do not want to give the impression of having the magic answer; you may reply, “LOLWUT, I can’t make that do whatever you imagine”, or worse, find a privacy-wrecking information leak. More fun is that when trying to get a more rigorous handle on my understanding of the two different transaction models, I noticed that something on p. 11 of [Zahnentferner 2018] is encrypted with RSA key, ID 0x7998B6321C09B6CE. A brief search of various keyservers (including Protonmail’s) and the web fails to find any information about this key. Sigh. I love little puzzles, but this is just mean!
