What is Merkle Tree Proof of Reserves and what it brings
Hello, I’m 0xice9 from @OrbiterResearch. This is the first episode from the channel “EVEN YOUR GRANDMA KNOWS”.
After all the things we know that happened these days, @cz_binance has proposed that all exchanges (whether CEX or DEX) should use Merkle Tree Proof of Reserves to keep assets transparent and prevent insolvency issues. So what is the Merkle Tree Proof of Reserves and what it brings?
Proof of Reserves
In the world of crypto, it is quite easy for an exchange to prove its total assets by simply making its corresponding public portfolio address. For example, @binance has [a page of Proof of Assets](https://www.binance.com/en/assets-proof) to facilitate users to see their public holdings.
It’s certainly nice to be able to see the exchange’s total reserves, but as a user, I want to know if my money is actually being held for real or if it’s just a number shown on the platform, and that’s what the Merkle Tree proof of reserves can bring.
Merkle Tree
Merkle Tree is not a real tree(ha, ha), it is a data structure that is already widely used in the blockchain area, in order to adapt to the problem of the ever-growing volume of data.
The Merkle tree itself is a typical binary tree structure, consisting of a root node, non-leaf nodes, and leaf nodes.
But instead of storing real data in it, the hash function is introduced for the purpose of 1. compressing the data 2. encrypting the data, and making it irreversible.
Compared with a normal tree structure, Merkle trees are generated from bottom to top. Every two leaf nodes can be aggregated and hashed into a Branch, and then the branch is aggregated and hashed with the same logic to finally generate the root node.
By designing the hash function, this tree is irreversible, and before the advent of quantum computers, it is theoretically impossible to reverse the leaf nodes from the root node.
Now the benefits:
* Since the root and all the data are associated, any leaf modification will result in changes to the root and the structure of the tree.
* As a leaf, you don’t need to know the whole tree structure to verify whether you belong to the tree or not
* Data compression
In simple terms, you can think of it as a system that knows whether data is valid or not at a low cost without validating each specific leaf data.
These are CEXs that currently have plans they will achieve proof or reserves (in no particular order):
* @binance
* @okx
* @HuobiGlobal
* @krakenfx
* @BitMEX
* @gate_io
* @bitgetglobal
Where gate.io has an open-source example, we can follow their thought and disassemble its specific implementation path
Given the simple Merkle Tree below:
We could consider the platform holding a 4 users database and construct a Merkle Tree based on their user_id and balance with keccak as the hash function.
Now the prove-of-reserve system should provide you with several things when you are the platform user:
* User Details
* Merkle Root Hash
* Minimum number of Nodes Hash
Hence the user would receive:
UID = 1
Balance = 1
Hash 2 = 0x8d9fb8d49241cf633a15d0ba03d0acd1f99b4450b5e02c7eb3a4a6c3a1c3557a
Hash B = 0x435327dcad4a9a1dbfca9259a0b6e79011eadbe97b160e57ef4752b34bb93e97
Root = 0xfd25450ff8ea24f58036910a6f8eb2cd82a3486a7557e1e2423bbd3d0118f56e
Obviously, a user is able to calculate:
//let H() = keccak()
Hash 1 = H(H(UID) + H(Balance)) = 0xa284944720d246a0f5f3de67cb4b832a8b5dfdc512e0554cedc652aaf162d178
Hash A = H(Hash 1 + Hash 2) = 0x89831bdd4a10278ac1b94d1c2b6f466ba58a7a616340a825e9e6c8859093317b
Root = H(Hash A + Hash B) = 0xfd25450ff8ea24f58036910a6f8eb2cd82a3486a7557e1e2423bbd3d0118f56eIt can be seen that the Root value is calculated to be equal to that in Figure 2, which completes the whole proof process.
For the data availability part, a user could only get the minimum information about the Merkle Tree but still be able to verify that his money is actually held by the platform. A user cannot get the uid or balance of any account other than himself (because the hash function is not reversible).
That’s the reason why the auditing company still needs to be imported as a concerned third party.
The auditing company actually audits the validity of the tree. First, they audit the balance in the database, then they audit whether the assets in the platform account match the database, and lastly, they audit whether the Merkle tree generated with that database is correct and valid.
But it only indicates that the exchange was 100% reserved at that moment of the announcement of the Merkle Root Hash.
Cons on Merkle Tree Proof of Reserves:
1. The frequency of updates is a key parameter to ensure the effectiveness of the system. CEX has a large number of transactions per second and it is not practical to update the root for every transaction. The probability is that the root you see will not be up to date, i.e. the knowledge is not up to date.
2. Exchanges can return incorrect results on their front-end pages, or even be a bit stealthy — fake the logic or data during tree construction. (possible but not necessary)
3. The issue of trust in the auditing company. Many of the organizations that crashed were also audited by layers of auditors, and having an audit does not mean infallibility. Moreover, the trust risk is transferred from the platform to the auditing company.
4. Effective proof and dissemination. If a certain user finds out that the tree root is faked, will he be able to effectively prove what he said is right and disseminate this fact?
5. Even if the exchange has implemented the Merkle Tree Proof of Reserves method, this does not prevent him from transferring all his assets at once. (Rug pulled, and claim their private key was compromised(@?) )
6. Only contracts that achieve automatic depositing and withdrawing can avoid a “bank run”, but this is impossible for centralized exchanges. (They could just shut it down, right? @?)
TL;DR
* The exchange itself has a database of users but doesn’t want you to see the details in it.
* So the Merkle Tree was introduced to give users a transparent channel to verify that the platform holds the full amount of capital reserves.
* Anyone can see the latest tree root. Users can only see if their balance matches the tree root.
* Auditing company proves the validity of adequate reserves and proper tree structure.
* Even if it is achieved, one more layer of user transparency would be added. The risk is still there.
* There is nothing wrong with the exchange IS ABLE TO achieve this, it would be a big problem if it CANNOT.
* Merkle Tree is just a method to solve the problem (not the only one). Zero Knowledge Proof can also be applied to such problems.
Next time someone talks about what is Merkle Tree Proof of Reserves, you can simply say that it’s an algorithm that allows users to validate if the exchange truly holds full reserves of their funds, without revealing any other information from others or the platform, bla bla bla.
Good day.
