The downfall of Multichain may become an opportunity for the transformation of cross-chain bridges

Written by: MiddleX

The progress of the Multichain event remains unclear, and the truth has yet to fully surface. What is certain is that LPs providing liquidity for Multichain, as well as users holding the mapped asset anyToken issued by Multichain, are likely to suffer. The amount of affected assets this time is too large, and it is uncertain whether anyone will step in to cover the losses.

On July 6, over $126 million in assets were manually transferred out of the MPC custody address. According to an analysis by the contract auditing team Beosin, the transfer of funds was entirely a human operation and unrelated to any contract vulnerabilities, proving that the private key of Multichain's MPC custody address has been compromised by external forces.

In an official statement released by Multichain on July 14, it was explicitly announced that Multichain's founder, zhaojun, had been taken away by the police on May 21. However, what was shocking was that the statement mentioned that all 24 MPC node private keys were entirely controlled by Zhaojun, and all node services were running on his personal server! WTF!!!

Currently, the progress of the event remains unclear, and the truth has yet to fully surface. What is certain is that LPs providing liquidity for Multichain, as well as users holding the mapped asset anyToken issued by Multichain, are likely to suffer. The centralization risk of multi-signature bridges is like a fat gray rhino; it is right there, visible to everyone, yet selectively ignored. The key is that this rhino is carrying hundreds of billions of dollars in assets!

Currently, almost all of the top cross-chain bridges in terms of TVL are multi-signature bridges. Before Multichain, incidents had already occurred with the Axie Infinity official bridge Ronin Bridge and the Harmony Chain official bridge Horizen Bridge due to private key leaks, resulting in losses of $620 million and nearly $100 million, respectively.

Why Multi-signature Bridges Are Not Trustworthy?

Generally speaking, cross-chain bridges can be divided into three types: light client type (native verification), witness type (external verification), and hash time-locked atomic transaction type (local verification).

Among them, hash time-locked atomic transactions have rarely been adopted due to poor user experience (requiring users to perform more than two operations) and the inability to support arbitrary message passing. Light client type cross-chain bridges are relatively difficult to implement and have high costs for compatibility with new chains, and are currently only applied in some dedicated bridges that only need to support a few chains. Witness type cross-chain bridges, on the other hand, are easier to develop and implement, can easily adapt to multiple chains, and have better performance (fast speed, low fees), making them the choice for most projects.

Witness type bridges achieve consensus signatures on cross-chain messages through a group of external Bridge Nodes to verify the authenticity of the messages, which is why we also refer to them as multi-signature bridges. Cross-chain bridges generally use a lock-mint logic to transfer assets between chains, where users lock native assets on the source chain (e.g., USDC) to mint mapped assets on the target chain (e.g., anyUSDC). These locked assets become the TVL of the bridge, and once stolen, the mapped assets in the hands of users or LPs will become unanchored from the native assets, making it impossible to redeem them at full value. However, if these external Bridge Nodes collude, or if they fail to properly secure their private key shards leading to more than 2/3 being compromised by hackers, such incidents can occur!

Most multi-signature bridges have only a handful of Bridge Nodes, or at most over 20. 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 they won't be tempted. If the incentives are large enough, conspiring among 20 nodes is not very difficult. This does not even take into account that many nodes of cross-chain bridges are often highly related "competitors," and in some cases, a single entity controls multiple nodes. For example, in the 9 nodes of Ronin Bridge, 4 are controlled by Star Mavis, and the situation with Multichain is even more extreme, with one person controlling all 24 nodes!

A hallmark of adulthood is no longer believing that human nature can withstand tests.

How Will Cross-Chain Bridges Improve?

The Multichain incident may serve as a turning point for the cross-chain bridge field. When people are no longer willing to tolerate the security risks brought by centralization, "multi-signature bridges" will naturally become unviable. If the era dominated by "multi-signature bridges" is the 1.0 era of cross-chain bridges, then the 1.0 era is rapidly fading away, and the protagonists of the cross-chain bridge 2.0 era will undoubtedly belong to safer cross-chain bridges.

So what kind of cross-chain bridges should we use, and how can cross-chain bridges improve to eliminate centralization risks while ensuring acceptable performance? We observe that there are mainly three directions in the industry: ZKbridge, Optimistic Bridge, and TEE Bridge.

ZK Bridge

With the rising interest in ZK narratives, recent explorations of applying ZK technology to cross-chain solutions have gained significant attention, and many projects in this direction have secured funding.

ZKBridge is a cross-chain bridge solution that applies ZK technology for light client scaling. We know that light client cross-chain bridges have extremely high security, as they directly verify messages from the source chain through the consensus layer of the target chain without introducing any third-party trust assumptions. However, light clients need to continuously maintain the block header sequence of the source chain, requiring verification of each new block header, which brings two major challenges:

• Huge on-chain overhead, which may render the bridge economically unfeasible.
• To create a universal bridge, at least two new light clients need to be developed for each additional supported chain, making the cost of compatibility with new chains high and difficult to achieve a truly universal bridge.

After introducing ZK technology:

• New block headers can be verified off-chain, and both the new block header and its validity proof (ZK Proof) can be submitted on-chain. The on-chain can directly verify the ZK Proof, which is equivalent to verifying the new block header, but the overhead can be significantly reduced. Furthermore, the process of executing SPV verification on transactions using block headers can also be placed on-chain.
• ZK technology simplifies the development of light clients, as on-chain light clients only need to verify ZK proof, which is much simpler than verifying the contract logic of new block headers.

However, the performance limits of ZKbridge are still weaker than those of multi-signature bridges. For EVM, the cost of verifying a ZK proof is at least 500k gas, compared to only 21k gas for verifying a single signature in a multi-signature bridge, which is nearly 25 times higher, ultimately translating into high cross-chain fees for end users. Although batch processing can allow multiple transactions to share the cost of a single processing, this will lead to longer waiting times for users.

Additionally, as a light client bridge, ZKbridge requires the chain to support smart contracts, making it impossible to connect with non-smart contract chains like BTC.

Optimistic Bridge

Optimistic bridges are an improvement on the trust root of multi-signature bridges. Optimistic bridges introduce the concept of a challenge window and a role known as the "Challenger" based on multi-signature bridges.

We know that the process of message transmission in a multi-signature bridge is as follows:

① Initiation: The user initiates cross-chain message transmission by interacting with the Source dApp on the source chain.

② Off-chain signing: The message is passed to Bridge Nodes, which complete consensus signing before passing it to the target chain.

③ On-chain verification of signatures: The target chain verifies whether the message is signed by the correct Bridge Nodes.

④ Execution: The verified message is submitted to the Target dApp for execution.

In the Optimistic Bridge, after the message completes step ③, it does not immediately enter step ④ but instead enters a timing phase. After the timer ends, if no Challenger raises a challenge against the message, it will then enter the execution phase and be executed by the Target dApp.

If a Challenger questions the message, it will be marked as "untrustworthy," and "untrustworthy" messages will not enter the execution phase. The Challenger will submit it back to the source chain, where the arbitration contract of the source chain will arbitrate. If the message genuinely exists on the source chain, it proves 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 punished.

Through this mechanism, the Optimistic bridge elevates the trust root of multi-signature bridges from m-of-n to 1-of-n, requiring only one honest Challenger for the bridge to be reliable.

The downside of the Optimistic Bridge is that it increases the user's waiting time, which is generally around 30 minutes. Users must wait for the challenge window to close before completing the cross-chain operation, which is impractical in many scenarios, as users do not have that patience. In practice, Optimistic Bridges often adopt a dual-model mechanism, where small transfers or non-sensitive operations skip the challenge window, and only large transfers or sensitive operations have a challenge window. The specific threshold can be customized by the application or chosen by users on the front end.

The mechanism of the Optimistic Bridge is undoubtedly a significant improvement over multi-signature bridges, ensuring security while also considering performance. However, unfortunately, security and performance do not truly coexist; it merely hands the choice of prioritizing security or performance to the user, which cannot be considered a perfect solution.

Moreover, since on-chain arbitration must be implemented through contracts, this solution still cannot support non-smart contract chains like BTC.

TEE Bridge

TEE Bridge refers to a multi-signature bridge that requires all nodes to use TEE devices to connect to the network. TEE stands for Trusted Execution Environment, which is a computing environment that runs on a given device isolated from the main operating system, like an enclave. This isolation is enforced through hardware.

In TEE Bridge, nodes use TEE devices to secure private key shards, and the signing process runs entirely within the TEE, making it very 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 on-chain verification mechanism.

The advantages of TEE Bridge include:

• Enhancing security without sacrificing performance based on multi-signature bridges.
• Compatibility with non-smart contract chains like BTC.

However, TEE Bridge still carries the risk of internal collusion. If more than 2/3 of the nodes collude, they can still launch an attack on the bridge.

BOOL: ZK-TEE Bridge

Bool Network is a unique cross-chain bridge project. It combines TEE Bridge with ZK technology and adopts an anonymous rotation mechanism to achieve higher security.

Bool Network itself is a permissionless network composed of numerous TEE nodes, where any entity can apply to establish one or more DHCs (Dynamic Hidden Committees) through Bool Network. If an entity needs to establish a cross-chain bridge supporting 10 chains, it can simply apply for 10 corresponding DHCs, each managing a group of MPC private key shards responsible for verifying and signing cross-chain messages.

A DHC typically contains 10 to 20 TEE node members, set by the creator of the DHC, with a signing threshold usually at 2/3, although the creator can set a higher threshold.

Bool Network randomly assigns members to all DHCs and regularly shuffles and redistributes them. With the help of ZK technology, Bool Network can ensure that the process of assigning members is completely random, and after the assignment is complete, each TEE node does not know which DHC it has been assigned to, nor does it know which nodes are in the same DHC, and it certainly does not know which DHC other nodes have been assigned to. It feels like attending a masquerade ball, where no one knows who anyone else is!

This is achieved through Bool Network's Ring VRF algorithm. Specifically, when Ring VRF assigns node members to DHCs, it gives each TEE node a temporary identity, represented by a ZK proof that can prove a node belongs to the current DHC without revealing specific information about the node. DHC members will identify each other through temporary identities and complete the MPC signing work through encrypted communication. After the current Epoch ends, Ring VRF will reshuffle all DHC members, at which point all temporary identities will become invalid, and Ring VRF will assign new temporary identities to each node.

In summary, Bool Network cleverly combines ZK technology and TEE technology to achieve complete anonymity among nodes, eliminating the possibility of collusion and further enhancing security based on TEE Bridge.

Conclusion

ZKbridge, Optimistic Bridge, and TEE Bridge are all excellent solutions that attempt to build more trustless cross-chain bridges, eliminating centralization risks and improving the security of cross-chain bridges. However, ZKBridge and Optimistic still face performance sacrifices and scalability shortcomings, while TEE Bridge has the potential for collusion attacks.

The ZK TEE-Bridge proposed by BOOL Network is an impeccable solution from all aspects, with advantages including:

• No sacrifice in performance, maintaining the speed and cost of cross-chain message transmission at the same level as "multi-signature bridges."
• Support for non-smart contract chains, with lower engineering effort for adapting to new chains.
• Elimination of potential collusion risks in TEE bridges, achieving ultra-high security comparable to light client bridges.
• Essentially a decentralized, trustless signing machine, which can be extended beyond the cross-chain field to areas such as oracles and distributed key management.