Scaling is a central discussion for blockchain teams and a critical issue that needs to be addressed as this technology matures. ECC has spearheaded groundbreaking research in this area, focusing primarily on layer 1 scalability. In this post, we’ll explain the importance of layer 1 scalability and summarize our research in this area.
Why is L1 scalability important?
Scalability solutions are designed to help blockchain networks maintain transaction throughput and low transaction fees as the network grows. Researchers have proposed a variety of potential solutions — from layer 1 approaches like sharding or proof-of-stake to layer 2 approaches like side-chains or off-chain computations.
The Lightning Network and BOLT are examples of layer 2 scalability solutions that enable payment channels to hold funds in escrow until one or more parties is ready to cash out. While layer 2 solutions are critical for ecosystem development, we believe that privacy must be protected at the base layer, or layer 1, in order to ensure consistent usability, fungibility, censorship resistance and a viable medium of exchange across all use cases.
Layer 1 scalability requires horizontal scalability, where the network scales as infrastructure providers contribute additional resources. Said another way, horizontal scalability means that as infrastructure is added, network capacity increases.
If Zcash is for everyone, we must scale layer 1 as usage grows. Some of this research has practical applications today, while some of it is speculative with a long-term vision for the future.
Summary of our work in 2019
Horizontal scalability and usability goals
ECC’s CTO, Nathan Wilcox, presented his vision for Zcash at a global scale at Zcon1. In order to scale Zcash to 10 billion users by 2050, he outlined two goals: usability continuity and ux-unobtrusive infrastructure. Usability continuity means that usability should not undergo qualitative changes as the network grows, e.g., changes in transaction flows or fee mechanics. UX-unobtrusive infrastructure refers to infrastructure that does not impact a user’s decision-making. For example, users should not need to understand whether the sender and the recipient are in the same shard or even that shards exist.
Practical recursive ZKPs with Halo
In September 2019, ECC researcher Sean Bowe, along with Daira Hopwood and Jack Grigg, published Halo, a paper detailing a new technique that allows for the creation of efficient, recursive zero-knowledge proofs. What does this mean in practice? With Halo, you can create a proof that verifies a prior instance of itself, a “proof of proofs” that allows you to compress any amount of data into a short proof that can be checked quickly. Not only does Halo avoid a trusted setup, but it also promises dramatic performance improvements, with proofs as small as 3.5 KiB. Halo research has been recognized as a breakthrough not just for cryptocurrencies, but for the entire field of applied cryptography. Since September, Sean and team have been working to formalize Halo so it can undergo extensive peer review and security analysis. They have developed a high-performance implementation which demonstrates practical efficiency. We may see variants of Halo deployed in production on other projects as early as this year. Sean explained Halo in layman’s terms during ECC’s quarterly livestream (starts at minute 22). Please note, Halo is a work in progress and has not yet been peer-reviewed.
Scaling privacy through sharding architecture
Daira Hopwood presented a research proposal for sharding architecture at Zcon1 and again at the ZKP Amsterdam Community Event. Daira’s research proposal calls for the use of sharding, a technique that partitions a database into sections or “shards” to improve the throughput limit, in order to scale to high transaction volumes. Hir proposal uses recursive SNARK validation (similar to Coda) to create summaries of state updates and to allow clients to catch up almost instantly. To reduce the reliance on trusted setups, Daira proposes transparent SNARKs. And finally, Daira’s proposal also includes a mix-net to replace broadcast of transactions to miners and all potential token receivers, while maintaining privacy. See Daira’s slides here.
Capacity increase: Faster block times with Blossom
Prior to investing in an ambitious architectural upgrade, less-disruptive capacity increases can satisfy current growth. Our latest network upgrade, Blossom, included an example of such a capacity increase: The block mining rate was doubled, allowing a higher rate of transaction confirmations, thus lowering fees and reducing confirmation times.
What to expect in 2020
Our audacious goal is to bring Zcash to 10 billion users, and to that end, we have dedicated much of our long term protocol research efforts into making a future version of Zcash horizontally scalable for Sapling-equivalent private payments. This research is part of our overall flight plan for 2020 and beyond. We know these goals are ambitious and that some of this research might never make its way into a network upgrade. We know any layer 1 scalability upgrade will require support from the Zcash development community, one that grows more diverse by the week.
While carrying out this far-reaching research, we also intend to develop a capacity plan to ensure there’s a common understanding of (1) how to measure usage and anticipate capacity limitations, (2) which different capacity improvements are plausible, and (3) what the respective risks and payoffs are. ECC wants to help the Zcash community prepare for network growth safely and effectively, well ahead of demand.
