2017 was an excellent year for Zcash as the protocol developed, matured, and the ecosystem expanded. The market-cap surpassed $1 Billion, and it is now well supported on various exchanges.
There are many repeated concerns and sources of misinformation spread about Zcash and, while the technology is still in its infancy, it is rapidly evolving to actively address these concerns. Such concerns primarily focus on the nature of the trusted setup, the performance cost of completing a shielded transaction and the fact that private transactions are not mandatory for all Zcash transactions.
In this article, I’ll outline some of the significant items planned for Zcash during 2018 and as a result, why I think 2018 will be a great year for followers of ZEC as a number of these highlighted concerns are being tackled head-on.
1. Sapling Network Upgrade
The Sapling network upgrade deserves a post unto itself. Sapling is the first major upgrade planned for the Zcash network (the first and current release being known as Sprout). Sapling will be implemented as a hard fork and is planned for September 2018 with the preparatory upgrade “Overwinter” planned to go live in June of 2018. Not only does Sapling promise some massive improvements regarding the performance of shielded transactions but it also brings with it improvements to security and other associated benefits.
Regarding performance of shielded transactions between Sprout and Sapling, it is best illustrated in the following graphic from the Zcash site:
Proving time has been reduced from 37 seconds to 7 seconds and memory usage from over 3GB to around 40MB, a staggering improvement of approximately 98% (note that low memory proving shipped for Sprout in version 1.0.13 reduced the current requirements to 1.7GB). Further improvements and optimisations are expected before September, but the memory requirements of Sapling now make mobile wallets supporting shielded transactions a realistic possibility. This will no doubt further the advance of the % of shielded transactions occurring on the network, hence improving security for all, and eventually paving the way for the future deprecation of transparent addresses.
In addition to these improvements, Sapling offers an increase in security. The current elliptic curve construction used in Sprout (BN128), due to some recent cryptographic developments, has been estimated to have only around 110 bits of security (lower than the 128 targeted). Sapling will use a new curve (BLS12–381) which targets the 128 bits of security level but does so without a loss of performance. Update: Zooko pointed out this isn’t entirely accurate — while the conjectured security level of this curve is around 110 bits the concrete security of the curve given current research is still around 128 bits. Regardless the curve is being upgraded as a precautionary measure.
In summary here is what we can expect from the Sapling network upgrade:
- Faster verification times
- Lower memory requirements
- Improved security by implementing a new elliptic curve construction (BLS12–381)
2. Powers of Tau Ceremony
Perhaps the biggest critisism you will hear about Zcash is that it relies on a trusted setup, which is a weakness of all zk-SNARK based systems. For zk-SNARKs to function, some public parameters need to be generated that are used to create and validate the zero-knowledge proofs. These parameters are generated from an underlying “secret” with the notable downside that if this secret (colloquially known as the toxic waste) is not destroyed then it is possible that someone with knowledge of it can create false proofs, and as a result, generate an infinite amount of ZEC (it should be noted that the zero-knowledge part of the protocol is not compromised in this instance and privacy is not at risk as data is encrypted on the blockchain).
Zcash devised an incredibly elaborate multi-party computation protocol to generate these public parameters with the outcome being, that if only one of the trusted participants acted honestly and destroyed their portion of the toxic waste, the process would have been a success. While the ceremony was executed as planned and there is no evidence that it was compromised it was limited to only six participants, was complex and expensive to perform, and would need to be completed again for the Sapling hard-fork and any future upgrades. It also assumes that the six participants did not collude and one of them successfully destroyed their portion of the toxic waste.
To improve upon this, a new multi-party computation system was proposed known as the Powers of Tau. The new and improved multi-party computation will be used to generate the new Sapling public parameters with the process being led by the non-profit Zcash Foundation. While it remains a trusted setup the new ceremony can include a potentially unbounded number of participants. Much like the original multi-party computation just one participant needs to destroy their portion of the “secret” for the protocol to be secure. As anyone can participate in the ceremony it greatly reduces the element of trust. According to the post outlining the ceremony:
The Powers of Tau ceremony proceeds in turns, one turn for each participant. You can think of this process as a bit like shuffling a deck of cards in public. Each participant shuffles the deck, proves that they did not modify or add any of the cards, and then hands the deck to the next participant.
The ceremony itself is divided into two phases, with the advantage that the first stage may be used for a wide variety of zk-SNARK circuits and this first stage can then be reused for the application-specific second stage of the process (Sapling is just one such application). There is no requirement for individuals to be the same in either stage and in both stages only one user needs to destroy their “secret” for the process to be a success.
At the time of writing, there have been 31 participants including myself, and all the public attestations of participation are published via this GitHub repo. There have been a variety of tools and techniques used to generate and destroy the randomness required from the conventional to the more outlandish. The sheer variety of approaches being one significant advantage in ensuring it is utterly unfeasible that anyone could compromise each and every participant. There is even one participant who has offered a bounty for anyone who can uncover their randomness that was generated as part of the process.
Since the Ethereum Byzantium hard-fork zk-SNARKs have been integrated within Ethereum and it is envisioned that a range of zapps (zero-knowledge dapps), enabling private smart contracts, will be developed. As each zapp will require its own trusted setup it is likely that Ethereum zapp developers will use the Powers of Tau ceremony and conduct a second phase of the setup, unique to each zapp.
3. Zcash Conference
Following on from the previous point with Ethereum adopting Zcash technology, what better way to bring the entire ecosystem together than a Zcash-focussed conference? The Zcash foundation is organising one in Montreal at the end of June named Zcon0 with more details to follow.
Interest is rightfully high in Ethereum regarding the potential use of zk-SNARKs within zapps, and there is likely some crossover of ideas and development which will benefit both ecosystems. Greater use of zk-SNARKs in the wild should form a virtuous circle of application developers and development.
4. Delegated Proving
Hardware wallets are a fantastic method for securing private keys that mostly protect the user from viruses and hacking. Zcash is currently supported on hardware wallets such as Ledger or Trezor but are limited to only supporting Bitcoin-style transparent addresses (t-addrs). It is likely that the lack of support for shielded addresses (z-addrs) on hardware wallets are a substantial reason why so little ZEC proportionally is held in shielded addresses (currently around 116,000 ZEC or ~4%).
Even given the vast improvements in performance with the Sapling network upgrade performing shielded transactions on existing hardware wallets is not going to be a practical reality. Indeed from this thread on Reddit, the Ledger CTO comments:
Nano S has 320 Kb flash, 10 Kb RAM, Blue has 480 Kb flash, 12 Kb RAM (less available for applications after the OS is installed)
With this in mind, a proposal known as Delegated Proving is under development that hardware wallets can make use of to support shielded transactions on these devices. To quote Zcash developer Ariel Gabizon:
The idea is that a computationally weak party can offload the heavy proof generation for a shielded transaction to a computationally strong party.
A natural implementation of this would be to offload the proof generation of a shielded transaction from a hardware wallet to some other infrastructure, such as Ledger’s, that performs the proof and returns it to the device for signing in a trustless manner. While this feature has yet to be released into the Zcash codebase, it is slated for the upcoming release of 1.0.15 as an experimental feature. However, while on the current Sprout network it will operate with severe limitations and its full utility will only be enabled by the Sapling network upgrade. Only then will proofs be able to be offloaded for z-addrs without a requirement to reveal the spending key and hence there is no requirement to trust the service generating the proof (which is fine in certain circumstances but not a good option for a hardware wallet).
In summary it is likely that hardware wallet support of shielded transactions will greatly ease the friction of using z-addrs for a large proportion of ZEC hodlers.
5. Zcash Foundation Grant Awards
Currently, 20% of each mining reward is directed to the founder’s reward (the reward ends after four years and so will be capped at 10% of the total supply of ZEC). While this has long been a point of contention for some, the single biggest beneficiary of the founder’s reward is the Zcash Foundation (accounting for 1.44% of the total monetary base). They have already started to put their current resources to good use funding a series of proposals in late 2017 with another round to come in 2018. We can look forward to seeing these projects being delivered during the first half of 2018, they include:
- A mobile light wallet
- An alternative implementation of the Zcash protocol written in Rust
- Further support for managing and maintaining a TOR node infrastructure
- Web-based XCAT tool for atomic swaps between Bitcoin and Zcash (see this video for an overview of the technology)
- Educational videos and outreach
While this post has focussed on upcoming changes planned for 2018, this is simply the short-term focus of Zcash. In addition to user-issued tokens on Zcash, the Zcash scientists are busy working on the next generation of zk-SNARKs known as zk-STARKs which do away with the need for a trusted setup and could greatly aid with the generally unsolved problem of scalability.