summary:Information on supply auditing and how it relates to assumptions and tradeoffs
tags:[announcements]
author:Sarang Noether, Ph.D.; Justin Ehrenhofer
---
We often hear questions and concerns about the topic of supply auditing, and how it applies to different projects. This post is intended to briefly and informally discuss the practical tradeoffs that projects make in their designs as they apply to the soundness of supply. It intentionally glosses over some technical details that, while important and subtle, may serve to muddy the waters for many readers.
Let's define what we might mean by supply auditing and soundness. When the term is used, it is often undefined in a way that doesn't help the discussion. For some people, it might mean that in any particular transaction, you can see the amounts being used and do simple arithmetic to convince yourself that no new assets were created in an attempt to game the supply. Transparent assets like Bitcoin or Ethereum do this; look at any transaction in a block explorer, and you'll see the amounts consumed and generated. For others, it might mean that whatever more complex mathematics is used for balance assertion is unlikely in practice to lead to problems that could allow unwanted inflation.
The transparent approach to supply is a design choice, and it has tradeoffs. As has been debated endlessly in blog posts and academic papers and conferences, you might not want the amounts involved in your transactions to be visible to the entire world. This could lead to personal risk, but also reduces the fungibility of the asset and can lead to all sorts of adversarial heuristics or shenanigans involving transaction acceptance. Transparent amounts, even when denominated, can be detrimental for privacy and fair use.
Other projects make different design choices intentionally, using different mathematics. In assets that focus more heavily on fungibility, amounts are typically not presented in the clear. Take popular projects like Monero or (shielded) Zcash, for example. In these projects, amounts are hidden using cryptographic structures called Pedersen commitments. To show that a transaction balances, the sender generates a signature or proof that uses clever (but well-understood) arithmetic on these hidden amounts to demonstrate to the network that no new assets were created. This helps with indistinguishability, which is beneficial for fungibility, security, and privacy.
To examine the different kinds of risk between transparent and "opaque" design choices, let's consider three (intentionally) broad types of problems that could arise:
- Cryptographic hardness assumption breaks
- Implementation flaws leading to detectable inflation
- Implementation flaws leading to undetectable inflation
The first class is a break of a fundamental cryptographic hardness assumption. Modern digital security relies heavily on assumptions that certain mathematical problems (like the [discrete logarithm problem](https://en.wikipedia.org/wiki/Discrete_logarithm#Cryptography)) are computationally difficult. It is not possible to _prove_ that these problems are hard, but decades of research and use implies this. If an adversary were able to efficiently solve the discrete logarithm problem, for example, they could recover Bitcoin, Ethereum, Zcash, or Monero private keys and steal funds. But relating to supply, solving related hardness problems would allow an adversary to represent a _different_ amount in a Pedersen commitment than was originally intended, fooling the network and inflating supply in an opaque asset. In short, breaking soundness is not a practical risk. The computational complexity required to pull off such a stunt (barring an arguably far-off-in-the-distance breakthrough that breaks the entire internet's security) is absurdly, time-scale-of-the-universe high.
The second class is implementation flaws leading to detectable inflation. These can come in all shapes and sizes, and have affected transparent assets (like Bitcoin in [two](https://en.bitcoin.it/wiki/Value_overflow_incident) separate [incidents](https://bitcoincore.org/en/2018/09/20/notice/)) and opaque assets (like [Monero](https://www.getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html)). In the case of one Bitcoin incident, inflation did occur, but nodes chose to fork the blockchain to revert inflated funds. In the other linked Bitcoin incident and Monero incident, it was verified that no inflation occurred.
The third class is implementation flaws leading to undetectable inflation. Such flaws could arise in many ways, but are limited to opaque assets (like Monero or shielded Zcash) where it is not possible to simply count the currently-available supply. Such a flaw affected [Zcash](https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/). In this case, it is worth noting that the use of transparent fund migration means that an attempt to move enough exploited funds through the transparent Zcash pool could be detected and would result in any remaining funds (including those of honest users) being [permanently frozen](https://electriccoin.co/blog/defense-against-counterfeiting-in-shielded-pools/). It could be possible to modify the Monero protocol to produce similar supply detection, but this introduces additional risks, reduces privacy and fungibility, and would still require a decision relating to fund freezing; there are no plans to do this.
So what's the takeaway? It's very important to note that not all inflation-related problems are created equally. It's safe to say that the practical risk of an implementation flaw is _far greater_ than that of a common computational hardness assumption break.
Notably, the use of a transparent asset is not sufficient to guarantee safety of funds. It is true that supply transparency means that inflation can in theory be detected by an appropriate implementation, but the remediation of supply inflation could mean that transactions are reverted and honest funds are affected. Further, transparent assets would not be immune from a (very unlikely) break of a cryptographic hardness assumption that results in key recovery and theft of funds.
In contrast, the use of an opaque asset introduces the risk of implementation flaws that may or may not be detectable because of the underlying mathematics of commitments and more complex proving systems. The use of mitigating approaches like transparent migrations can assert eventual available supply consistency, but this comes with the risk of losing honest funds too. Reviews and external audits of code and new mathematical constructions becomes especially important as a way to mitigate, but certainly not eliminate, these risks.
At the end of the day, there are tradeoffs inherent in supply-audit design choices. You can choose to represent amounts in the clear, like Bitcoin does; you can be sure that the supply is what you expect it to be (or fork to ensure this in case of exploited inflation), but you sacrifice fungibility and could expose users to personal risk. Or you can choose to hide amounts like (shielded) Zcash or Monero do; you improve privacy and fungibility, but at the cost of offloading supply soundness guarantees to the correctness of proof and signature constructions.
If your personal use case requires an absolute, 100%, no-holds-barred guarantee of supply, and you understand the risks inherent with this, then you need a transparent asset. But if you want to mitigate the risks associated with visible amounts, and are willing to accept the shift in risk onto proof system implementation correctness, then choose an asset focused on privacy and fungibility. There's no silver bullet here, but a necessary and careful analysis of your priorities and the tradeoffs you're willing to make for them.
