Before we can discuss the application of TEEs for blockchain related programs, we first have to establish what Trusted Execution Environments (TEEs) are.
At a high level, TEEs can be described as an isolated processing environment found on the CPU, a sort of separate secure area where whatever code and data enters remains confidential, where processes outside of a TEE cannot read or tamper with the data within it. These private regions of memory are known as enclaves.
By running code in this isolated, tamper-resistant processing environment, it "guarantees the authenticity of the executed code", where remote attestation can be provided to prove its trustworthiness to a third-party and untrusted code should not be able to interfere with the execution of a program within the TEE.
Ref: "Trusted Execution Environment: What It is, and What It is Not", Sabt et al.
Part of the "trust" part of the Trusted Execution Environment is trust that the program executed within the TEE remains untampered and unaffected by any external processes, e.g. the program cannot enter an illegitimate state due to a separate process attempting to modify the registers used in computation.
TEEs support remote attestation, a means to verify the authenticity and integrity of a program's execution. Basically, the TEE is able to produce a set of proofs to prove that the program run and its system states are legitimate — the TEE, as an attester, would collect a set of claims of trustworthiness, which are subsequently cryptographically signed to form evidence, which can then be gauged and interpreted by a verifying party. Do note, this doesn't mean that all evidence are cryptographic proofs! Yes, evidence is signed by a bunch of keys which serves to guarantee hardware trustworthiness, and verifiers would submit challenges to attesters that are responded to via asymmetric encryption. However, verifying parties can choose to deny the evidence!
The confidentiality and integrity of data (i.e. the lack of external interference in a program's state) are more or less an extension of the CPU's security features themselves: your Intel SGX, AMD SEV, Arm TrustZone etc. Part of this also comes down to tamper-resistant hardware e.g. a Trusted Platform Module (TPM, i.e. the shit you need for Windows 11 and Riot Vanguard). which make up a root of trust, which would essentially be hardware level secrets that are used to sign off on the program's execution.
For most intents and purposes, we can trust that a program executed within a TEE is what we expect it to be — you wouldn't be able to run a different program or a modified version of a program within a TEE and produce a valid set of attestations. However, this does not mean that we can verify the input of the program!
Let's say I make a request for computation of some data by a program running in a TEE. A malicious compute provider could pass in data that would be easier to compute (e.g. if my input calls for 100 iterations, I can instead pass in an input that only requires 20 iterations) and still produce valid attestations for the input, but in no way are you able to verify that the output actually corresponds to the input that you requested! The only way to do so is for the program itself to be able to perform cryptographic proofs corresponding to the input (e.g. ZKP), in which case we're sort of back to square one. The protection a TEE provides is limited to what executes within it! After all, signatures are not proofs!
Furthermore, do note that attestations are not standardized! If we want to make use of TEEs in a blockchain network, this would then require all nodes to be running similar hardware that make use of the same TEE implementation.
Ref: "Attestation Mechanisms for Trusted Execution Environments Demystifi ed", J. Menetrey et al.
From what we've established above, TEEs are not some silver bullet for arbitrary Proof of Compute. Rather, it serves as a privacy preservation method, where data confidentiality and integrity during runtime can be ensured.
This brings us to some obvious benefits that TEEs would bring about for certain blockchain related operations:
- Protection of private keys: if your private keys and operations performed using private keys exist entirely within a TEE, then it would secure it against a potential malicious actor. This can be applied to, say, crypto wallets, where all your crypto signatures are performed within the TEE, and this would prevent any malware on your computer from gaining access to the private key by, like, looking for it in memory or something. However, this also means that to maintain such a security model, the private key cannot leave the TEE, which means that you, as an end-user, also won't have access to it, so it's sort of a ride or die.
- Prevention of tampering with crypto related software: Similar to the above example, we can theorize that, say, a malicious program attempts to inject code into Metamask or something to drain your crypto wallets. If Metamask were to operate within a TEE, then this simply wouldn't be able to happen. Yipee.
- Private states and confidential computations: as repeatedly stated, this is the core benefit that TEEs provide. This can be relevant to privacy oriented projects (think of Monero and Penumbra) where you'd want to hide, say, transaction sizes or trade directions (think of, erm, tumblers. Research into an implementation of a BTC mixer based on TEEs exists). It can be argued that such programs may not necessarily need TEEs to accomplish these operations as they would still rely on some sort of ZKP/FHE/MPC/oblivious algorithm to actually perform the operation itself, but like, security + security = more security I suppose.
Looking at projects that have leveraged TEEs (nice Medium article here), we get a few more ideas:
- $TOKI makes use of Intel SGX enclaves to perform "light client verification", whereby the program that nodes run will be executed with an enclave for there to be trusted execution, and then this program produces cryptographic proofs that are then utilized in an MPC implementation. This makes some sense as you can mess with the program states during MPC to produce erroneous results, and the use of TEE here would produce more resilient programs.
- $TAIKO makes use of an SGX verifier, where ECDSA signatures are checked within a TEE. Once again, this is to ensure the legitimacy of a computation — this one is a bit goofy as the computation itself should be cryptographically verifiable, and use of TEE here is to make sure that the computation goes as intended.
- $ROSE (Oasis Protocol) makes use of SGX to perform confidential execution of smart contracts, with multiple layers of encryption and decryption before and after execution, where node operators and devs would be barred from reading the data that is being used in execution.
To address an elephant in the room: no, you can't use TEEs to get "verifiable AI compute". In theory, you could get private LLM interactions (where the prompts passed to the LLM are in some way hidden from the node operator, which would be a huge plus to privacy), but similarly to what has been discussed before, you would still require some sort of scheme to ascertain whether a node operator is actually executing your prompt or just passing in some other "easy to answer" prompt that will produce a valid signature too. An argument for TEEs still is that now there'd be a higher minimum overhead for Sybilling, e.g. our Sybil attack on Crynux worked because I could sidestep the actual LLM or Diffusion model execution, whereas in this case you would have to run the LLM or model still to produce some sort of output, in which you might as well just run the actual prompt.
However, TEEs, for now, (primarily) only exist for CPUs. GPU TEEs are in active development (see: NVIDIA's Hopper and Blackwell architectures), but this is still very much out of reach to most consumers and by extension, node operators.
TEEs, as repeatedly stated, also aren't some sort of silver bullet for verifiable computation: you still need your cryptographic primitives within your proof systems to accomplish complete end-to-end verifiable compute.
Just to throw my two cents in, the "reliance on centralized infra/single trusted party" in the form of the hardware manufacturer responsible for the TEE isn't really the most compelling argument against the use of TEEs? If you're willing to raise that argument, you're saying that as if your CPUs aren't already fucking backdoored, lol (see: Intel ME, AMD Secure Technology).
What is a fair argument is that TEEs have been broken before, so if your "privacy preserving application" is entirely reliant on the TEEs working as intended, you're sort of setting yourself up to eventually get pwned. A good resource can be found here on https://sgx.fail/, which details instances of real life deployments of Intel SGX leading to privacy failures (we find our good friend the Secret Network here! Surprisingly, news breaking of it being vulnerable didn't lead to $SCRT's price being decimated, probably because it already had a close to 90% drawdown prior to it.)
Well, TEEs are good for keeping wallets safe and privacy preservation operations (until they, ye'know, stop being privacy preserving), so there are uses for TEEs in the blockchain, but these applications simply aren't the one-shot-kill people are hoping for where we can abandon actual cryptography (the part that the currencies are named after) in favour of just running everything in a TEE and saying the attestations are all good.
I've avoided discussing rollback attacks and the sort as they've been actively mitigated and defended against, and often these just come back to the same argument that I've hopefully driven home: TEEs are only responsible for what happens in a TEE, and have no say for what data actually gets thrown into it.
Here's a nice paper that covers some of the points raised here in further depth: "Lessons Learned from Blockchain Applications of Trusted Execution Environments and Implications for Future Research", Karanjai et al.
In other words, don't hype up a project simply because it uses some TEE/SGX related implementation, because it's probably a very minor part of its actual security model. That is unless you're talking about a tumbler or mixer, in which case you probably shouldn't be talking about it anyways.