(1).png)
每天，人們產(chǎn)生高達(dá)4.02億TB的敏感數(shù)據(jù)。隨著個體越來越不愿廣泛分享數(shù)據(jù)，對這些數(shù)據(jù)進(jìn)行私密計算的需求與日俱增。這些解決方案主要依賴亞馬遜網(wǎng)絡(luò)服務(wù)（AWS）的基礎(chǔ)設(shè)施，其占據(jù)了全球云計算市場約30%的份額。
然而，AWS存在若干缺點，主要源于其集中式架構(gòu)。即使通過AWS Nitro Enclaves引入了增強的安全計算，仍在開發(fā)者采用方面仍面臨重大挑戰(zhàn)，更對區(qū)塊鏈安全和Web3應(yīng)用構(gòu)成深層障礙。
本文將剖析AWS的現(xiàn)狀，并介紹一種去中心化TEE云解決方案，該方案不僅解決了AWS的不足，還克服了現(xiàn)有其他TEE的局限性。不過，在此之前，我們需要探究AWS及其Nitro Enclaves產(chǎn)品為何能獲得如此高的知名度和市場份額，以及在這些進(jìn)步背后還存在哪些問題。
AWS Nitro與TEE
AWS是目前最受歡迎的云計算平臺，提供了一系列豐富的工具。簡而言之，AWS本質(zhì)上是滿足開發(fā)者所有計算需求的云基礎(chǔ)設(shè)施，包括計算、存儲和數(shù)據(jù)庫服務(wù)等。眾所周知，AWS占據(jù)了約30%的云基礎(chǔ)設(shè)施市場份額，這一比例相當(dāng)可觀。在軟件工程師或開發(fā)者中，有近48%的人以某種方式使用AWS，因此其需求量巨大。
隨著需求和客戶群的擴(kuò)大，包括擁有高度敏感數(shù)據(jù)的大型金融機構(gòu)、政府機構(gòu)和初創(chuàng)企業(yè)，人們對AWS的安全性和這些實體能否安全地存儲和使用這些數(shù)據(jù)進(jìn)行保密計算提出了質(zhì)疑。
正是在這一背景下，AWS萌生了在其平臺上實施TEE以保護(hù)使用中的數(shù)據(jù)的想法，以補充對靜態(tài)數(shù)據(jù)和傳輸中數(shù)據(jù)的加密。
這種集成TEE的新解決方案被稱為AWS Nitro Enclaves，它提供了一個硬件支持的隔離執(zhí)行環(huán)境。TEE在Amazon EC2實例內(nèi)建立了安全環(huán)境，消除了交互式訪問、持久存儲和外部網(wǎng)絡(luò)連接。這種隔離通過將敏感工作負(fù)載與父EC2實例、其操作員和其他軟件分離，最大限度減少攻擊面。
然而，Nitro Enclaves完全在AWS的EC2服務(wù)內(nèi)創(chuàng)建和管理，屬于高度中心化的框架。從創(chuàng)建到終止，Enclave管理的所有方面都由AWS的基礎(chǔ)設(shè)施控制，鑒于AWS作為集中式云提供商的性質(zhì)，這本質(zhì)上是中心化的。
簡而言之，AWS Nitro Enclaves通過基于硬件的可信執(zhí)行環(huán)境提供了強大的隔離，以保護(hù)敏感工作負(fù)載。然而，其集中式架構(gòu)引入了某些局限性和權(quán)衡。
AWS中心化之外的局限性
除了所有組件和數(shù)據(jù)依賴單一系統(tǒng)的中心化弊端外，AWS Nitro Enclaves還帶來了更多挑戰(zhàn)和新的安全考量。AWS將多個Nitro卡（定制硬件）連接到CPU上以運行TEE有效負(fù)載，這產(chǎn)生了雙重安全風(fēng)險：底層CPU和Nitro卡都可能出現(xiàn)漏洞。
Nitro Enclaves的一個重大問題是缺乏完善的內(nèi)存加密機制。與內(nèi)存加密直接集成到CPU中的解決方案不同，Nitro卡的外部性質(zhì)使得難以確保內(nèi)存中數(shù)據(jù)的端到端加密。這種配置可能會在內(nèi)存訪問期間暴露敏感信息以供篡改，因為加密依賴于CPU與外部設(shè)備之間的交互。
除此之外，開發(fā)者仍需使用Docker創(chuàng)建和配置包含Enclave軟件的Amazon機器映像（AMI），這對于不熟悉容器化的人來說可能很困難。他們還需要使用AWS CLI和Nitro Enclaves CLI來啟動實例和管理Enclave，導(dǎo)航Nitro Enclaves API，并與AWS密鑰管理服務(wù)集成，這有時需要了解加密證明過程。
TEE對Nitro卡的依賴導(dǎo)致了不可驗證的證明，因為代碼完整性的測量來源于Nitro卡，而非CPU本身。
AWS信任開發(fā)者和管理員來設(shè)置身份和訪問管理策略，這可能使他們能夠訪問敏感數(shù)據(jù)。他們的高級訪問權(quán)限產(chǎn)生了內(nèi)部威脅風(fēng)險，因為他們可能查看或篡改數(shù)據(jù)。
AWS Nitro的信任假設(shè)審視
然而，最重大的局限性在于AWS并未針對去中心化應(yīng)用和生態(tài)系統(tǒng)進(jìn)行優(yōu)化，它缺乏對Web3用例或治理系統(tǒng)的原生支持。
例如，AWS Nitro Enclaves缺乏持久存儲。雖然這種隔離對安全有益，卻限制了如需要在向量數(shù)據(jù)庫中存儲用戶數(shù)據(jù)的AI代理等用例。
密鑰管理也不符合“零信任”場景。雖然AWS密鑰管理服務(wù)（KMS）可用，但它專為Web2設(shè)計，允許管理員訪問私鑰。這與Web3要求密鑰必須完全由代碼控制且不暴露給任何人（包括管理員）相沖突。
Nitro Enclaves解決了開發(fā)者對云的不信任問題，但Web3要求在用戶、開發(fā)者和供應(yīng)商之間實現(xiàn)無需信任的解決方案。不支持安全代碼升級，需要類似智能合約治理的去中心化所有權(quán)，而開發(fā)者必須從頭開始構(gòu)建，這可能需要數(shù)月時間，且如果實施不當(dāng)，代碼可能存在漏洞。
由于缺乏網(wǎng)絡(luò)訪問，設(shè)置Web服務(wù)耗時耗力，迫使開發(fā)者編寫大量代碼來適應(yīng)應(yīng)用并確保加密安全，而這往往并不完美。
為什么Web3需要TEE？
我們使用TEE是因為我們無法完全信任開發(fā)者或管理員。Web3參與者并持不同理念，并追求使用無需信任的系統(tǒng)：如果某物必須被信任，那么它看起來就不太可靠。這就是為什么用戶依賴硬件運營商來檢查和管理應(yīng)用。應(yīng)用可以被分離，以防止它們在內(nèi)存訪問期間干擾或抓取或更改敏感數(shù)據(jù)，因為加密依賴于CPU和外部設(shè)備之間的順暢協(xié)作。用戶和數(shù)據(jù)提供者需要對其數(shù)據(jù)執(zhí)行的操作有明確的保證和驗證。
在開發(fā)Phala Network時，我們的初衷是結(jié)合AWS的優(yōu)勢與TEE的安全性，通過去中心化消除復(fù)雜性，同時增強安全性。這種方法旨在滿足Web3用例的需求。其結(jié)果是我們提出了去中心化TEE云的概念，為去中心化應(yīng)用提供安全性和集成性。
創(chuàng)建去中心化TEE云
要理解去中心化TEE云的概念，首先必須定義什么是去中心化云。那么，它是什么呢？
去中心化云是一種計算基礎(chǔ)設(shè)施，其中數(shù)據(jù)存儲、處理和管理分布在多個節(jié)點的網(wǎng)絡(luò)中，而不是集中在單個中央服務(wù)器或數(shù)據(jù)中心。與AWS等傳統(tǒng)的集中式云系統(tǒng)不同，去中心化云無需單一控制實體，而是依賴區(qū)塊鏈來運作。
去中心化TEE云
去中心化TEE云是一種將TEE與去中心化節(jié)點網(wǎng)絡(luò)相結(jié)合的計算基礎(chǔ)設(shè)施，以提供安全、私密且可驗證的計算。每個節(jié)點都配備了TEE，以保護(hù)敏感代碼和數(shù)據(jù)免受節(jié)點運營商的訪問或篡改。
Phala Network由一個去中心化的工作節(jié)點網(wǎng)絡(luò)組成，每個節(jié)點都配備了TEE。這些節(jié)點根據(jù)客戶需求為用戶執(zhí)行計算任務(wù)，如運行智能合約或處理敏感數(shù)據(jù)。
該過程始于用戶將其應(yīng)用或任務(wù)部署到網(wǎng)絡(luò)上。計算任務(wù)在這些節(jié)點的TEE內(nèi)執(zhí)行，確保代碼和數(shù)據(jù)保持機密性，甚至節(jié)點運營商也無法查看或篡改它們。
Phala使用密碼學(xué)證明來驗證TEE內(nèi)的計算是否正確執(zhí)行。節(jié)點運營商因提供誠實和安全的服務(wù)而獲得獎勵，通過經(jīng)濟(jì)激勵維護(hù)網(wǎng)絡(luò)的完整性。雖然這聽起來很簡單，但實施這一解決方案遠(yuǎn)比看起來復(fù)雜。
為什么創(chuàng)建去中心化TEE云如此困難？
TEE本身并非中心化或去中心化，其中心化程度取決于在系統(tǒng)中的實施和部署方式。TEE是處理器內(nèi)的一個安全隔離區(qū)域，旨在保護(hù)敏感代碼和數(shù)據(jù)免受同一設(shè)備上的操作系統(tǒng)或其他進(jìn)程的未經(jīng)授權(quán)訪問。TEE是在中心化還是去中心化模式下運行，取決于其所在的更廣泛系統(tǒng)的架構(gòu)。
歷史上，創(chuàng)建集中式系統(tǒng)比創(chuàng)建去中心化系統(tǒng)更簡單，因為后者在實施和節(jié)點通信方面面臨挑戰(zhàn)。在Phala Cloud之前，我們已成功創(chuàng)建了完全去中心化的Phala Network 1.0（SGX）?，F(xiàn)在正在以同樣理念開發(fā)Phala Cloud，盡管這需要時間。Phala是目前唯一一個將TEE與完全去中心化相結(jié)合的平臺，不同于中心化提供商或部分去中心化協(xié)議。
去中心化和TEE的優(yōu)勢顯而易見，但在產(chǎn)品開發(fā)中仍不足夠。試想阿里巴巴是全球最大的電子商務(wù)平臺，占據(jù)了巨大的市場份額。若一款新產(chǎn)品以兩倍的功能和更低的價格推出，它會占據(jù)整個市場嗎？遺憾的是，不會，因為人們已經(jīng)習(xí)慣了現(xiàn)有產(chǎn)品，即使新產(chǎn)品更好，也會對其存在偏見。
這是我們面臨的挑戰(zhàn)之一，但我們不追求兩倍的改進(jìn)，而是確保Phala比競爭對手好十倍且用戶友好。此外，如前所述，AWS不適合Web3環(huán)境，我們旨在為Web3應(yīng)用和開發(fā)者填補這一空白。除了去中心化這一明顯優(yōu)勢，我們還想強調(diào)Phala與AWS的其他差異。
Phala Cloud與AWS
首先，AWS為Nitro Enclaves的設(shè)置過程復(fù)雜。這涉及多個步驟，包括安裝Nitro CLI、將Docker鏡像轉(zhuǎn)換為Enclave文件以及處理文件傳輸，這些都非常耗時。
相比之下，Phala允許開發(fā)者“即遷即改”部署，并輕松將現(xiàn)有的Docker容器遷移到安全的TEE中。使用Dstack SDK，開發(fā)者只需進(jìn)行最小更改即可將Docker容器轉(zhuǎn)換為保密虛擬機（Confidential VM），并通過戶友好的Cloud UI進(jìn)行部署，同時仍支持模板和自定義Docker Compose文件。
在安全性方面，AWS依賴于信任開發(fā)者和管理員來正確配置訪問控制和管理資源。盡管AWS使用TEE進(jìn)行隔離計算，但其集中式基礎(chǔ)設(shè)施要求信任AWS和管理系統(tǒng)的人員，這可能導(dǎo)致敏感數(shù)據(jù)被訪問。Phala采用零信任模型，默認(rèn)不信任任何一方。敏感數(shù)據(jù)在TEE內(nèi)保持安全，甚至節(jié)點運營商也無法訪問，因此適合需要無需信任操作的Web3應(yīng)用。
從產(chǎn)品角度來看，AWS主要服務(wù)于企業(yè)客戶，因為傳統(tǒng)IT領(lǐng)域的企業(yè)數(shù)量眾多。因此，它在產(chǎn)品和技術(shù)方面并未完全符合Web3初創(chuàng)企業(yè)的價值主張。相比之下，Phala專為去中心化應(yīng)用而構(gòu)建。它原生支持與區(qū)塊鏈智能合約交互的AI代理以及隱私保護(hù)的DApp。
此外，Phala通過與各種協(xié)議的合作伙伴關(guān)系以及對希望利用TEE安全性的DApp的集成，深度融入了區(qū)塊鏈生態(tài)系統(tǒng)。
Phala定位為Web3 AI的執(zhí)行層，使開發(fā)者能夠構(gòu)建、啟動并從能夠安全且私密地理解和與區(qū)塊鏈智能合約交互的AI代理中獲利。我們通過利用NVIDIA GPU TEE在安全、可驗證且注重隱私的環(huán)境中運行大型語言模型（LLM），支持NEAR AI和Sentient等去中心化AI平臺。例如，我們與NOTAI的合作伙伴關(guān)系突出了AI代理的零信任執(zhí)行，其中我們通過TEE和RA Explorer提供無需信任和隱私保護(hù)。
我們還通過Phat Contracts支持與非AI相關(guān)的應(yīng)用集成，這些是具有原生HTTP請求支持的低成本、低延遲智能合約。
然而，鑒于許多加密原生團(tuán)隊也在構(gòu)建TEE和其他安全計算方法，Phala如何與這些解決方案區(qū)分開來呢？
Phala Cloud與TEE解決方案
Phala Network作為唯一一個完全去中心化的TEE云脫穎而出，為DApp提供安全、私密且可驗證的計算。與Oasis Protocol和Secret Network不同，后者專注于在其各自的區(qū)塊鏈中使用TEE實現(xiàn)隱私啟用的智能合約，而Phala提供了一個跨網(wǎng)絡(luò)的離線計算去中心化云計算平臺。
Phala靈活且可定制，利用廣泛的TEE硬件，包括Intel SGX、Intel TDX、AMD SEV和NVIDIA GPU TEE。Marlin Protocol增強了Web3的網(wǎng)絡(luò)性能，但不提供計算或隱私功能，而Oasis和Secret則在特定的區(qū)塊鏈生態(tài)系統(tǒng)中運行。Phala作為唯一具有廣泛硬件支持和Dstack等開發(fā)者中心工具的去中心化TEE云，具有獨特優(yōu)勢。
Phala的不同之處在于它提供了一個通用的去中心化TEE云，與專注于特定用例的Oasis Protocol、Marlin和Secret Network不同。Phala允許開發(fā)者在安全環(huán)境中部署任何應(yīng)用，如AI模型、Web服務(wù)器或數(shù)據(jù)庫。這是通過Phat Contracts和Phala Cloud實現(xiàn)的，后者支持Docker化部署，并可一鍵訪問CPU和GPU TEE。
此外，關(guān)于TEE或多方計算（MPC）哪個更適合特定用例的比較很多。在我們看來，TEE和MPC并非競爭對手，而是互補的伙伴。
Phala將TEE與MPC集成，以創(chuàng)建去中心化信任根（DeRoT）模型，這是一種用于保護(hù)基于TEE的應(yīng)用的先進(jìn)方法。MPC在TEE內(nèi)運行，以減少節(jié)點共謀風(fēng)險，同時TEE塊證明與MPC證明一起提交，以減輕零知識證明（ZKP）實現(xiàn)中的錯誤。要求MPC節(jié)點在TEE內(nèi)運行進(jìn)一步增強了這一多證明系統(tǒng)。DeRoT模型使用TEE、MPC和ZKP在網(wǎng)絡(luò)中分配信任。這種方法通過解決潛在的硬件或節(jié)點級威脅，提高了使用TEE的DApp的安全性。
去中心化TEE云的可能性
我們將專門撰寫一篇文章來探討這一主題，因為已有許多應(yīng)用在Phala上運行。因此，這一部分可能與整篇文章一樣長。但我們希望概述去中心化TEE云的可能用例。
首先，Phala支持在TEE內(nèi)部署AI模型，確保與區(qū)塊鏈網(wǎng)絡(luò)交互的安全和自主操作。這包括用于智能合約增強和跨代理交互的AI代理。開發(fā)者可以利用GPU TEE進(jìn)行AI計算，實現(xiàn)真正的抗審查和隱私保護(hù)。
開發(fā)者還可以將傳統(tǒng)應(yīng)用遷移到安全且無需信任的環(huán)境中，以提高安全性。該平臺通過Web3和傳統(tǒng)分析工具實現(xiàn)隱私保護(hù)的數(shù)據(jù)分析，這些工具可以在不暴露單個用戶信息的情況下分析數(shù)據(jù)。此外，它還可以通過隱私功能增強DeFi的安全計算，如保密交易頭寸或暗池交易。最后，去中心化TEE云可以通過將區(qū)塊構(gòu)建移入TEE來實現(xiàn)MEV保護(hù)，以實現(xiàn)公平排序和執(zhí)行。
有許多產(chǎn)品將Phala作為其基礎(chǔ)設(shè)施的一部分。我們將在另一篇文章中深入探討這些產(chǎn)品如何使用Phala以及它們從這種集成中獲得了什么。
結(jié)論
Web3和Web2的信任模型存在根本差異，這導(dǎo)致AWS等平臺存在局限性。在Web3中，數(shù)據(jù)（包括本質(zhì)上屬于數(shù)據(jù)的通證）真正由用戶擁有，而應(yīng)用開發(fā)者默認(rèn)不受信任。這種不信任源于開發(fā)者可能嘗試未經(jīng)授權(quán)訪問、修改或竊取用戶數(shù)據(jù)的潛力。
這種范式解釋了Web3中的幾個關(guān)鍵實踐：
1.智能合約代碼必須經(jīng)過嚴(yán)格審查，以消除后門或漏洞。
智能合約的所有權(quán)（或管理控制）是關(guān)鍵問題，用戶更重視透明度，而不是允許開發(fā)者擁有不受限制的控制權(quán)。
2.理想情況下，在Web3環(huán)境中，開發(fā)者應(yīng)編寫并部署智能合約代碼，然后放棄所有控制權(quán)，不再對應(yīng)用保留任何特權(quán)。
與智能合約不同，TEE可以在更廣泛的程序范圍內(nèi)執(zhí)行類似的所有權(quán)和控制原則。然而，AWS Nitro Enclaves在Web2框架內(nèi)運行，其中開發(fā)者保留登錄、訪問和修改數(shù)據(jù)和應(yīng)用的能力。Phala的TEE是根據(jù)Web3原則設(shè)計的，原生支持智能合約來管理基于TEE的應(yīng)用，與去中心化信任模型保持一致。
贊
.png)
8962
收藏
