我們隱私系列的第一部分涵蓋了“隱私”包含的內容，區塊鏈網絡中的隱私與 Web2 隱私的不同之處，以及為什麼在區塊鏈中實現隱私很困難。

本帖的主要觀點是，如果期望的終態是擁有可編程的隱私基礎設施，可以處理共享的私有狀態而不會有任何單一故障點，那麼所有的道路都將通向多方安全計算。我們還探討了多方安全計算的成熟度和其信任假設，突出了替代方法，比較了各種取捨，並提供了行業概況。

我們都在建造同一個東西嗎？繼續閱讀以了解更多。

感謝Avishay (SodaLabs), Lukas (Taceo), 邁克爾 ( 平衡), 和 Nico (Arcium) 用於形成本帖子的討論。

未受過去所累的可能

區塊鏈中現有的隱私基礎建設是為處理特定用例而設計的，例如私人支付或投票。這是一個相當狹窄的觀點，大多反映了區塊鏈目前的用途（交易，轉移和投機）。Tom Walpo放置它- 加密貨幣遭受費米悖論的困擾：

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

• 隱藏狀態：絕大多數金融應用案例至少需要對其他用戶進行隱私保護，許多多人遊戲如果沒有一些隱藏的狀態會讓遊戲變得相對無趣（例如，如果撲克桌上的每個人都能看到彼此的牌）。
• 隱藏的邏輯：有些用例需要隱藏一些邏輯，同時仍然使其他人能夠使用應用程序，例如匹配引擎、鏈上交易策略等。

從實證分析（來自web2和web3）來看，大多數用戶不願意為額外的隱私支付費用或額外跳過步驟，我們認為隱私本身並不是一個賣點。不過，這確實使得新的（希望是）更有意義的用例能夠存在於區塊鏈之上，從而使我們能夠打破費米悖論。

隱私增強技術（PETs）和現代加密解決方案（"可編程密碼學“) 是實現這一願景的基本構建模塊(見附錄有關可用的不同解決方案及其權衡的更多信息）。

塑造我們觀點的三個假設

三個關鍵假設塑造了我們對區塊鏈隱私基礎設施可能演變的觀點:

1. 加密學將從應用程序開發人員中抽象出來：大多數應用程序開發人員不想（或不知道如何）處理隱私所需的加密學。期望他們實現自己的加密和構建私有的應用程序特定鏈（例如，門戶）是不合理的。Zcash或者Namada）或公共鏈頂部的私人應用程式（例如龍捲風現金）。這實在是太多的複雜性和開銷，目前限制了大多數開發人員的設計空間（無法構建需要某些隱私保證的應用程式）。因此，我們認為管理加密部分的複雜性必須從應用程式開發人員中抽象出來。這裡的兩種方法是可程式設計隱私基礎設施（共用私有 L1/L2）或“機密即服務”，它支援外包機密計算。
2. 許多用例（可能比我們想像的要多）需要共用私有狀態：如前所述，許多應用程式需要一些隱藏狀態和/或邏輯才能正常運行。共用私有狀態是其中的一個子集，其中多方計算同一私有狀態。雖然我們可以信任一個中心化的方為我們做這件事，但理想情況下，我們希望以信任最小化的方式做到這一點，以避免單點故障。僅靠零知識證明 （ZKP） 無法實現這一目標 - 我們需要利用其他工具，例如可信執行環境 （TEE）、完全同態加密 （FHE） 和/或多方計算 （MPC）。
3. 更大的防护套装最大化隐私保护：大多数信息在揭示时進出在盾牌集中，我們應該盡量減少這一點。在同一區塊鏈上建立多個私人應用程式可以幫助加強隱私保證，因為可以增加在相同盾牌集中的使用者和交易數量。

隱私基礎架構的終局

在考慮上述假設的基礎上，區塊鏈隱私基礎設施的最終目標是什麼？是否有一種適用於每個應用的方法？一種能夠統治所有的隱私增強技術嗎？

並非如此。所有這些都有不同的取捨，我們已經看到它們以各種方式結合在一起。總共，我們已經確定了11種不同的方法（參見附錄。

今天，在區塊鏈中建立隱私基礎設施的兩種最流行方法分別利用ZKPs或FHE。然而，兩者都有根本性的缺陷：

• 基於ZK的隱私協議與客戶端證明可以提供強大的隱私保護，但無法讓多方對相同的私有狀態進行計算。這限制了表達性，即開發人員可以構建的應用程序類型。
• 完全同态加密（FHE）使得在加密的數據和共享的私有狀態上進行計算成為可能，但同時也帶來了一個問題：誰擁有這個狀態，即誰擁有解密密鑰。這限制了隱私保證的強度以及我們對於今天的隱私是否能夠在明天保持的信任程度。

如果理想的最終目標是擁有可以處理共享私有狀態且沒有任何單點故障的可編程隱私基礎設施，那麼這兩條路都通向多方安全計算（MPC）：

請注意，儘管這兩種方法最終會趨於一致，但多方安全計算（MPC）被用於不同的事情:

• ZKP網絡：MPC被用來通過在共享的私有狀態上進行計算來增加表達能力。
• FHE 網路: 多方安全計算（ MPC ）通過將解密金鑰分配給 MPC 委員會（而不是單一第三方）來增加安全性和加強隱私保證。

雖然討論開始轉向更細緻的觀點，但這些不同方法背後的保證仍未被充分探索。鑑於我們的信任假設歸結為多方安全計算的信任假設，要問的三個關鍵問題是:

1. MPC協議在區塊鏈中能夠提供多強的隱私保證？
2. 技術是否足夠成熟？如果不是，那麼瓶頸在哪裡？
3. 考慮到擔保的強度和引入的開銷，與替代方案相比，這是否有意義？

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

使用多方安全計算分析風險和弱點

每當一個解決方案使用FHE時，我們總是需要問：「誰持有解密金鑰？」如果答案是「網絡」，那麼接下來的問題是：「哪些真實實體組成了這個網絡？」後者問題與所有依賴MPC的用例有關。

來源：Zama talk在ETH CC

MPC的主要風險是勾結，即足夠多的參與方以惡意行為勾結解密數據或盗用計算。勾結可以在鏈下協議並且只在惡意方做出明顯行為（勒索，無中生有地鑄造代幣等）時才被揭示。毋庸置疑，這對系統能提供的隱私保證有重大影響。勾結風險取決於：

• 協議可以承受多少惡意方的閾值？
• 網絡由哪些方構成，它們的信任度如何？
• 參與網絡的不同方參與者數量及其分佈-是否存在常見的攻擊向量？
• 網絡是無權限還是有權限的（經濟利害與聲譽/法律為基礎）？
• 惡意行為的懲罰是什麼？串通遊戲在理論上是最佳結果嗎？

1. 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角度。

更微妙的風險包括邊緣案例，例如社會工程學，在這種情況下，資深工程師在過去10-15年間被所有包含在MPC集群中的公司雇用。

2. 技術是否已成熟？如果還沒有，有哪些瓶頸？

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

1. 小型操作者集合：為了使通信開銷可管理，目前大多數現有的協議都限制在小型操作者集合上。例如，Zama的解密網絡目前最多允許4個節點（儘管他們計劃擴展到16個）。根據Zama為其解密網絡（TKMS）發布的初步基準測試，即使只有4個節點的集群，解密也需要0.5-1秒（完整的端到端流程需要更長時間）。另一個例子是Taceo的...Worldcoin的iris数据库的多方安全计算实现，其中有3方（假設有2/3誠實方）。

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

替代方法

完整的隱私混合酒包括：

• 委託私密計算的FHE
• 用於驗證完全同態加密計算是否正確執行的ZKP
• 門限解密的多方安全計算
• 每個MPC節點在TEE中運行，以提供額外的安全性

這是一個複雜的問題，引入了許多未經探索的邊緣案例，具有很高的開銷，並且在未來很多年內可能不實際可行。另一個風險是在將多個複雜概念堆疊在一起時可能產生虛假的安全感。我們增加的複雜性和信任假設越多，就越難對整體解決方案的安全性進行推理。

值得嗎？也許，但也值得探索可能帶來顯著更好計算效率的替代方法，代價只是稍微較弱的隱私保證。來自Seismic的Lyron注意-我們應該專注於滿足我們所需的隱私級別和可接受的權衡的最簡單解決方案，而不是僅僅為了而過度設計。

1. 直接使用多方安全計算進行一般計算

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

在多方安全計算已經用於簡單的計算，如分散式簽名和更安全的錢包時，使用多方安全計算進行更一般的計算的主要挑戰是通信開銷（隨著計算的複雜性和涉及的節點數量的增加而增加）。

有一些方法可以降低開銷，例如預先進行和離線處理（即協議中最昂貴的部分） - 這是門都Arcium and SodaLabs正在探索。然後在線階段執行計算，該階段消耗離線階段生成的一些數據。這大大降低了整體通信開銷。

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

來源：蘇打實驗室

基於ZK的方法的好處是，只有在需要共享私有狀態的計算用例中才使用MPC。FHE與MPC直接競爭，並且在很大程度上依賴於硬體加速。

2. 可信執行環境

最近對 TEEs 的興趣有所恢復，可以單獨利用（基於 TEE 的私有區塊鏈或共處理器），也可以與其他 PETs（例如基於 ZK 的解決方案）結合使用（僅在共享私有狀態上使用 TEE 進行計算）。

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

總的來說，安全執行環境（TEE）似乎更適合需要短期隱私保護的驗證或用例（閾值解密，暗訂單簿等）。對於永久或長期隱私保護，安全保證似乎較不具吸引力。

3. 私人DAC和其他依賴於可信第三方的隱私方法

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

私人資料可用性委員會（DAC）就是其中一個例子； DAC 的成員將資料存儲在鏈下，用戶信任他們能正確地存儲數據並執行狀態遷移更新。另一種變體是加盟連鎖音序器由Tom Walpo提出。

雖然這種方法在隱私保證方面做出了很大的權衡，但在成本和性能方面，它可能是低價值、高性能應用程式唯一可行的替代方案（至少目前是這樣）。一個例子是Lens Protocol，該計劃將使用私有DAC實現私有饋料。對於鏈上社交等使用情況，現在在隱私和成本/性能之間的取捨可能還是合理的（考慮到其他替代方案的成本和開銷）。

4. 隱形位址

隱藏地址可以提供類似於每筆交易創建新地址的隱私保證，但該過程在後台自動化並對用戶抽象化。更多信息請參閱此Vitalik 的概述或者這個深入探討不同的方法. 這個領域的主要參與者包括 Umbra和Fluidkey.

雖然隱形位址提供了一種相對簡單的解決方案，但主要缺點是它們只能為交易（支付和轉帳）添加隱私保證，而不能為通用計算添加隱私保證。這使它們與上述其他三種解決方案區分開來。

此外，隱形地址提供的隱私保證不如其他選擇那麼強大。匿名性可能會被破解。簡單的聚類分析特別是如果進出轉帳金額不在相似範圍內（例如收到10,000美元，但平均每天交易花費在10-100美元之間）。隱藏地址的另一個挑戰是升級密鑰，目前需要為每個錢包進行單獨操作（密鑰儲存滾動可以協助解決此問題）。從使用者體驗方面來看，隱藏地址協議還需要帳戶抽象或支付主機來支付費用，如果該帳戶沒有支付費用的代幣（例如ETH）。

我們的論點存在的風險

考慮到快速發展的步伐和各種技術方案的普遍不確定性，我們的多方安全計算(MPC)終局論存在幾個風險。我們最終可能不需要以某種方式使用多方安全計算(MPC)的主要原因包括：

1. 共享私有狀態並不像我們所認為的那樣重要：在這種情況下，基於零知識證明的基礎設施更有可能取勝，因為它具有更強的隱私保證和比完全同態加密更低的開銷。已經有一些使用案例表明，基於零知識證明的系統在獨立的使用情景下運作良好，例如私人支付協議。Payy.
2. 性能上的權衡不值得隱私保證的好處：有人可能會爭辯說，具有 2-3 個許可方的 MPC 網路的信任假設與單個中心化參與者沒有顯著區別，並且成本/開銷的顯著增加是不值得的。對於許多應用來說，這可能是正確的，特別是低價值、成本敏感的應用（例如社交或遊戲）。但是，也有許多高價值用例，由於法律問題或巨大的協調摩擦，協作目前非常昂貴（或不可能）。後者是基於MPC和FHE的解決方案可以大放異彩的地方。
3. 專業化勝過通用設計：建立一個新的鏈並引導一個由使用者和開發人員組成的社區是很困難的。因此，通用隱私基礎設施（L1/L2s）可能難以獲得牽引力。另一個問題涉及專業化;單一協議設計很難涵蓋整個權衡空間。在這個世界上，為現有生態系統（保密即服務）或專業用例（例如支付）提供隱私的解決方案將占上風。我們對後者持懷疑態度，儘管它給應用程式開發人員帶來了複雜性，他們需要自己實現一些密碼學（而不是被抽象出來）。
4. 監管繼續阻礙隱私解決方案的實驗：這對於構建隱私基礎設施和具有某些隱私保證的應用程序的任何人來說都是一個風險。非金融用例面臨較少的監管風險，但很難（幾乎不可能）控制在無需許可的隱私基礎設施上構建了什麼。在解決技術問題之前，我們可能會解決監管問題。
5. 對於大多數用例來說，MPC和基於FHE的方案的開銷仍然過高：雖然MPC主要受到通信開銷的影響，但FHE團隊在很大程度上依賴於硬件加速來提高性能。然而，如果我們可以推斷出專用硬件在ZK方面的演變，那麼在我們獲得適用於生產的FHE硬件之前，將需要更長的時間。正在致力於FHE硬件加速的團隊的例子包括Optalysys,fhela，和鈮.

總結

最終，一個鏈的強度只有其最脆弱的環節一樣強。對於可編程的隱私基礎設施而言，如果我們希望它能夠處理共享的私有狀態而不單一失敗點，則信任保證歸結為多方安全計算的信任保證。

儘管這篇文章可能聽起來對多方安全計算（MPC）持批評態度，但事實並非如此。MPC對於依賴於中央化第三方的現狀提供了巨大的改善。在我們看來，主要問題是整個行業對於錯誤的自信感以及被掩蓋的問題。相反，我們應該正視問題，重點評估潛在風險。

然而，並非所有問題都需要使用相同的工具來解決。即使我們相信多方安全計算是終極目標，只要多方安全計算解決方案的開銷仍然很高，替代方法仍然是可行的選擇。在考慮哪種方法最適合解決特定問題的需求/特徵以及我們願意做出哪些妥協時，值得慎重考慮。

即使你擁有世界上最好的鎚子，也不是一切都是釘子。

附錄1：區塊鏈隱私的不同方法

隱私增強技術或 PETs 旨在改善以上一個或多個方面。更具體地說，它們是保護數據在存儲、計算和通信過程中的技術解決方案。

有大量不同的PET可供选择，但區塊鏈行業中最相關的包括三個字母的湯- ZKP、多方安全計算、FHE和TEE-以及其他方法，如隱藏地址:

這些PET可以以不同的方式組合起來，以實現不同的權衡和信任假設。我們還有依賴於可信第三方（中介隱私）的解決方案，例如私人數據可用性委員會（DAC）。這些可以使其他用戶隱私，但隱私保證僅來自對第三方的信任。在這個意義上，它類似於“web2隱私”（來自其他用戶的隱私），但可以通過其他保證（加密或經濟）來加強。

總共，我們已經確定了11種在區塊鏈網絡中實現一些隱私保證的不同方法。觀察到的某些取捨包括：

• 可信與信任最小化隱私（是否存在單點故障？
• 硬件 vs 軟件方法
• 孤立的實例 vs 多個PET的組合
• L1 與 L2
• 新鏈 vs 為現有鏈添加隱私保護（“作為服務的機密性”）
• 遮罩集大小（多鏈>單鏈>應用>單一資產）

附錄2：行業概述

在這11個類別中，許多不同的公司正在研究一個或多個解決方案。以下是行業目前狀況的（非完整）概述：

免責聲明：

1. 本文轉載自 [平衡]，所有版權歸原作者所有[Hannes Huitula]. 如果對此轉載有異議，請聯繫 門學習團隊將會儘快處理。
2. 責任聲明：本文所表達的觀點和意見僅代表作者個人觀點，並不構成任何投資建議。
3. 文章到其他語言的翻譯由Gate Learn團隊完成。除非另有說明，否則禁止複製、分發或抄襲翻譯后的文章。