Earlier this week, ZODL disclosed that they had remediated a soundness bug in Zcash's Orchard protocol, discovered days earlier by Taylor Hornby during persistent security analysis funded by Shielded Labs. The flaw was in the zk-SNARK circuit that Orchard uses to prove the correctness of shielded transactions, and it could have allowed an adversary to (undetectably) create counterfeit notes within the Orchard pool.
There are many reasons to believe this was not identified or exploited prior to Taylor's discovery, as we'll discuss later in this post. But, the mere possibility that an unknown actor could have exploited the bug (prior to the patch earlier this week) and may still retain counterfeit notes inside of the pool creates uncertainty for those receiving payments through Orchard today.
Thanks to a novel strategy suggested by Shielded Labs, with crucial ideas from Kris Nuttycombe at ZODL, we believe a network upgrade activated in approximately six weeks (following the scheduled EOS halt of zcashd) can protect Zcash users from counterfeit coins by placing a strong constraint on the amount of circulating ZEC and, over the long term, provide evidence that counterfeiting never occurred at all:
This approach relies on Zcash's existing accounting system called the turnstile. Any funds that enter or leave a pool are publicly tallied such that the amount of funds (supposedly) within a given pool is known with certainty at all times. The Zcash protocol prohibits withdrawing more money from a pool than had entered it previously, even if we cannot ascertain how many (possibly counterfeit) coins exist inside of the pool.
However, rather than merely asking users to migrate away from a deprecated pool, we are effectively forcing wallets to conduct Orchard transactions in the new pool. By restricting payments in the old pool, we force any hypothetical counterfeit coins to travel through the turnstile before wallets accept them as payment. This has the effect of auditing the Orchard pool's supply, since nothing useful otherwise happens on the old pool after the network upgrade.
Our Experience with Sprout
This approach differs from how we previously addressed a similar issue in Zcash's original Sprout protocol.
In that case, the zk-SNARK was patched in a network upgrade that replaced its broken construction with [Groth16]. That patch prevented future counterfeiting within the pool, but it could not apply retroactively: a hypothetical attacker who counterfeited Sprout notes could have maintained some fraudulent ZEC in that pool without detection. The Sprout pool was later modified so that it could not receive new inflows through the turnstile, effectively deprecating the pool and encouraging users to migrate away from it. The turnstile was never violated, and the Sprout pool today contains around 25,000 ZEC that may be abandoned or lost.
Nearly eight years later this gives strong evidence that counterfeiting never took place, since if it did, either the counterfeiter (or a legitimate user) would have attempted to migrate their funds out of Sprout in violation of the turnstile. Since this didn't happen, the most a hypothetical counterfeiter could expect to have stolen from the pool is relatively small, which does not make sense for any plausible adversary.
Moreover, the remaining ZEC in the pool years later would have been unforseeable by a counterfeiter, just like the volatile ZEC price. In general, the inability to predict the future—like how many other counterfeiters exist, when counterfeiting might be publicly detected, how the community might respond—means the only sensible strategy for a counterfeiter is to attempt to sell as many ZEC as possible without raising flags.
What about the new Orchard bug?
It is our belief that the same pattern will play out again. The recently discovered bug was hard to find and evaded extensive auditing—it was only noticed a day after a frontier AI model was made available to Taylor Hornby for permitted security research uses, and with Taylor's extensive experience subjecting Zcash's protocol to targeted scrutiny.
The bug was exploitable for several years. In any of that time, a counterfeiter would have had the ability to draw on the shielded pool's contents and sell the ill-gotten ZEC on the market without detection. Despite this, the pool continued to grow and has only modestly decreased since the patch was disclosed this week. This seems unlikely in the presence of counterfeiting: any rational actor, given the aforementioned uncertainties, would be unaware of how much opportunity remained.
The New Approach
In the past, the turnstile was framed as a way to protect the global supply of Zcash from inflation by compartmentalizing the impact of any soundness bug to the shielded pool it affected. While this is true, we believe the turnstile has two other crucial roles. It also allows us to upper-bound the impact of a counterfeiter in retrospect, continually increasing our confidence that a vulnerability was not exploited. This is why almost nobody can reasonably claim that Sprout was ever exploited, given the ridiculous self-defeating behavior of a hypothetical adversary. This is great, but mostly helpful for future reassurance.
Much more importantly, though, the turnstile can be used to verify the integrity of the circulating supply of ZEC. Our proposed approach effectively forces Orchard funds to travel through the turnstile into the new Ironwood pool before they can be used to make payments, rendering (hypothetical) counterfeit coins that remain in the old pool increasingly worthless.
This strategy is elegant because users (after the network upgrade) obtain immediate assurance that their wallets, and the wallets of other users, are not circulating counterfeit ZEC in the old Orchard pool. It is a mechanism by which everyone forces fraudulent coins through the turnstile before they can engage economically, escalating the timeline for obtaining evidence of retroactive counterfeiting.
It is also exciting that we can achieve this without a disruptive change to the UX or many of the protocols and integrations being built with Orchard, since the protocol stays the same.
High Assurance
One of the important secondary goals is to obtain high assurance that the patched shielded protocol will be safe from counterfeiting, and does not contain any more bugs. In order to achieve this, Tachyon and Valar Group are each engaging in several auditing and formal verification efforts to confirm that the Orchard protocol's zk-SNARK circuit is correct, maximally reducing security to the correctness of specifications and cryptographic assumptions.
Tachyon has been engaging in this same kind of formal analysis for the Tachyon protocol and other cryptographic software that our team has been building, and we are leveraging our experience to obtain an independently strong conviction in the security of the (patched) Orchard shielded protocol.