Why do Unichain and Flare both introduce trusted execution environment?

Author: Haotian

Recently, there has been extensive discussion around the differences between ZK and Trusted Execution Environment (TEE). The reason is that @unichain, a newcomer to layer2, claims that its millisecond-level sub-block is built on TEE, while @FlareNetworks, which is touted as a data blockchain Oracle Machine, integrates traditional Internet channels such as Google Cloud and introduces verifiable off-chain computation through TEE. Combining these two things, let me share my thoughts:

1. TEE (Trusted Execution Environment) is a hardware-level security technology. In simple terms, TEE creates an independent, secure, and isolated enclave environment within the processor, completely separate from the main operating system program. It can securely store and protect sensitive data while having strict access control mechanisms.

This means that developers can execute specific programs in TEE, fully amplifying the execution efficiency and performance of the hardware while ensuring security. Currently, there are various TEE implementation methods, including Intel SGX, ARM TrustZone, etc., which have broader applications in mobile internet, internet of things, and other fields. The applications in the blockchain scene are being explored.

2. Unichain is based on TEE environment, which allows transactions to be pre-executed and verified, making them occur before the transactions are officially packaged and block generated. This breaks the previous restriction of uniformly uploading transactions to Mempool and waiting for packaging, while also providing a relatively secure and tamper-resistant environment, thus making it possible.

The Flare Network’s approach to Oracle Machine is also amplified by the use of TEE environments. Building an Oracle Machine on the blockchain is purely for feeding price indicators into the Decentralized Finance contract environment, which can be quite challenging. If the scope of data is expanded to include sports match results, social media data, real-time election rankings, etc., it will require significant off-chain computing and processing power, and ultimately deliver verifiable results to the on-chain environment.

Flare will perform intensive computing operations in the TEE environment provided by Google Cloud, and only feed trusted results to the on-chain to avoid the large cost generated by the accumulation of massive data sources on-chain. The idea is simple: complex computing tasks are executed off-chain, and then verified on-chain through short proofs, reducing the data load and computing requirements on-chain.

3. After the analogy, it is not difficult to find that TEE’s trusted execution environment relies to some extent on hardware manufacturers (such as AMD, Intel) combined with traditional upstream service providers such as Google Cloud to provide ‘trustworthiness’ and preprocess the original data once before applying the data result to on-chain. This is a key difference from ZK, which is based on mathematical principles and cryptographic algorithms and does not rely on any hardware for trust: TEE requires a third-party trust party.

How to solve this problem? The logic is simple: TEE+ verifiable Prove network. Introducing a verifiable proof network can significantly improve the transparency and credibility of the TEE system. The Decentralization verification network that Unichain wants to introduce, and the distributed Node governance architecture provided by Flare’s blockchain architecture both act as roles in this verification network.

Although Unichain has not yet disclosed the implementation and governance details of this validation network, the key points are how to use the remote attestation feature of the TEE enclave environment and how to interact with the on-chain environment to generate proofs and ensure security and confidentiality provided by the hardware.