Author | Faust & Abyss, Geek Web3

Abstract: Since the emergence of various cross-chain bridges, the various hacker attacks that followed have almost never stopped. The theft of US$620 million from Axie's official cross-chain bridge in 2022 shocked the world. Countless people began to think about how to solve the security and trustlessness of cross-chain bridges, but to this day, there are still many unresolved issues in this field.
 
However, just like the public chain track, the cross-chain bridge also has an "impossible triangle" in its design concept, and it is still impossible to break it today. In order to have advantages in cost and UX, most cross-chain bridges adopt a witness model similar to multi-signature, and this solution has been a hot commodity in the eyes of hackers since the first day of its implementation.
 
Bitter historical experience tells us that witness bridges without added protective measures will sooner or later fail, but such bridges are already commonplace in the entire Bitcoin ecosystem, which is creepy.
 
Bool Network, which will be introduced in this article, provides dynamically rotating witnesses for cross-chain bridge projects. It combines privacy computing and TEE encapsulation keys to try to further optimize the security model of traditional witness bridges and solve the decentralization problem of cross-chain bridges. This may bring hope for a breakthrough for Bitcoin cross-chain bridges.

The current state of the Bitcoin ecosystem: multi-signatures are everywhere
 
The essence of a cross-chain bridge is to prove to chain B that someone on chain A has initiated a cross-chain request and that the party has paid the fee in accordance with regulations. There are different ways to prove this.
 
Light client bridges often deploy smart contracts on the chain and verify cross-chain messages on the chain Native. This type of bridge has the highest security, but is also the most expensive and cannot be implemented on the Bitcoin chain (currently, projects under the banner of Bitcoin ZK Bridge can only ensure that BTC uses the ZK Bridge when crossing to other chains, and BTC cannot use the ZK Bridge when crossing back).
 
Optimistic bridges, represented by BitVM, use fraud proofs to ensure that cross-chain messages are processed truthfully, but this solution is extremely difficult to implement. Most Bitcoin cross-chain bridges eventually adopted the witness model, designating several witnesses off-chain to verify and confirm all cross-chain messages.
 
DLC bridges, represented by DLC.link, introduce the idea of ​​payment channels based on oracle/witness multi-signatures to limit the scenarios where witnesses can do evil to the greatest extent, but they still cannot completely eliminate the hidden dangers of multi-signatures at the root.



(The impossible triangle of cross-chain bridges mainly refers to: 1. Scalability: whether it can support the transmission of any message 2. No need for trust: no or as little trust assumption as possible 3. Easy adaptability: difficulty of implementation, whether it can adapt to different public chains including Bitcoin)

Eventually we will find that before BitVM is implemented, except for projects such as Lightning Network/payment channels or RGB++ that are based on client verification or isomorphic binding, other Bitcoin cross-chain bridges are multi-signature in nature.

History has long proven that if the trust problem of multi-signature cross-chain bridges and even large-scale asset management platforms is not solved, it will only be a matter of time before funds are stolen.

In response to this, some project owners ask witnesses to over-collateralize their assets, using potential slashing as a disciplinary condition, or ask large institutions to act as witnesses to provide credit endorsements, weakening the security risks of cross-chain bridges. But in the final analysis, the security model of bridges based on the witness model is basically the same as that of multi-signature wallets, and ultimately the trust model must be determined according to thresholds, such as M/N, and the fault tolerance rate is relatively limited.



How to set up and handle multi-signatures, how to make multi-signatures as trustworthy as possible, and how to prevent witnesses from doing evil or raising the cost of external attacks will be issues that Bitcoin's second-layer cross-chain bridge needs to think about in the long term.

Is there any way to make it difficult for multi-signature participants to collude and for hackers to steal keys from the outside? Bool Network attempts to solve the security problem of the witness bridge through a comprehensive solution based on the ZKP-RingVRF algorithm and TEE.

Bool Network: Privacy computing infrastructure designed for cross-chain bridges, etc.

In fact, whether it is KYC, POS or POW, the essence is to decentralize and fight against witches, to prevent important management rights from being concentrated in the hands of a few people. Using multi-signature/MPC solutions on top of POA and KYC can alleviate security risks through the credit endorsement of large institutions, but this model is essentially no different from centralized exchanges. You still have to trust these designated witnesses not to embezzle the money in the cross-chain bridge fund pool. This is actually a consortium chain, which fundamentally violates the Trustless essence of blockchain.

The POS-based multi-signature/MPC solution is more trustless than POA, and the entry threshold is much lower than the latter, but it still faces various problems: such as privacy leakage of nodes.

Suppose there is a witness network composed of dozens of nodes, which is dedicated to serving a cross-chain bridge. Since these nodes need to exchange data frequently, their public keys, IP addresses or other identity information are easily exposed to the outside world. Attackers can build targeted attack paths, which often leads to the theft of keys of certain nodes. In addition, witnesses may also collude internally, which is easy to happen when the number of nodes is relatively small.

So how do we solve the above problems? You may instinctively think that we need to strengthen the protection of the key to prevent it from being snooped by the outside world. A more reliable method is to encapsulate the key in a TEE (Trusted Execution Environment).

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

The question here is, how to ensure that the witness really stores the key and generates the signature in the TEE? In fact, as long as the witness presents the remote proof information of the TEE, we can verify whether it is running in the TEE. We only need to verify the TEE proof on any chain, and the cost is almost negligible.

(Not long ago, Scroll also announced the use of TEE as an auxiliary prover in addition to ZKEVM, and verified all blocks on its Sepolia test network)



Of course, in addition to TEE, the problems are not over yet. Even if you introduce TEE, if the total number of witnesses is not large, for example, only 5, we will still encounter various problems. Even if the key encapsulated in TEE cannot be "seen", the witness committee composed of a few people cannot guarantee anti-censorship and availability. For example, if the above 5 nodes collectively run away, paralyzing the cross-chain bridge, the bridged assets cannot be locked-mint or redeemed smoothly at this time, which is basically equivalent to permanent freezing.

After comprehensively considering factors such as compatibility, decentralization, and cost, Bool Network proposed the following idea:

We build a permissionless candidate witness network by staking assets. As long as you stake enough assets, you can join. When the network is large enough, for example, when hundreds or thousands of devices are connected, we regularly randomly select some nodes from the network to act as witnesses of the cross-chain bridge, so as to avoid the problem of "class solidification" of witnesses (this idea is also reflected in the current POS Ethereum)

So how can we make the lottery algorithm random? Traditional POS public chains such as Algorand and Cardano introduce VRF functions, periodically output pseudo-random numbers, and extract block producers based on the output results. However, traditional VRF algorithms often fail to protect privacy. Who participated in the VRF calculation process and who the selected persons associated with the random numbers output by VRF are almost exposed to the public.
 


The dynamic witnesses of the cross-chain bridge and the dynamic selection of block producers of the POS public chain have different issues to consider. Even if the identity of the block producer of the public chain is leaked, it is usually harmless because the attacker's malicious scenarios are limited and will be constrained by many restrictions.
Once the identity of the cross-chain bridge witness is leaked, hackers can obtain their keys, or these witnesses collude internally, which will put the entire bridge asset pool into a complete crisis. Anyway, the security model of the cross-chain bridge and the POS public chain is very different, and the identity confidentiality of the witness must be taken more seriously.

Our instinct is that it is best to hide the list of witnesses. In this regard, Bool Network uses an original ring VRF algorithm to hide the identity of the selected witnesses among all candidates. The overall details are relatively complicated. We simplify it and express it as follows:

1. Before entering the Bool network, all candidates must first pledge assets on Ethereum or a chain created by Bool, leaving a public key as registration information. This public key is also called a "permanent public key". The set of "permanent public keys" of all candidates is publicly visible on the chain. To put it simply, this permanent public key is everyone's identity information;

2. Every few minutes to half an hour, the Bool network will randomly select several witnesses through the VRF function. However, before that, each candidate must generate a one-time "temporary public key" locally and generate a ZKP to prove that the "temporary public key" is associated with the "permanent public key" recorded on the chain; in other words, use ZK to prove that you exist in the candidate list, but do not reveal who it is;

3. What is the role of "temporary public key"? It is for privacy protection. If we draw directly from the "permanent public key" set, when the lottery results are announced, everyone will know who is elected directly, and the security will be greatly reduced.

If everyone temporarily submits a one-time "temporary public key" and then selects a few winners from the "temporary public key" set, you will only know that you have won the lottery at most, because you don't know who the other winners' temporary public keys correspond to.

4. This is not the end. Bool Network intends to do this: directly make you not know what your "temporary public key" is. How to do this? Just put the temporary public key in plain text in TEE, encrypt it into "garbled code" and then send it out.



We can also put the generation of "temporary public keys" into TEE. Since TEE can keep data and calculations confidential, you have no idea what is happening in TEE. When the "temporary public key" is generated, it will be encrypted into "garbled code" and sent outside TEE. At this time, you have no idea what the original text of your "temporary public key" is. You can only see an encrypted ciphertext (note that the ZKP mentioned in the second paragraph, which proves that the temporary public key is associated with a permanent public key, is also encrypted together with the temporary public key).

5. The candidate needs to send the garbled "temporary public key" ciphertext to the designated Relayer node. The Relayer is responsible for decrypting the garbled ciphertext and restoring the original "temporary public key" from it.

There is a problem here, that is, the Relayer knows who the sender of each ciphertext is. As long as he parses each ciphertext into a "temporary public key", he will naturally know which person each "temporary public key" corresponds to. Therefore, the above work must also be done in TEE. The public key ciphertexts of hundreds of people enter TEE and become the original public key texts after they come out, just like a coin mixer, which can effectively protect privacy.

6. After Relayer obtains the original "temporary public keys", it collects them together and submits them to the VRF function on the chain to select the winners. That is, a few winners are selected from these "temporary public keys" to form the next cross-chain bridge witness committee.

In this way, the overall logic is actually clear: we regularly randomly select a few from the witness temporary public key set to act as temporary witnesses for the cross-chain bridge. This design is named DHC (Dynamic Hidden Committee).

Because each node runs TEE, the private key fragments of MPC/TSS, the core programs run by witnesses, and all computing processes are hidden in the TEE environment. No one knows what the specific calculation content includes, and even the selected person himself does not know that he has been selected. This can fundamentally prevent collusion or external attacks.



Bool Network cross-chain message life cycle
 
After introducing the general idea of ​​Bool hiding the identity of witnesses and keys, let's sort out the workflow of Bool Network. We assume that the left side is the source chain and the right side is the target chain. The entire diagram above constitutes the full process life cycle of assets from the source chain to the target chain. From this, we analyze the four cross-chain processes of Bool Network from the perspective of data flow:



First, after the withdrawer initiates the withdrawal action on the source chain, the message is sent to the Messaging Layer by the Realyer; after the message reaches the Messaging Layer, the dynamic committee verifies the message to confirm that the message does exist and is valid on the source chain, and then signs it.

Some people may ask, since we mentioned earlier that no one knows whether they have been selected into the witness committee, how can we pass the message to the designated person and ask them to sign? In fact, this is easy to solve. Since we don’t know who is the selected witness, we can simply broadcast the entire network and pass the pending cross-chain message to everyone.

At the beginning, we mentioned that everyone's temporary public key is generated and encapsulated in the local TEE, and the temporary public key cannot be seen outside the TEE. To verify whether your temporary public key is selected, this part of the logic is directly deployed in the TEE. As long as the cross-chain message to be processed is input into the TEE, the program inside the TEE will determine whether to sign and confirm the message.



After signing a cross-chain message in TEE, you cannot send the digital signature directly, because if you send the signature directly, people will find that you have attached a signature to the cross-chain message and guess that you are one of the selected witnesses. Therefore, if you want to make the outside world not know whether you have signed the cross-chain message, the best way is to encrypt the signature information itself, which is similar to the idea of ​​encrypting the temporary public key mentioned above.

In summary, Bool Network will transmit the cross-chain message to be signed to everyone through P2P. The selected witness will verify and sign the message in TEE, and then broadcast the encrypted ciphertext. After others receive the ciphertext, they will put it into TEE for decryption. The above process is repeated until all selected witnesses have signed. Finally, it is decrypted by Relayer into the original format of TSS signature, completing the confirmation and signing process of the cross-chain message.

The core is that almost all activities are carried out in TEE, and from the outside, no one can know what is happening. Each node does not know who the witness is, and does not know whether it is a selected witness, which fundamentally prevents collusion and greatly increases the cost of external attacks.

To attack a cross-chain bridge based on Bool Network, you need to determine who the witnesses in the dynamic committee are, but you don’t know who they are, so you can only attack the entire Bool network. For cross-chain bridge infrastructures such as ZetaChain that are purely based on POS and MPC, the identities of all witnesses are exposed. Assuming the threshold is 100/200, you only need to attack at least half of the nodes in the network.

But when it comes to Bool, because of the privacy protection, in theory you have to attack all the nodes. In addition, all Bool nodes run TEE, so the difficulty of attack will be raised again.

Moreover, Bool Network is essentially a witness bridge. The witness bridge only needs to submit a signature on the target chain to complete the cross-chain processing process, with the lowest cost. Since there is no redundant relay chain design like Polkadot, the redundancy of the second-order verification is avoided, and the cross-chain speed of Bool can be very fast. This cross-chain mode meets the needs of both asset cross-chain and message cross-chain, and has good compatibility.

How do you evaluate Bool's product design ideas?

Here we put forward two viewpoints. First, cross-chain assets are ToC products. Second, cross-chain bridges are more competitive than cooperative. In the long run, because the barriers of cross-chain protocols are high and the demand is relatively homogeneous, the concentration of funds related to cross-chain bridges will become higher and higher. This is because cross-chain protocols have relatively strong moat barriers, including scale effects and conversion costs.

As a dedicated infrastructure at a lower level than the cross-chain bridge, Bool actually has broader business prospects than the upper-level cross-chain bridge projects. It can even assume the function of an oracle, and is not limited to cross-chain message verification. In theory, it can also enter the track of full-chain oracle, truly building a decentralized oracle and providing privacy computing services.