Author: Middle.X
Thanks to Ronnie @Bool Network and Aki @Darwinia for their discussions on the content of this article, some of which was originally published in the PAKA Cross-Chain Research Report, click to view the full report.

Among the many cross-chain security incidents, private key leakage is one significant type. A typical case is the situation encountered by the Axie Infinity official bridge Ronin Bridge in March this year and the Harmony official bridge Horizen Bridge in June, both of which suffered significant losses due to the leakage of private keys from the validator nodes of the cross-chain bridges.

Since validator nodes need to use programs to sign cross-chain events, this forces private keys to be exposed on the network, making them easy targets for hacker attacks. However, this issue can largely be avoided by managing node private keys using TEE. TEE can also be applied in various ways to cross-chain bridges, playing a positive role in optimizing both the security and performance of cross-chain bridges.

TEE stands for Trusted Execution Environment, which is not unfamiliar in our daily lives; for example, fingerprint verification on mobile phones runs within a TEE.

TEE is a computing environment that runs on a given device, isolated from the main operating system, much like an enclave. This isolation is enforced through hardware. The process of running programs in a TEE is covert and imperceptible to the outside world, reducing the likelihood of TEE being attacked by hackers. After the program runs in the TEE, the output results are attached with a signature generated by the device, which will be remotely verified by the device vendor, generating a remote attestation. The remote attestation can confirm to the outside world that the program was executed completely in the TEE without being tampered with or interfered with. For this reason, TEE can run applications with high security requirements, such as cryptographic key management, biometric authentication, secure payment processing, etc.

We will illustrate the specific applications of TEE in cross-chain bridges by combining the cases of pNetwork, Avalanche, Bool Network, and LCP.

pNetwork

pNetwork is a cross-chain bridge developed by the Provable Things team, launched in March 2020, and is a Wrap bridge, with wrapped assets referred to as pTokens.

The basic model of a Wrap bridge is Lock-Mint and Burn-Unlock. pNetwork is responsible for verifying Lock and Burn actions on the source chain through a network composed of TEE nodes and executing Mint and Unlock on the target chain.

Any entity with a TEE device can stake 200 $PNT (for at least 3 months) to become a TEE node of pNetwork. The TEE node network in pNetwork will be responsible for consensus signing of cross-chain messages. During initialization, the TEE node set needs to jointly participate in the calculation of keys to generate public key and private key shards, where there is only one public key, which is public, while the private key shards are generated locally and stored "sealed" in the TEE. Even the operator of the TEE node cannot know the private key shards.

In addition to running programs within the Enclave, TEE nodes also need to run full nodes of the connected chain outside the Enclave to facilitate the light nodes within the Enclave to query block headers.

pTokens Journey

• The process from Token to pToken is as follows:

1. The user calls the Lock function of the smart contract on the source chain, initiating Lock transaction T, depositing the Token into the source chain's custody address, providing the target chain address they wish to receive in the transaction note field;

2. After the TEE node detects the transaction, it further retrieves all Lock transactions in the block where transaction T is located, passing them into the Enclave, along with the block header N and the Merkle path of these Lock transactions;

3. The light node program in the Enclave first verifies block header N, then verifies all Lock transactions using block header N;

4. Once verified, the Enclave will sign a batch of Mint transactions to mint the corresponding amount of pToken for all target addresses;

5. Each Enclave communicates with each other in an encrypted manner to synthesize a complete signature (a signature can be synthesized from more than 2/3 of the private key shards) and submits these Mint transactions;

6. The transaction is broadcast to the target chain, and once confirmed by the target chain, the user's target address receives the pToken.

• The process from pToken to Token is as follows:

1. The user calls the smart contract on the source chain, initiating Burn transaction T, sending the pToken to the burn address, specifying the target chain's receiving address in the note field;

2. After the TEE node detects the transaction, it further retrieves all Burn transactions in the block where transaction T is located, passing them into the Enclave, along with the block header N and the Merkle path of these Burn transactions;

3. The light node program in the Enclave first verifies block header N and verifies these Burn transactions using block header N;

4. Once verified, the Enclave will sign a batch of Unlock transactions to transfer the corresponding amount of Token from the custody address to all target addresses;

5. Each Enclave communicates with each other in an encrypted manner to synthesize a complete signature and submits these Unlock transactions;

6. The transaction is broadcast to the target chain, and once confirmed by the target chain, the user's target address receives the Token.

Since the private key is stored in the Enclave and the verification and signing processes also occur in the Enclave, it is economically and practically inconvenient for malicious attackers to attack the network. Additionally, the pToken Network encourages TEE nodes to use devices from different vendors, as the specific principles of TEE devices from different vendors may vary. A diversified vendor TEE node will further increase the difficulty for attackers, as they would need to breach multiple vendors' TEE devices to potentially carry out an attack.

Therefore, using an MPC network composed of TEE nodes adds an extra layer of security compared to an MPC network composed of non-TEE nodes. Furthermore, pNetwork has chosen to open-source its code, which clarifies every process occurring within the Enclave, and the remote attestation includes the program's hash root, allowing anyone to verify the consistency between the code executed in the Enclave and the code publicly available from pNetwork. This serves as an additional security declaration, as it eliminates the possibility of malicious intent from the program's authors.

In October 2021, pNetwork V2 was released, which expanded pNetwork into an AMB bridge.

pNetwork V2 continues the core features of V1, still using an MPC network composed of TEE nodes to verify cross-chain messages, but the V2 version is not limited to messages related to asset cross-chain.

Avalanche Bridge

Avalanche Bridge (AB) is the official cross-chain bridge of Avalanche, currently supporting cross-chain asset transfers between the Avalanche C chain and Ethereum.

Similar to pNetwork, Avalanche Bridge uses an MPC network composed of TEE nodes to verify cross-chain events, with the TEE nodes in Avalanche Bridge referred to as Wardens. To pursue lower fees and faster speeds, Avalanche Bridge has made some design optimizations.

First, to accelerate verification efficiency, Avalanche Bridge runs full nodes directly within the TEE and establishes an index within the Enclave to query transactions, unlike pNetwork's TEE nodes, which run full nodes outside the Enclave and light nodes within the Enclave. Of course, pNetwork currently supports asset transfers across 9 chains and may support more in the future, which could pose challenges to the storage space of the Enclave.

Second, Avalanche Bridge uses ordinary addresses instead of contract addresses to host locked assets. This avoids some of the costs associated with contract calls.

During initialization, Wardens communicate with each other in an encrypted manner to create a custody address and seal the private key shards in their respective Enclaves. This custody address is an EOA address starting with 0x, which can be used for both Ethereum and Avalanche C chain.

Taking ERC20 asset cross-chain as an example, we will explain the steps Avalanche Bridge takes to handle asset cross-chain:

• Wrap: Ethereum -> Avalanche

1. The user initiates a deposit transaction on Ethereum (no contract call required), transferring the ERC20 asset to the custody address;

2. Each Warden monitors that address to discover the deposit transaction (Wardens do not listen to messages on the chain but directly discover deposit transactions through user requests on the Avalanche Bridge frontend, meaning if the user initiates a transaction directly to the custody address without going through the Avalanche Bridge frontend, the Wardens will not take any action);

3. The Warden submits the transaction to the Enclave, where the Enclave performs verification;

4. Once verified, the Warden will sign a Mint transaction with their respective private key shards and communicate with each other in an encrypted manner to synthesize a complete signature (a signature can be synthesized from more than 3/4 of the private key shards).

5. The Warden submits the Mint transaction to the Avalanche C chain, allowing the custody address to call the Mint contract to mint Wrap assets for the user (for security reasons, Avalanche Bridge only supports asset cross-chain to the same target address as the initiating address).

• Unwrap: Avalanche -> Ethereum

1. The user calls the Burn function in the bridge contract on the Avalanche C chain, initiating a burn transaction to send the Wrapped asset to a specified burn address;

2. The Warden detects this transaction and submits it to the Enclave;

3. Each Enclave verifies the transaction;

4. Once verified, each Enclave signs an Unlock transaction with their private key shards to send the corresponding amount of native assets from the custody address to the user's Ethereum address (no contract call required);

5. The Enclaves communicate with each other in an encrypted manner to synthesize the complete signature and submit the Unlock transaction to Ethereum. Once the transaction is confirmed, the user will receive the transfer from the custody address on Ethereum.

We find that in the asset cross-chain process of Avalanche Bridge, only the Mint and Burn transactions require contract calls, while the Lock and Unlock transactions are just ordinary transfers that do not require contract calls. This design reduces gas consumption, thereby lowering the cross-chain transaction fees for users.

Both pNetwork and Avalanche Bridge fully utilize the characteristics of TEE, significantly reducing the likelihood of private keys being stolen by external attackers. However, we must note that this still does not prevent internal collusion among TEE nodes.

• If TEE nodes collude, they could attempt to synthesize private keys, replace programs in the Enclave, or create false events by forking the source chain to deceive the Enclave into signing.

The Bool Network we will discuss next can achieve "external defense against attacks and internal prevention of collusion."

Bool Network

Bool Network is also a cross-chain bridge project that uses a network of TEE nodes as external validators. Bool Network has made further innovations—introducing a rotation mechanism for TEE nodes and an anonymity mechanism.

Bool Network is designed as a cross-chain bridge for arbitrary messages, supporting any third party to build cross-chain applications on it. Drawing from Cosmos IBC, it introduces the concept of Channels, allowing two applications deployed on different chains to establish a Channel for orderly message transmission between them. Each Channel corresponds to at least one MPC committee. This committee is responsible for consensus signing of cross-chain messages within that Channel during the current Epoch. The MPC committee is rotated, serving only for one Epoch, with re-elections held for each Epoch.

• Bool Network currently assigns two committees for each Channel as backups to improve service availability.

Anyone can become a candidate TEE node by staking $BOL. Before each Epoch begins, Bool Network uses the Ring VRF algorithm to elect the MPC committee for each Channel. Nodes selected as members of the MPC committee receive a temporary identity (public-private key pair) for communication, used to communicate with other TEE nodes in the same committee during the consensus signing process. When an Epoch ends, all temporary identities become invalid, and the network will re-elect nodes to select a new rotating MPC committee, assigning them new temporary identities.

Although each candidate TEE node must provide permanent identity information (device code) during registration, the temporary identity used for communication does not expose the permanent identity information. In other words, nodes are anonymous during communication. If there are 100 candidate nodes, you will only know that the node you are communicating with is one of those 100, but you will not know which specific one.

The number of TEE nodes required for the MPC committee of each Channel and the signing threshold are customizable by the Channel creator. Common threshold values include 15-of-21, 13-of-19, and 5-of-9.

Within the same Epoch, there may be overlaps among the MPC committee members of different Channels, and some candidate nodes may not be selected for any committee, resulting in idle states. These situations are normal.

We find that Bool Network has constructed an impregnable black box through the combination of TEE, rotation mechanism, and anonymity mechanism. Since the signing program runs in the TEE of anonymous nodes, and their communication content is encrypted, when operational, the operators of the TEE nodes themselves cannot know which Channel's MPC committee they have been selected into, which nodes they have communicated with for consensus, or which messages they have signed, making it practically impossible for collusion among nodes.

From the perspective of external attackers, if they want to attack a specific Channel, they cannot know which devices or entities are behind the current MPC committee, nor can they intercept this information from communications. Whether it is internal collusion or external attacks, they can only choose to breach the majority of all candidate nodes to potentially succeed in an attack, which undoubtedly incurs a huge cost.

Bool Network is a project still under development, and some technical details have not been fully determined.

LCP

LCP stands for Light Client Proxy, proposed by Datachain as a new paradigm for using TEE in cross-chain bridges. At the time of writing this article, LCP is still in the conceptual stage and has no code implementation. LCP is completely different from the aforementioned three. The approaches of pNetwork, Avalanche Bridge, and Bool Network all involve using TEE to manage private keys, verify messages, and execute signatures. LCP's approach is to use TEE to run light clients.

LCP's idea borrows somewhat from LayerZero, which uses an external oracle network to run ultra-light clients. However, this "ultra-light client" does not verify newly acquired block headers like a real chain node but confirms the validity of block headers through consensus signatures from nodes in the oracle network. LCP aims to run a genuine light client within the TEE.

We know that light client cross-chain bridges are the most secure type of cross-chain bridge technology, as they deploy a light client of the source chain on the target chain, allowing the target chain to verify transactions from the source chain. However, its drawbacks are quite significant:

On-chain storage and computing resources are tight, and on-chain light clients consume a lot of gas during the synchronization and verification of block headers, making on-chain light clients very expensive, and in some cases, even economically unfeasible. Although there are some solutions to build relatively lightweight on-chain light clients, these solutions increase development difficulty and code complexity.

Executing light clients off-chain can effectively solve the above problems, but we need to verify the operational status of the off-chain light client on-chain, which can be achieved through TEE's remote attestation. Theoretically, LCP only requires one TEE node and does not need multiple nodes to reach consensus on the authenticity of transactions. However, to ensure availability, it is still necessary to arrange some redundancy.

When there is a transaction T that needs verification:

1. Transaction T will first be submitted to the TEE node;

2. The TEE node will pass transaction T, the block height N of transaction T, and the Merkle path of transaction T into the Enclave;

3. The light client in the Enclave runs an update program, updating to block height N (it needs to connect to external full nodes but does not require trust) and performs SPV verification of transaction T using the block header of height N;

4. After verification is complete, the Enclave generates a remote attestation;

5. The TEE node submits the verification result of transaction T and the remote attestation to the target chain;

6. The verification program on the target chain checks the validity of the remote attestation, confirming that the program indeed ran in the TEE and that the running program is the correct light client program.

It should be noted that although pNetwork's TEE nodes also run light clients, the light client triggers the local private key shard to sign the transaction after verifying it, and the final verification on-chain is the signature, not the program running in the TEE itself. Therefore, pNetwork still falls under the category of external verification. LCP, on the other hand, submits remote attestation to the chain, which includes the program hash for on-chain verification that the correct light client program is running in the TEE. Classifying LCP as an "extension of native verification" would be more appropriate.

Running light clients in the TEE simplifies things significantly; light clients no longer need to consider how to save storage and computing resources, nor do they require complex "slimming" and "scaling" solutions. However, we must recognize that running light clients in the TEE always has a slightly lower security level than running them on-chain. This is because TEE is not absolutely secure; its technical defenses may be breached, and there is a slight possibility that TEE device vendors could act maliciously. However, this issue can be mitigated through redundancy of TEE nodes and diversification of device vendors.

Conclusion

In this article, we have discussed several scenarios in which TEE is applied to cross-chain bridges.

The most direct application of TEE in cross-chain bridges is the management of private keys. As we have illustrated with pNetwork, Avalanche Bridge, and Bool Network, in today's environment where people are concerned about the security of cross-chain bridges, we should perhaps expect the use of TEE to manage private keys to become a standard method for multi-signature cross-chain bridges. Bool Network's approach to anonymizing nodes provides us with valuable insights for preventing collusion among TEE nodes, while LCP's solution offers a new paradigm for light client cross-chain bridges, enhancing their versatility and scalability while maintaining the theoretical security level of light client bridges.

Cross-chain bridges are still undergoing intense evolution, and the use of TEE is just one of the evolutionary directions. We are also observing other evolutionary paths and are looking forward to more secure cross-chain bridges.

References

https://hackmd.io/@phala/BJh_3bbQU

https://www.8btc.com/article/608236

https://ptokens.io/ptokens-rev5b.pdf

https://medium.com/pnetwork/introducing-pnetwork-v2-bfa7fcdcedb8

https://zhuanlan.zhihu.com/p/406818768

https://medium.com/avalancheavax/avalanche-bridge-secure-cross-chain-asset-transfers-using-intel-sgx-b04f5a4c7ad1

https://mp.weixin.qq.com/s/Hw-jW9YtyJjxtI-xo_ANUQ

https://twitter.com/TigerVCDAO/status/1588215376235462656

https://docs.lcp.network/