Introduction

Every day, people generate up to 402 million terabytes of sensitive data. The demand for private computing of this data is increasing, as individuals are reluctant to share their data broadly. These solutions are primarily supported by Amazon Web Services (AWS) infrastructure, which captures approximately 30% of the global cloud computing market. However, AWS has several disadvantages, primarily due to its centralized architecture. Even with the introduction of enhanced security computations through AWS Nitro Enclaves, it faces significant challenges in developer adoption and poses even greater difficulties for blockchain security and Web3 applications in general.

In this article, we explore the current AWS landscape and introduce a Decentralized Trusted Execution Environment (TEE) Cloud solution, which addresses not only AWS's shortcomings but also the limitations of other TEEs currently available. First, however, we examine why AWS and its Nitro Enclaves offering have gained significant popularity and market share, and what issues persist despite these advancements.

AWS Nitro and TEEs

AWS is currently the most popular cloud computing platform, offering a wide array of tools. To provide a brief overview, AWS is essentially a cloud infrastructure for all computation-related needs that developers might have. This includes compute, storage, and database services, among others. As most people know, AWS holds approximately 30% of the cloud infrastructure market share, which is significant. With nearly 48% of all software engineers or developers using AWS in some capacity, there is a substantial demand for it.

As demand and the customer base grew, including large financial institutions, governments, and startups with highly sensitive data, questions arose regarding AWS's security and whether these entities could securely store and use this data for confidential computing.

It was at this point that AWS conceived the idea of implementing TEEs into its platform to protect data in use, complementing encryption for data at rest and in transit.

This new solution with TEE implementation is called AWS Nitro Enclaves, which provides a hardware-backed isolated execution environment. TEEs establish secure environments within Amazon EC2 instances, eliminating interactive access, persistent storage, and external networking. This isolation minimizes the attack surface by separating sensitive workloads from the parent EC2 instance, its operators, and other software.

However, Nitro Enclaves operate within a highly centralized framework, as they are created and managed entirely within AWS’s EC2 service. All aspects of enclave management, from creation to termination, are controlled by AWS’s infrastructure, which is inherently centralized, given AWS's nature as a centralized cloud provider.

To simply say, AWS Nitro Enclaves offer strong isolation through hardware-based trusted execution environments protecting sensitive workloads. Nevertheless, their centralized architecture introduces certain limitations and trade-offs.

Limitations of AWS Beyond Centralization

In addition to the drawbacks of centralization, where all components and data depend on a single system, AWS Nitro Enclaves present further challenges and introduce new security considerations. AWS attaches several Nitro Cards (customized hardware) to CPUs to run the TEE payload, which creates a double security risk: vulnerabilities could arise from both the underlying CPUs and the Nitro Cards.

A significant concern with Nitro Enclaves is the lack of proper memory encryption mechanisms. Unlike solutions where memory encryption is integrated directly into the CPU, the external nature of Nitro Cards makes it difficult to ensure end-to-end encryption of data in memory. This configuration could risk exposing sensitive information to manipulation during memory access, since encryption relies on the interaction between the CPU and the external device.

On top of that, developers must still create and configure Amazon Machine Images with enclave software, often using Docker, which can be difficult for those unfamiliar with containerization. They also need to use the AWS CLI and Nitro Enclaves CLI to launch instances and manage enclaves, navigate Nitro Enclaves APIs, and integrate with AWS Key Management Service, which sometimes requires an understanding of cryptographic attestation processes.

The reliance on Nitro Cards for the TEEs leads to unverifiable attestation, as the measurement of the code's integrity originates from the Nitro Card, not the CPU itself.

AWS trusts developers and administrators to set up Identity and Access Management policies, which could allow them to access sensitive data. Their high-level access creates insider threat risks, as they might view or alter data.

AWS Nitro Trust Assumption Review

However, the most significant limitation is that AWS is not optimized for decentralized applications and ecosystems; it lacks native support for Web3 use cases or governance systems.

For example, AWS Nitro Enclaves lack persistent storage. While this isolation is beneficial for security, it limits use cases such as AI agents that require user data storage in vector databases.

Key management also doesn’t align with “zero trust” scenarios. While AWS Key Management Service (KMS) is available, it is designed for Web2, allowing administrators to access private keys. This conflicts with Web3 requirements where keys must be controlled solely by code and never exposed, even to administrators.

Nitro Enclaves address developers' distrust of the cloud, but Web3 demands trustless solutions among users, developers, and vendors. Secure code upgrades are not supported, necessitating decentralized ownership similar to smart contract governance, which developers must build from scratch, potentially taking months and risking vulnerable code if not implemented properly.

Setting up a web service is time-consuming due to the lack of network access and forcing developers to write extensive code to adapt applications and secure encryption, which is often imperfect.

Why do we even need TEEs for Web3?

We use TEEs because we can’t fully trust developers or admins. People in web3 have a different mentality and aim for using trustless systems: if something must be trusted, this is not looking very good. That’s why users rely on hardware operators to check and manage apps. Apps can be separated so they don’t interfere, this protects sensitive data from being grabbed or changed during memory access, since encryption depends on the CPU and external devices working together smoothly. Users and data providers require clear assurance and verification regarding the operations that programs perform on their data.

Combining the benefits of AWS, TEE, and Decentralization

When developing Phala Network, our initial vision was to combine the strengths of AWS with the security of TEEs, eliminating complexity while enhancing security through decentralization. This approach is tailored to meet the demands of Web3 use cases. The result is our concept of a decentralized TEE cloud, which delivers security and integration for decentralized applications.

Creating Decentralized TEE Cloud

To understand the concept of a decentralized TEE cloud, it is essential to first define a decentralized cloud. So, what is it?

A decentralized cloud is a type of computing infrastructure where data storage, processing, and management are distributed across a network of multiple nodes instead of being concentrated in a single central server or data center. Unlike traditional centralized cloud systems like AWS, a decentralized cloud operates without a single controlling entity, relying on blockchain for its functioning.

Decentralized TEE Cloud

A decentralized TEE cloud is a computing infrastructure that combines TEEs with a decentralized network of nodes to provide secure, private, and verifiable computation. Each node is equipped with a TEE that protects sensitive code and data from being accessed or altered, even by the node operator.

Phala Network consists of a decentralized network of worker nodes, each equipped with a TEE. These nodes perform computational tasks for users, such as running smart contracts or processing sensitive data, in a manner tailored to the customer's needs.

The process begins when users deploy their applications or tasks to the network. Computations are executed inside the TEEs on these nodes, ensuring that the code and data remain confidential — even node operators cannot see or tamper with them.

Phala uses cryptographic proofs to verify that computations are performed correctly within the TEEs. Node operators are rewarded for providing honest and secure services, maintaining the network’s integrity through economic incentives. While this sounds straightforward, implementing this solution is far more complex than it appears.

Why is It Difficult to Create a Decentralized TEE Cloud?

TEEs are not inherently centralized or decentralized; their centralization depends on how they are implemented and deployed within a system. A TEE is a secure, isolated area within a processor designed to protect sensitive code and data from unauthorized access, even by the operating system or other processes on the same device. Whether a TEE operates in a centralized or decentralized manner is determined by the architecture of the broader system in which it is used.

Creating something centralized has historically been simpler than creating something decentralized due to the challenges of implementation and node communication. Before Phala Cloud, we successfully created Phala Network 1.0 (SGX) and made it completely decentralized. Now, we are doing the same with Phala Cloud, though it requires time. Phala is currently the only platform combining TEEs with full decentralization, unlike centralized providers or partially decentralized protocols.

The benefits of decentralization and TEEs are clear, but in product development, they are not enough. Imagine AliExpress as the largest e-commerce platform, capturing a huge market share. Now, imagine a new product launches with twice the features and lower prices: will it capture the entire market? Unfortunately, no, because people are accustomed to the existing product and biased against something new, even if it’s better.

This is one of the challenges we face, but instead of aiming for twice the improvement, we ensure Phala is ten times better and user-friendly. Moreover, as previously noted, AWS does not fit the Web3 environment, and we aim to fill this gap for Web3 applications and developers. We want to highlight how Phala differs from AWS, beyond the obvious advantage of decentralization.

Phala Cloud vs. AWS

First of all, AWS’s setup for Nitro Enclaves is complex. This involves multiple steps, including installing the Nitro CLI, converting Docker images to enclave files, and handling file transfers, all of which are quite time-consuming. In contrast, Phala allows developers to “lift-and-shift” deployments and easily migrate existing Docker containers to secure TEEs. Using the Dstack SDK, developers can convert Docker containers into Confidential VMs with minimal changes, utilizing a user-friendly Cloud UI for deployments, while still retaining support for templates and custom Docker Compose files.

In terms of security, AWS relies on trusting developers and administrators to correctly configure access controls and manage resources. Although AWS uses TEEs for isolated computations, its centralized infrastructure necessitates trust in both AWS and the personnel managing the systems, potentially allowing access to sensitive data. Phala employs a zero-trust model, ensuring no party is trusted by default. Sensitive data remains secure within TEEs and is inaccessible even to node operators, making it suitable for web3 apps requiring trustless operations.

Focusing more on the product side, AWS primarily caters to enterprise customers, given the large number of enterprises in traditional IT. Consequently, it doesn’t fully align with the value proposition of web3 startups, both product-wise and technologically. On the other hand, Phala is purpose-built for decentralized apps. It natively supports AI agents interacting with blockchain smart contracts and privacy-preserving dapps.

Furthermore, Phala is deeply integrated into the blockchain ecosystem through partnerships with various protocols and integrations for dapps that want to leverage the security of TEE.

Web3 Integration

Phala is positioned as the execution layer for Web3 AI, empowering developers to build, launch, and profit from AI Agents that can understand and interact with blockchain smart contracts securely and privately by default. We support decentralized AI platforms like NEAR AI and Sentient, among others, by utilizing NVIDIA GPU TEEs to run LLMs in secure, verifiable, and privacy-focused environments. For example, our partnership with NOTAI highlights zero-trust execution for AI agents, where we provide trustlessness and privacy through TEEs and RA Explorer for transparency.

We also support integrations with applications not related to AI through Phat Contracts, which are low-cost, low-latency smart contracts with native HTTP request support.

However, given that many crypto-native teams are also building TEEs and other methods of secure computation, how does Phala differentiate itself from these solutions?

Phala Cloud vs. TEE Solutions

Phala Network stands out as the only fully decentralized TEE cloud, delivering secure, private, and verifiable computation for dapps. Unlike Oasis Protocol and Secret Network, which focus on privacy-enabled smart contracts using TEEs within their respective blockchains, Phala provides a decentralized cloud computing platform with off-chain computation across a network.

Phala is flexible and customizable, leveraging a wide range of TEE hardware, including Intel SGX, Intel TDX, AMD SEV, and NVIDIA GPU TEEs. Marlin Protocol enhances network performance for web3 but does not offer computation or privacy features, while Oasis and Secret operate within specific blockchain ecosystems. Phala has a unique edge as the only decentralized TEE cloud with broad hardware support and developer-centric tools like Dstack.

Phala is different because it offers a general-purpose decentralized TEE cloud, unlike Oasis Protocol, Marlin, and Secret Network, which focus on specific use cases. Phala allows developers to deploy any application, such as AI models, web servers, or databases, in a secure environment. This is facilitated through Phat Contracts and Phala Cloud, which supports Dockerized deployments with one-click access to CPU and GPU TEEs.

Multi-proof System

Also, there are many comparisons of how TEE or MPC (Multi-Party Computation) is better for particular use cases. In our case, TEE and MPC are not competitors but friends that complement each other.

Phala integrates TEEs with MPCs to create a decentralized root of trust (DeRoT) model, a state-of-the-art approach for securing TEE-based applications. MPC runs within TEEs to reduce node collusion risks, while TEE block proofs are submitted alongside MPC proofs to mitigate errors in ZKP (Zero-Knowledge Proof) implementation. Requiring MPC nodes to operate within TEEs further strengthens this multi-proof system. The DeRoT model distributes trust across the network using TEEs, MPC, and ZKPs. This approach improves the security of dapps that use TEE by addressing potential hardware or node-level threats.

What’s Possible With a Decentralized TEE Cloud?

We are going to dedicate an entire article to this topic because numerous applications already run on Phala. Consequently, this section could be as long as the entire article itself. However, we want to outline the possible use cases for a decentralized TEE cloud.

First, Phala supports the deployment of AI models within TEEs, ensuring secure and autonomous operations that interact with blockchain networks. This includes AI agents for smart contract enhancement and cross-agent interactions. Developers can leverage GPU TEEs for AI computation, achieving genuine censorship resistance and privacy.

Developers can also migrate traditional apps to a secure and trustless environment for enhanced security. The platform enables privacy-preserving data analysis through tools like web3 and traditional analytics, which analyze data without exposing individual user information. Furthermore, it can enhance secure computation for DeFi with privacy features, such as confidential trading positions or dark pool trading. Finally, a decentralized TEE cloud can provide MEV protection by moving block building into a TEE for fair ordering and execution.

There are many products that use Phala as part of their infrastructure. We will take a deeper look at this in another article where we will focus on exactly how completely different products use Phala and what they gain from this integration.

Conclusion

The trust models of Web3 and Web2 fundamentally differ, resulting in distinct limitations for platforms like AWS. In Web3, data (including tokens, which are essentially data) is genuinely owned by users, where application developers are untrusted by default. This lack of trust originates from the potential for developers to attempt unauthorized access, modification, or theft of user data.

This paradigm explains several key practices in Web3:

1. Smart contract code must undergo rigorous review to eliminate backdoors or vulnerabilities.

2. The ownership (or administrative control) of smart contracts is a critical concern, with users prioritizing transparency over allowing developers unrestricted control.

Ideally, in a Web3 environment, developers should write and deploy smart contract code, then relinquish all control, retaining no further privileges over the application.

In contrast to smart contracts, TEEs can enforce similar ownership and control principles across a broader range of programs. However, AWS Nitro Enclaves operate within a Web2 framework, where developers retain the ability to log in, access, and modify data and applications. Phala’s TEE is designed with Web3 principles having native support for smart contracts to govern TEE-based applications having alignment with decentralized trust models.