Written by: 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 its millisecond-level sub-blocks are built on TEE, while the so-called data blockchain oracle old chain, @FlareNetworks, integrates traditional internet channels like Google Cloud to introduce verifiable off-chain computation through TEE. Combining these two points, 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, allowing for the secure storage and protection of sensitive data, while enforcing strict access control mechanisms.
This means that developers can execute specific programs in the TEE, fully amplifying the hardware's execution efficiency and performance 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 formally packaged into blocks. This breaks the previous limitation of transactions being uniformly uploaded to the Mempool and waiting for packaging, while also providing a relatively secure and closed environment to prevent tampering and malicious activities, thus making it possible.
The approach of Flare Network in using oracles is also amplified by leveraging the TEE environment. Feeding price indicators into a blockchain purely for DeFi contracts can be highly competitive, but by expanding the data scope to sports game results, social media data, election real-time rankings, etc., it requires substantial off-chain computational and processing capabilities, ultimately transmitting the verifiable results back to the on-chain environment.
Flare will perform intensive computational operations through the TEE environment provided by Google Cloud, only feeding trustworthy results onto the chain, avoiding the accumulation of large data sources on-chain that would incur significant costs. The idea is simple: complex computational tasks are executed off-chain, and then verified on-chain through brief proofs, thus reducing the data load and computational demands on the chain.
3) After analogy, it is not hard to find that the TEE trusted execution environment somewhat relies on hardware manufacturers (such as AMD and Intel) in conjunction with traditional upstream service providers like Google Cloud to provide 'trustworthiness', performing a pre-processing step on the raw data before applying the results to the chain. This has a key distinction from ZK, which is based on mathematical principles and cryptographic algorithms that do not rely on any hardware for trust: TEE requires a third-party trust entity.
How can this problem be solved? The logic is 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 and the distributed node governance architecture provided by Flare's blockchain itself both play the role of this verification network.
Although Unichain has not yet revealed the implementation and governance details of this verification network, how to utilize the remote verifiable features of the TEE enclave environment and how to generate proofs under the premise of hardware providing security and confidentiality to interact with the on-chain environment will certainly be key points.