RE: Zcash Foundation's question "Can Zcash scale to a million users?"

The Zcash Foundation recently published a blog post asking the question: Can Zcash scale to a million users?

https://www.zfnd.org/blog/can-zcash-scale-to-a-million-users/

There were a bunch of great, related questions in the blog post as well. I am just as eager to know the answers to these questions!

I have had the topic of Zcash scalability on my mind because I recently downloaded a couple of the shielded-first mobile wallets and have noticed that syncing often takes quite a while. Both Nighthawk and ZecWallet Lite took about 20 minutes for the initial sync, and each time I open the wallet (usually once a week or so) it’s another 10-15 minutes before I can do anything. I assume this wait time will only get longer as blocks start to fill up, but maybe that is an incorrect assumption and someone more familiar with the Lightwallet protocol can correct me on that.

On my desktop wallet, my problem is not sync time because I run my own full node; although of course there is the initial sync which takes a while, at least once I’m fully synced I can leave the full node on 24/7 and my wallet balance is available instantly when I open my desktop wallet. With my full node the scalability problem is overall resource usage. Zcash has 2MB blocks every 1.25 minutes, which comes out to around 841GB per year if blocks start to become consistently full (as bitcoin blocks currently are). That’s about $70 per year in hard drive space - not outrageous, but once I start needing to set up complex RAID systems, this starts to go beyond financial cost to including higher compute costs and general maintenance costs as well.

Some more napkin math: at 2000 bytes per shielded tx (the figure currently provided at https://z.cash/upgrade/) times 1 million users making one Zcash transaction equals 2GB of data. That much data per month or even per week is manageable to me. 2GB per day (1 million users x 1 tx per day) starts to push up against the capacity limit of the system, and starts to make my life as a node operator more difficult. Bear in mind that many apps you’ve never heard of have more than 1 million daily users - this is not a lot in the software world.

So the problem is clear: Zcash can handle a million daily users, but barely, and to do so would put some strain on home node operators such as yours truly. If Zcash adoption goes viral, to be as successful or even moreso than Signal in terms of daily users, the system will need to change significantly to handle that volume. And that is to say nothing of adoption on the level of mainstream payment apps like PayPal, which has hundreds of millions of users, or Alipay, which has over a billion users.

In the spirit of solutions, and the main reason for this post, I would like to share for your review and feedback a blog post I recently published about scaling bitcoin with sidechains: https://lightco.in/2020/11/08/sidechains/

Since Zcash is very similar to bitcoin, and shares similar constraints (perhaps even tougher constraints in some ways, since shielded transactions are much larger than a normal bitcoin transaction), I am interested to hear from folks at the Zcash Foundation (and from the broader community, hence my posting this reply in the public forum) about what they think of my proposal for scaling via sidechains and my reasons mentioned in the post for proposing scaling via sidechains specifically (rather than other methods like increasing the block size limit, reducing block times, sharding, or other techniques, or some combination thereof) as applied to Zcash.

As my post mentions, I don’t think sidechains are a panacea for scaling, but for the reasons discussed in my post I do think they provide the best foundation on which other scaling strategies (such as payment channel networks and rollups and the like) can be built. I will briefly mention those reasons here, and you can read the post for more details:

  • Sidechains can experiment with different scaling tradeoffs that we might want to avoid on the mainchain, such as increasing the block size limit or further decreasing block times.
  • Sidechains can also experiment with features that we might not want to deploy on the mainchain right away, if ever.
  • Users who prefer to run their own full node for privacy and/or security reasons can store their funds on a sidechain that maintains a small block size limit to accommodate home node users.
  • Sidechains can be added on an as-needed basis; if the already-deployed sidechains reach their capacity limit, you can just deploy another sidechain.

My vision is to keep the mainchain very lean, always fast and easy for home node operators to verify using affordable off-the-shelf computer hardware, and for the vast majority of transaction volume to happen on sidechains and Layer 2 payment channel systems. I make my case for this vision in my blog post (that link again is https://lightco.in/2020/11/08/sidechains/).

Feedback and other ideas welcome!

cc @antonie @pili

6 Likes

Part of the motivation for Orchard, the next shielded protocol, is to enable scaling via zk rollups. This ticket describes a possible next step after Orchard is activated: Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub

10 Likes

Daira, we need a name for “shielded transaction aggregate” it’s mouthful to say. zkagg?

2 Likes

I use “agg” in inner speech, similarly to “tx”.

2 Likes