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 essential 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 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, 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. Even when denominated, transparent amounts can harm privacy and fair use.
Other projects make different design choices intentionally, using different mathematics. In assets focusing more 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 benefits 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 some mathematical issues (like the discrete logarithm problem) are computationally complex. It is impossible to prove these complex problems, but decades of research and use imply this. If an adversary could efficiently solve the discrete logarithm problem, 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 initially 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, affecting transparent assets (like Bitcoin in two separate incidents) and opaque assets (like Monero). 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 impossible to count the currently-available supply. Such a flaw affected Zcash. In this case, it is worth noting that 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. It could be possible to modify the Monero protocol to produce similar supply detection, but this introduces additional risks, reduces privacy and fungibility, and still requires 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 typical computational hardness assumption break.
Notably, using a transparent asset is insufficient to guarantee the safety of funds. Supply transparency indeed means that an appropriate implementation can detect inflation. Still, 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, using 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. Using mitigating approaches like transparent migrations can assert eventual available supply consistency, but this comes with the risk of losing honest funds. Reviews and external audits of code and new mathematical constructions become especially important to mitigate, but certainly not eliminate these risks.
There are tradeoffs inherent in supply-audit design choices. You can represent amounts in the clear as 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 hide amounts as (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 supply guarantee, and you understand the inherent risks, 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, 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.
