Defects and Improvement Ideas of Merkle Tree Reserve Proof

With trust in centralized institutions collapsing after the collapse of FTX, CZ called on exchanges on Twitter to adopt Merkle Tree's proof-of-reserve method to prove that they did not misappropriate user assets. Several exchanges then responded and actively prepared proof of reserves to reassure customers that their funds are safe. However, the Merkle Tree reserve proof method has some fundamental flaws. Specifically, it is easy for centralized institutions to bypass the non-appropriation check that this proof-of-reserve method hopes to achieve through some paths.

In the following, I describe two fundamental flaws of existing Merkle Tree proof-of-reserve methods and offer some ideas on how to improve them.

How Existing Proof-of-Reserves Methods Work

In order to alleviate the information asymmetry between users and centralized institutions, the existing proof of reserves usually adopts the traditional audit method, that is, a third-party audit company trusted by all parties issues an audit report to prove that the centralized institutions hold on-chain The amount of assets (proof of reserves) matches the sum of user asset balances (proof of liabilities).

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

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

After the snapshot of the Merkle Tree and the confirmation of the ownership of the address on the chain are completed, the audit agency will check the total amount of assets at both ends of the liabilities and reserves, and then determine whether the centralized institution has embezzled user funds.

Drawbacks of Existing Proof-of-Reserve Methods

1. Possibility of passing audits using borrowed funds

One problem with the proof-of-reserve approach is that the audits are based on a specific point in time and usually only happen every few months or even years. That said, centralized exchanges still have the opportunity to embezzle user funds and easily fill the gap during audits by borrowing.

2. The possibility of colluding with external funding parties to pass the audit

Providing an associated digital signature is not the same as ownership of the asset at the corresponding address. Centralized institutions can collude with external funding parties to provide proof of assets on the chain. External funders can even use the same fund to provide asset certification for multiple institutions at the same time. Current audit methods are difficult to identify such fraudulent behavior.

Some Thoughts on Improving Proof Methods

An ideal proof-of-reserve system should provide auditors and end users the ability to perform real-time checks of liabilities and reserves. However, it also comes with high costs and/or disclosure of user account information. In the case of obtaining enough data, the third-party auditing company can even infer the user's position information based on the anonymous data.

In order to prevent the possibility of the reserve certificate being falsified during the audit and not at the cost of leaking user information, I propose the following two main ideas:

1. Spot check 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 through the fear of being caught by random audits.

How to practice: Audit requests can be randomly sent to centralized institutions by trusted third-party auditors. After receiving the instruction, the centralized institution needs to generate a Merkle Tree, which contains the user account balance (proof of liability) marked according to the block height number at that specific point in time.

2. Use the MPC-TSS scheme to accelerate the proof of reserves

During random audits, centralized institutions are required to provide proof of reserves within 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 a centralized institution can store most of its assets in a few fixed addresses (such as hot or cold wallets), the total amount of funds stored in a large number of on-chain addresses is still large. Aggregating funds from all of these addresses to a small number of public addresses during an audit is a very time-consuming task. This time gap also gives enough room for misappropriation to seek loans or financial help to fill the gap.

Is it possible for centralized institutions to prove reserves directly on the addresses where they actually hold assets, without consolidating on-chain assets to a small number of addresses? One possible approach is to utilize the MPC Threshold Signature Scheme (MPC-TSS) technique.

In a nutshell, MPC-TSS is an advanced encryption technology that divides a private key into two or more private key shards, which are held by multiple parties after encryption. 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 hosting technology is also a product that Cobo has launched recently.

Under this solution, a third-party audit institution (which can be a law firm, an audit firm, a custodian, a trustee, or even the regulator itself) can hold a private key shard, while the centralized organization holds the rest of the private key. key fragmentation. As long as the "threshold" is set to a number greater than one, all assets will still be under the control of the centralized authority. At the same time, it should be pointed out that in order for the centralized organization to generate a large number of addresses co-managed by the auditor, the MPC-TSS co-management solution needs to support the BIP32 protocol. Owning a piece of private key sharding, the audit institution can definitely know the set of addresses on the chain of the centralized institution, and count the asset scale of the highly centralized institution in the specified block.

thank you

Thanks to Cobo colleagues including Discus Fish, Lily King, Jeanette, Tavia, Linfeng, Ellaine for all their valuable discussions and constructive suggestions during the writing of this article.

Cobo is a world-leading digital asset custody and blockchain technology provider headquartered in Singapore. As an innovative company driven by technology at its core, Cobo focuses on building scalable infrastructure to promote the development of the Web 3.0 field.