DLT Interoperability and More ⛓️#22— Ivy Cross: A Privacy-Preserving and Concurrency Control Framework for Blockchain Interoperability⛓️

In this series, we analyze papers on blockchain and interoperability.

This edition covers a paper on a paper that formalizes a blockchain interoperability protocol that uses Trusted Execution Environments (TEEs).

➡️ Title: IvyCross: A Privacy-Preserving and Concurrency Control Framework for Blockchain Interoperability
➡️ Authors: Ming Li, Jian Weng, Yi Li, Yongdong Wu, Jiasi Weng, Dingcheng Li, Guowen Xu, Robert Deng

➡️ Paper source: https://hal.uca.fr/hal-03906880/document

➡️ Background:

TEEs build “an isolated environment that enables hardware-based protections on user-level code and data to provide confidentiality and integrity. Several hardware-based protection technologies have been designed, such as Intel SGX, ARM TrustZone, and AMD Secure Processor” In this paper, Intel SGX is used. “Intel SGX creates a sandbox environment called enclave in which a program can be executed without interference. When an enclave interacts with other enclaves, Intel SGX introduces attestation to allow users to trust each other. It is essentially a proving process that enables a user to trust: 1) his program is running in an enclave, 2) the enclave is up to date. There are two types of attestation, local attestation, and remote attestation. Intel SGX provides Intel Attestation Service (IAS) to help users to validate a remote attestation.”

A good summary of what TEEs are is available here. TEEs, in the case of the paper, allow flexible compatibility and real-time efficiency and enable confidentiality preserving smart contracts.

Interestingly, the authors proposed a concurrency control mechanism for interoperability, which we proposed in our paper Hermes: Fault-Tolerant Middleware for Blockchain Interoperability (open-source code available here). Some systems using Hermes/Secure Asset Transfer Protocol have already been implemented, see for example, CBDC bridging between Hyperledger Fabric and permissioned EVM-based blockchains.

Onto the paper!

➡️ Contributions:

• The authors propose “a low-cost interoperability mechanism with simplified TEEs as the underlying architecture while preserving concurrency and privacy”, based on the assumptions that “the confidentiality of programs can be guaranteed in the TEE“ and that an adversary “can not break the fundamental security of blockchain”.

💪 Strong points:

• The authors propose an interesting approach to the interoperability problem. Several attempts to secure cross-chain bridges using trusted hardware have been deployed. Still, to the best of my knowledge, the cross-chain logic of those systems is to verify a transaction has been sent to a particular address and issue another transaction (possibly upon the agreement of k out of n parties) to another blockchain. This work proposes a generalization of this scheme, in the sense that more general-purpose cross-chain logic is implemented in the TEE, with some privacy advantages, but some limitations of practicality.
• The model is interesting and decouples well the different parties. In use cases depicting the transfer of value across chains, the standardized SATP gateways could be used or considered.

🤞 Suggestions for improvement:

• Something that might be confusing: what the authors call “cross-chain smart contracts” are, in fact, off-chain programs (cross-chain logic clients) that are run by the enclave and that call smart contracts. The on-chain part of the system is not mentioned too, but is relevant, as cross-chain logic settlement occurs there.
• Although it might provide an additional security layer, several vulnerabilities that have been found on TEEs might make TEEs impractical to secure billions of user funds. The security assumptions (that both hosts are not compromised at the same time) is strong. However, this problem can be alleviated by designing a decentralized ecosystem, “where many cryptocurrency exchanges can take part in providing cross-chain services for profits and only two exchanges are required for each contract execution.”, supported by reputation mechanisms.
• “To avoid storing many block headers in TEE while preventing it from receiving error data, we require a cross-chain smart contract to run simultaneously on both hosts.” — this means that the TEEs are in a limited state, verifying block headers on the go. If, for some reason, applications built on top of the framework require historical data, the TEEs would have to recompute this data.
• While “The confidentiality of execution states and user inputs, as well as the unlinkability of transactions in cross-chain smart contracts, can be fully preserved.” is advertised as a feature, the user needs to blindly trust the TEE, as transparency is sacrificed (computation is hidden in the TEE, thus providing the privacy in the cross-chain scenario).
• The solution appears to have considerable overhead: “The performance of deposit, including the transaction generation and confirmation, takes 0.519s, 15.111s, 1.083s in local Bitcoin, Ethereum and FB testnets on average, which depends on the difficulty level setting. A low difficulty level is set in our configurations for saving resources.”. However, without precise system parameters and source code, it is hard to do a precise analysis.

🔥 Points of interest:

• The presented scheme relies on cross-chain logic implemented as programs running inside an enclave. The concept of cross-chain logic is presented here. Inputs given to the enclave will stay private, as they are encrypted with the TEE’s public key, and the latter does not leak data — hence the confidentiality preserving smart contracts. If a user trusts the security offered by TEEs, this can be a great way to improve privacy. Cross-chain logic inside TEEs queries several blockchains and executes logic based on a private state to the enclave. However, transactions to blockchains are typically public, i.e., privacy in terms of unlinkability will be limited, possibly for common use cases such as bridging. Unlinkability capabilities come in the form of hidden inputs to the TEE that acts as a mixer but depend on a specific use case and implementation.
• In this scheme, two TEE-powered hosts are used, “an execution host and a verification host. Specifically, the privacy of inputs and execution outputs can be preserved by encrypting them under the key pair generated by two TEEs. […]. It is assumed that only one host at a time can be compromised.
• IvyCross protocol consists of four basic phases: the initialization phase, the execution phase, the challenge-and-response phase, and the finalization phase.

1. The initialization phase is a setup, where the participants generate keys, and “make deposits”.
2. In “Execution — Participants can send inputs to the contract to trigger a state transition in this phase. The input is encrypted using the public key of the contract and decrypted for calculation in the enclaves. If there is no dispute, i.e., two hosts and participants behave honestly in this phase, the contract goes to the finalization phase. Otherwise, it enters the next challenge-and-response phase.”
3. In the “Challenge-and-response — This phase happens is conducted between V and R within a time of several blocks. For example, suppose V detects that R accepts an invalid deposit transaction for contract execution. In that case, it complains to the CrossChainGame contract by sending a challenge transaction and waits for a response. If the challenge succeeds, i.e., V proves that the deposit is valid, the states in the cross-chain contract will roll back and the challenger gets a reward from the CrossChainGame contract. If R does not receive a response in due time, V can upload the evidence to Be and terminate this contract execution by complaining to the participants.”.
4. Finally, “Finalization. After the execution, the protocol returns a final output and assigns the deposits according to the predefined policy. For the lottery contract, R instructs its enclave to generate two transactions that transfer participants’ deposits to the winner’s address.”

• Interestingly, the authors in this paper did not implement or model the most popular cross-chain use case, bridging. However, three use cases are offered in the implementation section: lotteries, auctions, and loans (I can only see the usefulness in the cross-chain scenario for the latter). Furthermore, there is no code available. Let us take the Lottery use case:

“As mentioned earlier (see Sect. II-A), the cross-chain lottery contract determines one winner based on a collaboratively generated number. We only require participants to send a number to the enclave without using an inefficient commit-and-reveal scheme.” This could be a way for a user to send their vote, and the winner would have an address with the prize generated. The framework would then give the private key to the winner.

🚀 What are the implications for our work?

• This work helps us build more secure blockchain interoperability middleware.