作者：EQ Labs 來源：equilibrium 翻譯：善歐巴，金色財經

我們的隱私系列第 1 部分介紹了“隱私”的含義、區塊鏈網絡中的隱私與 web2 隱私有何不同，以及為什麼在區塊鏈中難以實現隱私。

本文的主要觀點是，如果理想的最終狀態是擁有可編程的隱私基礎設施，能夠處理共享的私有狀態而沒有任何單點故障，那麼所有的道路都通向MPC。我們還將探討MPC的成熟度及其信任假設，強調替代方法，比較權衡，並提供行業概述。

擺脫過去的束縛，迎接未來

區塊鏈中現有的隱私基礎設施旨在處理非常具體的用例，例如私人支付或投票。這是一種相當狹隘的觀點，主要反映了區塊鏈目前的用途（交易、轉賬和投機）。正如Tom Walpo 所說- 加密貨幣遭受費米悖論：

除了增加個人自由之外，我們認為隱私是擴大區塊鏈設計空間的先決條件，超越當前的推測性元數據。許多應用程序需要一些私有狀態和/或隱藏邏輯才能正常運行：

• 隱藏狀態：絕大多數金融用例需要（至少）對其他用戶保密，並且如果沒有一些隱藏狀態，許多多人遊戲的趣味性就會大大降低（例如，如果撲克桌上的每個人都能看到彼此的牌）。
• 隱藏邏輯：某些用例需要隱藏一些邏輯，同時仍允許其他人使用該應用程序，例如匹配引擎、鏈上交易策略等。

實證分析（來自 web2 和 web3）表明，大多數用戶不願意為增加隱私而支付額外費用或跳過額外的環節，我們也同意隱私本身並不是賣點。然而，它確實使新的和（希望）更有意義的用例能夠在區塊鏈之上存在——讓我們擺脫費米悖論。

隱私增強技術（PET）和現代密碼解決方案*（“可編程密碼”）是實現這一願景的基本構建模塊（有關可用的不同解決方案及其權衡的更多信息，請參閱附錄*） 。

影響我們觀點的三個假設

三個關鍵假設決定了我們對區塊鏈隱私基礎設施如何發展的看法：

1. 加密技術將從應用程序開發人員手中抽象出來：大多數應用程序開發人員不想（或不知道如何處理）處理隱私所需的加密技術。期望他們實現自己的加密技術並構建私有應用專用鏈*（例如Zcash或Namada）或在公共鏈**（例如 Tornado Cash）之上的私有應用程序是不合理的。這實在太複雜了，開銷也太大了，目前限制了大多數開發人員的設計空間（無法構建需要某些隱私保障的應用程序）。因此，我們認為必須將管理加密部分的複雜性從應用程序開發人員手中抽象出來。這裡的兩種方法是可編程隱私基礎設施（共享私有 L1/L2）或“機密即服務”*，後者允許外包機密計算。
2. 許多用例（可能比我們想象的要多）需要共享私有狀態：如前所述，許多應用程序需要一些隱藏狀態和/或邏輯才能正常運行。共享私有狀態是其中的一個子集，其中多方對同一私有狀態進行計算。雖然我們可以信任一個中心化方為我們完成這件事並就此打住，但理想情況下，我們希望以信任最小化的方式來做這件事，以避免單點故障。僅靠零知識證明 (ZKP) 無法實現這一點 - 我們需要利用其他工具，例如可信執行環境 (TEE)、完全同態加密 (FHE) 和/或多方計算 (MPC)。
3. 更大的屏蔽集可最大程度地保護隱私：大多數信息在進入或退出屏蔽集時都會被洩露，因此我們應儘量減少這種情況。在同一區塊鏈上構建多個私有應用程序可以通過增加同一屏蔽集內的用戶和交易數量來幫助加強隱私保障。

隱私基礎設施的終結

考慮到上述假設，區塊鏈隱私基礎設施的最終目標是什麼？是否有一種方法適合所有應用程序？是否有一種隱私增強技術可以統領所有應用程序？

不完全是。所有這些都有不同的權衡，我們已經看到它們以各種方式結合在一起。總的來說，我們已經確定了 11 種不同的方法。

目前，在區塊鏈中構建隱私基礎設施的兩種最流行方法是利用 ZKP 或 FHE。然而，兩者都存在根本缺陷：

• 基於 ZK 且具有客戶端證明的隱私協議可以提供強大的隱私保障，但不允許多方對同一私有狀態進行計算。這限制了表達能力，即開發人員可以構建哪些類型的應用程序。
• FHE 支持對加密數據和共享私有狀態進行計算，但提出了誰擁有該狀態的問題，即誰擁有解密密鑰。這限制了隱私保障的強度，以及我們可以相信今天的隱私明天仍然如此的程度。

如果理想的最終狀態是擁有可編程的隱私基礎設施，可以處理共享的私有狀態而不會出現任何單點故障，那麼兩條路都可以通向 MPC：

請注意，儘管這兩種方法最終會趨於融合，但 MPC 的用途不同：

• ZKP 網絡：MPC通過實現共享私有狀態的計算來增加表達能力。
• FHE 網絡：MPC通過將解密密鑰分發給 MPC 委員會（而不是單個第三方）來提高安全性 並加強隱私保障。

雖然討論開始轉向更細緻入微的觀點，但這些不同方法背後的保證仍未得到充分探索。鑑於我們的信任假設歸結為 MPC 的假設，需要提出的三個關鍵問題是：

1. MPC 協議在區塊鏈中能提供的隱私保障有多強？
2. 技術是否足夠成熟？如果不夠，瓶頸是什麼？
3. 考慮到保證的力度及其引入的開銷，與其他方法相比它是否有意義？

讓我們更詳細地解答這些問題。

使用 MPC 分析風險和弱點

每當解決方案使用 FHE 時，人們總是需要問：“誰擁有解密密鑰？”。如果答案是“網絡”，那麼後續問題是：“哪些真實實體構成了這個網絡？”。後一個問題與所有以某種形式依賴 MPC 的用例相關。

*資料來源：*Zama 在 ETH CC 上的演講

MPC 的主要風險是串通，即有足夠多的參與方惡意串通解密數據或盜用計算。串通可以在鏈下達成一致，並且只有當惡意方採取某些明顯行動（勒索、憑空鑄造代幣等）時才會被揭露。毋庸置疑，這對系統可以提供的隱私保障具有重大影響。串通風險取決於：

• 該協議可以承受多少惡意方？
• 網絡由哪些方組成？他們的可信度如何？
• 參與網絡的不同方的數量及其分佈 - 是否存在常見的攻擊媒介？
• 網絡是無需許可的還是需要許可的（經濟利益與聲譽/法律基礎）？
• 對惡意行為的懲罰是什麼？串通博弈在理論上是最優結果嗎？

1. MPC 協議在區塊鏈中能提供的隱私保障有多強？

TLDR：不如我們所希望的那麼強大，但比依賴一個集中的第三方要強大。

解密所需的閾值取決於所選的 MPC 方案 - 很大程度上是活躍度*（“保證輸出交付”）*和安全性之間的權衡。您可以採用非常安全的 N/N 方案，但只要有一個節點離線，它就會崩潰。另一方面，N/2 或 N/3 方案更穩健，但串謀風險更高。

需要平衡的兩個條件是：

1. 祕密信息永遠不會洩露（例如解密密鑰）
2. 祕密信息永遠不會消失（即使 1/3 的參與方突然離開）。

所選方案因實施而異。例如，Zama 的目標是 N/3，而 Arcium 目前正在實施N/N 方案，但稍後還將支持具有更高活性保證（和更大信任假設）的方案。

在這個權衡邊界上，一個妥協的方案是採用混合解決方案：

• 高信任委員會以例如 N/3 閾值進行密鑰處理。
• 計算委員會是輪換的，例如有 N-1 閾值（或多個具有不同特徵的不同計算委員會供用戶選擇）。

雖然這在理論上很有吸引力，但它也引入了額外的複雜性，例如計算委員會如何與高信任委員會互動。

加強安全保障的另一種方法是在受信任的硬件內運行 MPC，以便將密鑰共享保存在安全區域內。這使得提取或使用密鑰共享進行協議定義以外的任何操作變得更加困難。至少Zama和Arcium正在探索 TEE 角度。

更細微的風險包括諸如社會工程之類的邊緣情況，例如，MPC 集群中的所有公司都僱用了一名高級工程師超過 10 至 15 年。

2. 技術是否足夠成熟？如果不夠成熟，瓶頸是什麼？

從性能角度來看，MPC 面臨的關鍵挑戰是通信開銷。它隨著計算的複雜性和網絡中節點數量的增加而增長（需要更多的來回通信）。對於區塊鏈用例，這會帶來兩個實際影響：

1. 小型操作符集：為了使通信開銷可控，大多數現有協議目前僅限於小型操作符集。例如，Zama 的解密網絡目前最多允許 4 個節點（儘管他們計劃擴展到 16 個）。根據 Zama 為其解密網絡 (TKMS) 發佈的初始基準，即使只有 4 個節點的集群，解密也需要 0.5-1 秒（完整的 e2e 流程需要更長的時間）。另一個例子是 Taceo為 Worldcoin 的虹膜數據庫實施的 MPC，該數據庫有 3 方（假設 2/3 誠實方）。

*資料來源：*Zama 在 ETH CC 上的演講 2. 3. 許可操作員集：在大多數情況下，操作員集是經過許可的。這意味著我們依賴聲譽和法律合同，而不是經濟或加密安全。無許可操作員集的主要挑戰是無法知道人們是否在鏈下串通。此外，它需要定期引導或重新分配密鑰份額，以便節點能夠動態進入/退出網絡。雖然無許可操作員集是最終目標，並且正在研究如何擴展 PoS 機制以實現閾值 MPC（例如 Zama），但許可路線似乎是目前最好的前進方向。

替代方法

全面的隱私組合包括：

• FHE 用於委託隱私計算
• ZKP 用於驗證 FHE 計算是否正確執行
• 用於閾值解密的 MPC
• 每個 MPC 節點都在 TEE 內運行，以增強安全性

這很複雜，引入了許多未探索的極端情況，開銷很大，並且在未來很多年內可能都無法實際實現。另一個風險是，人們可能會因為將多個複雜概念疊加在一起而產生虛假的安全感。我們添加的複雜性和信任假設越多，推斷整體解決方案的安全性就越困難。

這值得嗎？也許值得，但也值得探索其他方法，這些方法可能會帶來顯著更好的計算效率，而隱私保證只會略弱一些。正如Seismic 的 Lyron所指出的那樣 - 我們應該專注於最簡單的解決方案，以滿足我們對所需隱私級別和可接受權衡的標準，而不是僅僅為了它而過度設計。

1. 直接使用 MPC 進行通用計算

如果 ZK 和 FHE 最終都回歸到 MPC 的信任假設，為什麼不直接使用 MPC 進行計算呢？這是一個合理的問題，也是Arcium、SodaLabs （ Coti v2使用）、 Taceo和Nillion等團隊正在嘗試做的事情。請注意，MPC 有多種形式，但在三種主要方法中，我們這裡指的是基於祕密共享和*亂碼電路 (GC)*的協議，而不是使用 MPC 進行解密的基於 FHE 的協議。

雖然 MPC 已經用於分佈式簽名和更安全的錢包等簡單計算，但使用 MPC 進行更通用計算的主要挑戰是通信開銷（隨著計算的複雜性和所涉及的節點數量的增加而增加）。

有一些方法可以減少開銷，例如提前離線進行預處理（即協議中最昂貴的部分）—— Arcium和SodaLabs都在探索這一點。然後在在線階段執行計算，這會消耗離線階段產生的一些數據。這大大降低了整體通信開銷。

SodaLabs 的下表顯示了在其 gcEVM 中執行不同操作碼 1,000 次需要多長時間的初始基準*（以微秒為單位）。*雖然這是朝著正確方向邁出的一步，但仍有許多工作要做，以提高效率並將操作符集擴展到幾個節點之外。

來源：SodaLabs

基於 ZK 的方法的好處是，您只將 MPC 用於需要在共享私有狀態下進行計算的用例。FHE 與 MPC 的競爭更為直接，並且嚴重依賴硬件加速。

2. 可信執行環境

最近，人們對 TEE 的興趣又重新燃起，它既可以單獨使用（基於 TEE 的私有區塊鏈或協處理器），也可以與其他 PET（如基於 ZK 的解決方案）結合使用（僅使用 TEE 進行共享私有狀態的計算）。

雖然 TEE 在某些方面更為成熟，並且引入的性能開銷更少，但它們並非沒有缺點。首先，TEE 具有不同的信任假設（1/N），並且提供基於硬件而非軟件的解決方案。人們經常聽到的批評是圍繞SGX 過去的漏洞，但值得注意的是 TEE ≠ Intel SGX。TEE 還需要信任硬件提供商，而硬件價格昂貴（大多數人無法負擔得起）。解決物理攻擊風險的一個解決方案可能是在太空中運行 TEE來處理關鍵任務。

總體而言，TEE 似乎更適合只需要短期隱私的證明或用例（閾值解密、暗盤賬本等）。對於永久或長期隱私，安全保障似乎不太有吸引力。

3. 私有 DAC 和其他依賴可信第三方保護隱私的方法

中介隱私可以提供隱私，防止其他用戶訪問，但隱私保證完全來自對第三方的信任（單點故障）。雖然它類似於“web2 隱私”（防止其他用戶的隱私），但它可以通過額外的保證（加密或經濟）來加強，並允許驗證正確執行。

私有數據可用性委員會 (DAC)就是一個例子；DAC 的成員將數據存儲在鏈下，用戶信任他們能夠正確存儲數據並執行狀態轉換更新。另一種形式是Tom Walpo 提出的特許序列器。

雖然這種方法在隱私保障方面做出了很大的權衡，但就成本和性能而言，它可能是對低價值、高性能應用程序唯一可行的替代方案（至少目前如此）。例如，Lens Protocol計劃使用私有 DAC 來實現私有信息流。對於鏈上社交等用例，隱私和成本/性能之間的權衡目前可能是合理的（考慮到替代方案的成本和開銷）。

4. 隱身地址

隱身地址可以提供與為每筆交易創建新地址類似的隱私保證，但該過程在後端自動進行，並且對用戶不公開。有關更多信息，請參閱Vitalik 的這篇概述或這篇深入探討不同方法的文章。該領域的主要參與者包括Umbra和Fluidkey。

雖然隱身地址提供了一種相對簡單的解決方案，但主要缺點是它們只能為交易（付款和轉賬）添加隱私保證，而不能為通用計算添加隱私保證。這使它們與上面提到的其他三種解決方案有所不同。

此外，隱身地址提供的隱私保障不如其他替代方案強大。匿名性可以通過簡單的聚類分析來打破，特別是當傳入和傳出的轉賬不在相似範圍內時（例如，收到 10,000 美元，但每天的交易平均花費 10-100 美元）。隱身地址的另一個挑戰是升級密鑰，如今需要為每個錢包單獨升級（密鑰存儲彙總可以幫助解決這個問題）。從用戶體驗方面來看，如果賬戶沒有費用代幣（例如 ETH），隱身地址協議還需要賬戶抽象或付款人來支付費用。

我們的論點面臨的風險

鑑於快速的發展速度和不同技術解決方案的普遍不確定性，我們認為 MPC 將成為最終解決方案的論點存在一些風險。我們最終可能不需要某種形式的 MPC，主要原因包括：

1. 共享私有狀態並不像我們想象的那麼重要：在這種情況下，基於 ZK 的基礎設施更有可能獲勝，因為它比 FHE 具有更強的隱私保證和更低的開銷。已經有一些用例表明基於 ZK 的系統在孤立用例中運行良好，例如私有支付協議Payy。
2. 性能上的權衡不值得隱私保障的好處：有人可能會說，具有 2-3 個許可方的 MPC 網絡的信任假設與單箇中心化參與者並無太大區別，而且成本/開銷的大幅增加是不值得的。對於許多應用程序，尤其是低價值、成本敏感的應用程序（例如社交或遊戲），這可能是正確的。然而，也有許多高價值用例，由於法律問題或協調摩擦大，協作目前非常昂貴（或不可能）。後者是 MPC 和基於 FHE 的解決方案可以大放異彩的地方。
3. 專業化勝過通用設計：構建新鏈並引導用戶和開發人員社區非常困難。因此，通用隱私基礎設施 (L1/L2) 可能難以獲得關注。另一個問題涉及專業化；單一協議設計很難覆蓋整個權衡空間。在這個世界上，為現有生態系統（機密性即服務）或專門用例（例如支付）提供隱私的解決方案將佔上風。然而，我們對後者持懷疑態度，因為它給應用程序開發人員帶來了複雜性，他們需要自己實現一些加密技術（而不是將其抽象出來）。
4. 監管繼續阻礙隱私解決方案的試驗：對於任何構建隱私基礎設施和具有某些隱私保障的應用程序的人來說，這都是一個風險。非金融用例面臨的監管風險較小，但很難（不可能）控制在無需許可的隱私基礎設施之上構建什麼。我們很可能在解決監管問題之前解決技術問題。
5. 對於大多數用例來說，基於 MPC 和 FHE 的方案的開銷仍然太高：雖然 MPC 主要受到通信開銷的影響，但 FHE 團隊嚴重依賴硬件加速來提高其性能。但是，如果我們可以推斷 ZK 方面專用硬件的發展，那麼在我們獲得可用於生產的 FHE 硬件之前，需要的時間將比大多數人想象的要長得多。致力於 FHE 硬件加速的團隊包括Optalysys、fhela和Niobium。

概括

歸根結底，鏈條的強度取決於其最薄弱的環節。在可編程隱私基礎設施的情況下，如果我們希望它能夠處理共享的私有狀態而不會出現單點故障，那麼信任保證就歸結為 MPC 的保證。

雖然這篇文章聽起來對 MPC 有所批評，但事實並非如此。MPC 極大地改善了目前依賴中心化第三方的現狀。我們認為，主要問題是整個行業存在虛假的信心，問題被掩蓋了。相反，我們應該直面問題，專注於評估潛在風險。

然而，並非所有問題都需要使用相同的工具來解決。儘管我們認為 MPC 是最終目標，但只要 MPC 驅動的解決方案的開銷仍然很高，其他方法也是可行的選擇。我們總是值得考慮哪種方法最適合我們試圖解決的問題的特定需求/特徵，以及我們願意做出哪些權衡。

即使你有世界上最好的錘子，也不一定所有的東西都是釘子。