Cobo CTO: Merkle Tree Reserve Proof’s Flaws and Improvements

This article explains two fundamental flaws in the existing Merkle Tree reserve proof method and proposes some ideas on how to improve it.

Written by: Jiang Changhao, Co-founder and CTO of Cobo

With the collapse of trust in centralized institutions after the collapse of FTX, CZ called on exchanges on Twitter to adopt Merkle Tree's proof of reserves method to prove that they did not misappropriate user assets. Subsequently, many exchanges began to respond and actively prepared proof of reserves to assure customers that their funds are safe. However, the Merkle Tree proof of reserves method has some fundamental flaws. Specifically, centralized institutions can easily bypass the non-misappropriation check that this proof of reserves method hopes to achieve through some paths.

Below, I will explain two fundamental flaws of the existing Merkle Tree reserve proof method and provide some ideas on how to improve it.

How existing proof of reserves methods work

In order to alleviate the information asymmetry between users and centralized institutions, existing reserve proofs usually adopt traditional audit methods, that is, a third-party audit company trusted by all parties issues an audit report to prove that the number of assets held on the chain by the centralized institution (reserve proof) matches the total asset balance of users (liability proof).

For proof of liability, a centralized institution needs to generate a Merkle Tree containing user account information and asset balances. The Merkle Tree essentially creates an anonymized and unalterable snapshot of the user account asset balances. Each user can independently calculate the hash of their account and determine whether their account is included in the Merkle Tree.

For proof of reserves, the centralized institution needs to provide the on-chain addresses it holds and verify and audit them. A common practice is to require the centralized institution to provide a digital signature to prove its ownership of the on-chain address.

After the Merkle Tree snapshot and on-chain address ownership confirmation are completed, the auditing agency verifies the total amount of assets on both the liability and reserve sides to determine whether the centralized institution has misappropriated user funds.

Flaws of existing proof-of-reserve methods

1. Possibility of using loan funds to pass audit

One problem with the Proof of Reserves approach is that audits are based on a specific point in time and are usually only conducted every few months or even years. This means that centralized exchanges still have the opportunity to embezzle user funds and easily fill the gap during the audit period through loans.

2. Possibility of collusion with external funding parties to pass the audit

Providing a digital signature is not the same as ownership of the assets at the corresponding address. Centralized institutions can collude with external funding parties to provide proof of assets on the chain. External funding parties can even use the same funds to provide asset proof for multiple institutions at the same time. Current audit methods make it difficult to identify such fraud.

Some ideas on improving the proof method

An ideal reserve proof system should provide auditors and end users with the ability to check liabilities and reserves in real time. However, it will also bring high costs and/or the disclosure of user account information. With enough data, third-party auditing companies can even infer user position information based on anonymous data.

In order to prevent the possibility of reserve proofs being forged during audits without leaking user information, I propose the following two main ideas:

1. Random audit

Random audits at unpredictable intervals will make it difficult for centralized institutions to manipulate account balances and on-chain assets. This approach can also deter misconduct by fearing being caught by random audits.

How to implement: Audit requests can be randomly sent to a centralized institution by a trusted third-party auditing agency. After receiving the instruction, the centralized institution needs to generate a Merkle Tree containing the user account balances (debt proof) at that specific point in time, marked according to the block height number.

2. Using the MPC-TSS solution to speed up reserve proof

During random audits, centralized institutions need to provide proof of reserves in a very short period of time. This is a big challenge for centralized institutions (such as exchanges) that manage a large number of on-chain addresses for users. Even if centralized institutions can store most of their assets on a few fixed addresses (such as hot wallets or cold wallets), the total amount of funds stored in a large number of on-chain addresses is still large. It is a very time-consuming task to aggregate the funds in all these addresses into a few public addresses during the audit. Such a time difference also gives misappropriation behavior enough room to seek loans or financial assistance to fill the gap.

Is it possible for a centralized institution to prove reserves directly on the addresses where it actually holds assets, without consolidating on-chain assets to a few addresses? One possible approach is to utilize the MPC Threshold Signature Scheme (MPC-TSS) technology.

In summary, MPC-TSS is an advanced encryption technology that divides a private key into two or more private key shards and holds them by multiple parties after encryption. The holders of these private key shards can work together to sign transactions without exchanging their respective private key shards or merging private keys. This MPC-TSS custody technology is also a product that Cobo has recently launched.

Under this solution, a third-party auditing agency (which can be a law firm, auditing firm, custodian, trustee or even the regulator itself) can hold one private key shard, while the centralized agency holds the remaining private key shards. As long as the "threshold" is set to a number greater than one, all assets will remain under the control of the centralized agency. It should also be pointed out that in order for centralized agencies to be able to generate a large number of addresses co-managed by auditors, the MPC-TSS co-management scheme needs to support the BIP32 protocol. By owning a private key shard, the auditing agency can know the address set on the centralized agency chain with certainty and calculate the asset size of the centralized agency at a specified block height.

We would like to thank Cobo colleagues including Discus Fish (Shenyu), Lily King, Jeanette, Tavia, Linfeng, and Ellaine for all the valuable discussions and constructive suggestions during the preparation of this article.