Understand Bool Network in three minutes: hexagonal warriors in cross-chain bridges

Can the risk of collusion be eliminated and the security of the cross-chain bridge improved without sacrificing the performance, scalability, and versatility of the cross-chain bridge?

Written by: MiddleX

With the development of the multi-chain pattern, the cross-chain bridge has become an important infrastructure in the Web3 field. No matter how the public chain pattern evolves, the cross-chain is always a constant rigid demand. For Dapp project parties, they need to expand their business scope to as many chains as possible, from a single-chain Dapp to a full-chain Dapp; for public chain project parties, everyone has the motivation to bridge Bitcoin and Ethereum Square, to import assets and traffic for their own ecology; for encrypted users, they also hope to allow their encrypted assets to travel on different chains in a decentralized manner, instead of relying on centralized exchanges.

However, the cross-chain bridge, as a "cash transport vehicle" between chains, has been "robbed" repeatedly. In the past two years, almost without exception, mainstream cross-chain bridge projects have been patronized by hackers. Among all types of encryption security incidents, the cross-chain bridge incident topped the list with a loss of nearly US$2 billion. To solve the safety problem of the cross-chain bridge, it is imminent to add armor to this "open-top" "money carrier".

How to break the game?

Generally speaking, there are two types of security incidents in cross-chain bridges: one is caused by contract code loopholes, such as the lack of token contract address verification, which causes the counterfeit currency deposit events forged by attackers to be unfiltered, and another example is the lack of access control, which leads to The validator set list has been tampered with; the other is the collusion of the validator nodes to steal the private key, and then steal the funds locked by the cross-chain bridge, or mint counterfeit coins to rob LP.

The main reason for the former is that the cross-chain bridge code base is not yet mature, and such problems will gradually decrease with the accumulation of industry experience. The main reason for the latter is the inherent flaws in the design of cross-chain bridges.

The cross-chain bridge essentially solves the problem of how one chain knows events on another chain. This problem is divided into two aspects, one is transmission, and the other is verification. In the cross-chain bridge, anyone can pass cross-chain events, the key is how the target chain verifies that the event actually happened on the source chain. **

According to different verification mechanisms, cross-chain bridges are divided into three types: Natively Verified, Locally Verified, and Externally Verified.

• Native Verification means that all verifiers of the target chain conduct consensus verification on the events of the source chain, which is generally realized by deploying the light client of the source chain on the target chain. This light client continuously saves and updates the block header of the source chain, and then performs SPV verification of the events of the source chain.
• Local verification refers to the direct verification of the transaction by the counterparty, also known as point-to-point verification. A typical paradigm is an atomic swap based on hashed timelocks. Since the economic interests of the parties to the transaction are antagonistic, there is no possibility of collusion.
• External verification refers to the introduction of a group of external witnesses to be responsible for verifying cross-chain messages. The set of external witnesses performs a consensus signature on cross-chain events. After the target chain verifies the signature, it considers the event credible.

The cost of native verification is high, which is mainly reflected in two points. First, the cost of on-chain verification is high. Running a light client on the chain and performing SPV verification on events will consume a lot of Gas. Second, the development cost of compatibility with new chains is high. To be compatible with a new chain, it is necessary to develop at least one pair of light clients. With the rise of ZK narratives, there are currently solutions on the market to improve native verification through ZK technology, which can effectively alleviate the above costs. However, no matter how optimized, at least one ZK proof needs to be verified on the chain, and the cost is about 500 k Gwei. Verification only needs to verify a signature (21 k Gwei) which is quite different. Therefore, native verification cannot gain an advantage in the price competition of cross-chain bridges, and cannot realize the true "full chain".

Local authentication was once adopted by well-known projects such as Celer and Connext, but these projects, without exception, have changed their tune and no longer use local authentication. The reason is that the transaction experience of local verification is extremely poor. No matter how optimized it is, it always requires the user to operate at least twice (initiate the transaction, unlock the hash lock). live. In addition, local verification is only applicable to asset cross-chain, and cannot be extended to any message cross-chain.

The implementation cost of external verification is low, the cross-chain overhead is low, it can be easily adapted to multiple chains, and supports cross-chain cross-chaining of arbitrary messages. Currently, it is the solution adopted by most cross-chain bridge projects. However, external cross-chain bridges introduce potential collusion risks due to the introduction of new trust assumptions. Most of the external verification cross-chain bridges use MPC (secure multi-party computing) technology to fragment the private key, so that each external verification node can master a fragment. Compared with ordinary MutiSig (multi-signature) technology, MPC technology is more universal (there is no requirement for the signature scheme adopted by the chain), the verification cost is lower (only a single signature needs to be verified on the chain), and it is convenient to transfer signature authority (Only need to refresh the shard, no need to change the address) and other advantages, but this does not change the centralization essence of external verification, and cannot prevent collusion.

So what kind of cross-chain solution can be used to eliminate the risk of collusion and improve the security of the cross-chain bridge without sacrificing the performance, scalability, and versatility of the cross-chain bridge?

BOOL Network scheme

BOOL Network is a cross-chain bridge product launched by LayerBase Labs. LayerBase Labs has been researching in the cross-chain field for nearly 4 years, during which it launched some minimum viable products, but due to the imperfection of these products, they have not been widely used. Recently, LayerBase Labs launched a cross-chain bridge based on Dynamic Hidden Committee (DHC): BOOL Network. This solution is considered perfect enough, so it is ready to be unveiled to the public.

BOOL Network's cross-chain solution integrates ZK technology and TEE technology on the basis of MPC technology, and transforms the external verifier set into an unknowable and unknowing dynamic hidden committee, achieving a high degree of anti-collusion attributes, thereby achieving a high degree of security.

Let's use an example to illustrate what is "dynamic hidden member club".

Suppose you are a general, commanding 1000 soldiers and ordered to guard 50 granaries, how will you arrange your soldiers?

Assuming that all granaries are equally important, the best arrangement would be to divide the 1,000 soldiers into 50 squads of 20 men each to guard a granary.

But the division of troops brings a hidden danger. If more than half of the soldiers in a certain team conspire, the corresponding granary may fall. That is to say, if 11 soldiers in a team conspire, they may betray you and rob the granary.

This is something you cannot tolerate. In order to prevent this kind of conspiracy and ensure the safety of the granary, you can take the following measures:

• Dynamic: All soldiers are regrouped and squads are re-divided every day, so that the granary guarded by each soldier and his teammates will not be fixed;
• Hidden: Blindfold the soldiers so that they don't know which granary they are guarding or who their teammates are.

In this way, the rebellious soldiers will not know who to conspire with. Even if there are traitors agreed in advance, they cannot control and cannot know whether the traitors are in the same team.

Assuming that to ensure a high probability of success in conspiracy, the traitor must conspire with the majority of your entire team of 1,000 people. This is undoubtedly as difficult as climbing the sky. Through "dynamic" and "hidden" methods, you make each squad's reliability reach the level of the entire team.

This is exactly the scheme adopted by BOOL Network.

TEE - Blindfold each soldier

BOOL Network requires nodes in the network to use TEE devices to participate in the verification of cross-chain events. The BOOL Network is completely open and accessible, and any subject with a TEE device can become a verification node by pledging $BOOL.

The full name of TEE is Trusted Execution Environment (Trusted ute Environment). It is a computing environment running on a given device that is isolated from the main operating system, like an enclave. This isolation is enforced by hardware. The process of running programs in TEE is hidden, and cannot be perceived or interfered by the outside world. This makes it impossible for hackers to attack.

TEE can run applications with high security, such as biometric authentication, secure payment management, etc. In our daily life, TEE is no stranger, and the fingerprint verification on mobile phones is run in TEE. This can ensure that other mobile phone applications cannot obtain fingerprint information while using the fingerprint verification result.

During the verification process of cross-chain events, external verification nodes need to perform consensus signatures. At this time, the private key has to be exposed to the network, which is very easy to become the target of hacker attacks. The attack on Axie Infinity's official bridge Ronin Bridge in March 2022 and the attack on Harmony public chain's official bridge Horizen Bridge in June 2022 were caused by the private key of the bridge node being obtained by hackers. Using TEE to store private key fragments and execute consensus signatures will greatly improve security and prevent private keys from being obtained by hackers. On this basis, BOOL Network requires that all communication between TEE nodes is also fully encrypted, so that hackers cannot intercept any information from the communication content between nodes.

Ring VRF - Let soldiers rotate randomly

BOOL Network is designed as a tool for creating a cross-chain bridge, which supports any third party to create a cross-chain bridge on it. When a third party creates a cross-chain bridge on the BOOL Network, it needs to create a DHC (Dynamic Hidden Membership Club) first. Assuming that the third party wants the cross-chain bridge it creates to support 10 chains, it needs to create 10 DHCs, each chain corresponds to a DHC, and all cross-chain messages sent to the chain are verified by the DHC.

Every time a third party creates a cross-chain bridge through the BOOL Network, several DHCs will be generated. As the number of cross-chain bridges created on the BOOL Network continues to increase, there may be thousands of DHCs. A third party can set the signature threshold of DHC, and the common signature thresholds are 5-of-9, 13-of-19, and 15-of-21.

It should be noted that the members in each DHC are not fixed, but are constantly rotating, and each Epoch will shuffle once. Based on ZK technology, BOOL Network has developed the Ring VRF protocol, which can assign members to each DHC completely randomly. Ring VRF will generate a ZK proof for DHC members. This ZK proof represents the temporary identity of members. DHC members use temporary identities to identify and communicate with each other, so as to cooperate to complete a certain work (such as MPC threshold signature); Doing so ensures the anonymity of DHC members both externally and with each other.

In the same Epoch, TEE nodes in different DHCs may overlap, or some TEE nodes may be idle without entering any DHC. These situations are allowed, but RIng VRF will give each TEE nodes have exactly equal opportunity.

In short, **By dynamically hiding the committee member mechanism, BOOL Network has built an unbreakable black box. If a TEE node is in a working state, no one (including the node operator himself, other nodes, and external attackers) has any way of knowing the running state of the node. Which DHC is the node in? On the same DHC as which other nodes? What consensus communications took place? What messages are signed? There is no way to know the truth. This is the "unknowable" and "unknowledge" mentioned above. Under such a premise, as long as the BOOL Network itself is safe, every dynamic hidden member is safe. To ensure a high probability of success in the attack, the attacker must master the majority of nodes in the BOOL Network. However, since the programs running in the TEE cannot be tampered with, attackers can only shut down the network and cannot steal assets in the network.

How to evaluate a cross-chain solution

Although security is the most urgent problem to be solved for cross-chain bridges, security is not the only criterion for evaluating cross-chain bridges. If in order to solve a problem, a new problem is created, it is not really solving the problem.

LayerBase Labs has long studied various light client-based expansion solutions, including the ZK Client solution. The basic principle of ZK Client is to expand the light client through ZK technology, put the verification of the block header and the SPV verification of the source chain event off the chain, generate a ZK certificate and submit it to the chain, and only need to verify the ZK certificate on the chain It is equivalent to verifying block headers and source chain events. Although this scheme is safe enough, the Gas consumption on the chain is still high. Secondly, the ZK circuit under the chain and the light client on the chain are relatively good in terms of engineering implementation. Complexity, which may lead to more vulnerability at the code level, thus affecting the security of the cross-chain bridge. In addition, in order to avoid each chain having to deploy light clients of all other chains, this solution often has to introduce a relay chain (see the figure below), and the existence of the relay chain will make the cross-chain that can be completed in one step The message delivery process had to be split into two steps, resulting in an increase in the Latency (delay) of cross-chain message delivery.

There are many people in the industry advocating ZK Client technology, and even claim that ZK Client is the ultimate solution for cross-chain bridges. What we want to say is that technology is not for show, let alone for fashion, but for real problem solving. ZK Client creates far more problems than it solves.

We also studied the so-called Ultra Light Client solution of LayerZero. LayerZero puts the light client into the off-chain oracle to solve the problem of gas overhead on the chain, but you hand over the responsibility of verification from the verifier of the target chain Given the off-chain oracle, it is no longer native verification, but external verification, and there is a security assumption for the off-chain oracle. As for the security premise claimed by LayerZero Labs: "Relayer and oracle machine are independent of each other", it does not exist in reality, and the attack experiment of L2BEAT Labs has confirmed this point.

We have also noticed the optimistic verification scheme adopted by Nomad and Celer. By adding a challenger role on the basis of external verification, the security of m-of-n can be successfully improved to 1-of-n. Although this scheme is well conceived, the cost is a delay of about 30 minutes, which will limit the scope of application of the scheme.

We also found the cool design of Avalanche Bridge, which uses TEE nodes as external verifiers to verify cross-chain events, and achieves an efficient and cheap cross-chain experience through minimalist contract design. But we have also seen that although Avalanche Bridge can safely keep the private key to prevent external attackers, it cannot prevent the collusion attack between internal TEE nodes.

In the end, we proposed the current BOOL Network's dynamic hidden committee scheme. From a security perspective, it can prevent external hacker attacks and prevent internal collusion. In terms of performance and experience, BOOL Network's cross-chain experience is not in the Make any sacrifices on the basis of external verification, and maintain the same level as the external verification bridge.

To evaluate a cross-chain bridge, we believe that based on the impossible triangle, it should be expanded into six aspects for comprehensive evaluation, namely cost (Cost), speed (Speed), security (Security), usability (Liveness) , Generality, and Scarablity**.

• Cost: The cost of cross-chain mainly lies in the gas cost on the chain. The cost of a cross-chain message verification of BOOL Network is actually only a single signature verification, which is at the same level as the external verification bridge;
• Speed: Here we only evaluate the latency of the cross-chain bridge itself, without considering the finality of the chain itself. At this point, since there is no redundant on-chain and off-chain calculations, and no relay chain design (relay chain will lead to redundant second-order verification), the cross-chain speed of BOOL Network can also reach the limit level;
• Security: We have fully discussed that BOOL Network can prevent external attacks and internal collusion. *
• Availability: Simply put, don't crash. BOOL Nework will allow each DHC to be equipped with one or more backup DHCs when it is created to prevent availability problems caused when more than half of the TEE nodes in a certain DHC are offline.
• Generality: It is not only necessary to support asset cross-chain, but also to support arbitrary message cross-chain, which is also satisfied by BOOL Network.
• Scalability: Can it quickly support new chains. BOOL Network only needs to deploy a set of simple contracts to support a new chain (1 person-month development man-hours can be completed), and now we have completed the support for all mainstream blockchains. In addition, BOOL Network is not restricted by the Turing completeness of the chain, and can support non-Turing complete chains such as BTC without adding new trust assumptions.

It can be said that the BOOL network is the hexagonal warrior in the cross-chain bridge.

It is worth mentioning that the technical solution papers of BOOL Network have been included in IEEE TIFS, the top journal in the field of cryptography (Link: This represents the recognition of BOOL Network technical solutions by the cryptography community.

Future direction

BOOL Network currently provides a secure cross-chain bridge building platform, and any third party can create a full-chain application based on Bool Network. BOOL Network will become the most solid underlying support for the whole chain application.

Looking at it from another perspective, BOOL Network essentially builds a decentralized signature machine, which can be used not only to verify messages on the chain, but also to verify messages off the chain, which means that BOOL Network will become a A safe and reliable full-chain oracle. In addition, the decentralized TEE network built by BOOL Network will also provide privacy computing services in the future.