Multichain has collapsed, where should the cross-chain bridge lead to?

Where should the cross-chain bridge lead after Multichain's collapse?

Multichain is in trouble, and the progress of the event is still unclear, and the truth has not fully emerged. What can be determined is that the LPs that provide liquidity to Multichain and the users who hold the mapping asset anyToken issued by Multichain are likely to suffer. The amount of assets affected this time is too large, and it is unknown whether someone will come forward to bail them out.

On July 6th, more than $126 million in assets were transferred out of the MPC custody address by human intervention. According to the analysis of the contract audit team Beosin, the transfer of funds was completely manipulated by humans and had nothing to do with contract vulnerabilities, indicating that the MPC custody address private key of Multichain has been controlled by external forces.

In the official statement released by Multichain on July 14th, it was explicitly announced that Multichain founder Zhaojun was taken away by the police on May 21st. However, what is surprising is that the statement mentioned that all 24 MPC node private keys of Multichain are controlled by Zhaojun, and all node services run entirely on his personal server! WTF!!!

The progress of the event is still unclear, and the truth has not fully emerged. What can be determined is that the LPs that provide liquidity to Multichain and the users who hold the mapping asset anyToken issued by Multichain are likely to suffer. The centralized risk of the multi-signature bridge, like a fat gray rhinoceros, is there for everyone to see, but it is selectively ignored. The key point is that this rhinoceros is carrying billions of dollars in assets!

Currently, almost all of the top TVL cross-chain bridges on the market are multi-signature bridges. Before Multichain, there have been incidents where the official bridge of Axie Infinity, Ronin Bridge, and the official bridge of Harmony Chain, Horizen bridge, collapsed due to private key leaks, causing losses of $620 million and nearly $100 million, respectively.

• Why did Vitalik sell MKR? What is the story behind it?
• Why does the increase in DAI deposit interest rate to 8% cause a sp...
• An Analysis of Polygon’s Newly Launched CDK Stack System Comp...

Why can’t multi-signature bridges be trusted?

Generally speaking, cross-chain bridges can be divided 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, the atomic transaction based on hash time lock is rarely used due to its poor user experience (requiring users to perform more than two operations) and inability to support arbitrary message transmission. Lightweight client type cross-chain bridges are currently only applied in some dedicated bridges that only need to support a few chains due to their relatively difficult engineering implementation and high compatibility costs for new chains. Witness type cross-chain bridges are relatively easy to develop and implement, can easily support multiple chains, and have good performance (fast speed, low cost), which has become the choice of most projects.

The Witness-type Bridge achieves consensus and signs cross-chain messages through a set of external Bridge Nodes to verify the authenticity of the messages. Therefore, it is also called a multi-signature bridge. Cross-chain bridges generally use lock-mint logic to transfer assets between chains. Users lock native assets (such as USDC) on the source chain to mint mapped assets (such as anyUSDC) on the target chain. These locked assets become the bridge’s Total Value Locked (TVL). If they are stolen, the mapped assets held by users or LPs will be detached from the native assets and cannot be fully redeemed. However, if these external Bridge Nodes collude or fail to properly safeguard their own private key fragments, resulting in more than 2/3 of them being obtained by hackers, such incidents can occur!

Most multi-signature bridges have only a few Bridge Nodes, ranging from single digits to dozens. 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, there is no guarantee that they will not be tempted. If the potential benefits are significant, colluding with 20 nodes is not difficult. This doesn’t even take into account the fact that many nodes in cross-chain bridges are often highly related “friends” in terms of interests. Some cross-chain bridges even have a situation where one entity controls multiple nodes. For example, out of the 9 nodes in the Ronin Bridge, 4 are controlled by Star Mavis company. The situation with Multichain is even more extreme, with one person controlling 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 “multi-signature bridge” naturally cannot continue to operate. If the era dominated by the “multi-signature bridge” is the 1.0 era of cross-chain bridges, then the 1.0 era is accelerating its departure, and the protagonist of the 2.0 era of cross-chain bridges will undoubtedly be a more secure one.

So, what kind of cross-chain bridges 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, namely ZKbridge, Optimistic Bridge, and TEE Bridge.

ZK Bridge

Due to the rise of ZK narratives, the exploration of using ZK technology for cross-chain purposes has also attracted much attention, and many projects in this direction have received financing.

ZKBridge is a cross-chain bridge solution that uses ZK technology for lightweight client scalability. We know that lightweight client cross-chain bridges have high security. Their 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, lightweight clients need to constantly maintain the block header sequence of the source chain. In the process, they need to verify each new block header, which brings two major challenges:

• The high on-chain cost may render the bridge economically infeasible.

• If we want to build a universal bridge, we need to develop at least two new lightweight clients for each additional supported chain. The cost of compatibility with new chains is high, making it difficult to create a truly universal bridge.

After introducing ZK technology:

• It is possible to verify new block headers off-chain and submit them along with their validity proofs (ZK Proofs) to the blockchain. The blockchain can directly verify the ZK Proofs, which is equivalent to verifying the new block headers, but with significantly reduced costs. Furthermore, the process of executing SPV verification using block headers can also be put on the blockchain.

• ZK technology simplifies the development of lightweight clients. On-chain lightweight clients only need to verify ZK proofs, which is much simpler than verifying new block headers with contract logic.

However, the performance limit of ZKbridge is still weaker than that of multi-signature bridges. For example, in the case of EVM, the cost of verifying a ZK proof is at least 500k gas, which is nearly 25 times higher compared to the 21k 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, it also brings longer waiting times for users.

In addition, as a lightweight client bridge, Zkbridge needs to connect to chains that support smart contracts and cannot be connected to non-smart contract chains like BTC.

Optimistic Bridge

The Optimistic Bridge is an improvement over the trusted root of a multi-signature bridge. In addition to 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 message transmission in a multi-signature bridge is as follows:

① Initiation: Users initiate cross-chain message transmission by interacting with the Source dApp on the source chain.

② Off-chain signature: The message is passed to Bridge Nodes, and after achieving consensus signature, 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 Target dApp for execution.

In the Optimistic Bridge, after the completion of step ③, the message does not immediately enter step ④. Instead, it enters a timing phase. After the timing period ends and no challenger questions the message, the message can enter the execution phase 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 phase, and the challenger will submit it back to the source chain for arbitration by the source chain’s arbitration contract. If the message is proven to exist 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 have committed fraud by signing a false message. After arbitration, a reward will be given to the honest party and a penalty will be imposed on the dishonest party.

Through this mechanism, the Optimistic Bridge elevates the trust root of the multi-signature bridge from m-of-n to 1-of-n, where only one honest challenger is needed for the bridge to be reliable.

The drawback of Optimistic Bridge is that it increases the waiting time for users, which is usually around 30 minutes. Users have to wait for the end of the challenge window period to complete 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 can skip the challenge window period, while only large transfers or sensitive operations have a challenge window period. The specific threshold can be customized by the application program or chosen by the user in the frontend.

Optimistic Bridge’s mechanism is undoubtedly a significant improvement over multi-signature bridges, as it ensures security while also considering performance. However, unfortunately, security and performance are not truly balanced, as it simply gives the choice of prioritizing security or performance to the user, which 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, based on multi-signature bridges. TEE stands for Trusted Execute Environment, which is an isolated computing environment running on a given device, separate from the main operating system, similar to an enclave. This isolation is enforced by hardware.

In TEE Bridge, nodes use TEE devices to store private key fragments, and the signature program runs entirely in 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 verification mechanism on-chain.

The advantages of TEE Bridge are:

• It significantly improves security without sacrificing performance based on multi-signature bridges.

• It is compatible with non-smart contract chains like BTC.

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

BOOL: ZK-TEE Bridge

Next, I will introduce a more ingenious 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 extremely high security of the bridge.

Bool Network itself is a permissionless network composed of numerous TEE nodes. Any entity can apply to establish one or more DHCs (Dynamic Hidden Committee) through Bool Network. If an entity needs to establish a cross-chain bridge supporting 10 chains, they can apply for 10 corresponding DHCs. Each DHC manages a set of MPC private key fragments and is responsible for verifying and signing cross-chain messages.

A DHC usually consists of 10 to 20 TEE node members, set by the creator of the DHC. The signing threshold is typically 2/3, but the creator of the DHC can also set a higher threshold.

Bool Network randomly assigns members to all DHCs and shuffles them regularly. With the help of ZK technology, Bool Network can achieve a completely random allocation process for members. After the allocation is completed, each TEE node does not know which DHC it is assigned to, nor does it know which nodes it shares a DHC with, let alone which DHC other nodes are assigned to. This feeling is like attending a masked ball, where no one knows who is who!

This is achieved through the Ring VRF algorithm of Bool Network. Specifically, when allocating DHC member nodes, Ring VRF assigns each TEE node a temporary identity, which is represented as a ZK proof that can prove that a node belongs to the current DHC without revealing the specific information of the node. DHC members will recognize each other through temporary identities and complete MPC signature through encrypted communication. After the current epoch ends, Ring VRF will reshuffle all DHC members, and all temporary identities will become invalid. Ring VRF will assign new temporary identities to each node.

In summary, Bool Network achieves complete anonymity among nodes, eliminates the possibility of collusion, and further enhances security based on the combination of ZK technology and TEE technology in the TEE Bridge.

Summary

ZKbridge, Optimistic Bridge, and TEE Bridge are all excellent solutions. They are all trying to build more trustless cross-chain bridges, eliminate centralization risks, and improve the security of cross-chain bridges. However, ZKBridge and Optimistic still have performance sacrifices and scalability limitations, and TEE-Bridge may be vulnerable to collusion attacks.

The ZK TEE-Bridge proposed by BOOL Network is an impeccable solution in all aspects. Its advantages include:

• No performance sacrifice, the speed and cost of cross-chain message transmission are at the same level as “multi-signature bridges”

• Support for non-smart contract chains, with low engineering effort to adapt to new chains

• Elimination of collusion risks that may exist in TEE bridges, achieving ultra-high security comparable to light client bridges

• Essentially a decentralized, trustless signing mechanism that can be extended to areas such as oracles and distributed private key management, not limited to cross-chain applications

• Axie Infinity