Zcash Blockchain Size—Risks?

Let’s breakdown what we know…

With 75 second block times we have 1152 blocks per day. Zcash has a blocksize limit of 2MB.

Shielded Orchard transactions are 9.1KB (2in, 2out). That gives us a theoretical max of ~219 shielded Orchard tx per block and theoretical max of ~252,000 shielded orchard tx per day.

How many of these non-spam transactions (i.e. historic average input/output) would cause issues for the network in a similar fashion to the ongoing spam attack? Can the network handle the theoretical max number of shielded Orchard transactions per 2MB block?

Again, what type of performance testing results and scaling plans can be shared by the ECC, @nathan-at-least ?

3 Likes

I intended to reply to your comment. See my above post.

1 Like

Hi! I’m a Zcash user for a long and have tried to promote zec as private cryptocurrency. But the current state with the blockchain growth give me concerns about the future and the present of Zcash. I want share some of them here. I see that Zcash developers, ECC don’t care much about fullnode users. Most of the users uses light clients anyway, so why to pay much attention to full node users anyway? I think that hits the possible ideological stem of the community. People who care much about privacy and decentralization tend more to use full node wallets. And besides of the poor quality of full node wallets in zcash, fast blockchain growth add pressure on full node users. Additionally more competitors here appears over time which either care more of fullnode users or focused on light clients but allow to transact privately with wider range of assets including assets with better price performance and stablecoins. I share examples in the end of posts.

So, I want to share my thoughts about possible solutions:

1. Full (strong) statelessness where consensus nodes (miners, validators) don’t need the state to produce blocks.

This way unfairly didn’t get attention in blockchains because of how it can make UX worse. But it is crucial for complex smart-contract chains with account model where every transaction can interact with a random part of the state and need to get it from somewhere. In UTXO-like chains things should be easier as a wallet allready has enough data to create transactions. The problem here that a wallet now need online backups to store their part of the state to keep funds accessibly. But exact issue already exists in Bitcoin’s Lightning Network and solved with a traditional encrypted backups. Otherwise, a decentralized solution for backups can be developed with Data Availability Sampling for example.

Full statelessness is unexplored area. This way if chosen helps keep Zcash bleeding edge and unique. I believe that UX problems mostly exist because of all previous crypto UX expirience has evolved for statefull chains.

2. Reasonable block limits with fee market.

I don’t understand why Zcash devs are so against the fee market. Known pseudonymous person of L2 scallability discussions “polynya” proposes the trilemma of Spam Mitigation - Low fees - Censorship resistance. Only two of three can be easy achievable at the same time. Most of Web 2.0 gives up on Censorship Resistance to provide free and spam protected services. Zcash tries to do low fees and it is cersorship resistant because of private transactions so it is vulnerable to spam and DoS attacks. Some people in community proposes a solition which censor transactions created likely by the attacker while this transactions are allowed by the protocol.

We have 2MB blocks in Zcash (equivalent to 16MB blocks if blocktime was 10 min like in bitcoin) to provide enough capacity. But we don’t have much usage and adoption. I think it sane to keep blocks bearable and rise limit when it needs. Now we have big block which is either empty or filled by spam. And consumers hardvare which on which not easy to manage the 1TB/year blockchain growth. In future with better hardware and optimized software 2MB blocks will be easier to manage but in the best scenario we will need more blockspace due the usage.

Two of biggest big blocker proponents in crypto are the Bitcoin Cash and Bitcoin SV communities. Neither has fast development and bleeding edge tech as ZK, and not very tech focused. Both are loosing their relevance on the market. I’m not glad to see Zcash in the same boat.

I propose to lower blocksize to 0.5MB for now. It will reduce blockchain growth to 210GB/y and gives 4 years on 1 TB drives for more fundamental scalling changes.

3. Zcash can give up on full node users completely. But need more features to stay relevant on the market.

I think the idea of a general classical cryptocurrency (like Bitcoin, Litecoin or Zcash) which resides on its own chain are obsolete. There are very few dumb cryptos it the top. Zcash needs to become a platform. And name Zcash is suitable for a coin, but not much for a platform or a blockchain. It will better to have a separate name of the chain.

At the end I want to share a list of projects which I see as present or competitors and to compare them with Zcash.

  1. Monero. As for privacy payments majority of crypto users uses Monero. I don’t like their toxic community which a copy of the bitcoin maximalism. Their ignorance of the market and ZK tech drives them on their own esoteric branch of transactional privacy with small anonset of tx. But they have better software and care of fullnode wallet users as first-class citizens.

  2. Bitcoin. Bitcoin is not generally a competitor due the lack of the private transactions at a protocol level. But they have strong privacy aware sub-community of users and developers. They has perfect fullnode privacy-oriented wallets like Wasabi and Sparrow.

  3. Ethereum rollups. They are mostly focused on light client users. Aztec Connect currently provides the same level of transactional privacy as Zcash’s sapling. And it allows to use such wide-accepted assets like ETH and DAI. It even allows withdrawal on general Ethereum addresses wich allows to use it as a shielded pool to provide sender anonymity like z-to-t transactions in Zcash. Additionaly, it allows private interactions with Ethereum DeFi protocols and soon can has its own contracts. Cons: more expensive transactions, withdrawals require up to hours of time to be confirmed.

  4. Cosmos IBC chains. Zcash probably will switch to PoS, implement ZSA and IBC. But those space will not be empty as projects like Penumbra and Namada will provide all the same features and even more.

  5. Alt L1s. The Aleo team build universal private blockchain with general purpose contracts.

6 Likes

I’ve missed a link to Polynya’s post: Transaction quality trilemma. This is more of a quick speculative… | by Polynya | Medium

1 Like

Hi, welcome to the forum!

It’s great to see a community member who really cares about the future of Zcash. I just want to respond to some of your opinions.

This is not true. Recent updates to alleviate the worsening UX due to increased transaction load in Zcash have been focused on zcashd where there have been 3 releases with notable improvements in the last 4 month.

Zcash is clearly not in the same boat as the other projects you mentioned in the same paragraph.

I also want to comment that some of your suggestions seem to not take into account future improvements that will be possible after NU5 with Halo.

4 Likes

Synchronization performance is important for usability in a short term. But there are issue with blockchain growth itself. In few years it can be few TBs. It’s bearable with software optimizations, stable reliable sync if in some point in future it will be possible to get rig of this data somehow: pruning, regenesis, statelessness, etc. I did’t see this plans on the roadmap but probably I’ve missed something as I looked for recognizable buzzwords and Zcash can just has different words for them.

2 Likes

I agree, or at least appreciate, many of your well reasoned points. I think working towards an algorithmic fee design like 1559 would be a very good goal for the community to get aligned on, for example.

However, one thing I’ve noticed is that individual forum posts, no matter how well reasoned, do little to move the needle. Instead, I think we need some sort of community working group that can collaborate with devs to explore design options and voice opinions and suggestions. We need organization that can listen to and consolidate the broad ecosystem’s concerns, prioritize user wish lists, and present them formally.

One thing I think is most frustrating is when people think they aren’t being heard or that they don’t understand the Zcash design choices. However, often times a free-for-all “voice your concerns” format, especially with text-based communication, can turn into a nasty melee, which then disincentives the people actually working on Zcash to listen to the community because it’s not helpful and often demoralizing. One way to break out of that cycle is again through organization. For instance, a community working group could meet a few times to try and consolidate questions and concerns about Zcash and then that working group, or representatives from it, could attend one of the Arborist calls for a Q&A with developers to work through Zcash’s challenges and strategies. If done throughout the year, I think this would lead to a more active, well-informed, empowered community and a stronger channel of communication between Zcash stakeholders and Zcash developers.

10 Likes

Excellent insight and suggestion!

2 Likes

Are there any technical updates about the Zcash blockchain size bloat-attack mitigation efforts?

2 Likes

Please consider reduce the blockchain space. Ordinary user still would like to operate a full node with ZebraD on Macbook. :flushed:

3 Likes

Despite this blockchain growth more than likely being some form of attack, wouldn’t we also be seeing the same issue if vastly more people were using Zcash? No doubt Zcash developers are being forced to confront this issue sooner than would be absolutely necessary if all Zcash users were acting in good-faith, but I can’t think of a more predictable and, as yet, unresolved crypto-currency issue.

No doubt this amounts to a crude work-around and a significant deviation from the current model (ie: requiring a hard-fork) but…

What if new chains were initiated every year or period of years (like traditional business ledgers having balances brought forward for each new accounting period) and, in order for users to bring their balances onto each new chain, balances would need to be spent to a special address to have them appear on the current chain? This would allow the majority of nodes to maintain a much smaller blockchain while a minority of nodes would be needed to maintain one or more previous chains. Naturally, at the initiation of a new chain, the only valid transactions on the old chains would be to those special addresses that cause a balance to be brought forward to the current chain.

2 Likes

While it is a positive takeaway that this situation is forcing the issue of scalability, it was foreseen that extremely low fixed fees would enable this situation. Read through the Github link in the Tweet, very informative.

2 Likes

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.

3 Likes

Blockchain total size now exceeds 200GB!

2 Likes

It’s growing at over 300GB per year, 50% faster than Ethereum. At this rate, it will be the 2nd chain to surpass 1TB (Ethereum is already over 550GB).

3 Likes

ZIP 317 has been delayed and is scheduled to be implemented in zcashd 5.5.0

zcashd 5.4.0 is close to being released.

Another few months of until ZIP 317 gets deployed…

Dynamic transaction fees will only make spamming more expensive. We still have to deal with the bloat.

6 Likes

Is it true that the bloated chain size will remain forever; There are no means to reduce its size

3 Likes

Like everyone else, I don’t like bad news, but unfortunately, we have lost about 25% of nodes since June 2022. Statistics Zcash / Node explorer — Blockchair
In fact, we are approaching the number of 150 nodes, in the style of a PoS network.

@nathan-at-least for your information

If we don’t come up with ways to popularize the installation of nodes, then we are critical near of the need to switch to PoS. (@tokidoki, @dismad, @squirrel)

6 Likes

bitcoind and other coins’ nodes can run in pruned mode while still enabling wallet functionality.

zcashd, however, currently cannot: Re-enable wallet when pruning · Issue #4080 · zcash/zcash · GitHub

I would be running my own node again currently if this were the case, as surely others would.

Apparently, wallet functionality in pruned mode has been backported in a PR open since 2017:

To highlight one consequence of the growing chain size, due to the lack of pruning, Lamassu has had to disable shielded sending support on their ATMs:

It would seem that allowing for pruned, wallet-enabled nodes is low-hanging fruit for partially addressing this issue, permitting for more nodes to be run and additional shielded use-cases.

5 Likes

Some like to complain about blockchain size but how much does it really matter? :smirk:

Screenshot_2023-02-11_11-40-56

I think the real issue is lack of education from those who entered into this arena in the last 2 years. Why run a node when a CEX is so much easier and convenient ? As seen on ZecHub:

With a full node, you download all the blockchain data and only query for addresses / transactions locally. When you have a copy of the ledger that you have validated yourself, you no longer have to trust a third party to be honest about the state of the ledger.” -Jameson Lopp

I have been active on trying to help here, but at the end of the day, users must see value in investing time and money into learning why they should run a node. For power users like myself, this is self evident.

2 Likes