AWS 不适合 Web3：去中心化 TEE 云可提升 10 倍效率
2025-05-28 10:58
Block-1598
每天，人们产生高达 4.02 亿 TB 的敏感数据。随着个体越来越不愿广泛分享数据，对这些数据进行私密计算的需求与日俱增。这些解决方案主要依赖亚马逊网络服务（AWS）的基础设施，其占据了全球云计算市场约 30% 的份额。然而，AWS 存在若干缺点，主要源于其集中式架构。即使通过 AWS Nitro Enclaves 引入了增强的安全计算，仍在开发者采用方面仍面临重大挑战，更对区块链安全和 Web3 应用构成深层障碍。本文将剖析 AWS 的现状，并介绍一种去中心化 TEE 云解决方案，该方案不仅解决了 AWS 的不足，还克服了现有其他 TEE 的局限性。不过，在此之前，我们需要探究 AWS 及其 Nitro Enclaves 产品为何能获得如此高的知名度和市场份额，以及在这些进步背后还存在哪些问题。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 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 并未针对去中心化应用和生态系统进行优化，它缺乏对 Web3 用例或治理系统的原生支持。例如，AWS Nitro Enclaves 缺乏持久存储。虽然这种隔离对安全有益，却限制了如需要在向量数据库中存储用户数据的 AI 代理等用例。密钥管理也不符合“零信任”场景。虽然 AWS 密钥管理服务（KMS）可用，但它专为 Web2 设计，允许管理员访问私钥。这与 Web3 要求密钥必须完全由代码控制且不暴露给任何人（包括管理员）相冲突。Nitro Enclaves 解决了开发者对云的不信任问题，但 Web3 要求在用户、开发者和供应商之间实现无需信任的解决方案。不支持安全代码升级，需要类似智能合约治理的去中心化所有权，而开发者必须从头开始构建，这可能需要数月时间，且如果实施不当，代码可能存在漏洞。由于缺乏网络访问，设置 Web 服务耗时耗力，迫使开发者编写大量代码来适应应用并确保加密安全，而这往往并不完美。我们使用 TEE 是因为我们无法完全信任开发者或管理员。Web3 参与者并持不同理念，并追求使用无需信任的系统：如果某物必须被信任，那么它看起来就不太可靠。这就是为什么用户依赖硬件运营商来检查和管理应用。应用可以被分离，以防止它们在内存访问期间干扰或抓取或更改敏感数据，因为加密依赖于 CPU 和外部设备之间的顺畅协作。用户和数据提供者需要对其数据执行的操作有明确的保证和验证。在开发 Phala Network 时，我们的初衷是结合 AWS 的优势与 TEE 的安全性，通过去中心化消除复杂性，同时增强安全性。这种方法旨在满足 Web3 用例的需求。其结果是我们提出了去中心化 TEE 云的概念，为去中心化应用提供安全性和集成性。要理解去中心化 TEE 云的概念，首先必须定义什么是去中心化云。那么，它是什么呢？去中心化云是一种计算基础设施，其中数据存储、处理和管理分布在多个节点的网络中，而不是集中在单个中央服务器或数据中心。与 AWS 等传统的集中式云系统不同，去中心化云无需单一控制实体，而是依赖区块链来运作。去中心化 TEE 云是一种将 TEE 与去中心化节点网络相结合的计算基础设施，以提供安全、私密且可验证的计算。每个节点都配备了 TEE，以保护敏感代码和数据免受节点运营商的访问或篡改。Phala Network 由一个去中心化的工作节点网络组成，每个节点都配备了 TEE。这些节点根据客户需求为用户执行计算任务，如运行智能合约或处理敏感数据。该过程始于用户将其应用或任务部署到网络上。计算任务在这些节点的 TEE 内执行，确保代码和数据保持机密性，甚至节点运营商也无法查看或篡改它们。Phala 使用密码学证明来验证 TEE 内的计算是否正确执行。节点运营商因提供诚实和安全的服务而获得奖励，通过经济激励维护网络的完整性。虽然这听起来很简单，但实施这一解决方案远比看起来复杂。TEE 本身并非中心化或去中心化，其中心化程度取决于在系统中的实施和部署方式。TEE 是处理器内的一个安全隔离区域，旨在保护敏感代码和数据免受同一设备上的操作系统或其他进程的未经授权访问。TEE 是在中心化还是去中心化模式下运行，取决于其所在的更广泛系统的架构。历史上，创建集中式系统比创建去中心化系统更简单，因为后者在实施和节点通信方面面临挑战。在 Phala Cloud 之前，我们已成功创建了完全去中心化的 Phala Network 1.0（SGX）。现在正在以同样理念开发 Phala Cloud，尽管这需要时间。Phala 是目前唯一一个将 TEE 与完全去中心化相结合的平台，不同于中心化提供商或部分去中心化协议。去中心化和 TEE 的优势显而易见，但在产品开发中仍不足够。试想阿里巴巴是全球最大的电子商务平台，占据了巨大的市场份额。若一款新产品以两倍的功能和更低的价格推出，它会占据整个市场吗？遗憾的是，不会，因为人们已经习惯了现有产品，即使新产品更好，也会对其存在偏见。这是我们面临的挑战之一，但我们不追求两倍的改进，而是确保 Phala 比竞争对手好十倍且用户友好。此外，如前所述，AWS 不适合 Web3 环境，我们旨在为 Web3 应用和开发者填补这一空白。除了去中心化这一明显优势，我们还想强调 Phala 与 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 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 的安全性。我们将专门撰写一篇文章来探讨这一主题，因为已有许多应用在 Phala 上运行。因此，这一部分可能与整篇文章一样长。但我们希望概述去中心化 TEE 云的可能用例。首先，Phala 支持在 TEE 内部署 AI 模型，确保与区块链网络交互的安全和自主操作。这包括用于智能合约增强和跨代理交互的 AI 代理。开发者可以利用 GPU TEE 进行 AI 计算，实现真正的抗审查和隐私保护。开发者还可以将传统应用迁移到安全且无需信任的环境中，以提高安全性。该平台通过 Web3 和传统分析工具实现隐私保护的数据分析，这些工具可以在不暴露单个用户信息的情况下分析数据。此外，它还可以通过隐私功能增强 DeFi 的安全计算，如保密交易头寸或暗池交易。最后，去中心化 TEE 云可以通过将区块构建移入 TEE 来实现 MEV 保护，以实现公平排序和执行。有许多产品将 Phala 作为其基础设施的一部分。我们将在另一篇文章中深入探讨这些产品如何使用 Phala 以及它们从这种集成中获得了什么。Web3 和 Web2 的信任模型存在根本差异，这导致 AWS 等平台存在局限性。在 Web3 中，数据（包括本质上属于数据的通证）真正由用户拥有，而应用开发者默认不受信任。这种不信任源于开发者可能尝试未经授权访问、修改或窃取用户数据的潜力。1.智能合约代码必须经过严格审查，以消除后门或漏洞。智能合约的所有权（或管理控制）是关键问题，用户更重视透明度，而不是允许开发者拥有不受限制的控制权。2.理想情况下，在 Web3 环境中，开发者应编写并部署智能合约代码，然后放弃所有控制权，不再对应用保留任何特权。与智能合约不同，TEE 可以在更广泛的程序范围内执行类似的所有权和控制原则。然而，AWS Nitro Enclaves 在 Web2 框架内运行，其中开发者保留登录、访问和修改数据和应用的能力。Phala 的 TEE 是根据 Web3 原则设计的，原生支持智能合约来管理基于 TEE 的应用，与去中心化信任模型保持一致。原文来源于 Phala Network，由区块链骑士编译整理，英文版权归原作者所有，中文转载请联系编辑。声明：本文内容仅供学习交流，不构成任何投资建议。
来个“点赞、分享、推荐”👇
【免责声明】市场有风险，投资需谨慎。本文不构成投资建议，用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。
