Zcash Blockchain Size—Risks?

[curiouschipmunk]

Hello wonderful Zcash community! I have some questions related to Zcash blockchain bloat. I have seen a number of statements related to attempted solutions, but I am concerned we are not adequately discussing the risks.

As I understand it, the Zcash blockchain has grown to over 119GB in size (as of time of writing), increasing over 100X in the last ~4months. Growth is showing no signs of slowing down.

Question 1: At what point will node operators begin experiencing failures and/or stop supporting Zcash due to the size of the chain?

Question 2: If this occurs, what are some of the potential risks of a smaller pool of node operators?

Thank you!

[Autotunafish]

That chart represents the size of the blocks, not the blockchain. I don’t know the exact numbers but I would guess it’s increased about 20% since the release from 80-something to yeah just over 100GB roundabouts.

[kowalabearhugs]

The chart does represent blockchain growth. The link states, “the cumulative growth of Zcash’s full node size, in gigabytes, from the genesis block.” I believe the blockchain size on disk was ~30-something GB in June and is now ~117 GB.

This chart showcases the average size of the blocks: https://bitinfocharts.com/comparison/size-zec.html#1y

[Autotunafish]

I could have swore it was more than that

[steven-ecc]

Since mid-June, the size of the Zcash blockchain has grown from approximately 30GB to approximately 116GB representing an almost quadrupling in chain size. During that time, we’ve added on average .78GB per day to the chain.

At ECC, we’ve been tracking the impact of the increased shielded transaction load since it started and have been taking steps to mitigate its impact ever since. Our first priority was to ensure the stability of network operations and restore node performance to near historic levels, even under this increased load. We released multiple zcashd releases (5.1.0 and 5.2.0) for that purpose.

Release 5.1.0 provided faster block validation for Sapling and Orchard transactions reducing worst-case block validation times for observed historic blocks by around 80%. We also made performance improvements to the getblocktemplate RPC to reduce block propagation times throughout the network

Release 5.2.0 provided a number of updates to node and zcashd wallet performance including various caching improvements, parallelizing and batching trial decryption of Sapling outputs, and improvements to witness handling.

We will release zcashd 5.3.0 next week which will have continued performance and scalability improvements primarily in the area of concurrent memory utilization.

Our top priority at ECC remains an improved sync experience for our mobile SDKs. The NightHawk, Unstoppable, and Edge wallets are built on this SDK and have experienced extreme sync times since this load started, to the point of being unusable in some cases. We’ll roll out SDKs updates in a couple of phases, with the first phase offering incremental sync improvements, and targeted for release in the next couple of weeks.

We have also spent significant time analyzing potential fee changes, like those proposed in ZIP 317 to make chain usage more fair and equitable among all users. We are almost complete with our analysis and will have a concrete recommendation that we’re supportive of potentially as early as this coming week.

None of these items directly address the rate of growth of the blockchain. The fact is, if block space is fully utilized in every block added to the chain, we would be adding about 2GB on a daily basis. The maximum block size is currently set at 2MB and the protocol is designed to allow those blocks to be filled. We are monitoring to see if there are any other impacts on the Zcash ecosystem due to this or other factors. If you are a Zcash user and are having issues, please reach out to us.

Supporting further increases in the levels of usage of Zcash will require more than a quick fix to scale properly. Our next priority after the SDK updates is to define a medium term roadmap focused on performance and scalability which has the goal of allowing the chain to scale at max capacity and still provide the basis for an excellent experience for ZEC users. We’ll be publishing more on this as we nail down some of the specifics.

[grassroots]

here is a correct, uptodate size chart *

So since around 6.2022 up to now 10.2022 it grew by 117 / 32Gb = 3.65 = 260%
Yes it causes a lot of problems, and engineers dont care since they can ‘fork it out later’, but meanwhile dont recognize that a bunch of actual users fall down the bandwagon. Whoever is spamming, they are successful in crippling the project.
Engineer above: ‘extensive analysis blah’ with result:

“None of these items directly address the rate of growth of the blockchain.”

It is a research project and the vibe is that it wont change anytime soon.

* https://blockchair.com/zcash/charts/blockchain-size

[David_Heisenberg]

I believe the line you quoted from Steven is not quite used in good faith. The point is that the Zcash blockchain is designed to allow up to 2 Gb of growth a day due to block size and time. We could raise txn fees 100x or more and a motivated attacker (say, a government) could still fill up the blockchain and cause the same current problem. I would imagine the same could be done for just about every blockchain (government spam attack aka non-economic actor attack). The difference with Zcash seems to be that there is no current pruning method (entire nullifier set of spent coins has to be maintained and checked against) to reduce blockchain size. So even with a greatly reduced rate of growth, the growth of the blockchain is always positive.

It seems to me that an EIP-1559 style fee mechanism should be next top priority, allowing fees proportional to usage while still maintaining txn indistinguishability during a given time (is this mostly correct @nathan-at-least ?).

Eventually, I assume recursion and sharding will lead to further scalability, and combined with a better fee mechanism, will help prevent at least “free” purchasing of all block space.

However, the fact remains that Zcash blockchain will continue to grow at a positive rate. At what point will it become a security risk for the network where miners or future POS block producers feel it is more trouble than it is worth? I’m not sure, but if Zcash price (which is directly proportional to the number of believers in ZEC being money) can have success, it will help tip the scales for miners/block producers to continue to secure the network since they can turn a greater profit. Therefore, getting more and more believers in ZEC as money is directly related to increasing the security and sustainability of the network.

[tromp]

@David_Heisenberg

We could raise txn fees 100x or more and a motivated attacker (say, a government) could still fill up the blockchain and cause the same current problem.

The IMO remote possibility of an attacker willing to spend 100x as much as they are now is NO reason whatsoever to keep the cost of spam attacks as low as they are now. We don’t know how well the attacker is financed but it’s safe to assume that making spam far more costly will significantly deter any would-be spammers.

[David_Heisenberg]

I would agree. Which is why I advocate for work on a better fee mechanism. Nonetheless, the point stands that in the limit of non-economic actors, the Zcash blockchain design, or any blockchain to a degree, is susceptible to spamming. Zcash is susceptible perhaps even more so due to its strength as a subversive tool due to its privacy features.

I think by being aware of this potential problem, we should be even more vigilant about the need for scaling and anti-DOS strategies, which will only serve to both improve Zcash user experience and strengthen its defense against disruptive actors. I call attention to the problem to advocate for a proactive approach instead of a reactive one.

[curiouschipmunk]

I appreciate all the extra feedback and engagement on this topic, but I do not feel like anyone has adequately addressed my original questions. Is there perhaps somebody at the Foundation or ECC who can help?

Without answers to these questions, I am growing concerned that the project is flying blindly into a disaster.

@curiouschipmunk

Question 1: At what point will node operators begin experiencing failures and/or stop supporting Zcash due to the size of the chain?

Question 2: If this occurs, what are some of the potential risks of a smaller pool of node operators?

[artkor]

@curiouschipmunk

Question 1: At what point will node operators begin experiencing failures and/or stop supporting Zcash due to the size of the chain?

1. If we are talking about ordinary users like me, then problems will begin as soon as the volume of the blockchain exceeds the size of existing hard drives for free sale. At the moment, I can afford a 2Tb SSD for this function. This means that my margin of safety for holding the Zcash node when the block is fully loaded, as it is today, is about 2,300 days, or 6+ years.

2. As long as there are at least two nodes on this planet, the network will continue to function. I had an experience when I held two nodes of one deceased coin, which was created on the basis of bitcoin. Even after a year and a half, the network was functioning, I was mining coins almost in one gate. A couple more people were doing it. They saw that my IP continued to hold the network and believed in the miracle of the resurrection of this coin. I’m sure that Zcash is not threatened by such crisis. Because it is a very popular coin. And if Zcash switches to PoS over the next 2-3 years, the block producers will have an incentive to support the network in the form of a reward - staking.

[ChileBob]

6.2Tb remaining on my node, so I’m good.

[nathan-at-least]

@David_Heisenberg

It seems to me that an EIP-1559 style fee mechanism should be next top priority, allowing fees proportional to usage while still maintaining txn indistinguishability during a given time (is this mostly correct @nathan-at-least ?).

The simpler, more pressing improvement is specified in ZIP-317 (current draft) which requires fees to be proportional to how many inputs & outputs they have (appromixately, the ZIP specifies a more precise notion of “logical actions”).

A change similar to EIP-1559 from Ethereum (which was actually proposed for Zcash earlier on) will take more time, although I believe that (or some other change that ensures fees rise and fall with usage) will be necessary in the longer term.

[noamchom]

@David_Heisenberg

a motivated attacker (say, a government)

if there was ever such a thing as a strawman argument.

This situation is obviously a crypto attacker(s) who have something against Zcash or something to prove or most absurdly, too much time on their hands (and $20 laying around to spend for the lulz).

For the capital spending that has happened in the past 5 years around Zcash and the developer ecosystem that supports it, I am stunned at how slowly mitigation is happening for such a crippling attack.

The blockchain bloat could have been stopped (made prohibitively expensive) more than a month ago with a simple hard-coded fee update. (Lets say a 100x increase)

For regular (non-attacker) Zcash users, they’d understand that the transient fee spike is just that. Transient. Pay more for fees now (temporarily), as a cost to let the engineers work to a true fix for the future, without having to watch the blockchain size bloat to damaging levels.

In the months following, the teams undertake the R&D about a follow-up implementation which ideally should stand up to the test of time, under any network use (or spam attack conditions)

The chain will end up above 200GB (122GB currently, growing ~1GB a day) in no time under the approach taken. Are there talks about using a hard-fork to leave the bloated blockchain behind?

Zcash blockchain size chart

[David_Heisenberg]

@noamchom

if there was ever such a thing as a strawman argument.

I’m not sure why people seem to think I’m claiming that a government is filling up the blocks rn. I’m simply pointing out this is a viable attack vector, which should add extra emphasis to fixing the Zcash network resource pricing and to scalability. Additionally, a strawman argument is one that appears like it has merit on the surface, but can be easily disproven. I don’t see how it is possible to claim that in the future some guy in an NSA basement couldn’t quite easily be filling up Zcash blocks. If people want to claim that that will never happen and shouldn’t be considered, I wouldn’t be surprised if in the future we end up in a scenario like we have now.

Put in another way, my point is - how can we design Zcash to defend as best as possible against even the worst case scenario of an extremely well funded adversary trying to clog the chain? By thinking of worst case scenarios, it should help to make Zcash more resilient to attacks instead of assuming only the most benign intentions of possible Zcash users.

I wasn’t around when the decision was made to go for a flat fee for all txns, but it seems like if there was more concern over spamming, by any type of actor let alone a well funded one, the current situation may have been avoided or mitigated. But alas, this is where we are now and I don’t think it does much good to opine on the past (although we can learn from it). Zcash is developed by a relatively small group of people and it operates in a space where there are very few people who have the technical ability to contribute. I tend to believe that Zcash architects and engineers generally have very good reasons for their choices, even if the choice made at the end of the day leads to later problems (nothing is ever as easy as it seems).

Also, I’m not so sure a quick 100x fee change is theoretically possible (emphasis on “quick”). If Zcash could change fees overnight, it probably means it isn’t very decentralized. I wonder how long it would take Bitcoin to implement such a fee change? There has to be at least some consensus building, and I’m not so sure everyone would immediately agree a 100x fee change would be an obvious change to make overnight, even if hindsight shows it to be.

Lastly, if it is not clear already, I am just as concerned as many others here about the blockchain size growth and the usability problems it causes both on back and front ends. I 100% think a more appropriate fee mechanism needs to be worked on. And from what I can tell, an EIP 1559 style one is the best target. Therefore, unless I learn otherwise, I will be focused on advocating for that to be a priority in Zcash development.

[artkor]

@noamchom

This situation is obviously a crypto attacker(s) who have something against Zcash or something to prove or most absurdly, too much time on their hands (and $20 laying around to spend for the lulz).

I’m a little upset for these guys, because they spent $2,000 before their activities were noticed by the crypto community. ))

[tokidoki]

Things will improve but Zcash is currently usable by many people. It is probably not the number of people we want to see using Zcash, but obviously current number is not far from the number we see before the supposed “attack”.

The fact that Zcash will be even more usable after current planned improvements made to zcashd and mobile sdk, should make us more optimistic of the future. On top of the expected release of Zebra, better Tor integration and of course, regulatory works done by awesome Zcashers.

[kowalabearhugs]

Given that the lightwallet infrastructure was rendered virtually unusable by spam transactions with a large number of outputs… How many non-spam transactions (i.e. historic average input/output) would cause issues for the network in a similar fashion? Can the network handle the theoretical max number of shielded transactions per 2MB block?

What type of performance testing results can be shared by the ECC, @nathan-at-least ?

[local_miner]

Bitcoin’s average block size has been about 1.2 MB for a long while, and it seems to be doing fine. But Zcash generates 8 times more blocks than BTC does, so this may be a little concerning. I hope the devs at ECC eventually figure things out about these allegedly transaction spammers.

Maybe going back to mining 1 block per 10 minutes would temporally do the trick?

[Minghe]

I‘m curious that how much is the current Shielding TPS of zcash protocol? If more users(ultimite 1 billion?) would use the shielding transaction, what will this impact Zcash Blockchain protocol?