AWS不适合Web3：去中心化TEE云可提升10倍效率

每天，人们产生高达4.02亿TB的敏感数据。随着个体越来越不愿广泛分享数据，对这些数据进行私密计算的需求与日俱增。这些解决方案主要依赖亚马逊网络服务（AWS）的基础设施，其占据了全球云计算市场约30%的份额。

然而，AWS存在若干缺点，主要源于其集中式架构。即使通过AWS Nitro Enclaves引入了增强的安全计算，仍在开发者采用方面仍面临重大挑战，更对区块链安全和Web3应用构成深层障碍。

本文将剖析AWS的现状，并介绍一种去中心化TEE云解决方案，该方案不仅解决了AWS的不足，还克服了现有其他TEE的局限性。不过，在此之前，我们需要探究AWS及其Nitro Enclaves产品为何能获得如此高的知名度和市场份额，以及在这些进步背后还存在哪些问题。

AWS Nitro与TEE

AWS是目前最受欢迎的云计算平台，提供了一系列丰富的工具。简而言之，AWS本质上是满足开发者所有计算需求的云基础设施，包括计算、存储和数据库服务等。众所周知，AWS占据了约30%的云基础设施市场份额，这一比例相当可观。在软件工程师或开发者中，有近48%的人以某种方式使用AWS，因此其需求量巨大。

随着需求和客户群的扩大，包括拥有高度敏感数据的大型金融机构、政府机构和初创企业，人们对AWS的安全性和这些实体能否安全地存储和使用这些数据进行保密计算提出了质疑。

正是在这一背景下，AWS萌生了在其平台上实施TEE以保护使用中的数据的想法，以补充对静态数据和传输中数据的加密。

这种集成TEE的新解决方案被称为AWS Nitro Enclaves，它提供了一个硬件支持的隔离执行环境。TEE在Amazon EC2实例内建立了安全环境，消除了交互式访问、持久存储和外部网络连接。这种隔离通过将敏感工作负载与父EC2实例、其操作员和其他软件分离，最大限度减少攻击面。

然而，Nitro Enclaves完全在AWS的EC2服务内创建和管理，属于高度中心化的框架。从创建到终止，Enclave管理的所有方面都由AWS的基础设施控制，鉴于AWS作为集中式云提供商的性质，这本质上是中心化的。

简而言之，AWS Nitro Enclaves通过基于硬件的可信执行环境提供了强大的隔离，以保护敏感工作负载。然而，其集中式架构引入了某些局限性和权衡。

AWS中心化之外的局限性

除了所有组件和数据依赖单一系统的中心化弊端外，AWS Nitro Enclaves还带来了更多挑战和新的安全考量。AWS将多个Nitro卡（定制硬件）连接到CPU上以运行TEE有效负载，这产生了双重安全风险：底层CPU和Nitro卡都可能出现漏洞。

Nitro Enclaves的一个重大问题是缺乏完善的内存加密机制。与内存加密直接集成到CPU中的解决方案不同，Nitro卡的外部性质使得难以确保内存中数据的端到端加密。这种配置可能会在内存访问期间暴露敏感信息以供篡改，因为加密依赖于CPU与外部设备之间的交互。

除此之外，开发者仍需使用Docker创建和配置包含Enclave软件的Amazon机器映像（AMI），这对于不熟悉容器化的人来说可能很困难。他们还需要使用AWS CLI和Nitro Enclaves CLI来启动实例和管理Enclave，导航Nitro Enclaves API，并与AWS密钥管理服务集成，这有时需要了解加密证明过程。

TEE对Nitro卡的依赖导致了不可验证的证明，因为代码完整性的测量来源于Nitro卡，而非CPU本身。

AWS信任开发者和管理员来设置身份和访问管理策略，这可能使他们能够访问敏感数据。他们的高级访问权限产生了内部威胁风险，因为他们可能查看或篡改数据。

AWS Nitro的信任假设审视

然而，最重大的局限性在于AWS并未针对去中心化应用和生态系统进行优化，它缺乏对Web3用例或治理系统的原生支持。

例如，AWS Nitro Enclaves缺乏持久存储。虽然这种隔离对安全有益，却限制了如需要在向量数据库中存储用户数据的AI代理等用例。

密钥管理也不符合“零信任”场景。虽然AWS密钥管理服务（KMS）可用，但它专为Web2设计，允许管理员访问私钥。这与Web3要求密钥必须完全由代码控制且不暴露给任何人（包括管理员）相冲突。

Nitro Enclaves解决了开发者对云的不信任问题，但Web3要求在用户、开发者和供应商之间实现无需信任的解决方案。不支持安全代码升级，需要类似智能合约治理的去中心化所有权，而开发者必须从头开始构建，这可能需要数月时间，且如果实施不当，代码可能存在漏洞。

由于缺乏网络访问，设置Web服务耗时耗力，迫使开发者编写大量代码来适应应用并确保加密安全，而这往往并不完美。

为什么Web3需要TEE？

我们使用TEE是因为我们无法完全信任开发者或管理员。Web3参与者并持不同理念，并追求使用无需信任的系统：如果某物必须被信任，那么它看起来就不太可靠。这就是为什么用户依赖硬件运营商来检查和管理应用。应用可以被分离，以防止它们在内存访问期间干扰或抓取或更改敏感数据，因为加密依赖于CPU和外部设备之间的顺畅协作。用户和数据提供者需要对其数据执行的操作有明确的保证和验证。

在开发Phala Network时，我们的初衷是结合AWS的优势与TEE的安全性，通过去中心化消除复杂性，同时增强安全性。这种方法旨在满足Web3用例的需求。其结果是我们提出了去中心化TEE云的概念，为去中心化应用提供安全性和集成性。

创建去中心化TEE云

要理解去中心化TEE云的概念，首先必须定义什么是去中心化云。那么，它是什么呢？

去中心化云是一种计算基础设施，其中数据存储、处理和管理分布在多个节点的网络中，而不是集中在单个中央服务器或数据中心。与AWS等传统的集中式云系统不同，去中心化云无需单一控制实体，而是依赖区块链来运作。

去中心化TEE云

去中心化TEE云是一种将TEE与去中心化节点网络相结合的计算基础设施，以提供安全、私密且可验证的计算。每个节点都配备了TEE，以保护敏感代码和数据免受节点运营商的访问或篡改。

Phala Network由一个去中心化的工作节点网络组成，每个节点都配备了TEE。这些节点根据客户需求为用户执行计算任务，如运行智能合约或处理敏感数据。

该过程始于用户将其应用或任务部署到网络上。计算任务在这些节点的TEE内执行，确保代码和数据保持机密性，甚至节点运营商也无法查看或篡改它们。

Phala使用密码学证明来验证TEE内的计算是否正确执行。节点运营商因提供诚实和安全的服务而获得奖励，通过经济激励维护网络的完整性。虽然这听起来很简单，但实施这一解决方案远比看起来复杂。

为什么创建去中心化TEE云如此困难？

TEE本身并非中心化或去中心化，其中心化程度取决于在系统中的实施和部署方式。TEE是处理器内的一个安全隔离区域，旨在保护敏感代码和数据免受同一设备上的操作系统或其他进程的未经授权访问。TEE是在中心化还是去中心化模式下运行，取决于其所在的更广泛系统的架构。

历史上，创建集中式系统比创建去中心化系统更简单，因为后者在实施和节点通信方面面临挑战。在Phala Cloud之前，我们已成功创建了完全去中心化的Phala Network 1.0（SGX）。现在正在以同样理念开发Phala Cloud，尽管这需要时间。Phala是目前唯一一个将TEE与完全去中心化相结合的平台，不同于中心化提供商或部分去中心化协议。

去中心化和TEE的优势显而易见，但在产品开发中仍不足够。试想阿里巴巴是全球最大的电子商务平台，占据了巨大的市场份额。若一款新产品以两倍的功能和更低的价格推出，它会占据整个市场吗？遗憾的是，不会，因为人们已经习惯了现有产品，即使新产品更好，也会对其存在偏见。

这是我们面临的挑战之一，但我们不追求两倍的改进，而是确保Phala比竞争对手好十倍且用户友好。此外，如前所述，AWS不适合Web3环境，我们旨在为Web3应用和开发者填补这一空白。除了去中心化这一明显优势，我们还想强调Phala与AWS的其他差异。

Phala Cloud与AWS

首先，AWS为Nitro Enclaves的设置过程复杂。这涉及多个步骤，包括安装Nitro CLI、将Docker镜像转换为Enclave文件以及处理文件传输，这些都非常耗时。

相比之下，Phala允许开发者“即迁即改”部署，并轻松将现有的Docker容器迁移到安全的TEE中。使用Dstack SDK，开发者只需进行最小更改即可将Docker容器转换为保密虚拟机（Confidential VM），并通过户友好的Cloud UI进行部署，同时仍支持模板和自定义Docker Compose文件。

在安全性方面，AWS依赖于信任开发者和管理员来正确配置访问控制和管理资源。尽管AWS使用TEE进行隔离计算，但其集中式基础设施要求信任AWS和管理系统的人员，这可能导致敏感数据被访问。Phala采用零信任模型，默认不信任任何一方。敏感数据在TEE内保持安全，甚至节点运营商也无法访问，因此适合需要无需信任操作的Web3应用。

从产品角度来看，AWS主要服务于企业客户，因为传统IT领域的企业数量众多。因此，它在产品和技术方面并未完全符合Web3初创企业的价值主张。相比之下，Phala专为去中心化应用而构建。它原生支持与区块链智能合约交互的AI代理以及隐私保护的DApp。

此外，Phala通过与各种协议的合作伙伴关系以及对希望利用TEE安全性的DApp的集成，深度融入了区块链生态系统。

Phala定位为Web3 AI的执行层，使开发者能够构建、启动并从能够安全且私密地理解和与区块链智能合约交互的AI代理中获利。我们通过利用NVIDIA GPU TEE在安全、可验证且注重隐私的环境中运行大型语言模型（LLM），支持NEAR AI和Sentient等去中心化AI平台。例如，我们与NOTAI的合作伙伴关系突出了AI代理的零信任执行，其中我们通过TEE和RA Explorer提供无需信任和隐私保护。

我们还通过Phat Contracts支持与非AI相关的应用集成，这些是具有原生HTTP请求支持的低成本、低延迟智能合约。

然而，鉴于许多加密原生团队也在构建TEE和其他安全计算方法，Phala如何与这些解决方案区分开来呢？

Phala Cloud与TEE解决方案

Phala Network作为唯一一个完全去中心化的TEE云脱颖而出，为DApp提供安全、私密且可验证的计算。与Oasis Protocol和Secret Network不同，后者专注于在其各自的区块链中使用TEE实现隐私启用的智能合约，而Phala提供了一个跨网络的离线计算去中心化云计算平台。

Phala灵活且可定制，利用广泛的TEE硬件，包括Intel SGX、Intel TDX、AMD SEV和NVIDIA GPU TEE。Marlin Protocol增强了Web3的网络性能，但不提供计算或隐私功能，而Oasis和Secret则在特定的区块链生态系统中运行。Phala作为唯一具有广泛硬件支持和Dstack等开发者中心工具的去中心化TEE云，具有独特优势。

Phala的不同之处在于它提供了一个通用的去中心化TEE云，与专注于特定用例的Oasis Protocol、Marlin和Secret Network不同。Phala允许开发者在安全环境中部署任何应用，如AI模型、Web服务器或数据库。这是通过Phat Contracts和Phala Cloud实现的，后者支持Docker化部署，并可一键访问CPU和GPU TEE。

此外，关于TEE或多方计算（MPC）哪个更适合特定用例的比较很多。在我们看来，TEE和MPC并非竞争对手，而是互补的伙伴。

Phala将TEE与MPC集成，以创建去中心化信任根（DeRoT）模型，这是一种用于保护基于TEE的应用的先进方法。MPC在TEE内运行，以减少节点共谋风险，同时TEE块证明与MPC证明一起提交，以减轻零知识证明（ZKP）实现中的错误。要求MPC节点在TEE内运行进一步增强了这一多证明系统。DeRoT模型使用TEE、MPC和ZKP在网络中分配信任。这种方法通过解决潜在的硬件或节点级威胁，提高了使用TEE的DApp的安全性。

去中心化TEE云的可能性

我们将专门撰写一篇文章来探讨这一主题，因为已有许多应用在Phala上运行。因此，这一部分可能与整篇文章一样长。但我们希望概述去中心化TEE云的可能用例。

首先，Phala支持在TEE内部署AI模型，确保与区块链网络交互的安全和自主操作。这包括用于智能合约增强和跨代理交互的AI代理。开发者可以利用GPU TEE进行AI计算，实现真正的抗审查和隐私保护。

开发者还可以将传统应用迁移到安全且无需信任的环境中，以提高安全性。该平台通过Web3和传统分析工具实现隐私保护的数据分析，这些工具可以在不暴露单个用户信息的情况下分析数据。此外，它还可以通过隐私功能增强DeFi的安全计算，如保密交易头寸或暗池交易。最后，去中心化TEE云可以通过将区块构建移入TEE来实现MEV保护，以实现公平排序和执行。

有许多产品将Phala作为其基础设施的一部分。我们将在另一篇文章中深入探讨这些产品如何使用Phala以及它们从这种集成中获得了什么。

结论

Web3和Web2的信任模型存在根本差异，这导致AWS等平台存在局限性。在Web3中，数据（包括本质上属于数据的通证）真正由用户拥有，而应用开发者默认不受信任。这种不信任源于开发者可能尝试未经授权访问、修改或窃取用户数据的潜力。

这种范式解释了Web3中的几个关键实践：

1.智能合约代码必须经过严格审查，以消除后门或漏洞。

智能合约的所有权（或管理控制）是关键问题，用户更重视透明度，而不是允许开发者拥有不受限制的控制权。

2.理想情况下，在Web3环境中，开发者应编写并部署智能合约代码，然后放弃所有控制权，不再对应用保留任何特权。

与智能合约不同，TEE可以在更广泛的程序范围内执行类似的所有权和控制原则。然而，AWS Nitro Enclaves在Web2框架内运行，其中开发者保留登录、访问和修改数据和应用的能力。Phala的TEE是根据Web3原则设计的，原生支持智能合约来管理基于TEE的应用，与去中心化信任模型保持一致。