Multichain has fallen, what can save the cross-chain bridge?

Multichain falls, what can save cross-chain bridges?

Something went wrong with Multichain, and the progress of the event is still unclear, and the truth has not yet fully emerged. What can be confirmed is that the LPs providing liquidity to Multichain and the users holding anyToken, the mapped asset issued by Multichain, are likely to suffer. The amount of affected assets is too large, and it is unknown whether anyone will come forward to make up for the losses.

On July 6th, more than 126 million US dollars of assets were transferred from the MPC custodial address deliberately. According to the analysis of the contract auditing team Beosin, the transfer of funds was completely deliberate and had nothing to do with contract vulnerabilities, proving that the private key of Multichain’s MPC custodial address has been controlled by external forces.

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

• Ethereum SAAS Staking One-Week Data Record
• DeFi Regulatory Woes Uniswap in Heaven, Tornado Cash in Hell
• MEKE public beta countdown ends, focusing on derivative trading in the DeFi sector.

WTF!!!!!!!!!!!!!!!

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

Currently, almost all the top TVL cross-chain bridges on 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, collapsed due to private key leaks, resulting in losses of 620 million USD and nearly 100 million USD respectively.

Why is the multi-signature bridge not trustworthy?

In general, cross-chain bridges can be divided into three types: light 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 (requires users to perform more than 2 operations) and inability to support arbitrary message transmission. The light client type cross-chain bridge is relatively difficult to implement in terms of engineering, and the cost of compatibility with new chains is high, so it is currently only used in some dedicated bridges that only need to support a small number of chains. The witness type cross-chain bridge is relatively easy to develop and implement, can easily adapt to multiple chains, and has good performance (fast speed, low cost), making it the choice of most projects.

The witness type bridge verifies the authenticity of cross-chain messages by a group of external Bridge Nodes collectively signing, so we also call it a multi-signature bridge. Cross-chain bridges generally use the lock-mint logic to transfer assets between chains. Users lock the native assets on the source chain (e.g., USDC) to mint the mapped assets on the target chain (e.g., anyUSDC). These locked assets become the TVL of the bridge. Once they are stolen, the mapped assets in the hands of 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 about 20. When the TVL (Total Value Locked) is low, these entities may not conspire to do harm. However, when the TVL of the multi-signature bridge reaches hundreds of millions of dollars, there is no guarantee that they will not be tempted. If the benefits are significant enough, it is not difficult to conspire with 20 nodes. This is not considering the fact that many nodes of cross-chain bridges are often highly related “friendly competitors” with high interest rates. There are even cases where a single entity controls multiple nodes of a cross-chain bridge. For example, out of the 9 nodes of the Ronin Bridge, 4 are controlled by Star Mavis Company. The situation with Multichain is even more extreme, as 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 become a turning point for the field of cross-chain bridges. When no one is willing to tolerate the security risks brought by centralization, “multi-signature bridges” naturally cannot continue. If the era dominated by “multi-signature bridges” 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 safer cross-chain bridges.

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 have observed 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 received a lot of attention, and many projects in this direction have been funded.

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 because they directly verify messages from the source chain at the consensus layer of the target chain, without introducing any third-party trust assumptions. However, lightweight clients need to continuously maintain the block header sequence of the source chain, and they need to verify each new block header, which brings two major challenges:

• Significant on-chain costs, which may make the bridge economically infeasible.

• If a universal bridge is to be made, at least two new lightweight clients need to be developed for each new supported chain. The cost of compatibility with a 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 headers and their validity proofs (ZK Proofs) can be submitted to the chain. The chain can directly verify the ZK Proofs, which is equivalent to verifying the new block headers, but with significantly reduced costs. Furthermore, the process of performing SPV verification of transactions with block headers can also be placed on-chain.

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

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 compared to the 21k Gas required to verify a signature in a multi-signature bridge. This ultimately translates into high cross-chain fees for front-end users. Although batch processing allows the cost to be shared among multiple transactions, it also results in longer waiting times for users.

In addition, as a light client bridge, Zkbridge requires integration with chains that support smart contracts, so non-smart contract chains like BTC cannot be integrated.

Optimistic Bridge

The Optimistic bridge is an improvement on the multi-signature bridge that relies on trust roots. The Optimistic bridge introduces the concept of a challenge window and a role called the “challenger”.

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

① Initiation: Users interact with the Source dApp on the source chain to initiate the cross-chain message delivery.

② Off-chain signature: The message is passed to Bridge Nodes for consensus signing and then transmitted to the target chain.

③ On-chain signature verification: The target chain verifies if the message has been signed by the correct Bridge Nodes.

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

In the Optimistic Bridge, after completing step ③, the message does not immediately proceed to step ④, but enters a timing phase. If there are no challengers questioning the message after the timing phase, the message will proceed to the execution phase and be executed by the Target dApp.

If a challenger questions the message, it will be marked as “untrusted”. Untrusted messages will not enter the execution phase and the challenger will submit it 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 means the challenger made a false report. If the message does not exist on the source chain, it proves that the Bridge Nodes engaged in fraud by signing a false message. After arbitration, rewards will be given to the honest party while the dishonest party will be punished.

Through this mechanism, the Optimistic bridge elevates the trust root of the multi-signature bridge from m-of-n to 1-of-n, making the bridge reliable with just one honest challenger.

The drawback of the Optimistic Bridge is that it increases the waiting time for users, which generally takes around 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, the Optimistic Bridge often adopts 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 the user in the front-end.

The mechanism of the Optimistic Bridge is undoubtedly a significant improvement on the multi-signature bridge, as it ensures security while also considering performance. Unfortunately, security and performance are not truly balanced, but rather the choice between prioritizing security or performance is given to the user. It cannot be considered a perfect solution.

In addition, because on-chain arbitration must be implemented through smart contracts, this solution still does not support non-smart contract chains like BTC.

TEE Bridge

TEE Bridge refers to requiring all nodes to use TEE devices to access the network based on a multi-signature bridge. TEE stands for Trusted Execute Environment, which is a computing environment running on a specific device that is isolated from the main operating system, like an enclave. This isolation is enforced through hardware.

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

The advantages of TEE Bridge are:

• It significantly enhances security without sacrificing performance based on a multi-signature bridge.

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

However, TEE Bridge still carries the risk of internal collusion. If a 2/3 majority of 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 for 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 Committees) 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, which can be set by the creator of the DHC. The signature threshold is usually set at 2/3, but the creator of the DHC can also set a higher threshold.

Bool Network randomly assigns members to all DHCs and reshuffles and reallocates 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 has been assigned to, nor does it know which nodes it has been allocated with in the same DHC, let alone which DHC other nodes have been assigned to. It feels like attending a masquerade ball, where no one knows who is who!

This is achieved through Bool Network’s Ring VRF algorithm. Specifically, when allocating node members to DHCs, 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 recognize each other through these temporary identities and complete MPC signature work through encrypted communication. After the current Epoch ends, Ring VRF will reshuffle the members of all DHCs, and at this time, all temporary identities will become invalid, and Ring VRF will assign new temporary identities to each node.

In summary, Bool Network combines ZK technology with TEE technology to achieve complete anonymity between nodes and eliminate the possibility of collusion. It further enhances security based on TEE Bridge.

Conclusion

ZKbridge, Optimistic Bridge, and TEE Bridge are all excellent solutions that are attempting 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 shortcomings in scalability, while TEE-Bridge has the possibility of collusion attacks.

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

• No sacrifice in performance, with the speed and cost of cross-chain message transmission kept 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 the collusion risks that may exist in TEE bridges, achieving ultra-high security comparable to light client bridges

• Essentially a decentralized, Trustless signing machine that can be extended beyond the field of cross-chain to areas such as oracle and distributed private key management

We will continue to update Blocking; if you have any questions or suggestions, please contact us!