Amid growing interest in practical ways to scale and safeguard blockchains, hardware‑based approaches are coming into focus. The role of Trusted Execution Environments (TEEs) in blockchain systems has gradually expanded from privacy-preserving projects to applications that improve scalability and enable secure offchain computation. Currently, over 50 teams are working on TEE-based blockchain projects. In this article, Cointelegraph Research explores the technical foundations of TEEs in blockchain systems and examines key use cases of this technology.
Mechanics of TEEs in blockchains
Most blockchain technology relies on cryptography and distributed computing to maintain security. TEEs add a different approach, namely, hardware-level trust.
A Trusted Execution Environment is an isolated area within a device processor that is designed to keep data and code tamper-proof and confidential during execution. The resulting secure enclave is inaccessible to the rest of the operating system and can prove to third parties through remote attestation what instructions it is executing.
To do this, the CPU measures the Trusted Computing Base, which includes the boot firmware, operating system kernel and application binaries and saves it into secure hardware registers. It then signs this measurement using a private attestation key embedded in the CPU. This produces a cryptographic attestation report that a remote verifier can check to confirm the enclave’s authenticity and integrity.
Leveraging this hardware-level trust for confidential smart contract execution requires that blockchain nodes use chips with a TEE. This requirement typically applies to nodes that are responsible for transaction as well as block validation and offchain computation. In a layer-1 setup, consensus nodes continue to replicate an encrypted version of each contract’s state as part of the global ledger.
Each of the nodes contains a TEE that replicates the decryption, plaintext execution and reencryption of every transaction. This hardware dependence introduces a trade-off between enhanced privacy and a smaller validator set. Fewer people can run nodes if specific hardware is required. However, the additional trust this requires is partially traded off by the remote attestation TEEs can provide.
An alternative design is a layer-2 scheme wherein TEE computations are not secured by distributed consensus, but by a dispute resolution mechanism, as seen in rollups. This approach uses a similar encryption pipeline to an L1 setup but can help improve scalability. However, most layer-2 systems lose contract interoperability since they are executed on separate machines, which means contracts cannot call each other.
TEEs use standard asymmetric cryptography to obfuscate function calls and smart contract code. Function calls are encrypted with the TEE’s public key before being submitted to the blockchain, decrypted in the enclave and executed.
Secret Network, built with the Cosmos SDK and Intel SGX, was the first blockchain to have private smart contracts facilitated by TEEs. Secret Contracts allow developers to build confidential DeFi apps, which hide contract logic, inputs, outcomes and state, but not the addresses. It also enables the creation of Secret Tokens, whose balances and transaction history remain confidential and are visible only to their owners or explicitly authorised smart contracts.
Vulnerabilities of trusted execution environments
Private smart contract execution depends on the trustworthiness of the TEE hardware manufacturer. While it is doubtful that a corporation such as Intel would jeopardize its reputation with a targeted attack on blockchain systems, Intel’s Management Engine (IME), an autonomous system embedded in most Intel CPUs since 2008, has contained multiple serious vulnerabilities over the years.
TEE vendors may fall under government influence to introduce backdoors, comply with surveillance mandates or provide access to encrypted data under national security laws. Accidental vulnerabilities could also undermine the security of a TEE. For example, the Plundervolt attack exploited Intel’s dynamic voltage interface to induce computation faults inside SGX enclaves, which enabled attackers to bypass integrity checks and extract keys and secrets from encrypted memory.
Private smart contract execution with TEEs
To enable privacy-preserving DApps, smart contracts must execute in a way that keeps both logic and data confidential. To read and run confidential smart contract code, TEEs can access the keys required to decrypt contract data.
If these keys are ever compromised, an attacker could decrypt previously stored contract data. To avoid this, Trusted Execution Environments use distributed key management that splits key control across multiple trusted nodes and frequently rotates short-term keys to limit the impact of a breach.
Ekiden was the first to design such a system, and it served as a basis for similar models on other blockchains. The most sensitive keys are managed by the KMC (key-management committee, which is a group of the most trusted nodes) with threshold cryptography. The committee’s shares are proactively reshared to rotate who holds which share. Meanwhile, individual worker nodes hold limited-access short-lived keys tied to specific tasks.
These keys are issued by the KMC for each contract and expire at the end of every epoch. To obtain a key, a worker node must first prove its legitimacy to the KMC through secure channels. Each KMC member then generates a key share using a pseudo-random function and transmits it to the node, which reconstructs the full key once it has collected a sufficient number of shares.
If a KMC node is compromised, its access can be revoked through governance, and it will be excluded from future epochs. This reduces the potential impact of a breach, though not eliminating it entirely. When a confidential contract is deployed, its enclave generates a fresh public key and publishes it on the blockchain along with the contract code and encrypted initial state.
Users who later call the contract retrieve this key to encrypt their inputs before sending them to the compute node. To guarantee authenticity, the node also provides a signing key bound to the enclave via attestation when it starts up.
Other use cases of TEEs in blockchains
Beyond private smart contract execution, TEEs can significantly improve blockchain scalability and efficiency. TEE-enabled nodes can securely execute computationally intensive tasks offchain and submit the results onchain. Thus, applications can offload computational overhead from the blockchain layer to the trusted offchain environment. This can help reduce gas costs and increase the overall throughput of the chain.
IExec is one of the largest decentralized cloud computing platforms that uses Trusted Execution Environments for offchain computations. It uses Intel SGX-based enclaves to offload and isolate computation from the blockchain.
A requester, usually a smart contract or user, can purchase a confidential computation as a task onchain. The blockchain then notifies worker nodes to execute the task inside a secure enclave. Before execution proceeds, the enclave generates an attestation report containing cryptographic evidence of the enclave’s code and configuration.
This report is sent to a Secret Management Service, which verifies the enclave’s integrity and authenticity. Only if the enclave passes this verification does the actual computation begin.
Trusted execution environments can also be used to provide an MEV-proof blockchain infrastructure. Unichain, an optimistic rollup on Ethereum developed by the Uniswap team and launched in October 2024, leverages TEEs in its block-generation process. Its block builder, developed in collaboration with Flashbots, uses TEEs to construct blocks within a protected enclave.
When routed to the TEE builder, transactions are filtered, priority-ordered and bundled into Flashblocks. This allows Unichain to achieve 1-second block times, with plans to introduce 250-millisecond sub-blocks and improve transaction ordering. Block building within TEEs helps to reduce MEV extraction because mempool transactions remain encrypted. With these features, Unichain aims to build a DeFi-designated blockchain.
Conclusion
Trusted execution environments on blockchains are gaining momentum as developers seek more efficient privacy solutions. TEEs have the potential to shape the future of decentralized applications with low-cost and high-latency secure computation. Despite their potential, TEEs are not yet natively supported by most blockchains due to hardware requirements and trust assumptions.
In the future, we expect use cases of TEEs to expand from privacy-preserving applications and become focused on scalability solutions for blockchains and offchain computation for decentralized applications. This shift is driven by the emergence of more computationally demanding DApps, such as decentralized AI applications. TEEs may facilitate these use cases with low-cost, high-performance offchain computation.
This article does not contain investment advice or recommendations. Every investment and trading move involves risk, and readers should conduct their own research when making a decision.
This article is for general information purposes and is not intended to be and should not be taken as legal or investment advice. The views, thoughts, and opinions expressed here are the author’s alone and do not necessarily reflect or represent the views and opinions of Cointelegraph.
Cointelegraph does not endorse the content of this article nor any product mentioned herein. Readers should do their own research before taking any action related to any product or company mentioned and carry full responsibility for their decisions.