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的應用，與去中心化信任模型保持一致。