Historical experience indicates that traditional multi-signature/witness bridges are prone to issues, but they are commonplace in the Bitcoin ecosystem, causing significant concern.

This article introduces @bool_official, which enhances traditional witness bridges by providing dynamically rotating witnesses and integrating privacy computing with TEE-encapsulated keys. This approach aims to improve the security model of traditional witness bridges and address the decentralization challenges of cross-chain bridges, potentially offering a breakthrough solution for Bitcoin cross-chain bridges.

1.The Current State of the Bitcoin Ecosystem: Multi-Signatures Everywhere

At its core, a cross-chain bridge needs to prove to Chain B that a cross-chain request has been initiated on Chain A and that the requisite fees have been paid. There are various methods to achieve this.

Light client bridges often deploy smart contracts to natively verify cross-chain messages, offering the highest security but also incurring the highest costs. This method is also not feasible on the Bitcoin chain (current projects promoting Bitcoin ZK bridges can only ensure BTC crosses to other chains through these bridges, but not back to Bitcoin through ZK bridges).

Optimistic bridges, like BitVM, use fraud proofs to ensure the accuracy of cross-chain message processing. However, implementing this solution is extremely challenging. Most Bitcoin cross-chain bridges end up using the witness model, where a few off-chain witnesses are designated to verify and confirm all cross-chain messages.

DLC bridges, such as those represented by DLC.link, introduce the concept of payment channels on top of the oracle/witness multi-signature foundation to limit scenarios where witnesses could act maliciously. However, this approach still cannot completely eliminate the inherent risks of multi-signatures.

Ultimately, we observe that before BitVM is widely implemented, aside from projects like the Lightning Network/payment channels or RGB++ that rely on client-side verification or homomorphic binding, all other Bitcoin cross-chain bridges fundamentally rely on multi-signatures.

History has shown that without addressing the trust issues in multi-signature cross-chain bridges and large asset management platforms, fund theft incidents are inevitable.

To tackle this, some projects require witnesses to over-collateralized assets, using potential slashing as a deterrent, or rely on large institutions as witnesses to provide credit endorsements, thereby reducing the security risks associated with cross-chain bridges.

However, bridges that rely on the witness model have a security framework similar to that of multi-signature wallets, ultimately governed by a threshold (e.g., M/N) to define their trust model, which offers limited fault tolerance.

Determining how to implement and manage multi-signatures, how to make multi-signatures as trustless as possible, and how to prevent witnesses from acting maliciously or increasing the cost of external attacks are long-term considerations for Bitcoin Layer 2 cross-chain bridges.

Is there a method to make it challenging for multi-signature participants to collude maliciously and for hackers to steal keys from the outside? Bool Network seeks to address the security issues of witness bridges through a comprehensive solution based on the ZKP-RingVRF algorithm and TEE.

2. Bool Network: Privacy Computing Infrastructure for Cross-Chain Bridges

Whether it’s KYC, POS, or POW, the core goal is to achieve decentralization and prevent critical management powers from being concentrated in the hands of a few.

Implementing multi-signature/MPC schemes on top of POA and KYC can reduce security risks through the credit backing of large institutions. However, this approach is essentially similar to centralized exchanges because you still need to trust these designated witnesses not to misuse the funds in the cross-chain bridge’s pool. This essentially forms a consortium chain, which fundamentally violates the trustless principle of blockchain.

Multi-signature/MPC schemes based on POS offer a more trustless approach compared to POA and have a much lower entry threshold. However, they still face various issues, such as node privacy leaks.

Imagine a witness network composed of dozens of nodes specifically serving a certain cross-chain bridge. Because these nodes frequently exchange data, their public keys, IP addresses, or other identity information can be easily exposed, allowing attackers to create targeted attack paths. This often leads to the theft of some nodes’ keys. Additionally, witnesses might conspire internally, especially when the number of nodes is relatively small.

So, how can we address these issues? One instinctive solution is to enhance key protection measures to prevent exposure. A reliable method is to encapsulate the keys in a Trusted Execution Environment (TEE).

TEE allows node devices to run software within a secure local area, where other system components cannot access its data. You can isolate private data or programs in a secure execution environment to prevent confidential data from being leaked or maliciously manipulated.

The challenge is ensuring that witnesses genuinely store keys and generate signatures within the TEE. This can be verified by having witnesses present TEE’s remote attestation information, which can be confirmed on any blockchain at a minimal cost.

(Recently, Scroll also announced the adoption of TEE as an auxiliary prover alongside ZKEVM and verified all blocks on its Sepolia testnet.)

(Diagram of the Internal Structure of Bool Network Node Devices)

Of course, TEE alone doesn’t solve all problems. Even with TEE, if the number of witnesses is small, say only five, various issues will still arise. Even if the keys encapsulated in TEE cannot be accessed, a witness committee of just a few people cannot ensure censorship resistance and availability. For example, if these five nodes collectively go offline, causing the cross-chain bridge to become paralyzed, the bridged assets cannot be locked, minted, or redeemed, which is essentially equivalent to permanent freezing.

After considering compatibility, decentralization, and cost, Bool Network proposed the following solution:

We establish a permissionless candidate witness network through asset staking. Anyone who stakes sufficient assets can join. When the network scales up to hundreds or thousands of devices, we periodically randomly select nodes from the network to act as witnesses for the cross-chain bridge. This approach prevents the “class solidification” of witnesses (similar to the concept reflected in the current POS Ethereum).

So how do we ensure the randomness of the selection algorithm? Traditional POS public chains like Algorand and Cardano use VRF functions to periodically output pseudo-random numbers and select block producers based on these outputs. However, traditional VRF algorithms often cannot protect privacy, exposing who participates in the VRF calculation process and the identities of the selected block producers.

The considerations for dynamic witnesses of cross-chain bridges differ from those for POS public chains. The exposure of block producers’ identities in a public chain is generally harmless because the attack scenarios are limited and constrained by various conditions.

However, if the identity of a cross-chain bridge witness is leaked, hackers only need to obtain their keys or if the witnesses collude, the entire bridge asset pool will be at risk. The security model of cross-chain bridges is vastly different from that of POS public chains, necessitating a stronger emphasis on witness identity confidentiality.

Our initial thought is to keep the witness list hidden. Bool Network addresses this by using an original ring VRF algorithm to hide the identities of the selected witnesses among all candidates. Here’s a simplified explanation of the process:

1. Before joining the Bool network, all candidates must stake assets on Ethereum or a chain created by Bool, leaving a public key as their registration information. This public key is known as the “permanent public key.” The collection of all candidates’ “permanent public keys” is publicly visible on the blockchain. Essentially, this permanent public key serves as each candidate’s identity.
2. Every few minutes to half an hour, the Bool network randomly selects a few witnesses using the VRF function. However, before this selection, each candidate generates a one-time “temporary public key” locally and simultaneously generates a Zero-Knowledge Proof (ZKP) to prove that the “temporary public key” is linked to their “permanent public key” on the blockchain. This means they prove their presence in the candidate list without revealing their specific identity.
3. The “temporary public key” is crucial for privacy protection. If selections were made directly from the “permanent public key” set and the results announced, everyone would immediately know who was chosen, compromising security. By having everyone submit a one-time “temporary public key” and selecting from this set, you only know your own selection, as the identities behind the other selected temporary public keys remain unknown.
4. Additionally, Bool Network plans to ensure you do not even know your own “temporary public key.” This can be achieved by encrypting the temporary public key into “garbled” text within the TEE before sending it out.

We can have the “temporary public key” generation done within the TEE. Since the TEE keeps data and computations confidential, you won’t know what happens inside it. Once the “temporary public key” is generated, it is encrypted into “garbled” text before being sent out of the TEE. At this point, you only see an encrypted ciphertext and do not know the original content of your “temporary public key” (it’s important to note that the ZKP proving the association between the temporary public key and a permanent public key, mentioned earlier, is also encrypted along with the temporary public key).

1. Candidates must send the ciphertext of their “temporary public key” to a designated Relayer node. The Relayer is responsible for decrypting this ciphertext to retrieve the original “temporary public keys.”

The issue here is that the Relayer knows who sent each ciphertext and, by decrypting each one, naturally knows which “temporary public key” corresponds to which person. Therefore, this decryption work must also be done within the TEE. Hundreds of public key ciphertexts enter the TEE, and the original public keys come out, functioning like a mixer to effectively protect privacy.

1. Once the Relayer has the original “temporary public keys,” it collects them and submits them to the on-chain VRF function to select the winners. A few winners are chosen from these “temporary public keys” to form the next cross-chain bridge witness committee.

This process clarifies the overall logic: periodically, a few temporary witnesses are randomly selected from the pool of temporary public keys to serve as witnesses for the cross-chain bridge. This design is called the DHC (Dynamic Hidden Committee).

Because each node runs a TEE, the MPC/TSS private key fragments, the core programs run by the witnesses, and all computation processes are hidden within the TEE environment. No one knows the specific computational content, and even the selected individuals do not know they have been chosen. This fundamentally prevents collusion or external breaches.

3. The Lifecycle of Cross-Chain Messages in Bool Network

After outlining Bool’s approach to hiding witness identities and keys, let’s review the Bool Network’s workflow.

First, when a user initiates a withdrawal on the source chain, the Relayer sends the message to the Messaging Layer. Upon reaching the Messaging Layer, the Dynamic Committee verifies the message to confirm its existence and validity on the source chain, then signs it.

You might wonder, if no one knows whether they’ve been selected for the witness committee, how can the message be delivered to the designated individuals for signing? This is straightforward to address. Since the selected witnesses are unknown, we broadcast the cross-chain message to everyone in the network.

Earlier, we mentioned that each person’s temporary public key is generated and encapsulated in their local TEE, making it invisible outside the TEE. To verify whether one’s temporary public key has been selected, this logic is directly deployed within the TEE. By inputting the cross-chain message into the TEE, the program inside the TEE will determine whether to sign and confirm the message.

After signing the cross-chain message within the TEE, the digital signature cannot be sent out directly. If you send the signature directly, everyone will know that you have signed the message, identifying you as one of the selected witnesses. To prevent this, the signature itself must be encrypted, similar to the earlier encryption of the temporary public key.

In summary, Bool Network uses P2P propagation to deliver the cross-chain message to everyone. Selected witnesses verify and sign the message within the TEE, then broadcast the encrypted ciphertext. Others receive the ciphertext and decrypt it within their TEE, repeating the process until all selected witnesses have signed. Finally, the Relayer decrypts the ciphertext into the original TSS signature format, completing the confirmation and signing process of the cross-chain message.

The core idea is that almost all activities occur within the TEE, making it impossible to determine from the outside what is happening. Each node does not know who the witnesses are or if they themselves are the selected witnesses, fundamentally preventing collusion and significantly increasing the cost of external attacks.

To attack a cross-chain bridge based on Bool Network, you would need to identify the witnesses in the Dynamic Committee, but their identities are unknown. Therefore, you would need to attack the entire Bool network. In contrast, cross-chain bridge infrastructures based solely on POS and MPC, like ZetaChain, expose the identities of all witnesses. If the threshold is 100/200, you would need to attack half of the network’s nodes.

With Bool, due to privacy protection, you would theoretically need to attack all nodes. Additionally, since all Bool nodes run TEE, the difficulty of the attack increases significantly.

Moreover, Bool Network operates as a witness bridge. A witness bridge only needs to submit a signature on the target chain to complete the cross-chain processing, making it highly cost-effective. Unlike Polkadot’s redundant relay chain design, which involves secondary verification, Bool’s cross-chain speed is very fast. This model meets both asset cross-chain and message cross-chain needs, offering excellent compatibility.

4. How to Evaluate Bool’s Product Design Concept?

Let’s consider two points: first, cross-chain assets are a consumer-facing (ToC) product; second, cross-chain bridges are more competitive than cooperative. In the long term, due to the high barriers to entry for cross-chain protocols and relatively homogeneous demand, the concentration of funds related to cross-chain bridges will increase. This is because cross-chain protocols have strong moat barriers, including economies of scale and high switching costs.

As a more foundational specialized infrastructure compared to cross-chain bridges, Bool has broader commercial prospects than the upper-level cross-chain bridge projects. It can even function as an oracle, extending beyond cross-chain message verification. Theoretically, it can enter the decentralized oracle market, constructing a decentralized oracle and providing privacy computing services.

Statement:

1. This article is reproduced from [Geek Web3], with copyright belonging to the original authors [ @faustliu1997 & @AbyssWeb3 ]. If there are any objections to the reprint, please contact the Gate Learn team, who will process it promptly according to relevant procedures.
2. Disclaimer: The views and opinions expressed in this article are solely those of the authors and do not constitute any investment advice.
3. Other language versions of this article are translated by the Gate Learn team and may not be copied, distributed, or plagiarized without mentioning Gate.io.