[continued from part III]

Zero-knowledge proofs

Borrowing on a principle from blockchain ideologues that that trusted intermediaries introduce vulnerabilities, we can instead fallback on a purely cryptographic approach to constructing a proof of solvency. The first attempt at this in the literature dates to a paper from CCS 2015 introducing a scheme called Provisions. The authors independently tackle both sides of the accounting book.

• Liabilities are publicly made available as a set of cryptographic commitments, with one commitment for the each customer balance. Commitments are private in the sense that the number is not publicly visible, but it can be selectively disclosed. Each commitment is opened only for the specific customer, for example by emailing them with the information required to verify the committed value. This part effectively crowd-sources verification, by allowing every customer to confirm that their balance is represented accurately. More importantly, the commitment scheme uses a construction that also allows committing to a total balance which is verifiably equal to the sum of individual commitments. That figure represents the total amount of customer claims to cryptocurrency stored by the customer. While the proof implies a public commitment to the sum, that number is not publicly disclosed. As such the amount of assets under custody can remain confidential as a proprietary business metric.
• Proof of assets is done using zero-knowledge proofs, over a cover set that includes the actual custodian addresses as a proper subset. The main contribution of the paper is a provably secure protocol for doing that demonstration without disclosing specific addresses or for that matter total assets. True custodian addresses are obscured among a larger cover set, which could be all addresses on the blockchain if one wanted maximum privacy. The prover uses zero-knowledge proofs over the entire set to demonstrate that the smaller subset for which she knows the private keys— in other words, custodian keys— collectively have enough bitcoin balance to exceed the liabilities committed to in the first step. Again this proof is made public for anyone interested to verify.

Falling short of the goal

At a high level, this model certainly succeeds in removing trust in a third-party accounting firm, allowing anyone including those who have no business relationship with the custodian to verify its financial health. But looking closer at the paper reveals a number of limitations:

1. Proving that liabilities were represented accurately now depends on the diligence of individual customers. This is really the same problem faced by trusted third-party accountant  in a different disguise: ledger integrity. Only this time there is a fighting chance for discrepancies to be uncovered: each customer can verify if their own balance was represented accurately. So the assurance provided by this “proof” is only as good as customer diligence in validating the ledger. It remains an article of faith that such participation will materialize. (Much like the belief that open source software must be getting more secure over time, because if there were any vulnerabilities someone, somewhere looking at it surely would have said something.) Consider that the level of effort involved is non-trivial and involves running random software to verify the commitment.
2. Limitations in the protocol, most importantly the lack of support for multi-signature addresses. This is a deal-breaker in the current incarnation: if there are few things cryptocurrency community can agree on, one of them is that the additional security and redundancy provided by multisig addresses is crucial for risk management when dealing with large amounts. This limitation affects core functionality, not just privacy. Provisions can not be used if the custodian itself is using multisig addresses, even if every other address in the cover set were P2PKH. (In other words, even if we are willing to give up privacy by exposing P2SH custodian addresses among the P2PKH decoys.)
3. Compatibility with hardware wallets. There is a more subtle implementation problem with incorporating a Provision-type design into an existing cryptocurrency storage system. The zero-knowledge proofs require using private key material in non-standard constructions. By “non-standard” we do not mean that they are dangerous or incorrect, only that these are not garden variety algorithms such as ECDSA signature, ECDH key-exchange or ECIES encryption that are widely supported. This matters because of another tried-and-true risk management strategy: using dedicated cryptographic hardware to store high value keys. Off the shelf hardware such as PCs or phones are not ideal for keeping keys due to their large attack surface. Special purpose devices such as hardware-security modules, smart cards and USB tokens are designed and validated to stringent threat models for the safekeeping of secrets. Their simplicity is an advantage for security becomes a disadvantage when contemplating fancy new protocols: these devices are deliberately not extensible. In other words, they support a fixed array of algorithms such as ECDSA and they can not be easily programmed— short of the manufacturer introducing an update— to perform arbitrary new computations using secret keys.
4. Not applicable to fiat currencies. Bank account balances are not verifiable by cryptographic techniques and will remain that way, short of all financial institutions agreeing on a new standard for digitally signed statements. That is not a problem for custodians only handling cryptocurrency. But in every other situation where fiat currency coexists with digital assets, it means the proof of solvency is incomplete. Recall the original reason why proofs are carried out independently for each asset class: to prevent the custodian from shifting balances around between currencies. Putting on the tinfoil hat, a paranoid customer could argue the custodian completed the solvency proof by temporarily using fiat deposits to purchase cryptocurrency.
   Without independent verification of fiat assets against liabilities, there is no way to disprove that line of conspiratorial thinking. (As an aside: stablecoins at first glance offer a solution. For the purpose of the proof, custodian converts its dollar assets into a stablecoin pegged one-to-one against the US dollar. Since stablecoins are tokens represented on a blockchain, the usual cryptographic proofs could then be carried out over control of private-keys in that setting. But the idea that this switch will dispense with third-party trust is illusory: the integrity of the stablecoin depends on its issuer. Transposing the problem from an old-fashioned attestation about bank statements into stablecoin balances introduces a host of new trust assumptions. Specifically that the issuer is carefully maintaining that 1:1 ratio by only minting new coins in proportion to fiat deposits and will allow timely conversion of the stablecoin back into USD on demand— just ask Tether customers how well that is working out.)

Internal controls vs externally verifiable proofs

As the state of the art advances, new protocols may well overcome some of these limitations. But there are more fundamental problems with a public cryptographic proof: possession of keys alone does not equate to sane procedures and risk management. Recent bankruptcy of the Canadian exchange QuadrigaCX is a great example of this. In court filings, company representatives identifies the root cause of $130M+ USD in customer funds being stuck: Quadriga used a single laptop for cold storage, with the password only known to the company founder who recently passed away. That is a staggering failure of internal controls: failure to identify the founder as key-person risk, failure to identify laptop as single point of failure. (There are many other ways this could have gone sideways, including disk corruption on that device.) But as long as one person at Quadriga had access to that cold wallet, they could have produced Provisions-style proofs and passed the solvency test with flying colors.

That is the intrinsic limitation of externally verifiable cryptographic proofs: they can demonstrate that the custodian controls the necessary secret keys at a point in time, but as the saying goes past performance is no guarantee of future results. By contrast a trusted-third party examination need not be limited to quantifying assets/liabilities. They can look into the actual design of cryptocurrency storage— is it a USB drive under the mat or geographically distributed HSMs? They can review policies & procedures around how funds are moved, interview select employees, ask for evidence showing that written procedures are being followed faithfully in day-to-day operations. None of that can guarantee the custodian will not experience a security breach or commit a serious blunder resulting in lost funds. But knowing an organization has consistently applied sound internal controls is at least as valuable a signal as seeing public proof that all the keys are accessible; unlike a point-in-time demonstration, organizational culture around risk management is indicative of future behavior.

The good news is that these two approaches are not mutually exclusive: we can combine third-party audits with partially-public proofs. The starting point is to revisit some of the privacy assumptions behind Provisions: from the perspective of the custodian, what are the zero-knowledge techniques trying to protect and how realistic is that expectation?

[continued]

CP

Updated 2/17: Additional comment on stablecoins.