Vitalik Buterin proposes zk-SNARKs to strengthen Merkle tree’s proof of reserves
Ethereum CEO and co-founder Vitalik Buterin proposed using zk-snarks to strengthen the privacy and robustness of Merkle tree exchange proof of reserves and in holding client funds in some kind, like a validium smart contract. CZ also agreed with the proposal and declared to implement it in Binance to make it open source.
Central exchange for implementing proof of solvency
Vitalik said that each time a prominent CEX blows up, a joint inquiry develops; it concerns whether or not users can utilize cryptographic techniques to solve the problem.
Rather than merely relying on conventional means, including government licenses and auditors and examining the corporate governance and the backgrounds of the individuals coordinating the exchange. Therefore, exchanges could innovate cryptographic proofs demonstrating that the funds they hold are sufficient to coverage of their liabilities to their users.
Moreover, he added, the crypto exchange could generate a system where it can’t withdraw a depositor’s funds without their acknowledgment. On the other hand, individuals could explore the entire spectrum between the dubbed “don’t be evil” admiring perfect CEX and the “can’t be evil”; however, current private and inefficient leakage, on-chain DEX, is deplorable.
Buterin identified that the post is intended to move exchanges closer toward trustlessness. Therefore, zk-snarks could be the solution for the technical limitations and newer and more robust ideas.
Zero-Knowledge Succinct Non-Interactive Argument of Knowledge,” or “zk-SNARK,” refers to a proof architecture in which one can illustrate possession of particular knowledge, such as a secret key, without uncovering that understanding or having conversations with either the prover or the verifier.
Working and operating on solvency
According to the post, proof of solvency works in a manner that proves the exchange accumulates funds in paying back all of its deposits. In this case, discussions commenced on how to solve the other side of the problem, where proving the total size of customers’ deposits (proof of liabilities) and proving ownership (proof of assets) leads to proof of solvency.
The easiest way to prove deposits is by publishing a list of (username and balance) pairs. Each user can verify the inclusion of their balance in the list, and anyone can check the complete list to see: every balance is a non-negative total sum is claimed amount.
Nonetheless, there can be changes in becoming (hash (username, salt, balance) pairs and sending each client privately their salt value. When there are balance and pattern leakages, there is a desire for privacy and policy, dubbed the Merkle tree technique.
The Merkle tree technique entails inserting the customer balance table into a Merkle sum tree. Each node in a Merkle sum tree is a (balance, hash) pair. The bottom-layer leaf nodes represent individual customers’ balances and salted username hashes. The balance in each higher-layer node is the sum of the two balances below it, and the hash is the hash of the two nodes below it. A Merkle sum proof, like a Merkle proof, is a “branch” of the tree made up of the sister nodes that run from a leaf to the root.
