Blockchain offers a radically transparent approach to the internet through dozens of open and permissionless networks that serve millions of users around the world. However, while transparency offers many benefits, it must be balanced with robust privacy tools that fortify the confidentiality and data security of every on-chain user. As Web3 embraces privacy, insight into the trends and technologies pushing on-chain privacy forward is essential. This blog post offers a simplified comparison of two distinct approaches to Web3 privacy: Zero-Knowledge Proofs and Trusted Execution Environments. From developers to users, learning the differences between these technologies is crucial to understanding the future of Web3.

‍

Before comparing these technologies, it’s useful to define some terms.

• Zero-Knowledge Proofs: A zero-knowledge proof (ZKP) is a cryptographic mechanism that allows anyone to prove the truth of a statement without having to share the information in a statement and without revealing how the information was received. Blockchain validators run computations that verify if a proof is correct and, if so, apply state changes without learning the data that was verified. Learn more about ZKP from the ZK MOOC.
• Trusted Execution Environments: A Trusted Execution Environment (TEE) uses a hardware-based secure computing model by separating a region of the processor from the rest of the CPU. When used to enable confidential blockchains, these environments receive encrypted data and run computations that cannot be directly observed or tampered with by anyone, even the hardware host. Read more about TEEs in this blog post. 

Let’s take a deep dive into both privacy-preserving technologies! 

‍Application Scalability

A key characteristic of ZKP is the frequent need to develop unique circuits in certain applications to meet specific use cases for a prover to demonstrate knowledge without revealing any information. This action is typically performed by constructing a circuit that executes a specific computation based on a particular secret. The verifier then receives proof that the circuit has been executed correctly.

In some applications, the same circuit cannot be used by multiple provers while in others, using a generic ZKP scheme, single circuits can be used by multiple provers. But multi-use circuits need to be carefully designed to ensure that they cannot be used to reveal any information about the secret being proved.

For TEEs, scalability across uses and applications is dependent on its implementation, which is determined by a set of factors, including hardware and software architecture and specific requirements of the TEE use case. In some circumstances, for example with a TEE implemented on a mobile device, uses may be limited to simple applications. For Web3 dApps, however, TEEs typically used by blockchain validators are capable of processing large computational workloads. And these environments support execution of arbitrary machine code and thus can be used by multiple developers across numerous applications. 

Oasis abstracts away the low-level but security-critical details of dealing with setting up TEEs, performing remote (re-)attestation, organizing compute committees, providing trusted tamper-proof storage, data availability, and more. For users and developers Oasis packages TEEs into runtimes that execute on the Oasis Network, with carefully designed external interfaces, making TEE-based confidential compute easy to consume in a safe manner.

In particular, for Solidity developers, this means that when building using TEEs on the Oasis Network there are no unique limitations or requirements based on user counts or specific ecosystems. Developers can not only add encrypted state to any Solidity dApp with only a few modifications, they can also specifically choose which aspects of state they wish to encrypt and which they wish to remain public. Instead of struggling through the friction of developing ZKP circuits for their smart contracts, Web3 developers can take advantage of the notable flexibility and scalability of TEEs with secure execution for any applications built on any blockchain network. 

‍Security and Performance

ZKP can be computationally expensive, depending on the type of algorithm used and complexity of the problem being proved. ZKPs usually require significant computational resources to generate proofs because their security is derived solely from cryptographic operations. Proof verification itself, however, is fast. But the complexity of most ZKP algorithms is proportional to the size of its circuit, and there are many different types of ZKP algorithms. Some types are more computationally expensive than others. Developers who use ZKPs often believe the security and privacy benefits will outweigh their computational costs.

TEEs are designed to provide a secure and isolated environment for running sensitive code without the burden of expensive cryptographic operations. Because security for TEEs is based on hardware with some software elements instead of exclusively relying on cryptography, performance for complex workloads is improved. TEEs are not immune to attacks, however, especially side-channel attacks, which attempt to exploit unintended information leakage from a system. On the other side, various mitigation techniques exist, ranging from more general and well-known (e.g., constant-time cryptography) to more specific methods required by unique use cases.

TEEs are designed to balance security and performance, so most TEE setups are optimized for efficiency and will often use specialized hardware to minimize the performance impact of any additional security operations. In fact, the bulk of computational overhead for TEE-based operations comes from the occasional need for additional security-related tasks, such as encrypting and decrypting data or verifying the integrity of code running within a TEE. 

For example, if we would want to provide privacy features for a Web3 DEX, using ZKPs alone would not be sufficient and would prove to be an extremely difficult task. In contrast, a TEE implementation gives much more flexibility where even more complex private data aggregation tasks like those needed in a DEX are more easily and efficiently implemented.

Or consider a scenario involving stablecoin transactions between a sender and receiver. Today, the norm is full visibility into all transaction data by the sender, receiver, issuer, and anyone else looking at the blockchain. Using TEEs, however, developers can build complex and sophisticated applications that customize visibility of on-chain data. Whether only the sender and receiver see data, or the issuer has visibility permission too, or even only the sender can view the data – all of these options are available to dApp developers building in robust and flexible TEEs. 

‍Smart Contract Flexibility

TEEs are built for high performance under significant computational workloads, like those that advanced smart contracts and data-heavy Web3 applications produce. Ease of use and developer flexibility within TEEs is a primary reason these environments are well suited for many of the complex applications built throughout Web3.

Overall, TEEs are well suited for generalized smart contract execution and especially smart contracts that need to aggregate large amounts of private data. The developer experience is much simpler too. For example, confidential applications built on Oasis Sapphire (confidential EVM powered by TEEs) can be developed in days as opposed to months or years using alternative privacy technologies.

ZKP is traditionally not optimized for smart contract execution. Recently there has been notable progress in supporting EVM compatibility, however these compatibility improvements are focused around scalability (and not privacy) use cases such as ZK-EVMs. ZKPs still have limitations with enabling privacy in generalized smart contract execution. This is because ZKPs require a prover to receive access to all global state and transaction data, which it can not do if some aspects of global state are private. This creates severe limitations on using ZKPs as a privacy solution for any application which will need to achieve privacy in a multi-party context, where knowledge from multiple participants is required.  

In certain applications with simpler use cases, ZKP can easily solve for user privacy. But as computational loads become more complex and the data inputs grow, this privacy becomes more challenging, more expensive, and less flexible. To mitigate these problems, custom circuits are sometimes required to protect dApps with large and complex data loads. Some teams building with ZKP are building frameworks to simplify the process of integrating ZKP into smart contracts, but they do not provide the same level of flexibility for privacy that TEEs offer.

‍Trust Trade Offs

Understanding the trust model of any Web3 privacy technology is important for developers and users. Some ZKP-based solutions, for example, can rely on semi-trusted sequencers to verify information. Even though ZKPs can be an effective scaling tool, it should be clear why ZKP as a privacy solution for Web3 is limited. Some ZKP-based solutions, for example, can rely on semi-trusted sequencers to verify information. If an application allows multiple sequencers, the privacy is degraded even worse. But in select use cases, ZKP can provide useful privacy – a primary example is the Zcash currency. Without revealing how many coins a user has or is spending, each user needs to prove they are not double-spending coins. Using a ZKP to prove a user did not cheat is essential. But to be clear: this technique is limited to very specific use cases (e.g., currency) and not optimized for generalizable secure computation.

For TEEs, the notion of trust is in the name. But the trustworthiness of a TEE is largely limited to the hardware-based trust where the TEE is implemented to provide a secure execution environment that is isolated from the rest of the system. This hardware-based trust is primarily based in the hardware designer and manufacturer and their security practices. This trust can be verified to a large extent using secure boot processes, secure enclaves, and other industry standard techniques. TEEs allow developers to produce tamper-proof attestations for data inputs and attestations for whatever application they are building or using.

‍Conclusion

In short, privacy technologies for Web3 exist on a spectrum with many strengths, weaknesses, and tradeoffs.

ZKP can satisfy some privacy-focused use cases, but there are limitations to their performance, scalability and support for general computation. Other Web3 privacy technologies like TEEs are more attractive for developers building dApps with large amounts of concurrent users and large amounts of data. In these situations, TEEs offer a flexible, scalable, and high-performance tool for integrating robust confidentiality into any Web3 application. But both tools can also be complementary, and some Web3 applications, for example, could use ZKP to improve the security and robustness of a TEE-based system. Regardless of which privacy tools a developer uses, the future of Web3 is bright with a wide range of privacy technologies to choose from.