Vitalik on having a safe Centralized Exchange using proof of solvency
With the recent failure of FTX, it’s important to discuss how to make it impossible for centralized exchanges (CEX) to steal funds from its customers. To regulate or decentralize, that is the question. (Historical moments like these warrant a Shakesprean touch.) While some say “regulate” and some say “decentralize”, yet another possibility is to use technology in general and cryptography in particular. Cryptography could allow us to avoid regulation — which often has adverse side-effects — and avoid decentralization — which can be inefficient — but still make it hard or impossible for unregulated centralized crypto exchanges to steal customer funds. Vitalik Buterin discusses cryptographic solutions to the stealing problem in his article from Nov 19th “Having a safe CEX: proof of solvency and beyond”.
In this short post, I will pull out some quotes that hopefully summarizes a few his key points for a non-technical audience.
User error
Preventing user errors by giving exchanges power will mean they have the power to do good and evil. Vitalik writes:
… exchanges need to support many different chains, and systems … would need to have code written in different languages to support different platforms, and cannot be implemented at all on others (notably Bitcoin) in their current form. In the long-term future, this can hopefully be fixed with technological upgrades and standardization; in the short term, however, it’s another argument in favor of custodial exchanges remaining custodial for now.
This leads us to this spectrum from don’t be evil to can’t be evil.
But it’s worth getting to the fundamental issue with the right half of this design space: dealing with user errors. By far the most important type of error is: what if a user forgets their password, loses their devices, gets hacked, or otherwise loses access to their account?
Exchanges can solve this problem: first e-mail recovery, and if even that fails, more complicated forms of recovery through KYC. But to be able to solve such problems, the exchange needs to actually have control over the coins. In order to have the ability to recover user accounts’ funds for good reasons, exchanges need to have power that could also be used to steal user accounts’ funds for bad reasons. This is an unavoidable tradeoff.
Proof of solvency
If you prove that customers’ deposits equal X (“proof of liabilities”), and prove ownership of the private keys of X coins (“proof of assets”), then you have a proof of solvency: you’ve proven the exchange has the funds to pay back all of its depositors.
If the information about all user account deposits is public, then the exchange can’t cheat because anybody can see how much the exchange owes its users. Thus, the exchange must prove they have this amount of assets. Due to the sensitive nature of this information, we can’t display all accounts and their balance. No, we must use cryptography to protect privacy. This is where a Merkle tree, as illustrated below, comes in.
…what if an exchange that has 1390 ETH of customer balances but only 890 ETH in reserves tries to make up the difference by adding a -500 ETH balance under a fake account somewhere in the tree?
Eve and Fred’s proof verification would also fail, because the intermediate node above Henry has -230 total ETH, and so is also invalid! To get away with the theft, the exchange would have to hope that nobody in the entire right half of the tree checks their balance proof.
Implementation
There are a few ways for centralized exchanges to implement this. The simplest solution is to
Keep a few public long-term-use addresses. The exchange would generate a few addresses, publish a proof of each address once to prove ownership, and then use those addresses repeatedly. This is by far the simplest option, though it does add some constraints in how to preserve security and privacy.
Read more
If you understood this blog post and want to read more, read Vitalik’s full article here.
Learning cryptography
Thanks to my bachelor’s in Mathematics and my tiny knowledge of python programming, I could grasp some — but not all — of the concepts in Vitalik’s article. I want to learn more cryptography since my field of study was closer to machine learning and statistical inference theory which is a different kind of mathematics. I feel like a novice when reading Vitalik’s posts. If you have recommendations for books and online courses on cryptography, please send them to me, as I’m keen to learn more about this important topic.
