Why did Unichain and Flare introduce trusted execution environments?
Author: Haotian
Recently, there has been extensive discussion around the differences between ZK and Trusted Execution Environments (TEE). The reason is that the newly entered layer2, @unichain, claims that its millisecond sub-blocks are built on TEE, while the oracle old chain @FlareNetworks, which claims to be a data blockchain, integrates traditional internet channels like Google Cloud to introduce verifiable off-chain computation through TEE. Combining these two matters, here are 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 isolated from the main operating system programs, allowing for the secure storage and protection of sensitive data, while having strict access control mechanisms.
This means that developers can execute specific programs within TEE, fully amplifying the execution efficiency and performance of the hardware while ensuring security. Currently, there are various implementations of TEE, including Intel SGX and ARM TrustZone, which have broader applications in mobile internet, IoT, and other fields, with applications in blockchain scenarios being explored.
2) Unichain, based on the TEE environment, allows transactions to be pre-executed and verified before they are officially packaged into blocks. This breaks the previous limitation of transactions uniformly uploading to the Mempool and waiting to be packaged, while also providing a relatively secure and closed environment to prevent tampering and malicious activities.
The approach of Flare Network in being an oracle is also amplified by leveraging the TEE environment. Feeding price indicators purely for DeFi contract environments can be highly competitive; however, if the data scope is expanded to include sports results, social media data, real-time election rankings, etc., it requires substantial off-chain computation and processing capabilities, ultimately transmitting the verifiable results back to the on-chain environment.
Flare will conduct intensive computational operations through the TEE environment provided by Google Cloud, only feeding trusted results onto the chain, thus avoiding the accumulation of large data sources on-chain that would incur significant costs. The idea is straightforward: complex computational tasks are executed off-chain, and then verified on-chain through brief proofs, which can reduce the data load and computational demands on-chain.
3) After drawing comparisons, it is not difficult to find that the TEE Trusted Execution Environment, to some extent, relies on hardware manufacturers (such as AMD and Intel) combined with traditional upstream service providers like Google Cloud to provide "trustworthiness," performing a pre-processing step on the raw data before applying the results on-chain. This has a key distinction from ZK, which relies on mathematical principles and cryptographic algorithms and does not depend on any hardware for trust: TEE requires a third-party trust entity.
How can this issue be resolved? The logic is also simple: TEE + verifiable Prove network. Introducing a verifiable proof network can significantly enhance the transparency and credibility of the TEE system. The decentralized verification network that Unichain aims to introduce, along with the distributed node governance structure provided by Flare's blockchain architecture, plays the role of this verification network.
Although Unichain has not yet disclosed the implementation and governance details of this verification network, how to utilize the remote verifiable characteristics of the TEE enclave environment and how to generate proofs and interact with the on-chain environment under the premise of hardware providing security and confidentiality will certainly be key points.