Written by: MiddleX
The progress of the Multichain incident is still confusing, and the truth has not yet fully surfaced. What is certain is that the LPs who provide liquidity to Multichain and the users who hold anyToken, the mapped asset issued by Multichain, are likely to suffer. The amount of assets affected this time is too large, and I don’t know if anyone will come out to cover the bottom.
On July 6, more than $126 million in assets were manually transferred out of the MPC custody address. According to the analysis of the contract audit team Beosin, the transfer of funds was entirely manual and had nothing to do with the contract vulnerability, proving that the private key of Multichain's MPC custody address has been controlled by external forces.
In the official statement released by Multichain on July 14, it was clearly announced that Zhaojun, the founder of Multichain, had been taken away by the police on May 21. However, what is shocking is that the statement mentioned that the private keys of Multichain’s 24 MPC nodes are all controlled by Zhaojun, and all node services are completely run in his personal server! WTF!!!
The progress of the incident is still confusing and the truth has not yet fully surfaced. What is certain is that the LPs who provide liquidity to Multichain and the users who hold anyToken, the mapped asset issued by Multichain, are likely to suffer. The centralization risk of the multi-signature bridge is like a fat gray rhino. It is there and everyone can see it, but they choose to ignore it. The key is that this rhino is carrying huge assets worth tens of billions of dollars!
Currently, almost all cross-chain bridges with the highest TVL on the market are multi-signature bridges. Before Multichain, Axie Infinity’s official bridge Ronin Bridge and Harmony Chain’s official bridge Horizen Bridge had collapsed due to private key leaks, causing losses of $620 million and nearly $100 million respectively.
Why are multi-signature bridges untrustworthy?
Generally speaking, there are three types of cross-chain bridges: light client type (native verification), witness type (external verification), and atomic transaction type based on hash time lock (local verification).
Among them, atomic transactions based on hash time locks are rarely used due to their poor user experience (users need to perform more than 2 operations) and inability to support arbitrary message transmission. Light client cross-chain bridges are currently only used in some special bridges that only need to support a few chains due to their relatively difficult engineering implementation and high cost of compatibility with new chains. Witness cross-chain bridges are relatively simple to develop and implement, can easily adapt to multiple chains, and have good performance (fast speed and low cost), making them the choice of most projects.
Witness bridges use a group of external Bridge Nodes to sign cross-chain messages in consensus to verify the authenticity of the messages, so we also call them multi-signature bridges. Cross-chain bridges generally use lock-mint logic to transfer assets between chains. Users lock the native assets on the source chain (such as USDC) to mint the mapped assets on the target chain (such as anyUSDC). These locked assets will become the TVL of the bridge. Once stolen, the mapped assets in the hands of users or LPs will be decoupled from the native assets and cannot be redeemed in full. However, if these external Bridge Nodes collude, or if they fail to keep their private key fragments well, resulting in more than 2/3 of them being obtained by hackers, this will happen!
Most multi-signature bridges have only a single-digit number of Bridge Nodes, and some have more than 20. When the TVL is low, these entities may not conspire to do evil, but when the TVL of a multi-signature bridge reaches hundreds of millions of dollars, no one can guarantee that they will not be tempted. If the interests are large enough, it is not difficult to collude with 20 nodes. This does not take into account that many nodes of many cross-chain bridges are often "friendly companies" with highly correlated interests, and some cross-chain bridges even have a situation where one entity controls multiple nodes. For example, 4 of the 9 nodes of Ronin Bridge are controlled by Star Mavis. The situation of Multichain is even more excessive, with 1 person controlling all 24 nodes!
The mark of an adult is that he no longer believes that human nature can stand the test.
How will cross-chain bridges be improved?
The Mulitichian incident may be a turning point for the cross-chain bridge industry. When everyone is no longer willing to tolerate the security risks brought by centralization, the "multi-signature bridge" will naturally not work. If the era dominated by the "multi-signature bridge" is the 1.0 era of the cross-chain bridge, then the 1.0 era is accelerating, and the protagonist of the cross-chain bridge 2.0 era must belong to the more secure cross-chain bridge.
So what kind of cross-chain bridge should we use? How can we improve the cross-chain bridge to eliminate the centralization risk while ensuring acceptable performance? We have observed that there are three main directions in the industry, namely ZKbridge, Optimistic Bridge and TEE Bridge.
ZK Bridge
As the ZK narrative heats up, the exploration of using ZK technology for cross-chain has also attracted much attention recently, and many projects in this direction have received financing.
ZKBridge is a cross-chain bridge solution that uses ZK technology for light client expansion. As we know, light client cross-chain bridges have extremely high security. Its essence is that the consensus layer of the target chain directly verifies the messages from the source chain without introducing any third-party trust assumptions. However, the light client needs to continuously maintain the block header sequence of the source chain, and verification needs to be performed on each new block header, which brings two major difficulties:
Huge on-chain overhead may make the bridge uneconomically viable
If you want to build a universal bridge, you need to develop at least two new light clients for each new chain you support. The cost of being compatible with new chains is high, making it difficult to build a truly universal bridge.
After introducing ZK technology:
The new block header can be verified off-chain, and the new block header and its validity proof (Zk Proof) can be submitted to the chain together. The chain can directly verify the ZK Proof, which is equivalent to verifying the new block header, but the cost can be greatly reduced. Furthermore, the process of performing SPV verification on transactions using block headers can also be put on the chain.
ZK technology simplifies the development of light clients. On-chain light clients only need to verify ZK proofs, which is much simpler than verifying the contract logic of a new block header.
However, the performance limit of ZKbridge is still weaker than that of multi-signature bridge. Taking EVM as an example, the minimum cost of verifying a ZK proof is 500k gas, which is nearly 25 times higher than the 21k gas of multi-signature bridge which only needs to verify one signature. This will eventually translate into high cross-chain fees for front-end users. Although batch processing can allow multiple transactions to share the cost of one processing, it will bring users a longer waiting time.
In addition, as a light client bridge, Zkbridge needs to access a chain that supports smart contracts, and non-smart contract chains such as BTC cannot be accessed.
Optimistic Bridge
The Optimistic Bridge is an improvement on the multi-signature bridge’s root of trust. Based on the multi-signature bridge, the Optimistic Bridge introduces the concept of a challenge window and a role called “Challenger”.
We know that the process of transmitting a message in a multi-signature bridge is as follows:
① Initiation: Users initiate cross-chain message transmission by interacting with Source dApp on the source chain
② Off-chain signature: The message is passed to the Bridge Nodes, and after the consensus signature is completed, it is passed to the target chain
③ On-chain signature verification: The target chain verifies whether the message is signed by the correct Bridge Nodes
④ Execution: The verified message is submitted to the Taregt dApp for execution
In Optimistic Bridge, after completing step ③, the message will not enter step ④ immediately, but will enter a timing phase. After the timing ends, if no challenger questions the message, the message will enter the execution phase and be executed by Taregt dApp.
If the challenger questions the message, the message will be marked as "untrusted". The "untrusted" message will not enter the execution phase. The challenger will submit it to the source chain, and the arbitration contract of the source chain will arbitrate it. If the message really exists in the source chain, it proves that the challenger misreported. If the message does not exist in the source chain, it proves that the Bridge Nodes are fraudulent and signed a false message. After the arbitration is over, the honest party will be rewarded and the dishonest party will be punished.
Through this mechanism, the Optimistic bridge improves the trust root of the multi-signature bridge from m-of-n to 1-of-n. As long as there is an honest challenger, the bridge is reliable.
The disadvantage of Optimistic Bridge is that it increases the waiting time for users, which is generally around 30 minutes. Users must wait for the challenge window to end before completing the cross-chain operation. This is not feasible in many scenarios, and users do not have the patience. In practice, Optimistic Bridge often adopts a dual-model mechanism. Small transfers or non-sensitive operations will directly skip the challenge window period. Only large transfers or sensitive operations will have a challenge window period. The specific threshold can be customized by the application or selected by the user on the front end.
The mechanism of Optmistic Bridge is undoubtedly a huge improvement on the multi-signature bridge, which not only ensures security but also takes into account performance. But unfortunately, security and performance are not really achieved at the same time. It just gives users the choice of whether to prioritize security or performance, which cannot be considered a perfect solution.
In addition, since on-chain arbitration must be achieved through contracts, this solution still cannot support non-smart contract chains such as BTC.
TEE Bridge
TEE Bridge means that on the basis of multi-signature bridge, all nodes must use TEE devices to access the network. TEE stands for Trusted Execute Environment, which is a computing environment isolated from the main operating system running on a given device, like an enclave. This isolation is enforced by hardware.
In TEE Bridge, nodes use TEE devices to store private key fragments, and the signature program is also run entirely in TEE, making it difficult for external hackers to steal. Unlike ZKbridge and Optimistic Bridge, TEE Bridge improves the security of cross-chain bridges through node hardware rather than changing the verification mechanism on the chain.
The advantages of TEE Bridge are:
While improving security, performance is not sacrificed at all on the basis of multi-signature bridge
Compatible with non-smart contract chains like BTC
However, TEE Bridge still has the risk of internal collusion. If 2/3 of the majority of nodes collude, they can still attack the bridge.
BOOL ：ZK-TEE Bridge
Bool Network is a unique cross-chain bridge project. Based on TEE Bridge, it combines ZK technology and adopts an anonymous rotation mechanism to achieve higher security.
Bool Network itself is a non-permissioned network composed of many TEE nodes. Any subject can apply to establish one or more DHCs (Dynamic Hidden Committees) through Bool Network. If a subject needs to build a cross-chain bridge that supports 10 chains, it only needs to apply for 10 corresponding DHCs. Each DHC manages a set of MPC private key shards, and they will be responsible for verifying and signing cross-chain messages.
A DHC generally contains 10 to 20 TEE node members, which is set by the creator of the DHC. The signature threshold is generally 2/3, but the creator of the DHC can also set a higher threshold.
Bool Network will randomly assign members to all DHCs, and will shuffle and redistribute them regularly. With the help of ZK technology, Bool Network can achieve a completely random process of assigning members, and after the assignment is completed, each TEE node does not know which DHC it is assigned to, nor does it know which nodes it is assigned to the same DHC, let alone which DHC other nodes are assigned to. This feeling is like attending a masquerade, where no one knows who is who!
This is achieved through Bool Network's Ring VRF algorithm. Specifically, when Ring VRF assigns node members to DHC, it will assign a temporary identity to each TEE node. The temporary identity is expressed as a ZK proof, which can prove that a node belongs to the current DHC, but does not expose the specific information of the node. DHC members will identify each other through temporary identities and complete the MPC signature through encrypted communication. After the current Epoch ends, Ring VRF will reshuffle all DHC members, at which time all temporary identities will become invalid, and Ring VRF will assign a new temporary identity to each node.
In short, Bool Network has achieved complete anonymity between nodes through the clever combination of ZK technology and TEE technology, eliminating the possibility of collusion and further improving security based on TEE Bridge.
summary
ZKbridge, Optimistic Bridge, and TEE Bridge are all very good solutions. They are all trying to build a more trustless cross-chain bridge, eliminate centralization risks, and improve the security of cross-chain bridges. However, ZKBridge and Optimistic still have performance sacrifices and shortcomings in scalability, and TEE-Bridge has the possibility of conspiracy attacks.
The ZK TEE-Bridge proposed by BOOL Network is an impeccable solution in all aspects. Its advantages include:
Without sacrificing performance, the speed and cost of cross-chain messaging remain at the same level as the "multi-signature bridge"
Supports non-smart contract chains, and the workload of adapting to new chains is low
Eliminates the risk of collusion in TEE bridges, achieving ultra-high security that is no less than that of light client bridges
Essentially, it is a decentralized, trustless signature machine that will not be limited to cross-chain applications, but can be extended to areas such as oracle machines and distributed private key management.
