NewsFlash Articles Data Fundraising BlockBeats Pro

How can CEX prove its innocence and improve the security of its funds?

Read this article in 26 Minutes

This paper will discuss how CEX can prove its innocence and continue to develop by combining the interpretation of Vitalik's article, the certification schemes of various CEX and the proposals of various parties.

原文标题：《痛定思痛，CEX 如何自证清白并提升资金安全性》

Original article by Huobi Research

The FTX explosion has thrown cold water on an already cooling crypto market. Users' trust in centralised trading platforms is rapidly diminishing, and coin movements are popping up one after another. To retain users and funds, CEXs have issued certificates of reserves to prove their innocence. Vitalik also discusses solvency proof in his post, explaining and envisioning how to achieve a safer CEX from a technical perspective. This paper will discuss how CEX can prove its innocence and continue to develop by combining the interpretation of Vitalik's article, the certification schemes of various CEX and the proposals of various parties.

1. Demonstrate solvency by technical means

Proving that CEX has the ability to repay users' withdrawals is basically proving that it has not embezzled users' deposits. This requires proving an inequality: the sum of assets controlled by CEX (proof of assets) > = Total deposits of users used (proof of liability). In addition to publishing these two numbers, CEX needs to prove that the numbers on both the left and right sides of the inequality are true, that the asset belongs and has always belonged to the trading platform, and that it did not tamper with the user's balance.

All kinds of technical approaches revolve around proving these two points. For proof of assets, the centralized institution needs to provide the on-chain address it holds and verify and audit it. It is common practice to provide a digital signature to prove ownership of the address on the chain. This approach is easy and widely adopted. The current discussion focuses on proof of liability, with the Merkle Tree asset reserve certificate recently published by various trading platforms being the most typical proof of liability.

1.1 Use Merkle tree for liability proof

Merkle trees are very common data structures in blockchains. It is a typical binary tree structure, consisting of a root node, a group of intermediate nodes and a group of leaf nodes. Each intermediate node (parent) of a higher level in the Merkle tree is a hash of the two intermediate nodes (child nodes) below it, computed layer by layer to reach the final root node. So the root node contains information about all the leaf nodes. Any changes to the underlying data are passed to the parent node and then layer by layer to the root node. It is often used to quickly prove the presence or absence of a particular element in a collection, compare whether large amounts of data are identical, find places to modify, and so on.

CEX use Merkle trees to create anonymised and immutable collective snapshots of the balance of the user's account assets, proving that they are not tampering with the user's balance. The most basic approach is to hash each user's username /UID (adding a number known only to the trading platform and user) along with its balance as a leaf node to form a Merck tree. If the user finds that the correct Merkle root cannot be calculated using his balance and the path in the Merkle tree, the trading platform can be judged to have misappropriated the user's assets.

But as Vitalik pointed out, there is a small Bug with the normal Merkle tree. Because it does not help users identify negative values, it cannot be used directly for proof of reserves. As shown below, if a trading platform has a total customer deposit of 1390 ETH, but it appropriates 500 ETH, so its reserves are only 890 ETH. The CEX will announce that the total number of user deposits is 890 ETH. To cover up the misappropriation of user assets, it can add a fake account somewhere in the tree that it controls, with a balance of -500 ETH. After the hash calculation, both positive and negative numbers will appear a very irregular string of numbers, other users can not distinguish. The Merkle tree from this fake account would perfectly contain other users' balance information, resulting in the user's verification results always being correct. An audit firm can spot this loophole, but if it is linked to a trading platform, the Merkle tree becomes useless.

To solve the negative value problem, Vitalik proposed an improved scheme named Merkle sum tree in the paper. Each node of the Merkel-sum tree contains two pieces of information: the balance and the hash. The underlying leaf node is the balance and username hash of each user. In each higher-level node, the balance is the sum of the balances of the next two nodes, and the hash is the hash of the overall information of the next two nodes, that is, the balance of the two nodes is hashed together with the hash value. Showing the balance separately helps the user identify negative values, thereby exposing CEX's misappropriation of the user's assets. As shown in the figure above, Greta found that Henny's balance was negative when doing self-verification; Both Eve and Fred find that the sum of the Greta and Henny balances is negative. This will cause all three of them to fail the test.

After the transformation, the trading platform uses the Merkle tree to issue the certificate of reserve as follows.

Generate Merkel-tree proof: The trading platform commissions an external audit firm or by itself to take a snapshot of all user balances and summarize them into the Merkel-tree. Verification: The auditor compares and verifies that the balance controlled by the trading platform is greater than or equal to the number provided by the Merkle tree. This proves whether the client's assets are fully supported by reserves. Users can check by themselves. If the user name and the balance value of the user are in the Merkel tree and there is no negative balance in the calculation process, it proves that the trading platform has not tampered with the user balance, that is, has not misappropriated the user assets.

1.2 Improvement scheme of Merck Tree

Using Merkle trees to prove user balances still has the small drawback of revealing privacy. As shown in the figure below, when Charlie self-verifies, CEX must tell him David's balance, the sum of Alice's and Bob's balances, and the sum of all user balances in the right half of the tree. While users may not (at least not so far) be able to do anything harmful if they learn this information, the privacy of the trading platform and the users whose balances are exposed is not always comfortable.

BitMEX has come up with a simple solution to this problem. They randomly split a user's account balance into several pieces and randomly filled each piece into one of the bottom leaf nodes of the Merkle tree. In this way, the exposed user balance is only fragmented, which can alleviate privacy issues to a certain extent. For example, Fred in the picture, his account is split into two parts, and Charlie does not know how much he has saved. But if someone really wanted to access other people's information through multiple accounts, it would take more effort, but it could still be done.

To fully address privacy concerns, you can introduce ZK-SNARK. As mentioned in the V God article, the Merkle tree is generated from the balances of all users, and ZK-SNARK is used to prove that all balances in the tree are non-negative and add up to some claimed value. If we use hashing to enforce privacy, then the Myrkel tree path given to each user will not reveal the balance of any other user. Or build a polynomial with all users' hash usernames and balances and make a KZG polynomial commitment to it. The trading platform proves that it knows this polynomial. The method of user verification is to take his balance as a point on the polynomial, let the trading platform calculate the value of the polynomial here, and then generate a witness. The user verifies the correspondence between the promise, the value and the witness. In KZG promise, polynomial, promise and witness all have corresponding relations, which cannot be forged arbitrarily, just like Merkle tree. It does not need to provide "sister nodes" as the basis of proof, and can complete the proof without revealing privacy.

1.3 Summary and deficiency of various schemes

Here, the basic Merkle summation tree, BitMEX scheme, ZK-SNARK Merkle tree and KZG polynomial commitment are summarized and compared, as shown in the following table. The first two methods are simple to operate, although there is a risk of privacy exposure, but in the current view, there is no major hidden danger, enough to be used in practice. In the latter two methods, ZK-SNARK is used to prove the addition calculation, which will bring additional operations to the trading platform, thus increasing the operation cost. The method of KZG polynomial commitment is more advanced, but the process of calculating commitment on the trading platform consumes a lot of resources and involves a lot of elliptic curve point calculation, so it may not be adopted for the time being. All of the above methods do not require the user to have a search operation and are easy to verify.

Neither these technical solutions to proof of liabilities nor the more common use of proof of assets have solved the following problems:

First, these liability proof schemes need to be supervised by users, but if the self-verification of users is too small, it is not enough to detect the evil behavior of trading platforms. Need to continue to educate the user, improve the user consciousness. Another approach is for trading platforms to monitor each other. Big trading platforms can register a certain number of accounts with other trading platforms and deposit a small amount of assets to verify their liability proof.

Second, both the certificate of assets and the certificate of liabilities are not real-time certificates. The trading platform can obtain funds by borrowing before making the certificate of assets, which should be checked and then returned. There are two ways to solve this problem. First, we can agree on a fixed time for all major trading platforms to audit at the same time. The second is the possibility of irregular surprise audits. Both methods can reduce the time it takes to borrow money. Third, the certification process relies on a trusted audit firm, but if the audit firm colludes with the trading platform, all subsequent technical means are invalidated. Fourth, and this is the most important, none of these plans is enforceable. Trading platforms can operate in an insolvent state. Especially in a bear market, if short-term economic pressures are so great that trading platforms can't survive the next bull market, diverting user funds becomes a natural move.

2. Semi-centralized CEX

All the proofs mentioned above are used to prove that CEX does not do evil, but CEX still has the power to do evil. If we go one step further, and use the constraints of technology to move the platform from no evil to no evil, then trust will be restored, even enhanced, and the crypto ecosystem will flourish.

Vitalik divides trading platforms into five categories, based on how much control they have over users' money and how easy it is to do evil. The current trading platform mainly consists of three categories. Below, from left, the first type of trading platform has complete control over users' funds, with no measures to monitor and prevent it from misappropriating users' funds. Before FTX thunderstorms, almost all CEX were like this. Most CEXs are now Class 2, where the trading platform controls the user's money but is monitored by external human controls. Most DeXes fall into category 5, where trading platforms have no control over users' money at all and therefore have no power to do evil.

V God pointed out that CEX and DEX are not binary opposites, there is a middle ground between fully centralized and fully decentralized CEX. They can inherit the efficient trading system of the traditional centralized trading platform, and disperse the power of the trading platform by the multi-signature private key holder, verifier, etc., so as to reduce the possibility of evil of the trading platform. These are the trading platforms in Category 3 and 4 of the V article.

A third type of trading platform still holds users' money, but it cannot operate under insolvency. Such trading platforms have yet to emerge. If you want to implement it, you need to put some restrictions on it. One way to think about it is to ask CEX to store assets at several fixed addresses controlled by multiple signatures, or to split the private key into several pieces using MPC technology. Monitor the capital status of the trading platform through real-time or high frequency solvency tests. Normally, only the private key controlled by CEX itself is required to complete the signature to transfer funds. If it detects insolvency/high percentage of single transfers/continuous transfers, other private key holders can activate emergency mode and collectively refuse transactions to achieve the effect of freezing accounts. This makes CEX less centralized by having multiple private key holders, and thus less easy to do evil. This type of trading platform may be the future evolution direction of CEX.

If such trading platforms are to continue to grow, auditing needs to go to another level. Future audits will need to be more credible, faster and more automated to accommodate the demands of these trading platforms.

The fourth type of trading platform does not host users' money, but uses a centralized trading system. The user's money is held in trust in a smart contract. DYDX can be seen as representative of this type of trading platform. It uses its trading system to match trades off-chain, packaging the results and submitting them to the main Ethereum network. It takes advantage of the convenience of a centralized trading system and the security of Ethereum's clearing layer. Now its V4 version has migrated to the Cosmos ecosystem, with the underlying blockchain built specifically for it, but the paradigm of centralized transaction + decentralized settlement has not changed. This kind of trading platform needs the underlying blockchain with low cost and high security as the guarantee, and it is not as convenient as ordinary CEX in dealing with cross-chain issues, so it is unlikely to become the evolution direction of CEX.

3. Borrow from traditional finance

As X Research DAO analyst Wilson notesIn this paper,The current centralized cryptocurrency trading platform has drawbacks such as excessive internal authority, opaque asset storage, impulse to magnify profits, and no external constraints. Technological progress is only one route to solving these problems. The other route is to establish a set of rational institutional arrangements to split and limit the CEX's authority.

The current crypto market is a lot like the early mixed stage of finance. CEX is a comprehensive institution that integrates various financial functions. On the one hand, it provides exchange trading entrustment and matchmaking; on the other hand, it also provides full custody of various Token assets (including stablecoin assets) recharged by customers, and various financial services. Multiple businesses also mean multiple authorities, and when an organization has too much power, it is only a matter of whether it will use it for its own benefit.

In the next stage, the crypto market will inevitably have the need to build a more secure trading mode. It can be regarded as a shortcut to learn from the securities industry system that has been validated and perfected for decades. The securities industry has formed a standardized trading system, including:

A third party depositary (commercial bank) will hold the transaction settlement funds of its customers. Securities registration and settlement institutions shall centrally provide registration, custody and settlement of securities. Securities brokers are entrusted by clients to buy and sell securities and provide financing and margin lending services. By the securities trading platform to complete the trading information of the floor order matching.

Through such a set of multi-party coordination and checks and balances, the securities industry avoids the situation that a single institution causes systemic risks. All the above four functions are completed by CEX, which greatly increases the harm of single point of failure. Therefore, it is necessary to combine the characteristics of crypto asset trading, draw lessons from the traditional financial model of separate operation, and let multiple independent institutions assume various functions of the current cryptocurrency trading platform, so as to realize decentralization and checks and balances.

This kind of reference is by no means easy. It has the following difficulties:

Splitting up would mean CEX surrendering a lot of authority, potentially reducing its profitability, so CEX itself has no desire to do so. This requires regulatory intervention, but how to formulate the rules needs to be explored, and the introduction of laws and regulations is time-consuming. It is unclear whether the fragmentation of the crypto market will result from the possibility of inconsistent national regulations. More institutional constraints also mean the possibility of higher administrative costs, which are passed on to users.

What is certain, however, is that if crypto assets become mainstream, these changes will occur. With a little more patience and self-preservation, a more regulated CEX is on its way.