Bool Network: The Ultimate Solution of Cross Chain Bridges Protected by Dynamic Hidden Committee (DHC)，introducing interoperability to the Bitcoin ecosystem

Is it possible to eliminate collusion risks and improve the security of cross chain bridges without sacrificing their performance, scalability, or general applicability?

Security issues with cross chain bridges

With the development of an omni-chain landscape, cross chain bridges have become crucial infrastructure in the Web3 field. Despite the ever-changing state of public chains, the need for cross chain communication remains consistent. For dApp developers, expanding their business scope to more chains and evolving from a single-chain dApp to a multi-chain one is essential. For public chain developers, bridging Bitcoin and Ethereum to bring assets and attraction into their own ecosystems is a common motivation. For Web3 users, the desire to decentralize their assets and move them across different chains without relying on centralized exchanges is widespread.

However, cross chain bridges, as the “cash trucks” between chains, are often targeted by hackers. Over the past two years, almost all mainstream cross chain bridge projects have suffered from security breaches. Among various types of crypto security incidents, the losses from cross chain bridge incidents rank highest, approaching nearly $2 billion. Therefore, addressing cross chain bridge security issues and adding protection to the “open-top” cash trucks is urgently necessary.

How to break the deadlock

In general, cross chain bridges are susceptible to two distinct categories of security incidents. The first pertains to smart contract code vulnerabilities, notably the absence of verification on token contracts, which enables malicious actors to deposit counterfeit tokens that go undetected. Insufficient access control is another critical aspect that can lead to the manipulation of the recorded validator list. The second category encompasses fraudulence perpetrated by validation nodes acting in collusion with each other, illicit access to private keys, and subsequent embezzlement of funds from cross chain bridge lock-up accounts. Additionally, malefactors may also exercise the option of minting fake coins to exploit LP and acquire ill-gotten gains.

The main reason for the former is that the standard code library for building cross chain bridges is not yet mature. It is, however, expected that the accumulation of industry expansion will lead to a gradual reduction in such issues. The primary cause of the latter is inherent flaws at the design level of cross chain bridges.

Essentially, cross chain bridges address the challenge of how information about events on one chain can be propagated to disconnected remote chains. The problem can be bifurcated into two critical aspects, namely transmission and verification. While cross chain events can be transmitted by anyone, the pertinent question remains how the target/destination chain can validate that such events have truly occurred on the source chain?

Figure 1. An intuitive diagram for cross chain communications

Three types of cross chain bridges can be categorized based on their verification mechanism: Native Verification, Local Verification, and External Verification.

• Native verification refers to the consensus-driven verification conducted by all validators on the target blockchain of events from the source blockchain, typically achieved through the deployment of a light client from the source chain on the destination chain. This client constantly maintains and updates the header of the source chain’s blocks, thereby enabling SPV (Simplified Payment Verification) of events on the source chain.
• Local verification refers to the direct validation of transactions by counterparties, also known as peer-to-peer validation. A typical paradigm is based on atomic swaps utilizing a hashed timelock. As the economic interests of the two parties involved in the transaction are adversarial, collusion is not possible.
• External validation refers to the introduction of a set of external witnesses responsible for verifying cross chain messages. The external witness set reaches consensus signatures on the cross chain events, and upon verification of the signature by the target chain, the event is deemed trustworthy.

The elevated expense associated with native verification can be largely attributed to two factors. Firstly, the expenditure associated with on-chain verification is considerably high, as engaging a light client to run on-chain and executing SPV of occurrences is very resource-intensive. Secondly, the development cost of supporting new chains can be quite steep, as each new chain compatibility requires the development of at least one pair of light clients. Fortunately, with the advent of ZK (Zero-Knowledge) technology, there are now solutions available that enhance native verification, thereby effectively mitigating the aforementioned expenses. Nevertheless, even with these optimizations, on-chain verification mandates at least one ZK proof to be verified, which amounts to an expenditure of approximately 500k Gwei, a cost that is not commensurate with external verification that necessitates only one signature verification (21k Gwei). Consequently, native verification does not have a competitive advantage in terms of pricing for cross chain bridges and cannot truly achieve a “fully connected” state.

The deployment of local validation was once embraced by prominent Web3 projects, including the likes of Celer and Connext. However, these projects have since altered their infrastructure and abandoned local validation as their preferred strategy. This shift has been motivated by the fact that local validation presents inadequate transaction experience. Despite extensive optimization efforts, the user is still required to undertake multiple operational steps (such as initiating the transaction and unlocking the hashed timelock) which belies the seamless ideal of blockchain transactions. Moreover, there is the issue of counterparty downtime or malicious intent which can result in frozen funds for the user. Furthermore, local validation is restricted to cross chain asset exchanges and is incompatible with message cross chain transactions.

The utilization of external verification in cross chain bridges offers numerous advantages such as a low implementation and maintenance cost, minimal cross chain overhead, flexibility to operate on multiple and heterogeneous chains, and support for various cross chain messaging schemes. The majority of cross chain bridge initiatives currently employ external verification as their adopted solution. However, the integration of external verification introduces new assumptions of trust and additional collusion risks. Most cross chain bridges implementing external verification apply MPC (Multi-Party Computation) to shard private keys so that every external verification node holds a unique private key share. As compared to the ordinary MultiSig (Multi-Signature) approach, MPC possesses greater generality (no requirements for the signature scheme of the chain), lower verification expenditures (just one signature to verify on the target chain), and more convenient signature authority transfer (only the need for a refreshed shard without changing the address), and other advantages. Despite these benefits, the centralization nature of external verification remains unchanged, and the risk of collusion still exists.

So what type of cross chain solution can be employed to mitigate collusion hazards and enhance the security of cross chain bridges, without compromising their performance, scalability, and generality?

Solution proposal for Bool Network

LayerBase Labs, a research team with an established history of extensive exploration in the cross chain realm dating back nearly four years, has announced the release of its latest cross chain bridge protocol, Bool Network. In previous iterations, the team had launched a series of minimal viable products that have never been widely promoted. Leveraging the Dynamic Hidden Committee (DHC) mechanism, the team’s latest product is deemed to be a comprehensive and sophisticated solution that is now ready for public use. This development marks a crucial milestone in LayerBase Labs’ ongoing journey to advance cross chain technology within the blockchain industry.

The cross chain solution offered by Bool Network incorporates cutting-edge cryptographic techniques, namely Zero-Knowledge (ZK) and Trusted Execution Environments (TEE), that leverage Multi-Party Computation (MPC) to establish unknowable and unconscious sets of constantly evolving validators, i.e. DHCs. This innovation effectively thwarts malicious collusion attempts, ensuring optimal security in the cross chain field.

To elucidate the notion of the “Dynamic Hidden Committee” in Bool Network, we shall provide an illustrative example.

Let us envisage a situation where you are a commander of an army overseeing the safekeeping of 50 granaries with the help of 1000 soldiers. How would you deploy your soldiers?

In the event of all granaries being equally significant, the optimal tactic would be to divide the 1000 soldiers into 50 groups, each consisting of 20 soldiers, to guard each granary.

However, this approach entails a peril. If over half of the soldiers in one team collude, they may cause their designated granary to be lost, and thus jeopardize the overall mission. In other words, if 11 soldiers in a team conspire, they may betray their authority, and take over the granary.

This impels the implementation of a countermeasure to deter conspiracy and prevent the granaries from being compromised. The solution is to apply the concept of “Dynamic Hidden Committee”.

• Dynamic: It necessitates the dynamic reformation and reassignment of soldiers into different teams every day. This empowers each soldier to guard a granary distinctly and work alongside different teammates every day.
• Hidden: Each soldier’s vision is obscured, and they are not apprised of which granary they are safeguarding nor who their teammates are.

The conspiring soldiers would be unable to collude cohesively owing to their ignorance of whom to plan with. Even if premeditated colluders are present, they would be unable to control other team members or determine whether the other participants belong to the same team.

Consequently, the odds of conspirators coordinating with a majority of 1000 soldiers become virtually impossible, thereby rendering the conspiracy non-viable. By adopting the “Dynamic” and “Hidden”, each team’s credibility will be proportionate to the total trustworthiness of the entire troop.

These strategies form the crux of Bool Network’s cross chain solution.

TEE — Blinding every soldier

Bool Network mandates that nodes in the network must use devices with TEE for verifying cross chain events. Bool Network is a permissionless system, and any entity possessing a TEE device can become a verification node by staking the network native token, $BOOL.

TEE stands for Trusted Execution Environment, which is an isolated computing environment running on a given device, separate from the primary operating system, similar to an Enclave. This isolation is enforced by hardware, and the execution of programs within the TEE is concealed from external perception and intervention, rendering hacking attacks infeasible.

TEE can run highly secure applications, such as biometric authentication and secure payment management. In our daily lives, TEE is ubiquitous, as exemplified by fingerprint verification on mobile devices. This ensures that other applications on the mobile device cannot access the fingerprint information.

During cross chain event verification, external verification nodes need to engage in a consensus signature process, which means that private keys need to be exposed to the network, making them highly susceptible to hacker attacks. The attacks on the Axie Infinity official bridge — Ronin Bridge in March 2022 and the Harmony public chain official bridge — Horizen Bridge in June 2022 were caused by hackers gaining access to the bridge node’s private keys. Using TEE to store private key shares and execute consensus signatures will significantly enhance security, preventing private key theft. Moreover, Bool Network demands that all communications between TEE nodes must be fully encrypted, thereby rendering it impossible for hackers to intercept any information from inter-node communication.

Ring VRF — Random rotation for soldiers

Bool Network is designed as a tool for building cross chain bridges that support third-party creation of application-specific bridges on the platform. When a third party creates a cross chain bridge on Bool Network, they need to create Dynamic Hidden Committees (DHC). If the third party plans to create a cross chain bridge that supports 10 chains, for example, they are required to create 10 DHCs, with each DHC corresponding to one chain responsible for verifying all cross chain messages sent to that chain.

As the number of cross chain bridges created on the platform continues to increase, the number of DHCs could increase to thousands or even tens of thousands. In addition, third parties can set the signature threshold for DHCs. Common signature thresholds include 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 constantly evolving. Members of DHC cooperate to perform a task such as conducting MPC threshold signatures using their temporary identifications, which are represented by a ZK proof generated by Ring VRF protocol proposed by Bool Network based on ZK technology. This ensures that DHC members always remain anonymous both externally and internally.

In the same epoch, TEE nodes from different DHCs may overlap, and some TEE nodes may be left idle without serving any DHC. These scenarios are allowed, but Ring VRF protocol guarantees each TEE node an equal opportunity to be selected on a probabilistic basis.

Figure 2. Dynamic Hidden Committees (DHC) on Bool Network

In essence, Bool Network has established an impenetrable black box through the use of its Dynamic Hidden Committee mechanism. When a TEE node is in operation, no one, including the operator of the node, other nodes, or external attackers, can ascertain the node’s operating status, its position in a specific DHC, which other nodes are in the same DHC, what consensus communications have occurred, or what messages have been signed. This is what was previously referred to as the “unknowable” and the “unconscious”. Given this context, as long as the Bool Network itself is secure, each committee member is secure as well. In order for an attacker to ensure a high probability of success, they must control the majority of nodes in the Bool Network. However, because the program run in the TEE is tamper-proof, attackers are only able to cause network crashes and cannot steal assets in the network.

How to evaluate a cross chain solution

Although security is the most pressing issue to be addressed for cross chain bridges, it is not the sole criterion for evaluating them. Creating a new problem while attempting to address an existing one does not constitute a genuine solution.

LayerBase Labs has long been researching various scaling solutions based on light clients, including the ZK Client scheme. The ZK Client operates on the fundamental principle of expanding the capabilities of light clients through the use of ZK. This involves moving the validation of block headers and SPV of source chain events off-chain, creating a ZK proof to be submitted to the destination chain. With only the need to validate the ZK proof, this solution is sufficiently secure. However, its on-chain gas consumption remains high, and both its off-chain ZK circuits and on-chain light clients are technically complicated to build, which may result in vulnerabilities at the code level, thus compromising the security of cross-chain bridges. Furthermore, to avoid the need for each chain to deploy light clients for all other chains, this solution often necessitates the introduction of a Relay chain (see Figure 3), which increases the latency of cross chain message transmission by splitting the process into two steps.

Figure 3. The comparison of development complexity between the light client solution and the relay chain solution

Currently, there are many advocates in the industry for ZK Client technology, even claiming that ZK Client is the ultimate solution for cross chain bridges. We would like to emphasize that technology is not for show nor for chasing after trends, but for truly solving problems. The problems created by ZK Client far outweigh the problems it solves.

We have also studied LayerZero’s so-called Ultral Light Client solution, in which LayerZero runs the light client off-chain through oracles to reduce on-chain gas expenses. However, when the verification responsibility is transferred from the verification on the target chain to oracles off-chain, it is no longer a native verification model but an external one, which has security hypotheses for oracles off-chain. As for the security premise that “Relayer and Oracle are mutually independent” claimed by LayerZero Labs, it simply does not exist in reality, as demonstrated by the attack experiments of L2BEAT Labs.

We also noticed the optimistic verification solution adopted by Nomad and Celer. By adding a challenger role to external verification, the security of m-of-n can be successfully increased to 1-of-n. Although this solution is well-conceived, its cost is a delay of about 30 minutes, which limits its scope of application.

We also found the design of Avalanche Bridge to be enlightening. It uses TEE nodes as external validators to verify cross chain events and achieves efficient and cost-effective cross chain experience with minimal contract design. However, we also see that Avalanche Bridge cannot prevent internal TEE nodes from conspiring attacks, though it can securely store private keys and prevent external attackers.

Finally, we propose the solution of Dynamic Hidden Committee for Bool Network. From a security perspective, it can prevent external hacker attacks while preventing internal conspiracy. In terms of performance and experience, Bool Network’s cross chain experience does not sacrifice anything on the basis of externally verified bridges, remaining at the same level.

When evaluating a cross chain bridge, we believe that it should be comprehensively assessed based on the conventional impossible triangle, expanded into six aspects: Cost, Speed, Security, Liveness, Generality, and Scalability.

• Cost: The cost of cross chain mainly lies in the gas cost of the chain. The cost of verifying a cross chain message on Bool Network is actually only equivalent to a single on-chain signature verification, which is in line with externally verified bridges.
• Speed: We only evaluate the latency of the cross chain bridge itself, without considering the finality issue of the chains themselves. In this regard, as there are no redundant on-chain and off-chain calculations, and no relay chain design (which can cause redundant second-order verification), the cross chain speed of Bool Network can also reach the ultimate level.
• Security: We have fully explored how Bool Network can achieve external attack resistance and internal conspiracy prevention in the preceding paragraphs.
• Liveness: It simply refers to not experiencing crashes. 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 being offline in a single DHC.
• Generality: It requires support for not only assets but also arbitrary message transmission across heterogeneous networks which Bool Network also satisfies.
• Scalability: How long does it take a cross chain bridge to support a new heterogeneous chain? Bool Network only needs to deploy a set of simple contracts to support a new chain (which can be completed within one person-month of development time), and we have now completed support for all mainstream blockchains. Additionally, Bool Network is not limited by chain Turing completeness and can support non-Turing complete chains such as Bitcoin without adding new security assumptions.

It can be summarized that Bool Network is the HEXAGON warrior among cross chain bridges.

Figure 4. Impossible hexagon for cross chain bridges

It is worth noting that the theoretical paper on Bool Network has been published in the premier cryptography journal IEEE TIFS (link: https://ieeexplore.ieee.org/document/9903072), signifying the recognition of the Bool Network solution in the cryptography community.

Figure 5. The theoretical paper on Bool Network has been published in IEEE Transactions on Information Forensics and Security (TIFS)

Future development directions

Bool Network currently provides a secure cross chain bridge construction platform, enabling any third party to create omni-chain applications based on Bool Network. It will become the most robust underlying infrastructure for embracing the omni-chain era of Web3.

Looking from a different perspective, Bool Network essentially establishes a decentralized signature scheme that can verify both on-chain and off-chain messages. This means that Bool Network will become a secure and reliable full-chain oracle. Additionally, the decentralized Trusted Execution Environment (TEE) network constructed by Bool Network can provide privacy computing services in the future.

Figure 6. The protocol stack for Bool Network

About Bool Network

Bool Network is a permissionless, fully trustless, and highly scalable cross-chain interoperability protocol based on Multi-Party Computation (MPC), Zero-Knowledge Proof (ZKP), and Trusted Execution Environment (TEE). It proposes a decentralized signature scheme to facilitate arbitrary message transmission and digital asset transfers across heterogeneous networks.

Follow us on social media:

Website: https://bool.network/
Twitter: https://twitter.com/bool_official
GitHub: https://github.com/boolnetwork
Discord: https://discord.com/invite/DVd4q9qq7a
Telegram: https://t.me/BoolCommunity