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…
cointelegraph.com