Vitalik Buterin, CEO and co-founder of Ethereum, suggested employing zk-snarks to improve the security and dependability of Merkle tree exchange proof of reserves and in keeping client funds in some manner, such as a validium smart contract. CZ concurred with the idea and said that Binance would use it to make it open source.
Implementing a Central Exchange for Solvency Evidence
Every time a well-known CEX crashes, according to Vitalik, a joint investigation is conducted to see whether or not users can employ cryptographic methods to resolve the issue.
Instead of only using traditional methods, one should also check corporate governance and the backgrounds of those in charge of managing the exchange, as well as government licenses and auditors. As a result, exchanges could develop novel cryptographic proofs proving that the monies they have on hand are enough to meet their obligations to their users.
Additionally, he continued, the cryptocurrency exchange may create a system that would prevent it from withdrawing a depositor's money without that person's consent. The existing private and ineffective leakage, on-chain DEX, is regrettable. On the other hand, people might explore the whole spectrum between the "don't be evil" praising excellent CEX and the "can't be evil."
Zk-SNARK, or zero-knowledge succinct non-interactive argument of knowledge, is a proof architecture that demonstrates the presence of specific knowledge, such as a secret key, without revealing that understanding or conversing with either the prover or the verifier.
Operating and Working Toward Solvency
The post claims that demonstrating the exchange's solvency involves showing it has funds to cover all of its deposits. In this scenario, conversations started about how to address the other side of the issue, where demonstrating the total amount of client deposits (demonstrating liabilities) and demonstrating ownership (demonstrating assets) results in demonstrating solvency.
A list of (username and balance) pairs published online is the simplest approach to demonstrate deposits. Every user can confirm that their balance is included in the list, and anyone can view the entire list to verify that every balance is a non-negative total sum that has been declared.
However, there may be adjustments made when sending each client their salt value privately and hashing pairs of username, salt, and balance. The Merkle tree technique, used when there are balance and pattern leakages, is used to achieve privacy and policy.
The customer balance table is placed into a Merkle sum tree using the Merkle tree approach. A Merkle sum tree has nodes that are (balance, hash) pairs. The salted username hashes and individual customer balances are represented by the leaf nodes in the bottom layer. Each higher-layer node's balance is the average of the two balances below it, and each node's hash is the average of the two nodes beneath it. A Merkle sum proof is a "branch" of the tree made up of the sister nodes that extend from a leaf to the root, just like a Merkle proof.
