Bool Network: The Hexagonal Warrior in Cross-Chain Bridges

Author: MiddleX, LayerBase Labs Advisor

With the development of the multi-chain landscape, cross-chain bridges have become an important infrastructure in the Web3 space. Regardless of how the public chain landscape evolves, cross-chain remains an unchanging necessity. For Dapp project teams, they need to expand their business scope to more chains, evolving from single-chain Dapps to full-chain Dapps; for public chain project teams, there is motivation to bridge Bitcoin and Ethereum to bring assets and traffic into their ecosystems; for crypto users, they hope to move their crypto assets across different chains in a decentralized manner, without relying on centralized exchanges.

However, cross-chain bridges, as the "cash trucks" between chains, have frequently been "robbed." In the past two years, mainstream cross-chain bridge projects have almost all been targeted by hackers. Among various types of crypto security incidents, cross-chain bridge incidents have topped the list with nearly $2 billion in losses. Addressing the security issues of cross-chain bridges and equipping this currently "open-top" "cash truck" with armor is urgent.

How to break the deadlock?

Overall, cross-chain bridge security incidents can be categorized into two types: one type is caused by contract code vulnerabilities, such as the lack of token contract address verification, which allows attackers to deposit counterfeit coins without being filtered, or the lack of access control, which leads to tampering with the validator list; the other type involves collusion among validator nodes, stealing private keys, thereby stealing locked funds from the cross-chain bridge, or minting counterfeit coins to rob LPs.

The primary reason for the former is that the codebase of cross-chain bridges is not yet mature, and these issues will gradually decrease as industry experience accumulates. The main reason for the latter is the inherent design flaws of cross-chain bridges.

Cross-chain bridges essentially solve the problem of how one chain knows about events on another chain. This problem can be divided into two aspects: transmission and verification. In cross-chain bridges, anyone can transmit cross-chain events; the key is how the target chain verifies that the event actually occurred on the source chain.

Based on different verification mechanisms, cross-chain bridges can be divided into three types: Natively Verified, Locally Verified, and Externally Verified.

• Natively Verified means that the full validators of the target chain reach consensus on events from the source chain, generally implemented by deploying a light client of the source chain on the target chain. This light client continuously saves and updates the block headers of the source chain, thereby performing SPV verification on events from the source chain.

• Locally Verified refers to direct verification of transactions by the counterparties, also known as peer-to-peer verification. A typical paradigm is atomic swaps based on hash time locks. Since the economic interests of both parties are adversarial, there is no possibility of collusion.

• Externally Verified means introducing a group of external witnesses responsible for verifying cross-chain messages. The external witness group reaches consensus signatures on cross-chain events, and the target chain considers the event trustworthy once it verifies the signature.

Natively Verified has a high cost, primarily reflected in two aspects: first, the on-chain verification cost is high; running a light client on-chain and performing SPV verification on events consumes a large amount of Gas; second, the development cost of supporting new chains is high; for each new chain supported, at least one pair of light clients needs to be developed. With the rise of ZK narratives, there are currently solutions on the market that improve native verification through ZK technology, which can effectively alleviate the aforementioned costs. However, regardless of how it is optimized, at least one ZK proof still needs to be verified on-chain, with an expense of about 500 k Gwei, which is incomparable to the external verification that only requires verifying a single signature (21 k Gwei). Therefore, native verification cannot gain an advantage in the price competition of cross-chain bridges and cannot achieve true "full-chain" capabilities.

Local verification was once adopted by well-known projects like Celer and Connext, but these projects have all changed their approach and no longer use local verification. The reason is that the transaction experience of local verification is extremely poor; no matter how it is optimized, users always need to perform at least two operations (initiating a transaction and unlocking the hash lock). If the counterparty goes offline midway or deliberately does not complete the transaction, it can lead to the user's funds being stuck. Moreover, local verification is only suitable for asset cross-chain and cannot be extended to arbitrary message cross-chain.

External verification has a lower implementation cost, low cross-chain overhead, can easily adapt to multiple chains, and supports arbitrary message cross-chain. Currently, it is the solution adopted by most cross-chain bridge projects. However, external cross-chain bridges introduce new trust assumptions, which bring potential collusion risks. Most externally verified cross-chain bridges use MPC (Secure Multi-Party Computation) technology to shard private keys, allowing each external verification node to hold a shard.

Compared to ordinary MultiSig technology, MPC technology has advantages such as stronger universality (no requirements on the signature scheme used by the chain), lower verification costs (only a single signature needs to be verified on-chain), and easier transfer of signing authority (only refreshing the shard is needed, without changing the address). However, this does not change the centralized nature of external verification and cannot eliminate collusion.

So what kind of cross-chain solution can eliminate collusion risks and improve the security of cross-chain bridges without sacrificing their performance, scalability, and universality?

The BOOL Network Solution

BOOL Network is a cross-chain bridge product launched by LayerBase Labs. LayerBase Labs has been researching the cross-chain field for nearly four years and has launched some minimum viable products during this period. However, due to the incompleteness of these products, they have not been widely promoted. Recently, LayerBase Labs launched a cross-chain bridge based on Dynamic Hidden Committee (DHC): BOOL Network, which is considered sufficiently perfect and is ready to be presented to the public.

The cross-chain solution of BOOL Network integrates ZK technology and TEE technology based on MPC technology, transforming the external verifier group into a non-knowledgeable, non-self-aware dynamic hidden committee, achieving a high degree of anti-collusion properties and thus achieving high security.

Let’s illustrate what a "Dynamic Hidden Committee" is with an example.

Suppose you are a general commanding 1,000 soldiers, tasked with guarding 50 granaries. How would you arrange your soldiers?

Assuming all granaries are equally important, the best arrangement would be to divide the 1,000 soldiers into 50 teams of 20, with each team responsible for guarding one granary.

However, this division brings a risk: if more than half of the soldiers in a team collude, the corresponding granary may be compromised. This means that if 11 soldiers in a team collude, they could betray you and seize the granary.

This is something you cannot tolerate. To prevent such collusion and ensure the safety of the granaries, you could take the following measures:

Dynamic: Reorganize all soldiers every day, reshuffling the teams so that each soldier's assigned granary and teammates are not fixed;

Hidden: Blindfold the soldiers so they do not know which granary they are guarding or who their teammates are.

With this approach, the betraying soldiers will not know with whom to collude. Even if there are pre-agreed traitors, they cannot control or know whether the traitors are in the same team.

To ensure that collusion is likely to succeed, the traitors must collude with the majority of your entire 1,000-person team. This is undoubtedly a daunting task. By using "dynamic" and "hidden" methods, you ensure that the reliability of each team reaches the level of the entire force.

This is precisely the solution adopted by BOOL Network.

TEE ------ Blinding Each Soldier

BOOL Network requires nodes in the network to use TEE devices to participate in the verification of cross-chain events. BOOL Network is completely open for access; any entity with a TEE device can become a verification node by staking $BOOL.

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 by hardware. The process of running programs in TEE is concealed, imperceptible, and uncontrollable from the outside. This makes it difficult for hackers to launch attacks.

TEE can run highly secure applications, such as biometric authentication and secure payment management. In our daily lives, TEE is not unfamiliar; fingerprint verification on mobile phones operates within TEE. This ensures that other mobile applications cannot access fingerprint information while using the results of fingerprint verification.

In the verification process of cross-chain events, external verification nodes need to perform consensus signatures, during which private keys must be exposed to the network, making them easy targets for hackers. The attacks that the official bridge Ronin Bridge of Axie Infinity faced in March 2022 and the attack on the official bridge Horizen Bridge of Harmony in June 2022 were both due to the private keys of bridge nodes being compromised by hackers. Using TEE to safeguard private key shards and execute consensus signatures will greatly enhance security and prevent private keys from being compromised. Furthermore, BOOL Network requires that all communications between TEE nodes are fully encrypted, so hackers cannot intercept any information from the communications between nodes.

Ring VRF ------ Randomly Rotating Soldiers

BOOL Network is designed as a tool for creating cross-chain bridges, supporting any third party to create cross-chain bridges on it. When a third party creates a cross-chain bridge on BOOL Network, they need to first create a DHC (Dynamic Hidden Committee). Suppose the third party wants their created cross-chain bridge to support 10 chains; they will need to create 10 DHCs, with each DHC corresponding to one chain, responsible for verifying all cross-chain messages sent to that chain.

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

It is important to note that the members of each DHC are not fixed and are continuously rotated; each Epoch will reshuffle the members. Based on ZK technology, BOOL Network has developed the Ring VRF protocol, which can randomly assign members to each DHC.

Ring VRF will generate a ZK proof for DHC members, representing their temporary identity. DHC members use temporary identities to recognize and communicate with each other, thereby collaborating to complete tasks (such as performing MPC threshold signatures); this ensures that DHC members are anonymous both externally and among themselves.

Within the same Epoch, TEE nodes in different DHCs may overlap, and some TEE nodes may not enter any DHC and remain idle; these situations are allowed, but Ring VRF will probabilistically give each TEE node an equal opportunity.

In summary, through the Dynamic Hidden Committee mechanism, BOOL Network constructs an impregnable black box. If a TEE node is in a working state, no one (including the node operator, other nodes, or external attackers) can know the operational status of that node, which DHC it is in, which other nodes are in the same DHC, what consensus communications it has engaged in, or which messages it has signed. This embodies the aforementioned "non-knowledgeable" and "non-self-aware." Under such premises, as long as the BOOL Network itself is secure, every dynamic hidden member is secure. To ensure that an attack is likely to succeed, the attacker must control the majority of nodes in BOOL Network. However, since the programs running in TEE are immutable, the attacker can only cause the network to go down but cannot steal assets within the network.

How to Evaluate a Cross-Chain Solution

Although security is the most urgent issue to be addressed by cross-chain bridges, it is not the only criterion for evaluating them. If solving one problem creates another, then it is not truly solving the problem.

LayerBase Labs has long studied various scaling solutions based on light clients, including ZK Client solutions. The basic principle of ZK Client is to use ZK technology to scale light clients by moving the verification of block headers and SPV verification of source chain events off-chain, generating a ZK proof to submit on-chain, where only the ZK proof needs to be verified, which is equivalent to verifying the block header and source chain events. Although this solution is sufficiently secure, its on-chain Gas consumption remains high. Additionally, the off-chain ZK circuit and the on-chain light client are both complex to implement, which may lead to more code-level vulnerabilities, thereby affecting the security of the cross-chain bridge.

Moreover, to avoid requiring every chain to deploy light clients for all other chains, this solution often has to introduce a relay chain (see the diagram below), and the existence of the relay chain forces the originally single-step cross-chain message transmission process to be split into two steps, increasing the latency of cross-chain message transmission.

Currently, many in the industry advocate for ZK Client technology, even claiming that ZK Client is the ultimate solution for cross-chain bridges. We want to emphasize that technology is not for show, nor is it to follow trends; it is meant to truly solve problems. The problems created by ZK Client far exceed the problems it solves.

We have also studied LayerZero's so-called Ultra Light Client solution, which runs light clients off-chain in oracles to address on-chain Gas costs. However, by transferring the verification responsibility from the validators of the target chain to off-chain oracles, it is no longer native verification but external verification, which relies on security assumptions about off-chain oracles. As for LayerZero Labs' claim that "Relayers and oracles are independent," this security premise does not exist in reality, as confirmed by L2BEAT Labs' attack experiments.

We have also noted the optimistic verification solutions adopted by Nomad and Celer, which successfully elevate the security of m-of-n to 1-of-n by adding a challenger role based on external verification. Although this solution is cleverly conceived, it comes at the cost of around 30 minutes of latency, which limits its applicability.

We also find the design of Avalanche Bridge to be cool; it uses TEE nodes as external verifiers to validate cross-chain events and achieves an efficient and inexpensive cross-chain experience through minimalist contract design. However, we also see that while Avalanche Bridge can securely safeguard private keys and prevent external attackers, it cannot guard against internal collusion attacks among TEE nodes.

Ultimately, we propose the current BOOL Network's dynamic hidden committee solution, which can prevent external hacker attacks while also preventing internal collusion from a security perspective. In terms of performance and experience, BOOL Network's cross-chain experience does not sacrifice anything based on external verification, maintaining the same level as external verification bridges.

When evaluating a cross-chain bridge, we believe it should be comprehensively assessed based on an expanded framework of six aspects, namely Cost, Speed, Security, Liveness, Generality, and Scalability.

• Cost: The cost of cross-chain transactions primarily lies in on-chain Gas costs. The fee for verifying a cross-chain message on BOOL Network is essentially equivalent to verifying a single signature, on par with external verification bridges;

• Speed: Here we only evaluate the latency of the cross-chain bridge itself, without considering the finality issues of the chains. In this regard, due to the absence of redundant on-chain and off-chain computations and the lack of a relay chain (which would lead to redundant second-order verification), BOOL Network's cross-chain speed can also reach optimal levels;

• Security: We have thoroughly discussed that BOOL Network can achieve protection against external attacks and internal collusion.

• Liveness: Simply put, it should not go down. BOOL Network will equip each DHC with one or more backup DHCs upon creation to prevent availability issues caused by more than half of the TEE nodes in a DHC going offline.

• Generality: It should support not only asset cross-chain but also arbitrary message cross-chain, which BOOL Network satisfies.

• Scalability: The ability to quickly support new chains. BOOL Network only requires deploying a set of simple contracts to support a new chain (which can be completed in one person-month of development time), and we have now completed support for all mainstream blockchains. Additionally, BOOL Network is not limited by the Turing completeness of chains and can support non-Turing complete chains like BTC without introducing new trust assumptions.

It can be said that BOOL Network is a hexagonal warrior among cross-chain bridges.

It is worth mentioning that the technical solution paper of BOOL Network has been included in the top journal in the field of cryptography, IEEE TIFS (link), representing the recognition of the cryptographic community for BOOL Network's technical solution.

Future Development Directions

BOOL Network currently provides a secure cross-chain bridge building platform, allowing any third party to create full-chain applications based on BOOL Network. BOOL Network will become the most solid underlying support for full-chain applications.

From another perspective, BOOL Network essentially builds a decentralized signing machine, which can be used not only to verify messages on-chain but also to verify messages off-chain. This means BOOL Network will become a secure and reliable full-chain oracle. Furthermore, the decentralized TEE network built by BOOL Network may also provide privacy computing services in the future.