Learning from the Pain：What CEX Can Do to Prove Innocence and Improve the Security of Funds

When it rains it pours, the FTX incident has hit the sluggish crypto market even harder: the trust of users on CEXs has so worn out that withdrawals are made at an unprecedented level. In order to retain users and funds, CEXs released proof of reserve to prove innocence. Vitalik has also posted an article discussing proof of solvency, shedding lights on how CEXs can be more secured from a technical perspective. This article will discuss how CEXs can prove innocence and achieve sustainable growth based on interpretation of Vitalik's article, various solutions of proof by CEXs and proposals from various parties.

1. Demonstrate Solvency by Technical Solutions

To prove solvency of a CEX is to demonstrate that funds of users are not misappropriated, which is also commensurate to proving the legitimacy of an inequality: total assets of CEX (proof of assets) is equal to or greater than total deposits of users (proof of liability). In addition to the declaration of the two values, the authenticity of the numbers must be valid, that is to say, the ownership of these assets always belongs to the CEX so that the balances of user accounts are not tampered.

All types of technical solutions are based on the above two aspects. For proof of assets, a centralized institution must provide on-chain addresses it holds, validated and audited. A common practice is to provide digital signatures to prove ownership of the on-chain addresses. It is commonly adopted because of the simplicity of implementation. Current arguments are on proof of liabilities, and the Merkle Tree as proof of reserve recently released by various CEXs is the representative proof of liabilities.

1.1 Merkle Tree as Proof of Liabilities

Merkle tree is a common data structure in blockchain: it is a typical binary tree structure that consists of a root node, a set of intermediate nodes and a set of leaf nodes. Each upper-level intermediary node (parent node) of the Merkle tree is the hash of the two underneath intermediate nodes (child nodes), and the final root node is obtained after such a layer-by-layer calculation. That is to say, the root node contains the information of all leaf nodes. Any change in the underlying data will be passed to parent node and reach the root node layer by layer. It is often applied to quickly prove the existence or non-existence of a particular element in a set, to validate the identicalness by comparing large datasets, and to locate changes, etc.

A Merkle Tree is utilized by CEXs in creating an anonymized and tamper-proof collective snapshot of account balances of users in order to prove that account balances are not tampered, which is achieved fundamentally by hashing username or UID of users (a number that is only known by CEX and the account owner will be added prior to the hashing process) and associate account balance as leaf nodes. If the correct root cannot be retrieved by inputting the account balance following the path on Merkle Tree, the assets are misappropriated by the CEX.

Figure 1: Merkel Tree as proof of reserve

However, as Vitalik pointed out, a small bug exits in general Merkle Tree: it cannot be deemed directly as reserve proofs because it does not identify negative values for users. As demonstrated in the figure below, if an exchange has total deposit of 1390 ETH, but 500 ETHs are misappropriated, only 890 ETH remain in the reserve. Then this CEX will claim that the total deposit is 890 ETH. To conceal the misappropriation, a forged account of -500 ETHs will be added somewhere in the Merkle Tree. After hashing, it will appear as irregular string of numbers regardless of positive or negative numbers so that other users cannot distinguish. The Merkle Tree obtained with this manipulated account would perfectly contain the balance information of other users, and validations of other users will always be legitimate. The vulnerability can be distinguished by auditing, but if a collusion is formed, the Merkle Tree will be null and void.

Figure 2: Small bug in Merkle Tree

Regarding the defect of negative value, Vitalik proposed an improved solution called Merkle Sum Tree in his paper. Each node of the Merkle Sum Tree contains two pieces of information¬– balance and hash. The underlying leaf node is the balance and hash of username. In each upper-level node, the balance is the sum of the balances of the two underneath nodes, and the hash is the collective hash of the two underneath nodes, that is to say, the balance and hash of these two nodes are hashed together. Displaying the balance separately is conducive for users to identify negative values, thus exposing CEX's misappropriation of user assets. As illustrated above for instance, Greta will find Henny's balance negative when implementing self-validation; Eve and Fred will both find the sum of Greta and Henny's balances negative; all 3 of them will fail in the validation.

After the modification, the procedure of releasing Merkle Tree as proof of reserve for CEXs will be as the following:

• Generation of Merkle Tree as proof: A snapshot of all user balances can be generated by appointed external auditing firm or by the CEX per se, which are then aggregated into a Merkle Sum Tree.
• Validation: The auditor compares and verifies that the balance controlled by the CEX is equal to or greater than the number provided by the Merkle Sum Tree, hence indirectly proving whether the user assets are backed in full. Users are able to conduct self-verification: if the value of username and account balance are contained in the Merkle Sum Tree, and never a negative value is found during the hashing, the CEX can be deemed as not guilty in tampering account balance of users, therefore not misappropriating assets of users.

1.2 Improved Merkle Tree

Proving user balances with Merkle Tree is also flawed in privacy leakage. As demonstrated in the figure below, when Charlie validates himself, the CEX must inform him the sum of David's balance, the sum of Alice's and Bob's balances, and the sum of all the balances of users on the right half of the diagram. Although users are not likely (at least not at this point) to conduct harmful behaviors with this batch of information, the privacy breach is not a comfortable thing for the CEX or the users whose balances are exposed.

Figure 3: Exposure of user balance in Merkle Tree

To address this problem, BitMEX proposes a simple and feasible solution. Account balance of users are split into several parts, and fill the underlying leaf nodes of the Merkle Tree with the split parts. In this case, the exposed balance is only in part, which can alleviate the privacy problem to some extent. For example, Fred in the picture, his account is split into 2 parts and Charlie has no clue of the total balance. However, if someone is intended to retrieve account balance of others by multiple accounts, it is feasible but with more efforts.

Figure 4: BitMEX's Improved Solution

To eliminate the vulnerability in privacy, ZK-SNARK could be the antidote. As mentioned in Vitalik's article, a Merkle Tree could be generated with all user balances, and ZK-SNARK could ensure all the balances are positive and the sum could be the claimed value. When hashing is in use to enhance privacy, the Merkle Tree path given to each user will not reveal the balances of any other users. Alternatively, a polynomial could be created with the hashed usernames and balances of all users and a KZG polynomial commitment is attached to it; the CEX only needs to proves the clarification of this polynomial. User validation could be completed by selecting one’s balance as an input variable on the polynomial and generate a proof based on the calculated result on this variable from the CEX; therefore, the polynomial commitment, the selected value and the proof could be validated by users. In a KZG commitment, the polynomial, the commitment, and the proof all have a correspondence that cannot be tampered arbitrarily, which is the same as Merkle Tree. The validation can be done without compromising privacy as it does not require "sister nodes" as the basis of proof.

1.3 Summary of Various Solutions

A comparison of the basic Merkle Sum Tree, BitMEX’s solution, ZK-SNARK Merkle Tree, and KZG polynomial commitment is summarized in the following table. For the former two, despite the risk of privacy exposure, they are simple to operate, and they seem to have no significant pitfalls at present and capable of being applied into various scenarios; while the latter two incur extra costs for CEXs as ZK-SNARK is applied for calculation of addition. KZG polynomial commitment is more advanced, but the process of calculating the commitment consumes enormous resources and involves a large number of elliptic curve point calculation, which is less like to receive mass adoption at the moment. All of the above do not require search operation from users, and are simple to validate.

Some problems remain untackled even with the above technical solutions as proof of liabilities and other commonly adopted solutions as proof of assets in presence:

First, all of these proofs of liabilities are subject to supervision of users, when users rarely conduct such censorship activities, misconduct of CEXs may not be detected. In other words, users must receive continuous education to increase the level of caution. Another approach would be peer supervision by CEXs: large CEXs could sign up for a certain number of accounts on other exchanges and deposit small amount of assets to verify their proof of liabilities.

Second, neither the proof of assets nor the proof of liabilities is instant, and the exchange could have obtained funds by borrowing before doing the proof of assets to cope with the inspection and pay the loan back afterwards. Two solutions could prevent this from happening: one is to set up a time slot for all exchanges to participate in the inspection the same time, while the other is to raid at random for auditing, which both squeeze the time and possibility for borrowing.

Third, the attestation process relies on auditing firm, when a collusion is active, all subsequent technical means are rendered useless.

Last but not least, none of these methods are mandatorily binding as CEXs can still operate in a state of insolvency. Especially in a bear market, the short-term economic distress may be so great that the exchange may not last through the next bull market, and it becomes a natural move for CEXs to “borrow” from users.

2. Semi-CEX

While various proofs mentioned earlier are to prevent CEX from misconduct, CEX is still capable of potential misconduct. If the capability of misconduct is completely striped from CEX rather than implementing precautious methods that exchanges are changed from “Don’t be evil” to “Can’t be evil”, the trust of users may be return, or even to a greater level, so that the crypto world may be boosted to a more prosperous state.

Vitalik classifies exchanges into 5 categories according to the degree of control over user funds and the convenience of misconduct, where current exchanges fall in 3 of these categories. As illustrated in the figure below, starting from the first one on the left, it has complete control over user funds and no measures are effective to monitor or prevent it from misappropriating user funds. Before the FTX crash, almost all CEXs were operated in this way. Most CEXs are now the second on the left, where the exchange controls user funds, but external human controls (i.e., auditors) are engaged for enforcement. Most DEXs fall into the first category on the right, where the exchanges have no control over user funds at all, therefore no ability for misconduct.

Figure 5: 5 different types of exchanges

Vitalik points out that CEX and DEX are not binary opposites that there is room in between full centralization and full decentralization as semi-CEX: it inherits the efficient trading system of traditional centralized exchanges and curtails the power of CEXs by, for example, multi-signature private key holders, validators, etc., thus reducing the possibility of exchange in malpractice, which are the third and fourth type on the left in Figure 5 mentioned in Vitalik’s article.

The third type of exchanges still have control over user funds, but it cannot operate in the state of insolvency. This type of exchange has not yet emerged, and some restrictions would need to be placed before launching. A possible solution may be that CEXs can be mandated to store assets on several fixed addresses controlled by multiple signatures or split the private key into several copies by MPC technology; therefore, the status of funds on exchange can be monitored through real-time or high-frequency solvency checks. In average cases, only the private key controlled by CEX itself is required to complete the signature to transfer funds. If insolvency/excessive single transfer ratio/continuous transfers are detected, other private key holders can activate emergency mode and collectively reject the transaction to freeze the account. In this case, multiple private key holders are in place to reduce the degree of centralization of CEX, thus reducing the convenience level for malpractice. This type of exchange may be an advanced and evolved form of CEX in the future.

Such exchanges will not have sustainable growth without simultaneous improvement of auditing; only by improving credibility, processing speed and degree of automation can auditor be competent in responding to such demand from exchanges.

For the fourth type of exchange, user funds are in the custody of smart contracts rather than in the hands of CEX; it is only centralized upon trading or transferring. DYDX may be considered a representative project in this type: the match-making process is completed off-chain by its own trading system, and the transaction is submitted to the Ethereum mainnet after compression. In this case, the centralized trading system facilitates the efficiency, and Ethereum, as the settlement layer, ensures the security. It has now migrated to the Cosmos ecosystem as V4, with the underlying blockchain tailored to customized scenarios, but the paradigm of centralized trading + decentralized settlement remains unchanged. This type of exchange demands a low-cost, high-security underlying blockchain as a fundamental setting, not to mention the inconvenience handling cross-chain cases compared to CEXs, and it is unlikely to become the future of CEX.

3. Learn from Traditional Finance

As Wilson, an analyst at X Research DAO, indicated in his article, current CEXs suffer from such drawbacks as excessive internal authority, lack of transparency in asset custody, internal motives of misappropriation for more profits, and lack of external censorship. Solely relying on technical methods can only be partially effective, and a set of reasonable orders must be in place to split and limit the power of CEX.

Current crypto market resembles the early financial world in a hybrid stage, where CEX is a comprehensive institution that combines various financial functions, providing commission and match-making service in floor trading, full custody of various token assets (including stablecoin), and other financial services such as wealth management. The more the services available, the more the capabilities on the assets. When an institution has too much power, it is only a matter of thought if the power will function on chasing for private gains.

The next stage of the crypto market is destined to have a more secure trading model, and it might be a shortcut to borrow wisdom from traditional securities industry that has been evolving and upgraded for decades. A standardized trading system has been developed in traditional securities market, including.

• A third-party depository (usually commercial bank) takes custody of the funds for transactions and settlements.
• All registration, custody and settlement are collectively submitted by issuing institution.
• A stockbroker accepts orders, trades on commission, and provides financing services.
• Exchanges complete the match-making of floor trading.

In this case, the whole securities industry enforced the market order by a collaborative yet balanced set of rules to eliminate the systematic risk caused by malpractice of a single unit. When the above four functions are all in the hands of CEX, it substantially aggravates the hazards of a single point of failure. Therefore, it is necessary to combine the characteristics of crypto-asset and learn from traditional financial industry on separation of individual business function, so that multiple mutually independent institutions can assume the intricate functions of current CEXs, thus achieving the separation of power and balance.

However, the following challenges remain active when duplicating experiences from traditional finance:

• CEXs may be reluctant to do so since separating business functions is somehow suspending ongoing lucrative business of CEXs.
• Regulations play significant part in rule-making, yet no one is certain on how the rules should be set, and it is also time-consuming for laws and legislations to be released.
• Regulatory rules may not be consistent from country to country, and it is unclear whether this will lead to a fragmentation of the crypto market.
• More constraints may incur higher administrative costs, which are passed onto users.

If crypto assets were to be perceived as a major asset class, the above-mentioned changes are bound to be materialized sooner or later, and CEXs will become more legitimate. Till then, we must have patience and remain cautious.  

References

1. https://www.odaily.news/post/5183267

2. https://vitalik.ca/general/2022/11/19/proof_of_solvency.html

3. https://www.kraken.com/zh-cn/proof-of-reserves

4. https://www.odaily.news/newsflash/304869

5. https://www.okx.com/proof-of-reserves

6. https://www.coinbase.com/blog/how-crypto-companies-can-provide-proof-of-reserves?__cf_chl_f_tk=1vKp.ArONaAOegsrdt3T_m4.dnLdDjyz6eU3u0fzxY0-1669552605-0-gaNycGzNDtE

7. https://blog.bitmex.com/bitmex-pol-system-now-live/

8. https://twitter.com/XResearchDAO/status/1592058023715147779

9. https://www.odaily.news/post/5183328

10. https://m.jinse.com/blockchain/2667533.html 

About Huobi Research Institute

Huobi Blockchain Application Research Institute (referred to as "Huobi Research Institute") was established in April 2016. Since March 2018, it has been committed to comprehensively expanding the research and exploration of various fields of blockchain. As the research object, the research goal is to accelerate the research and development of blockchain technology, promote the application of the blockchain industry, and promote the ecological optimization of the blockchain industry. The main research content includes industry trends, technology paths, application innovations in the blockchain field, Model exploration, etc. Based on the principles of public welfare, rigor and innovation, Huobi Research Institute will carry out extensive and in-depth cooperation with governments, enterprises, universities and other institutions through various forms to build a research platform covering the complete industrial chain of the blockchain. Industry professionals provide a solid theoretical basis and trend judgments to promote the healthy and sustainable development of the entire blockchain industry.

Contact us:

Website: http://research.huobi.com

Email: [email protected]

Twitter https://twitter.com/Huobi_Research

Telegram: https://t.me/HuobiResearchOfficial

Medium： https://medium.com/huobi-research

Disclaimer

1. The author of this report and his organization do not have any relationship that affects the objectivity, independence, and fairness of the report with other third parties involved in this report.

2. The information and data cited in this report are from compliance channels. The Sources of the information and data are considered reliable by the author, and necessary verifications have been made for their authenticity, accuracy and completeness, but the author makes no guarantee for their authenticity, accuracy or completeness.

3. The content of the report is for reference only, and the facts and opinions in the report do not constitute business, investment and other related recommendations. The author does not assume any responsibility for the losses caused by the use of the contents of this report, unless clearly stipulated by laws and regulations. Readers should not only make business and investment decisions based on this report, nor should they lose their ability to make independent judgments based on this report.

4. The information, opinions and inferences contained in this report only reflect the judgments of the researchers on the date of finalizing this report. In the future, based on industry changes and data and information updates, there is the possibility of updates of opinions and judgments.

5. The copyright of this report is only owned by Huobi Blockchain Research Institute. If you need to quote the content of this report, please indicate the Source. If you need a large amount of references, please inform in advance (see "About Huobi Blockchain Research Institute" for contact information) and use it within the allowed scope. Under no circumstances shall this report be quoted, deleted or modified contrary to the original intent.