AWS is not suitable for Web3: Decentralization TEE cloud can improve efficiency by 10 times.

Every day, people generate up to 402 million TB of sensitive data. As individuals become increasingly unwilling to share data widely, the demand for private computation of this data is growing day by day. These solutions mainly rely on the infrastructure of Amazon Web Services (AWS), which occupies about 30% of the global cloud computing market.

However, AWS has several drawbacks, mainly stemming from its centralized architecture. Even with the introduction of enhanced secure computing through AWS Nitro Enclaves, there are still significant challenges in adoption among developers, which poses deep obstacles to blockchain security and Web3 applications.

This article will analyze the current status of AWS and introduce a decentralized TEE cloud solution that not only addresses the shortcomings of AWS but also overcomes the limitations of existing TEE solutions. However, before that, we need to explore why AWS and its Nitro Enclaves product have gained such high visibility and market share, as well as what issues still remain behind these advancements.

AWS Nitro and TEE

AWS is currently the most popular cloud computing platform, offering a rich set of tools. In a nutshell, AWS is essentially cloud infrastructure for all of a developer's computing needs, including compute, storage, and database services. As we all know, AWS accounts for about 30% of the cloud infrastructure market share, which is quite a sizable percentage. Nearly 48% of software engineers or developers use AWS in some way, so it's in high demand.

As the demand and customer base expand, including large financial institutions, government agencies, and startups that possess highly sensitive data, concerns have been raised about the security of AWS and whether these entities can safely store and use this data for confidential computing.

Against this backdrop, AWS conceived the idea of implementing TEE on its platform to protect data in use, complementing the encryption of static data and data in transit.

This new solution integrating TEE is called AWS Nitro Enclaves, which provides a hardware-supported isolated execution environment. TEE establishes a secure environment within Amazon EC2 instances, eliminating interactive access, persistent storage, and external network connections. This isolation minimizes the attack surface by separating sensitive workloads from the parent EC2 instance, its operators, and other software.

However, Nitro Enclaves are created and managed entirely within AWS's EC2 service, belonging to a highly centralized framework. From creation to termination, all aspects of Enclave management are controlled by AWS's infrastructure, which is essentially centralized given AWS's nature as a centralized cloud provider.

In short, AWS Nitro Enclaves provides strong isolation through a hardware-based trusted execution environment to protect sensitive workloads. However, its centralized architecture introduces certain limitations and trade-offs.

Limitations Beyond AWS Centralization

In addition to the centralized drawbacks of relying on a single system for all components and data, AWS Nitro Enclaves also brings more challenges and new security considerations. AWS connects multiple Nitro cards (custom hardware) to the CPU to run TEE workloads, which creates dual security risks: vulnerabilities may exist in both the underlying CPU and the Nitro cards.

A significant issue with Nitro Enclaves is the lack of a robust memory encryption mechanism. Unlike solutions that integrate memory encryption directly into the CPU, the external nature of the Nitro card makes it difficult to ensure end-to-end encryption of data in memory. This configuration may expose sensitive information to tampering during memory access, as encryption relies on interactions between the CPU and external devices.

In addition, developers still need to create and configure an Amazon Machine Image (AMI) that includes Enclave software using Docker, which can be challenging for those unfamiliar with containerization. They also need to use the AWS CLI and Nitro Enclaves CLI to launch instances and manage Enclaves, navigate the Nitro Enclaves API, and integrate with AWS Key Management Services, which sometimes requires an understanding of the cryptographic proof process.

The reliance of TEE on the Nitro card leads to unverifiable proofs, as the measurement of code integrity comes from the Nitro card rather than the CPU itself.

AWS trusts developers and administrators to set identity and access management policies, which may allow them to access sensitive data. Their elevated access rights pose a risk of internal threats, as they may view or tamper with data.

Examination of the Trust Assumptions of AWS Nitro

However, the most significant limitation is that AWS has not been optimized for decentralized applications and ecosystems, lacking 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 need to store user data in a vector database.

Key management also does not fit into the "zero trust" scenario. While AWS Key Management Service (KMS) is available, it is designed for Web2 and allows administrators to access private keys. This conflicts with Web3's requirement that keys must be fully code-controlled and not exposed to anyone, including administrators.

Nitro Enclaves addresses developers' trust issues with the cloud, but Web3 requires trustless solutions among users, developers, and providers. It does not support secure code upgrades, necessitating decentralized ownership similar to smart contract governance, and developers must build from scratch, which can take months, and if implemented incorrectly, the code may have vulnerabilities.

Due to the lack of network access, setting up web services is time-consuming and labor-intensive, forcing developers to write a lot of code to adapt the application and ensure encryption security, which is often not perfect.

Why does Web3 need TEE?

We use TEE because we cannot fully trust developers or administrators. Web3 participants have different philosophies and strive for trustless systems: if something must be trusted, it appears to be less reliable. This is why users rely on hardware operators to check and manage applications. Applications can be isolated to prevent them from interfering with, scraping, or altering sensitive data during memory access, as encryption relies on smooth cooperation between the CPU and external devices. Users and data providers need clear guarantees and validations regarding the operations performed on their data.

When developing Phala Network, our original intention was to combine the advantages of AWS with the security of TEE, eliminating complexity through decentralization while enhancing security. This approach aims to meet the needs of Web3 use cases. The result is the concept of decentralized TEE cloud, providing security and integration for decentralized applications.

Create a decentralized TEE cloud

To understand the concept of decentralized TEE cloud, we must first define what decentralized cloud is. So, what is it?

Decentralized cloud is a computing infrastructure where data storage, processing, and management are distributed across a network of multiple nodes, rather than being centralized in a single central server or data center. Unlike traditional centralized cloud systems such as AWS, decentralized cloud does not require a single controlling entity but relies on blockchain to operate.

Decentralized TEE Cloud

Decentralized TEE cloud is a computing infrastructure that combines TEE with a decentralized node network to provide secure, private, and verifiable computing. Each node is equipped with TEE to protect sensitive code and data from access or tampering by the node operators.

Phala Network consists of a decentralized network of worker nodes, each equipped with a TEE. These nodes perform computational tasks for users based on client requirements, such as executing smart contracts or processing sensitive data.

The process begins with users deploying their applications or tasks onto the network. Computational tasks are executed within the TEE of these nodes, ensuring that code and data remain confidential, even node operators cannot view or tamper with them.

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

Why is it so difficult to create a decentralized TEE cloud?

TEE itself is neither centralized nor decentralized; its degree of centralization depends on how it is implemented and deployed within the system. TEE is a secure isolated area within the processor, designed to protect sensitive code and data from unauthorized access by the operating system or other processes on the same device. Whether TEE operates in a centralized or decentralized mode depends on the architecture of the broader system in which it resides.

Historically, creating centralized systems has been simpler than creating decentralized systems, as the latter faces challenges in implementation and node communication. Before Phala Cloud, we successfully created the fully decentralized Phala Network 1.0 (SGX). We are now developing Phala Cloud with the same philosophy, although it takes time. Phala is currently the only platform that combines TEE with full decentralization, unlike centralized providers or partially decentralized protocols.

The advantages of decentralization and TEE are obvious, but they are still not enough in product development. Imagine Alibaba as the largest e-commerce platform in the world, holding a huge market share. If a new product is launched with double the functionality and at a lower price, will it dominate the entire market? Unfortunately, no, because people have already become accustomed to the existing products, and even if the new product is better, there will still be bias against its existence.

This was one of the challenges we faced, but instead of going for twice as much improvement, we made sure that the Phala, which was ten times better than the competition, was user-friendly. In addition, as mentioned earlier, AWS is not suitable for the Web3 environment, and we aim to fill this gap for Web3 applications and developers. In addition to the obvious advantage of decentralization, we also want to highlight other differences between Phala and AWS.

Phala Cloud and AWS

First of all, the setup process for AWS Nitro Enclaves is complex. It involves multiple steps, including installing the Nitro CLI, converting Docker images into Enclave files, and handling file transfers, all of which are very time-consuming.

In contrast, Phala allows developers to deploy with "instant migration and modification" and easily migrate existing Docker containers into a secure TEE. Using the Dstack SDK, developers only need to make minimal changes to convert Docker containers into Confidential VMs and deploy them through a user-friendly Cloud UI, while still supporting 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 TEE for isolated computing, its centralized infrastructure requires trust in AWS and the personnel managing the system, which may lead to sensitive data being accessed. Phala adopts a zero-trust model, defaulting to not trusting any party. Sensitive data remains secure within the TEE, and even node operators cannot access it, making it suitable for Web3 applications that require trustless operations.

From a product perspective, AWS primarily serves enterprise clients, as there are numerous companies in the traditional IT sector. Therefore, it does not fully align with the value propositions of Web3 startups in terms of products and technology. In contrast, Phala is built specifically for decentralized applications. It natively supports AI agents that interact with blockchain smart contracts and privacy-preserving DApps.

In addition, Phala has deeply integrated into the blockchain ecosystem through partnerships with various protocols and the integration of DApps that wish to leverage TEE security.

Phala is positioned as the execution layer of Web3 AI, enabling developers to build, launch, and monetize AI agents that can understand and interact with blockchain smart contracts securely and privately. We support decentralized AI platforms such as NEAR AI and Sentient by leveraging NVIDIA GPU TEE to run large language models (LLMs) in a secure, verifiable, and privacy-focused environment. For example, our partnership with NOTAI highlights the zero-trust enforcement of AI agents, where we provide trustless and privacy protection through TEE and RA Explorer.

We also support the integration of non-AI related applications 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 TEE and other secure computing methods, how does Phala differentiate itself from these solutions?

Phala Cloud and TEE solutions

Phala Network stands out as the only fully decentralized TEE cloud, providing secure, private, and verifiable computing for DApps. Unlike Oasis Protocol and Secret Network, which focus on using TEE to enable privacy in smart contracts on their respective blockchains, Phala offers a decentralized cloud computing platform for offline computation across networks.

Phala is flexible and customizable, utilizing a wide range of TEE hardware, including Intel SGX, Intel TDX, AMD SEV, and NVIDIA GPU TEE. The Marlin Protocol enhances the network performance of Web3 but does not provide computing or privacy capabilities, while Oasis and Secret operate within specific blockchain ecosystems. Phala, as the only decentralized TEE cloud with extensive hardware support and developer-centric tools like Dstack, has unique advantages.

Phala is different in that 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 an AI model, web server, or database, in a secure environment. This is made possible through Phat Contracts and Phala Cloud, which supports Dockerized deployments and provides one-click access to CPU and GPU TEE.

In addition, there are many comparisons regarding which is more suitable for specific use cases: TEE or Multi-Party Computation (MPC). In our view, TEE and MPC are not competitors but complementary partners.

Phala integrates TEE with MPC to create a decentralized Root of Trust (DeRoT) model, an advanced approach for securing TEE-based applications. MPC operates within the TEE to reduce the risk of node collusion, while TEE block proofs are submitted with MPC proofs to mitigate errors in zero-knowledge proofs (ZKP) implementations. This multi-attestation system is further enhanced by the requirement for MPC nodes to operate within the TEE. The DeRoT model uses TEE, MPC, and ZKP to distribute trust in the network. This approach improves the security of DApps using TEEs by addressing potential hardware or node-level threats.

The potential of decentralized TEE cloud

We will specifically write an article to explore this topic, as there are already many applications running on Phala. Therefore, this section may be as long as the entire article. But we hope to outline the potential use cases of decentralized TEE cloud.

First, Phala supports deploying AI models within TEE to ensure secure and autonomous operations when interacting with the blockchain network. This includes AI agents for enhancing smart contracts and cross-agent interactions. Developers can leverage GPU TEE for AI computations, achieving true censorship resistance and privacy protection.

Developers can also migrate traditional applications to a secure and trustless environment to enhance security. The platform achieves privacy-preserving data analysis through Web3 and traditional analytical tools that can analyze data without exposing individual user information. Additionally, it can enhance the secure computations of DeFi through privacy features such as confidential trading positions or dark pool trading. Finally, the decentralized TEE cloud can achieve MEV protection by moving block construction into the TEE for fair ordering and execution.

Many products use Phala as part of their infrastructure. We will explore in another article how these products utilize Phala and what they gain from this integration.

Conclusion

The trust models of Web3 and Web2 have fundamental differences, which leads to limitations for platforms like AWS. In Web3, data (including tokens that essentially belong to the data) is truly owned by users, and application developers are assumed to be untrusted by default. This distrust arises 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.

The ownership (or management control) of smart contracts is a key issue; users value transparency more than allowing developers to have unrestricted control.

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

Unlike smart contracts, TEE can execute 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 according to Web3 principles, natively supporting smart contracts to manage TEE-based applications, in line with a decentralized trust model.