Something has happened with Multichain, and the progress of the incident is still unclear, and the truth has not completely surfaced. What can be confirmed is that the LPs providing liquidity for Multichain and the users holding anyToken, the mapping asset issued by Multichain, are likely to suffer. The amount of affected assets is so large that it is unknown whether anyone will come forward to make up for the losses.
On July 6th, assets worth more than $126 million were transferred out of the MPC custody address by someone intentionally. According to the analysis by the contract auditing team Beosin, the transfer of funds was completely manipulated and unrelated to contract vulnerabilities, proving that Multichain's MPC custody address private key has been compromised by external forces.
In the official statement released by Multichain on July 14th, it explicitly announced that Multichain's founder Zhaojun was taken away by the police on May 21st. However, what is shocking is that the statement mentioned that all 24 MPC nodes' private keys of Multichain are solely controlled by Zhaojun, and all node services are running on his personal server! WTF!!!
The progress of the incident is still unclear, and the truth has not completely surfaced. What can be confirmed is that the LPs providing liquidity for Multichain and the users holding anyToken, the mapping asset issued by Multichain, are likely to suffer. The centralized risk of the multi-signature bridge is like a fat and plump gray rhinoceros. It is there for everyone to see, but it is selectively ignored. The key is that this rhinoceros is carrying billions of dollars in assets!
Currently, almost all of the top TVL cross-chain bridges in the market are multi-signature bridges. Prior to Multichain, there have been incidents where the official bridges of Axie Infinity, Ronin Bridge, and Harmony Chain, Horizen bridge, have suffered losses of $620 million and nearly $100 million respectively due to private key leaks.
Why are multi-signature bridges not trustworthy?
Generally, cross-chain bridges can be classified into three types: lightweight client type (native verification), witness type (external verification), and atomic transaction type based on hash time lock (local verification).
Among them, atomic swaps based on hash time lock have been rarely used due to their poor user experience (requiring users to perform 2 or more operations) and inability to support arbitrary message transmission. Lightweight client-side cross-chain bridges, on the other hand, are currently only used in dedicated bridges that support a small number of chains due to their relatively difficult engineering implementation and high compatibility costs for new chains. Witness-type cross-chain bridges, on the other hand, are relatively easy to develop and can be easily adapted to multiple chains, with good performance (fast and low cost), making them the choice for most projects.
Witness-type bridges verify the authenticity of cross-chain messages by obtaining consensus signatures from a group of external Bridge Nodes, so we also refer to them as multi-signature bridges. Cross-chain bridges generally use a lock-mint logic to transfer assets between chains. Users lock the native assets on the source chain (such as USDC) to mint mapped assets on the target chain (such as anyUSDC). These locked assets will become the TVL (Total Value Locked) of the bridge. Once stolen, the mapped assets in the hands of users or LPs will be disconnected from the native assets and cannot be fully redeemed. However, if these external Bridge Nodes conspire or fail to properly safeguard their own private key fragments resulting in more than 2/3 of them being obtained by hackers, such incidents may occur!
Most multi-signature bridges have only a few Bridge Nodes, ranging from single digits to twenty or more. When the TVL is low, these entities may not conspire to do harm, but when the TVL of a multi-signature bridge reaches hundreds of millions of dollars, there is no guarantee that they won't be tempted. It is not very difficult for 20 nodes to conspire if the benefits are substantial. This is also without considering that many nodes of the cross-chain bridges are often highly related "friendly competitors," and some cross-chain bridges have a situation where one entity controls multiple nodes. For example, 4 out of 9 nodes of the Ronin Bridge are controlled by Star Mavis, and the situation is even more extreme in Multichain, where one person controls all 24 nodes!
A sign of adulthood is no longer believing that human nature can withstand tests.
How will cross-chain bridges be improved?
The incident with Multichain may be a turning point for the field of cross-chain bridges. When no one is willing to tolerate the security risks brought by centralization, the era dominated by multi-signature bridges naturally comes to an end. If the era dominated by multi-signature bridges is considered as the 1.0 era of cross-chain bridges, then the departure of the 1.0 era is accelerating, and the protagonist of the cross-chain bridge 2.0 era will undoubtedly be a more secure cross-chain bridge.
So, what kind of cross-chain bridge should we use, and how can cross-chain bridges be improved to eliminate centralization risks while ensuring acceptable performance? We observe that there are three main directions in the industry: ZKbridge, Optimistic Bridge, and TEE Bridge.
ZK Bridge
Due to the increasing popularity of ZK narrative, the exploration of using ZK technology for cross-chain has attracted a lot of 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 scalability. We know that light client cross-chain bridges have high security, as they directly verify messages from the source chain at the consensus layer of the target chain without introducing any third-party trust assumptions. However, light clients need to constantly maintain the block header sequence of the source chain, requiring validation of each new block header, which brings two major challenges:
Significant on-chain costs, which may make the bridge economically infeasible
If we want to create a universal bridge, for each new chain supported, at least two new light clients need to be developed, and the cost of supporting the new chain is high, making it difficult to create a truly universal bridge.
After introducing ZK technology:
New block headers can be verified off-chain, and the new block header along with its validity proof (Zk Proof) can be submitted to the chain. The chain can directly verify the ZK proof, which is equivalent to validating the new block header, but the cost can be greatly reduced. Furthermore, the process of performing SPV verification of transactions using block headers can also be moved to the chain;
ZK technology simplifies light client development, as on-chain light clients only need to verify ZK proof, which is much simpler than validating new block headers in contract logic.
However, the performance limit of ZKbridge is still weaker than that of multi-signature bridges. Taking EVM as an example, the cost of verifying a ZK proof is at least 500 k gas, which is nearly 25 times higher than the 21 k Gas required to verify a signature in a multi-signature bridge. This ultimately translates into high cross-chain fees for end users. Although batch processing can distribute the cost of multiple transactions in a single process, it also brings longer waiting times for users.
In addition, as a light client bridge, Zkbridge needs to integrate with chains that support smart contracts and cannot be integrated with non-smart contract chains like BTC.
Optimistic Bridge
Optimistic Bridge is an improvement on the trust root of a multi-signature bridge. In addition to the multi-signature bridge, Optimistic Bridge introduces the concept of a challenge window and a role called "challenger".
We know that the process of message delivery in a multi-signature bridge is as follows:
① Initiation: Users initiate cross-chain message delivery through interaction with the Source dApp on the source chain.
② Off-chain signature: The message is passed to the Bridge Nodes, and after completing consensus signing, it is transmitted to the target chain.
③ On-chain signature verification: The target chain verifies whether the message is signed by the correct Bridge Nodes.
④ Execution: The validated message is submitted to the Target dApp for execution.
In Optimistic Bridge, after completing step ③, the message does not immediately proceed to step ④. Instead, it enters a timing stage. After the timing ends, if there are no challengers questioning the message, the message will enter the execution stage and be executed by the Target dApp.
If a challenger questions the message, the message will be marked as "untrusted". "Untrusted" messages will not enter the execution stage. The challenger will submit it to the source chain for arbitration by the arbitration contract on the source chain. If the message truly exists on the source chain, it proves that the challenger made a false report. If the message does not exist on the source chain, it proves that the Bridge Nodes committed fraud by signing a false message. After arbitration, the honest party will be rewarded, while the dishonest party will be penalized.
Through this mechanism, Optimistic Bridge elevates the trust root of the multi-signature bridge from m-of-n to 1-of-n. It only requires one honest challenger for the bridge to be reliable.
The drawback of Optimistic Bridge is that it increases the waiting time for users, which generally takes about 30 minutes. Users must wait for the challenge window to end before completing the cross-chain operation, which is not feasible in many scenarios as users do not have the patience for it. In practice, Optimistic Bridge often adopts a dual model mechanism, where small transfers or non-sensitive operations skip the challenge window period, and only large transfers or sensitive operations have a challenge window. The specific threshold can be custom-defined by the application or chosen by the user in the front-end.
The mechanism of Optimistic Bridge undoubtedly represents a significant improvement on the multi-signature bridge, ensuring both security and performance. Unfortunately, security and performance do not truly coexist, but rather the choice of prioritizing security or performance is left to the user. It cannot be considered a perfect solution.
In addition, since on-chain arbitration must be implemented through contracts, this solution still does not support non-smart contract chains like BTC.
TEE Bridge
TEE Bridge refers to the requirement that all nodes must use TEE devices to access the network on top of the multi-signature bridge. 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 through hardware.
In TEE Bridge, nodes use TEE devices to store private key shards, and the signing process runs entirely within the TEE, making it difficult for external hackers to steal. Unlike ZKbridge and Optimistic Bridge, TEE Bridge enhances the security of cross-chain bridges through node hardware rather than changing the validation mechanism on the chain.
The advantages of TEE Bridge are:
It significantly enhances security without sacrificing performance based on the multi-signature bridge.
It is compatible with BTC-like non-smart contract chains.
However, TEE Bridge still faces the risk of internal collusion. If 2/3 of the nodes collude, they can still launch attacks on the bridge.
BOOL: ZK-TEE Bridge
Next, I will introduce a more clever cross-chain bridge paradigm: ZK-TEE Bridge, pioneered by the cross-chain bridge project Bool Network. Bool Network combines ZK technology with TEE Bridge to achieve complete anonymity of nodes, making collusion impossible and ensuring ultra-high security of the bridge.
Bool Network itself is a permissionless network consisting of numerous TEE nodes. Any entity can apply to establish one or more DHCs (Dynamic Hidden Committees) through Bool Network. If an entity needs to build a cross-chain bridge supporting 10 chains, they can apply for 10 corresponding DHCs. Each DHC manages a set of MPC private key shards and is responsible for verifying and signing cross-chain messages.
A DHC generally includes 10 to 20 TEE node members, as set by the creator of the DHC. The signature threshold is usually 2/3, but the DHC creator can also set a higher threshold.
Bool Network randomly assigns members to all DHCs and regularly shuffles and reassigns them. Leveraging ZK technology, Bool Network can ensure that the process of assigning members is completely random. After the assignment is completed, each TEE node does not know which DHC it has been assigned to or which nodes it has been assigned with in a DHC, nor does it know which DHC other nodes have been assigned to. It feels like attending a masquerade party, where no one knows who is who!
This is implemented through the Ring VRF algorithm of Bool Network. Specifically, when Ring VRF allocates member nodes of DHC, it assigns a temporary identity to each TEE node, which is represented as a ZK proof, proving that a node belongs to the current DHC without exposing the specific information of the node. DHC members will recognize each other through temporary identities and complete the MPC signature through encrypted communication. After the current Epoch ends, Ring VRF will shuffle all members of DHC again, at which point all temporary identities will become invalid, and Ring VRF will assign new temporary identities to each node.
In summary, Bool Network achieves complete anonymity between nodes, eliminates the possibility of collusion, and further enhances security based on TEE Bridge through the ingenious combination of ZK and TEE technologies.
Summary
ZKbridge, Optimistic Bridge, and TEE Bridge are all excellent solutions that attempt to build more trustless cross-chain bridges, eliminate centralization risks, and improve the security of cross-chain bridges. However, ZKBridge and Optimistic still sacrifice performance and have scalability limitations, while TEE-Bridge has the potential for collusion attacks.
The ZK TEE-Bridge proposed by BOOL Network is a flawless solution in all aspects, and its advantages include:
No performance sacrifices, with cross-chain message delivery speed and cost at the same level as "multi-signature bridge"
Support for non-smart contract chains and low engineering effort to adapt to new chains
Elimination of possible collusion risks in TEE bridges, achieving ultra-high security comparable to lightweight client bridges
Essentially a decentralized, trustless signature mechanism that can be extended beyond cross-chain domains to areas such as oracle and distributed private key management
