Clarify Merkle Tree：see how centralized exchanges "certify their innocence"

Nov 11, 2022

Based on Merkle Tree’s proof model, exchanges can prove whether the assets held by each user are included in the exchange reserves, but this scheme still has flaws.

Written by: Babywhale, Foresight News

Original Link: https://foresightnews.pro/article/detail/18550

In February 2019, Bitcoin and blockchain infrastructure company Blockstream published a blog post titled “Standardizing Bitcoin Proof of Reserves,” which explained how to self-certify the Bitcoin reserves of institutions such as exchanges and control over those reserves. Blockstream initially researched the scheme to prove to auditors the Bitcoin reserves on the Bitcoin sidechain Liquid Network, and later developed into a specification for Bitcoin Proof of Reserves.

Before Blockstream, the variety of verified schemes made it difficult for users to understand the reserves of each exchange. Additionally, there is a risk of funds being stolen during the transfer of assets in signed transactions due to the need to verify ownership of private keys.

This scheme is implemented through Bitcoin’s special UTXO (unspent transaction output) transaction format, by constructing a transaction output that contains all of the exchange’s bitcoin reserves, but at the same time constructing an invalid input. The transaction would be rejected by the network when broadcast and would not result in an actual transaction, but the transaction would still serve as proof of the amount of Bitcoin controlled by the exchange.

In fact, as early as 2014, there was a discussion in the Crypto community about how exchanges would certify their reserves to auditors. After Blockstream proposed Bitcoin’s proof-of-reserve scheme and joined BIP, the market began to study a more detailed scheme, and the proof model based on Merkle Tree is a scheme generally recognized by the current market.

U.S.-based cryptocurrency exchange Kraken explained its Proof of Reserves scheme in more detail. Kraken said that the so-called PoR (Proof of Reserves) is an independent audit conducted by a third party. The auditor will take an anonymous snapshot of all account balances, aggregate them into Merkle Tree, and obtain Merkle Root — a unique combination of data that identifies these balances generated when the snapshot is created.

Auditors then collect digital signatures generated by Kraken that prove ownership of on-chain addresses through publicly verifiable balances. Finally, auditors compare and verify that these balances exceed or match the client account balances shown in the Merkle Tree to determine whether the exchange holds sufficient reserves.

To briefly explain, the underlying data of Merkle Tree is the Hash generated by the asset data held by each account, and then Merkle Tree generates a new Hash through two hashes, and so on, the final Hash represents the assets owned by the exchange. The total amount of assets, which should be greater than or at least equal to the assets held by all users. The biggest reason why this scheme can be accepted is that each user’s asset data is included. If the exchange wants to tamper with any data in the process, it will have a great impact on the final data. (The reason for the impact comes from the algorithmic characteristics of Hash generation, which will not be repeated here).

Although this scheme proves that the exchange has enough ability to redeem all user assets when audit conducting, it also has certain shortcomings. For example, it is impossible to prove that the private key is exclusively owned, whether the assets during an audit are temporarily borrowed, how to prove that the exchange funds (equivalent to owner’s equity) are segregated from user assets (equivalent to exchange liabilities) and the prudence of the audit itself, etc.

In addition to Kraken, the cryptocurrency exchange BitMEX has disclosed its scheme to verify the Bitcoin reserves held by the exchange in 2021. The scheme also adopts the Merkle Tree-based proof mode to generate an ID for each user’s account, enabling users run a Bitcoin node by themselves, and then run this set of procedures to verify the account assets and the total assets of the exchange in each Bitcoin block height.

BitMEX also described its user privacy considerations when the proposal was released. If the data is made public, the assets of all users will also be disclosed. BitMEX plans to divide the assets of users to a certain extent, and combine part of the asset data of different users to form a Merkle Tree, which will be exposed immediately when it is first disclosed. It is also difficult to observe the user’s asset distribution and track its operations in the future.

Although the FTX incident sounded the alarm for us and promoted the further development of the transparency of exchanges, in fact, the current asset verification scheme still has many loopholes including the above shortcomings. In terms of many details, it is still difficult for the exchange to “certify itself”. The transparency of centralized institutions has always been an issue that has been widely concerned and discussed. Insufficient transparency will cause investors to worry, but too much transparency may expose commercial secrets to a certain extent, and these contradictions do not only occur in the field of Web3.

To give a simple example, many of the current centralized exchanges have launched cryptocurrency financial products. On the premise that the exchange does not abuse these assets, it may be partly used for quantitative trading, partly for hedging risks, partly in DeFi, partly for mortgage lending, and it is difficult for the exchange itself to make all its uses public.

At present, the proof of reserves to prove the redemption ability of the exchange is only the beginning. How to prove that the users’ funds are not confused with exchanges’ funds, how to prove that the financial products are not a Ponzi scheme, and how to prove the acceptance ability of the market maker are the follow-up problems that exchanges need to think about and solve.

Wu Blockchain

Discussion about this post