Author: Middle.X

Thank you Ronnie @Bool Network, Aki @Darwinia for participating in the discussion of this article.

Some of the content in this article was originally published in the PAKA Cross-Chain Interaction Research Report. Click to view the full report.

Communicate with me:

• Twitter: @middlex0
• VX: xuezhijie156

Among the many security incidents in Cross-Chain Interaction, Private Key leakage is one important type. Typical cases are the incidents that occurred in March this year with the official bridge Ronin Bridge of Axie Infinity and in June with the official bridge Horizen Bridge of Harmony, both of which resulted in significant losses due to the leakage of the validation node's Private Key in the Cross-Chain Interaction bridge.

As the Validator Node needs to use a program to sign Cross-Chain Interaction events, the Private Key has to be exposed on the network, making it an easy target for hackers. However, this problem can be largely avoided by using TEE to manage the Node's Private Key. TEE can also be applied to Cross-Chain Interaction bridges in various ways, which can positively impact the security and performance optimization of Cross-Chain Interaction bridges.

TEE stands for Trusted Execution Environment. It is not unfamiliar to our daily life. For example, fingerprint verification on mobile phones runs in TEE.

TEE is an isolated computing environment running on a given device, similar to an enclave. This isolation is enforced by hardware. The execution of programs in TEE is concealed and imperceptible to the outside world, reducing the likelihood of TEE being targeted by hackers. After the program completes its execution in TEE, the outputted computation results will be accompanied by a signature generated by the device. This signature will be remotely verified by the device vendor, generating a remote proof of validation. The remote proof of validation confirms to the outside world that the program has been executed intact in TEE without tampering or interference. Consequently, TEE can run applications with high security requirements, such as encryption key management, biometric authentication, secure payment processing, and more.

We will use the examples of pNetwork, Avalanche, Bool Network, and LCP to illustrate the specific application of TEE in cross-chain bridges.

pNetwork

pNetwork is a cross-chain bridges developed by the Provable Things team, launched in March 2020, it is a Wrap bridge, and the wrapped assets are called pTokens.

The basic model of the Wrap Bridge is Lock-Mint and Burn-Unlock. pNetwork verifies the Lock and Burn actions on the source on-chain through a network composed of a TEE Node, and performs Mint and Unlock on the target on-chain.

Any entity with a TEE device can stake 200 $PNT (at least 3 months) to become a TEE Node in the pNetwork. The TEE Node network in pNetwork will be responsible for Consensus signing of Cross-Chain Interaction messages. During initialization, the TEE Node set needs to jointly participate in the calculation of the keys to generate Public Key and Private Key fragments, where there is only one Public Key, which is in the public state, and the Private Key fragments are generated locally and stored in the TEE as "sealed." Not even the operator of the TEE Node can know the Private Key fragments.

In addition to running the program inside the Enclave, the TEE Node also needs to run a Full Node of the access chain outside the Enclave, so that the light Node inside the Enclave can query the block header.

pTokens Journey

• The process from Token to pToken is as follows:

1. The user calls the Lock function of the source chain smart contract and initiates the Lock transaction T to deposit the Token into the source chain custody Address. They provide the target chain Address where they want to receive payment in the transaction memo field;
2. After the TEE Node listens to the transaction, it further obtains all Lock transactions in Block N where transaction T is located, and passes them into the Enclave. At the same time, it will also pass the Block Header N and the Merkle paths of these Lock transactions.
3. The light node program in Enclave first verifies Block Header N, and then verifies all Lock transactions with Block Header N;
4. Once verified, Enclave will sign a batch of Mint transactions to mint the corresponding quantity of pTokens for all target Addresses;
5. The Enclaves communicate with each other through encryption to generate a complete signature (2/3 or more of the Private Key fragment signatures can be combined into a complete signature), and submit these Mint transactions;
6. The transaction is broadcast to the target chain and, once confirmed by the target chain, the user's target Address obtains the pToken.

• The process from pToken to Token is as follows:

1. Users call the Source Chain smart contract and initiate a Burn transaction T, sending pToken to the Burn Address, with the receiving Address on the target chain specified in the memo field.
2. After the TEE Node detects the transaction, it further retrieves all Burn transactions of Block T's Block Header N and passes them to the Enclave. At the same time, it also passes Block Header N and the Merkle path of these Burn transactions.
3. The light node program in Enclave first verifies Block Header N, and uses Block Header N to verify these Burn transactions;
4. Once the verification is passed, Enclave will sign a batch of Unlock transactions to transfer the corresponding amount of Token from the custodial Address to all target Addresses;
5. The Enclaves communicate with each other through encryption to synthesize the complete signature and submit these Unlock transactions;
6. The transaction is broadcast to the target chain. After the target chain confirms it, the user's target Address obtains the Token.

Since the Private Key is stored in the Enclave and the verification and signing processes are also performed in the Enclave, it is inconvenient for malicious attackers to attack the network both economically and practically. In addition, the pToken Network encourages TEE Nodes to adopt devices from different vendors. The specific principles of TEE devices from different vendors may vary, and diversified vendor TEE Nodes will further increase the difficulty of attackers' attacks, as attackers need to break through TEE devices from multiple vendors to potentially carry out attacks.

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. In addition, pNetwork chooses to make the code Open Source. Open Source code clearly indicates every process carried out in Enclave, and the hash root of the program is included in the remote proof so that anyone can verify the consistency between the code executed in Enclave and the code publicly disclosed by pNetwork. This is a further security statement as it eliminates the possibility of malicious program writers.

In October 2021, pNetwork V2 was released, expanding 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 Interaction messages, but V2 will not be limited to messages related to asset Cross-Chain Interaction.

Avalanche Bridge

Avalanche Bridge (AB) is the official Cross-Chain Interaction bridge of Avalanche, which currently supports the Cross-Chain Interaction asset transfer between Avalanche C chain and Ethereum.

Like pNetwork, Avalanche Bridge uses an MPC network composed of TEE Nodes to verify Cross-Chain Interaction events, with Avalanche Bridge's TEE Nodes being called Wardens. In order to pursue lower fees and faster speeds, Avalanche Bridge has made some optimizations in its design.

First of all, in order to accelerate the verification efficiency, Avalanche Bridge runs Full Node directly in TEE, and establishes an index in Enclave to query transactions, unlike pNetwork's TEE Node running Full Node outside Enclave and running light Node inside Enclave. Of course, pNetwork now supports asset transfer on 9 chains, and may support more in the future. If so, the storage space of Enclave may pose a challenge.

Secondly, Avalanche Bridge uses regular Address instead of contract Address to host locked assets. This avoids some of the costs associated with contract calls.

During initialization, Wardens communicate with each other via encryption, creating a managed Address, and sealing Private Key fragments in their respective Enclaves. The managed Address is a 0x prefixed EOA Address, which can be used for Ethereum as well as Avalanche C chain.

Taking the Cross-Chain Interaction of ERC20 assets as an example, we explain the steps of Avalanche Bridge in handling asset Cross-Chain Interaction.

Avalanche

1. Users initiate deposit transactions on the ETH network (no contract invocation required) and transfer ERC20 assets requiring Cross-Chain Interaction to the custody address.
2. Each Warden monitors the Address to discover the deposit transaction (Wardens do not listen to on-chain messages but directly discover deposit transactions through user requests on the Avalanche bridge frontend interface. This means that if users do not initiate transactions through the Avalanche bridge frontend interface and transfer funds directly to the custodial Address, Wardens will not process anything).
3. Warden passes the transaction to the Enclave for verification;
4. After verification, Warden will use their respective Private Key fragments to sign a Mint transaction, and communicate with each other for encryption to synthesize the complete signature (3/4 or more of the Private Key fragments' signatures can form a complete signature).
5. Warden submits a Mint transaction to Avalanche C chain, allowing the custodian Address to call the Mint contract to mint Wrap assets (for security reasons, Avalanche Bridge only supports Cross-Chain Interaction of assets to the target Address that is the same as the originating Address). Ethereum
6. Users call the Burn function in the Avalanche on-chain bridge contract and initiate a destruction transaction to send the Wrapped asset that requires Cross-Chain Interaction to the designated destruction Address;
7. After Warden detects this transaction, it will pass the transaction to Enclave;
8. Enclave verifies the transaction individually;
9. After the verification is passed, each Enclave signs an Unlock transaction with its own Private Key fragment to send the corresponding amount of native assets in the custody Address to the user's Ethereum Address (without calling the contract);
10. Enclave communicates with each other through encryption to complete the synthesis of the signature, and submits the Unlock transaction to Ethereum. After the transaction is confirmed, the user will receive a transfer of the hosted Address on the ETH network.

We found that only Mint transactions and Burn transactions need to call the contract in the asset Cross-Chain Interaction process of Avalanche Bridge, while Lock and Unlock transactions are just ordinary transfers and do not require calling the contract. This design drops gas consumption, thereby dropping the Cross-Chain Interaction fees for users.

Both pNetwork and Avalanche Bridge make full use of the features of TEE to significantly reduce the possibility of Private Key being stolen by external attackers. However, we need to note that this still cannot prevent internal collusion of TEE Nodes.

• If TEE Nodes collude, they can attempt to synthesize the Private Key, replace the program inside the Enclave, or create false events through forking the source chain to deceive the Enclave's signature.

And the Bool Network we are going to talk about next can achieve 'external attack prevention, internal conspiracy prevention'.

Bool Network

Bool Network is also a cross-chain bridges project that adopts TEE Node network as external validators. Bool Network has made further innovations - adding a round-robin mechanism and anonymous mechanism for TEE Nodes.

Bool Network is designed to be a cross-chain interaction bridge for arbitrary messages, supporting any third party to build cross-chain interaction applications on it. Bool Network refers to Cosmos IBC and introduces the concept of Channels. Channels can be established between two applications deployed on different on-chain to achieve ordered message delivery between the two. Each Channel corresponds to at least one MPC committee. The committee is responsible for the consensus signature of cross-chain interaction messages within the Channel during the current Epoch. This MPC committee is rotational, with a term of only 1 Epoch, and a re-election takes place at the beginning of each Epoch.

• Bool Network currently assigns two committees to each channel, serving as backups to improve service availability.

Anyone can become a candidate TEE Node by staking $BOL. Before each Epoch begins, Bool Network will use the Ring VRF Algorithm to elect an MPC committee for each Channel. Nodes selected as members of the MPC committee will 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. At the end of an Epoch, all temporary identities will expire, and the network will then re-elect Nodes to select a new rotating MPC committee and give them new temporary identities.

Although each candidate TEE Node needs to provide permanent identity information (device code) during registration, the temporary identity used by the Node during communication does not expose the permanent identity information. In other words, the Nodes are anonymous to each other during communication. If there are 100 candidate Nodes, you can only know that the Node you are communicating with is one of these 100, but you don't know which one specifically.

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

Within the same Epoch, the members of the MPC committees in different channels may overlap, and some candidate Nodes may not be selected into any committee, resulting in an idle state. These situations are all normal.

We found that Bool Network has built an unbreakable black box through the combination of TEE, round-robin mechanism, and anonymous mechanism. Because the signature program runs in the TEE of the anonymous Node, and the communication content between them is encryption, when in operation, the operator of the TEE Node has no way of knowing which Channel's MPC committee they have been selected into, with which Node they have had Consensus communication, signed which messages, they cannot even achieve self-awareness, let alone understanding others. This basically makes it impossible for Nodes to conspire.

From the perspective of an external attacker, if they want to attack a specific channel, they have no way of knowing which devices or entities are behind the current MPC committee, nor can they intercept this information from the communication. Whether it is internal collusion or external attack, they can only choose to attack the majority of the candidate nodes in order to have a chance of success, which undoubtedly comes at 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, a new paradigm proposed by Datachain to use TEE for cross-chain bridges. At the time of writing, LCP is still in the conceptual stage and has no code implementation. LCP is completely different from the previous three. The ideas of pNetwork, Avalanche Bridge, and Bool Network are all to use TEE to manage private keys, verify messages, and perform signatures. The idea of LCP is to run a light client using TEE.

The idea of LCP is more or less borrowed from LayerZero, which uses an external Oracle Machine network to run an Ultra Light Client, but this 'ultra light client' does not verify newly obtained Block headers like a real chain node, but confirms the validity of Block headers through the Consensus signature of nodes in the Oracle Machine network. LCP hopes to run a genuine light client inside TEE.

We know that the light client is the most secure type of cross-chain bridges technology, which enables the target chain to verify transactions from the source chain by deploying the light client of the source chain on the target on-chain. However, its disadvantages are very significant:

The storage and computing resources of the on-chain are tight, and the on-chain's light client consumes a lot of gas during the process of synchronizing and verifying block headers, which makes the on-chain light client very expensive. In some cases, it is not economically feasible. Although there are some solutions to build relatively lightweight on-chain light clients, these solutions will increase development difficulties and code complexity.

Placing the light client for off-chain execution can effectively solve the above-mentioned issues, but we need to verify the running status of the off-chain light client on-chain, which can be achieved through remote attestation of TEE. In theory, LCP only requires one TEE Node and does not require multiple nodes to confirm the authenticity of transactions through consensus. However, in order to ensure availability, it is still necessary to arrange some redundancy.

When there is a transaction T that needs to be verified:

1. The transaction T will first be submitted to the TEE Node;
2. TEE Node will pass transaction T, the block height N where transaction T is located, and the Merkle path of transaction T into the Enclave
3. The light client in Enclave runs the update program, updates to Block Height N (needs to connect to an external full node, but does not need to trust), and performs SPV verification on transaction T with Block Header at Height N.
4. After the verification, Enclave generates a remote attestation proof through remote authentication.
5. The TEE Node submits the verification result of transaction T and the remote attestation proof to the target chain
6. The on-chain verification program checks the validity of the remote attestation, confirms that the program is running in the TEE, and that the running program is the correct light client program.

It should be noted that although pNetwork's TEE Node also runs a light client, the local Private Key fragment will be triggered to sign the transaction after the light client verifies the transaction. The signature is ultimately verified on-chain, not the program itself running inside the TEE. Therefore, pNetwork still belongs to the category of external verification. LCP submits remote attestation proof to on-chain, which includes program hash for on-chain to check if the correct light client program is running in the TEE. It would be more appropriate to classify LCP as an "extended native verification".

Running light client in TEE makes things much simpler. The light client no longer needs to consider how to save storage and computing resources, nor does it need complex "slimming down" and "scaling up" schemes. However, we need to recognize that running a light client in TEE always has a lower security level than running a light client on-chain. This is because TEE is not absolutely secure, and its technical defenses may be breached, and there is a small possibility of malfeasance by TEE device manufacturers. However, this issue can be mitigated through redundancy of TEE Nodes and diversification of device manufacturers.

Summary

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 to safeguard Private Key, as exemplified by pNetwork, Avalanche Bridge, and Bool Network. As people worry about the security of cross-chain bridges, we may expect TEE to become a standard means of managing Private Key for multi-signature cross-chain bridges. To prevent the collusion of TEE Nodes, Bool Network gives us a good inspiration for anonymizing Nodes, while LCP provides a new paradigm for light client cross-chain bridges, which improves their universality and scalability while maintaining their theoretical security.

Cross-chain bridges are still in the midst of intense evolution, and the use of TEE is just one of its evolutionary directions. We are also observing other evolutionary directions, and we have high expectations for safer cross-chain bridges.

Reference materials

_3bbQU

_ANUQ