Why did Unichain and Flare both introduce trusted execution environments?

Written by: Haotian

Recently, there has been a wide range of discussions 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-blocks are built on TEE, while @FlareNetworks, an old oracle chain known as the data blockchain, integrates traditional Internet channels such as Google Cloud and introduces verifiable off-chain computing through TEE. Combining these two things, let me talk about my views:

1) TEE (Trusted Execution Environment) is a hardware-level security technology. Simply put, TEE creates an independent, secure, and isolated Enclave environment in the processor, which is completely isolated from the main operating system program, can safely store and protect sensitive data, and has a strict access control mechanism.

This means that developers can execute specific programs in TEE, fully amplifying the execution efficiency and performance of the hardware while ensuring security. There are currently many different TEE implementations, including Intel SGX ARM TrustZone, which has a wider range of applications in the fields of mobile Internet, Internet of Things, etc., and its applications in blockchain scenarios are being explored.

2) Based on the TEE environment, Unichain can allow transactions to be pre-executed and verified before the transaction is officially packaged and produced. This breaks the limitation of the original transaction being uniformly uploaded to the Mempool waiting for packaging, and can have a relatively safe and closed anti-tampering environment, so it can be realized.

Flare Network's idea of ​​​​making an oracle is also amplified with the help of the TEE environment. It would be very cumbersome to make a oracle data blockchain purely to feed prices (Price indicators) for the DeFi contract environment. If the data scope is expanded to sports game results, social media data, real-time election rankings, etc., it requires huge off-chain computing and processing capabilities, and finally delivers the verifiable results to the on-chain environment.

Flare will perform intensive computing operations through the TEE environment provided by Google Cloud, and only feed trusted results to the chain, avoiding the accumulation of large data sources on the chain and generating large costs. The idea is simple: complex computing tasks are performed off-chain, and then verified on the chain through short proofs, which can reduce the data load and computing requirements on the chain.

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

How to solve this problem? The logic is also simple: TEE + verifiable Prove network. Introducing a verifiable proof network can significantly improve the transparency and credibility of the TEE system. The decentralized verification network to be introduced by Unichain and the distributed node governance architecture provided by Flare's own blockchain architecture both play the role of this verification network.

Although Unichain has not yet disclosed the implementation and governance details of this verification network, how to use the remote authentication characteristics of the TEE enclave environment and how to generate proofs and interact with the on-chain environment under the premise of hardware security and confidentiality must be the key points.