當我們在談論區塊鏈網絡中的隱私時,我們究竟指的是什麼?

進階8/23/2024, 8:26:16 AM
本文認為,區塊鏈網絡中的隱私對於更廣泛的採用至關重要,而不僅僅是一個理想的功能。它突顯了當前區塊鏈透明度所帶來的挑戰,並強調不同的用戶和用例將需要不同程度的隱私,暗示一刀切的方法是不夠的。

本文的觀點和假設:

  • 在區塊鏈網絡中,一些隱私是必不可少的,而不是一種好事
  • 區塊鏈目前的透明性是更廣泛採用的一大障礙
  • 不同的使用者和使用情境將需要不同程度的隱私。並非所有問題都需要用同一個工具解決。

個人用戶關心隱私嗎?

是的,但有些比其他的更多。

每個人都在某種程度上關心隱私,我們在日常生活中都對隱私做出了一些內在的假設。例如,在公司的 Slack 群組中撰寫消息時,您會假設只有您的同事可以看到這些消息。同樣地,許多人可以接受信用卡公司或銀行監控他們的交易,但不會想將他們的交易歷史廣播給全世界。

企業有額外的理由關心隱私(競爭、安全和監管),通常願意為此支付比個人用戶更高的費用。

另一個重要問題是:使用者想要隱私保護來自誰?

  1. 網絡的其他用戶和外部觀察者
  2. 第三方和中介機構提供服務
  3. 政府、政府機構和大規模監控

對於大多數用例來說,第一個是絕對必需的,如果我們接受較弱的保證(更多信息請參見下文),則當前區塊鏈網絡已經可以實現。第二個是我們作為一個行業正在努力實現的目標,以便給用戶更多控制權,避免那些擁有商業模式的公司在未經許可的情況下利用我們的數據。第三個—來自政府和政府機構的隱私權—從監管和政治角度來看是最棘手的。

我們如何定義“隱私”?

隱私不是保密。私人事務是指某人不希望整個世界都知道的事情,但秘密事務是指某人不希望任何人知道的事情。隱私是有選擇性地向世界展示自己的力量 - 一位密碼朋克的宣言

隱私是一個複雜的主題,涵蓋了幾個不同的(但相關的)主題,如數據主權(數據的個人所有權)、密碼學等。此外,人們通常在不同的上下文中寬鬆地使用這個術語,沒有明確的定義,這使得很難進行推理。像機密性(什麼)和匿名性(誰)這樣的術語經常被與隱私互換使用,盡管它們都只是隱私特性的一個子集。

關於隱私的一些關鍵問題是:

  • 如果需要,可以向誰透露什麼?
  • 誰有權力透露信息?
  • 系統運作需要向誰透露什麼?
  • 有什麼保證今天是私人的,明天也會是私人的嗎?

基於這些問題,我們可以總結成一句話:

隱私是關於用戶(數據所有者)對分享哪些數據以及與誰以及在什麼條件下進行控制,並且有強有力的保證所設定為私密的內容保持私密。

我們需要新的術語嗎?

考慮到以上情況,「隱私」對我們想要達到的目標來說是一個不好的術語嗎?也許是,也許不是。這取決於你如何對待它。

一方面,“隱私”這個術語似乎相當二元(某些事物要麼是私人的,要麼不是),但正如我們在上面所強調的,它比那更加微妙。不同的事物可以是私人的(輸入、輸出、與之互動的程式等),某些事物對某個人來說可能是私人的,但對另一個人來說是公開的,而不同的隱私解決方案背後存在著一系列信任假設。此外,這個術語帶有負面含義,可能會偏離實際話題的討論。

另一方面,“隱私”是一個眾所周知的詞語,已經有人們對此有了一定的認識。引入新的術語可能會令人困惑,特別是如果對於應該使用哪個新術語沒有共識的話。試圖用另一個術語規避問題似乎也有點不誠實,我們應該能夠直言不諱地談論事情的本質。

作為區塊鏈網絡的協議工程師和建立者,從新的角度觀察事物可以幫助我們檢測新的問題或揭示當前解決方案中的差距。像是廣泛隱私文獻中使用的信息流控制(在更廣泛的隱私文獻中使用)或者可編程披露(我們的建議)這樣的替代術語或許更能捕捉到微妙之處。信息對一些人來說可能是私人的,對其他人來說可能是公開的,由用戶決定要與誰分享哪些信息。

然而,在本文中,我們將堅持使用“隱私”一詞,以避免不必要的混淆。

Web2中的隱私與區塊鏈網絡有何不同?

大多數互聯網用戶熟悉web2“隱私”。我們的數據在傳輸過程中是加密的今天高達95%的所有流量) 並與其他用戶隔離,但與可信的中介和服務提供商共享。換句話說,“隱私”(對於其他用戶)來自於信任中介。

這種方法能讓用戶在與服務提供商之外分享其數據方面擁有一定的控制。然而,這也意味著用戶需要對服務提供商給予相當程度的信任,讓其能夠安全地保存和適當地處理數據。此外,由於對數據使用方式的保證有限,透明度很低,這意味著用戶只能寄望服務提供商能夠如其所宣稱的那樣行事(基於聲譽的模式)。

區塊鏈網絡旨在減少對中間人的依賴,並通過從基於聲譽的模型轉移到經濟或加密保證來提供更強的保證。然而,分散模型也帶來了新的挑戰,特別是隱私方面。節點需要同步並就網絡的當前狀態達成共識,當所有數據都是透明的並在所有節點之間共享時(現狀)這相對容易。當我們開始加密數據時,這將變得更加困難-這也是為什麼大多數區塊鏈網絡今天是透明的主要原因。

為什麼區塊鏈網絡中的隱私很難實現?

實現區塊鏈網絡隱私有兩種方式:可信(中介)或最小信任(非中介)隱私。

兩者都具有挑戰性,但原因不同(意識形態與技術)。 受信任的隱私更容易獲得,但保證較弱,需要犧牲一些區塊鏈的意識形態,依靠中央化的參與者和中間人。 最小化信任的隱私可以提供更強的保證,確保用戶控制其數據,但在技術和政治方面更加困難(如如何與當前法規保持合規性)。

區塊鏈網絡中的可信隱私

值得信賴的方法在某種程度上類似於Web2風格的隱私,可以實現與其他用戶的隱私,但需要信任第三方或中介來進行。這不需要太高的技術要求,使其成為需要一些隱私保證但對成本敏感且交易價值較低的項目的實用選擇。這方面的一個例子是Web3社交協議(例如,鏡網路),更加強調性能和實用性,而不是隱私保證的硬度。

一種簡單的方法是使用一個validium在這種情況下,一個數據可用性委員會(DAC)保存當前狀態,用戶信任DAC操作者保持該狀態的私密性並根據需要進行更新。另一個例子是Solana的代幣擴展,該方法利用ZKPs實現付款的機密性(隱藏帳戶餘額和交易),但允許指定具有稽核權利的可信第三方以確保合規性。

我們認為這個模型可以延伸目前的 web2 范式,在這種范式下,您僅信任一個中介來遵守規則。有了區塊鏈,純粹基於信任的模型可以與一些額外的保證(經濟或加密)結合起來,中介將會按預期行事,或至少增加這樣做的動機。

還有一些混合解決方案,其中一個最小信任解決方案依賴於集中式組件以改善成本、使用體驗或性能。這個類別中的例子包括將私有ZKPs的證明外包給單個證明者,或者一個集中式中介擁有解密密鑰的FHE網絡。

(我們將有權限的區塊鏈納入可信類別,但其他解決方案與無權限的區塊鏈相關)。

區塊鏈網絡中的信任最小化隱私

信任最小化的方法通過一個可信的中介來避免單點失敗,這可以提供更強的保證。然而,從技術角度來看,實施起來要困難得多。在大多數情況下,它需要結合現代加密解決方案和結構性變化,例如使用不同的帳戶結構。

現有的解決方案主要圍繞著專用用例,比如:

  • 金融:私人轉帳、付款和交換旨在隱藏身份、輸入和/或輸出(誰發送了什麼、多少和給誰)。不同解決方案之間的取捨包括單資產與多資產的隱藏池以及隱私程度。此處的示例包括ZcashNamada,和Penumbra.
  • 身份:對於任何需要我們將鏈外身份與鏈上身份聯繫起來或試圖在鏈上存儲身份文件的解決方案,隱私都是不容妥協的。私營部門(例如,護照驗證全名along with政府的興趣增加支持隱私保護的數字身份解決方案。
  • 治理:私有鏈上投票的概念是隱藏誰投了什麼,並在投票結束前保持總計數的私密性,以免影響任何個人的投票決定。下面的圖表列出了一些具有不同特性和信任假設的示例:

  • 一些現有解決方案概觀 ( 來源)

然而,許多應用案例都依賴共享狀態,當我們嘗試將最小化信任的隱私擴展到這些通用用例時,情況會變得更加具有挑戰性。

另一件需要注意的事情是,雖然專門的用例(支付、投票、身份等)可能單獨運行良好,但它們要求使用者在不同用例的遮罩集(信任區域)之間移動。這是次優的,因為大部分的資訊都外洩了當進出一個被保護的組合時。

因此,目標應該是為通用計算(包括需要共享狀態的所有用例)啟用隱私,擴展隱藏集合並添加細粒度訪問管理控制(表達能力)。

如何評估不同的解決方案?

雖然最終目標很明確,但要到達那裡的道路很漫長。與此同時,我們需要框架來評估當前的解決方案以及它們所做的取捨。我們認為取捨空間可以分為三個大類:

  1. 什麼是私有的 - 與區塊鏈相關的不同類型的隱私:
  1. 私人輸入(訊息)
  2. 私有輸出(狀態更改)
  3. 私人對手方
    1. 用戶
    2. 功能
    3. 程式

解決方案能夠滿足的盒子越多,越好。理想情況下,您希望擁有所有盒子,但這通常需要做出一些妥協。函數和程序隱私之間的區別在於一些系統允許隱藏調用了哪個函數(例如用戶使用的競標邏輯),但仍然顯示用戶與之交互的程序。程序隱私是這一形式的更嚴格的形式,其中所有函數調用以及與之交互的程序都是私有的。這個類別也是圍繞匿名性(誰)與機密性(什麼)的討論所在。

重要的是要注意,用戶可以選擇性地向某些方​​式披露其中一些(或全部),但如果它們中沒有一個是默認為私人的,則用戶就沒有這個選擇權。

  1. 可編程性-您可以使用隱私進行什麼?

這個類別著重於私人計算的可編程性以及其局限性所在:

  • 你能在加密的數據上進行計算嗎?私有程序之間有任何可組合性嗎?
  • 私人和公共状态可以以任何方式互动吗?这样做的限制和权衡是什么?
  • 你可以有多複雜的程式有什麼限制(燃氣限制,表達能力等)?

如前所述,許多應用程序(在現實世界中)需要一些共享狀態,這在最大程度上難以以最小化信任的方式實現。在這個領域有許多正在進行的工作和研究,幫助我們從僅需要本地狀態(例如支付)的特定應用程序隱私解決方案轉向具有共享狀態的通用可編程隱私。

可編程性還涉及具有細粒度工具,以有選擇性地披露某些信息並在需要時撤銷訪問權限(例如,當員工辭職時,我們希望確保他們不再能夠訪問公司特定或其他敏感信息)

  1. 隱私保證的可靠性 - 隱私有多可靠?

核心問題是:我們能有多大的把握,現在的隱私在未來仍然能夠保持私密(前向隱私),並且有什麼樣的保證支持這一點?

這包括像這樣的東西:

  • 用戶需要向可信任的第三方或中介分享哪些信息(如果有的話)?有哪些保證可以確保中介會如預期般行事?
  • 盾牌集有多大?(Multichain > 網絡(L1/L2)> 應用程序 > 單一資產)
  • 審查的風險是什麼?(應用程式對基礎層隱私)
  • 這個證明系統是量子證明的嗎?
  • 證明系統是否需要可信設置?如果是,有多少參與者?
  • 系統是否以隱私為默認,或者是否有其他激勵措施來最大化在受保護集合內的互動次數?

正如我們在上面所看到的,這個類別包括技術問題(例如,選擇哪種證明方案)和基於設計的問題(例如,添加增加隱藏集大小的激勵措施)。

這個權衡框架如何映射到帖子開頭提出的四個問題?

  • 如果需要,可以透露什麼以及透露給誰?這個問題涉及到私密性和可程式化的問題。如果所有信息默認為公開,那麼用戶與隱私相關的唯一選擇就是是否參與網絡。我們需要默認隱私來有選擇地披露信息(至少對其他用戶/外部觀察者的隱私)。可程式化可以被表示為細粒度的披露規則,即信息何時、向誰、披露什麼以及如何(以及撤銷)。
  • 誰有權透露資訊?這主要與隱私保證的強度有關,當只有使用者有權共用資訊(信任最小化隱私)時最強。
  • 必須向誰揭示什麼才能使系統發揮作用?主要與可程式設計性有關。理想情況下,您需要盡可能少地顯示資訊,同時仍然能夠計算共享狀態,在不同程式之間具有可組合性,並能夠建立新的信任關係。實際上,情況並非如此(至少在今天),需要做出一些權衡。
    • 從區塊鏈之外的更大範圍來看,零知識證明可以對隱私方面產生範式轉移,因為它們使我們能夠證明某些事情是真實的,而不必透露過多的信息。例如,當我們租房時,我們需要向房東證明我們有足夠的收入支付租金。今天,這需要我們發送整個銀行帳單,這會洩露很多額外的信息。未來,這種信任關係可能建立在簡明零知識證明的基礎上。
  • 有什麼保證可以確保今天的隱私在明天仍然是如此?“前向隱私”概念主要與隱私保證的強度有關。更大的保護集合將有助於此,並使外部觀察者更難提取信息。對中介機構的信任較少可能有所幫助,但不一定,即使用戶完全控制其數據,他們的密鑰可能會洩漏,數據可能會意外洩漏,或者洩漏的數據可能會被拷貝。這個領域仍然相對未被探索和研究,但隨著區塊鏈網絡中的隱私越來越廣泛地被採用,其重要性將增加。

總結

最終,它歸結為誰應該控制共用哪些數據 - 用戶或仲介。區塊鏈試圖增加個人主權,但這是一場具有挑戰性的鬥爭,因為最終控制是權力,而權力鬥爭是混亂的。這也與監管方面和合規性有關 - 這是非仲介或信任最小化隱私具有挑戰性的一個重要原因(即使我們解決了技術障礙)。

今天,討論的範圍廣泛集中在金融使用案例(付款、轉帳、交換等)的隱私上 - 部分原因是這是大多數採用的地方。然而,我們認為非金融使用案例同等重要,甚至可能比金融化的使用案例更重要,而且它們並沒有相同的負面假設。需要私人輸入或狀態(撲克、戰艦等)的遊戲或個人希望保護其原始文件安全的身份解決方案可以成為推動區塊鏈網絡中隱私正常化的強大動力。同一應用程序中可以有不同隱私級別的選項,用於不同的交易,或者在滿足某些條件時揭示一些信息。今天,大多數這些領域仍然未被充分探索。

在理想的世界裡,用戶對於什麼是私密的,以及對誰私密,應該具有充分的表達能力,同時還能夠強有力地保證被設置為私密的內容始終如一。在我們的隱私系列的第二部分中,我們將更仔細地研究不同的技術是如何實現這一點,以及它們之間的取捨。

區塊鏈上實現去信任化、私有化的通用計算還需要很長時間和艱苦努力,但最終值得。

免責聲明:

  1. 本文轉載自[平衡],原標題[當我們談論區塊鏈網络中的隱私時,我們實際上意味著什麼(以及為什麼很難實現)?],所有版權均屬於原作者[Hannes Huitula]. 如果對此轉載有異議,請聯繫。門學習團隊會盡快處理。
  2. 免責聲明:本文中表達的觀點和意見僅代表作者的觀點和意見,不構成任何投資建議。
  3. 文章的翻譯工作由 Gate Learn 團隊完成。未經許可,複製、分發或抄襲翻譯的文章是被禁止的。

當我們在談論區塊鏈網絡中的隱私時,我們究竟指的是什麼?

進階8/23/2024, 8:26:16 AM
本文認為,區塊鏈網絡中的隱私對於更廣泛的採用至關重要,而不僅僅是一個理想的功能。它突顯了當前區塊鏈透明度所帶來的挑戰,並強調不同的用戶和用例將需要不同程度的隱私,暗示一刀切的方法是不夠的。

本文的觀點和假設:

  • 在區塊鏈網絡中,一些隱私是必不可少的,而不是一種好事
  • 區塊鏈目前的透明性是更廣泛採用的一大障礙
  • 不同的使用者和使用情境將需要不同程度的隱私。並非所有問題都需要用同一個工具解決。

個人用戶關心隱私嗎?

是的,但有些比其他的更多。

每個人都在某種程度上關心隱私,我們在日常生活中都對隱私做出了一些內在的假設。例如,在公司的 Slack 群組中撰寫消息時,您會假設只有您的同事可以看到這些消息。同樣地,許多人可以接受信用卡公司或銀行監控他們的交易,但不會想將他們的交易歷史廣播給全世界。

企業有額外的理由關心隱私(競爭、安全和監管),通常願意為此支付比個人用戶更高的費用。

另一個重要問題是:使用者想要隱私保護來自誰?

  1. 網絡的其他用戶和外部觀察者
  2. 第三方和中介機構提供服務
  3. 政府、政府機構和大規模監控

對於大多數用例來說,第一個是絕對必需的,如果我們接受較弱的保證(更多信息請參見下文),則當前區塊鏈網絡已經可以實現。第二個是我們作為一個行業正在努力實現的目標,以便給用戶更多控制權,避免那些擁有商業模式的公司在未經許可的情況下利用我們的數據。第三個—來自政府和政府機構的隱私權—從監管和政治角度來看是最棘手的。

我們如何定義“隱私”?

隱私不是保密。私人事務是指某人不希望整個世界都知道的事情,但秘密事務是指某人不希望任何人知道的事情。隱私是有選擇性地向世界展示自己的力量 - 一位密碼朋克的宣言

隱私是一個複雜的主題,涵蓋了幾個不同的(但相關的)主題,如數據主權(數據的個人所有權)、密碼學等。此外,人們通常在不同的上下文中寬鬆地使用這個術語,沒有明確的定義,這使得很難進行推理。像機密性(什麼)和匿名性(誰)這樣的術語經常被與隱私互換使用,盡管它們都只是隱私特性的一個子集。

關於隱私的一些關鍵問題是:

  • 如果需要,可以向誰透露什麼?
  • 誰有權力透露信息?
  • 系統運作需要向誰透露什麼?
  • 有什麼保證今天是私人的,明天也會是私人的嗎?

基於這些問題,我們可以總結成一句話:

隱私是關於用戶(數據所有者)對分享哪些數據以及與誰以及在什麼條件下進行控制,並且有強有力的保證所設定為私密的內容保持私密。

我們需要新的術語嗎?

考慮到以上情況,「隱私」對我們想要達到的目標來說是一個不好的術語嗎?也許是,也許不是。這取決於你如何對待它。

一方面,“隱私”這個術語似乎相當二元(某些事物要麼是私人的,要麼不是),但正如我們在上面所強調的,它比那更加微妙。不同的事物可以是私人的(輸入、輸出、與之互動的程式等),某些事物對某個人來說可能是私人的,但對另一個人來說是公開的,而不同的隱私解決方案背後存在著一系列信任假設。此外,這個術語帶有負面含義,可能會偏離實際話題的討論。

另一方面,“隱私”是一個眾所周知的詞語,已經有人們對此有了一定的認識。引入新的術語可能會令人困惑,特別是如果對於應該使用哪個新術語沒有共識的話。試圖用另一個術語規避問題似乎也有點不誠實,我們應該能夠直言不諱地談論事情的本質。

作為區塊鏈網絡的協議工程師和建立者,從新的角度觀察事物可以幫助我們檢測新的問題或揭示當前解決方案中的差距。像是廣泛隱私文獻中使用的信息流控制(在更廣泛的隱私文獻中使用)或者可編程披露(我們的建議)這樣的替代術語或許更能捕捉到微妙之處。信息對一些人來說可能是私人的,對其他人來說可能是公開的,由用戶決定要與誰分享哪些信息。

然而,在本文中,我們將堅持使用“隱私”一詞,以避免不必要的混淆。

Web2中的隱私與區塊鏈網絡有何不同?

大多數互聯網用戶熟悉web2“隱私”。我們的數據在傳輸過程中是加密的今天高達95%的所有流量) 並與其他用戶隔離,但與可信的中介和服務提供商共享。換句話說,“隱私”(對於其他用戶)來自於信任中介。

這種方法能讓用戶在與服務提供商之外分享其數據方面擁有一定的控制。然而,這也意味著用戶需要對服務提供商給予相當程度的信任,讓其能夠安全地保存和適當地處理數據。此外,由於對數據使用方式的保證有限,透明度很低,這意味著用戶只能寄望服務提供商能夠如其所宣稱的那樣行事(基於聲譽的模式)。

區塊鏈網絡旨在減少對中間人的依賴,並通過從基於聲譽的模型轉移到經濟或加密保證來提供更強的保證。然而,分散模型也帶來了新的挑戰,特別是隱私方面。節點需要同步並就網絡的當前狀態達成共識,當所有數據都是透明的並在所有節點之間共享時(現狀)這相對容易。當我們開始加密數據時,這將變得更加困難-這也是為什麼大多數區塊鏈網絡今天是透明的主要原因。

為什麼區塊鏈網絡中的隱私很難實現?

實現區塊鏈網絡隱私有兩種方式:可信(中介)或最小信任(非中介)隱私。

兩者都具有挑戰性,但原因不同(意識形態與技術)。 受信任的隱私更容易獲得,但保證較弱,需要犧牲一些區塊鏈的意識形態,依靠中央化的參與者和中間人。 最小化信任的隱私可以提供更強的保證,確保用戶控制其數據,但在技術和政治方面更加困難(如如何與當前法規保持合規性)。

區塊鏈網絡中的可信隱私

值得信賴的方法在某種程度上類似於Web2風格的隱私,可以實現與其他用戶的隱私,但需要信任第三方或中介來進行。這不需要太高的技術要求,使其成為需要一些隱私保證但對成本敏感且交易價值較低的項目的實用選擇。這方面的一個例子是Web3社交協議(例如,鏡網路),更加強調性能和實用性,而不是隱私保證的硬度。

一種簡單的方法是使用一個validium在這種情況下,一個數據可用性委員會(DAC)保存當前狀態,用戶信任DAC操作者保持該狀態的私密性並根據需要進行更新。另一個例子是Solana的代幣擴展,該方法利用ZKPs實現付款的機密性(隱藏帳戶餘額和交易),但允許指定具有稽核權利的可信第三方以確保合規性。

我們認為這個模型可以延伸目前的 web2 范式,在這種范式下,您僅信任一個中介來遵守規則。有了區塊鏈,純粹基於信任的模型可以與一些額外的保證(經濟或加密)結合起來,中介將會按預期行事,或至少增加這樣做的動機。

還有一些混合解決方案,其中一個最小信任解決方案依賴於集中式組件以改善成本、使用體驗或性能。這個類別中的例子包括將私有ZKPs的證明外包給單個證明者,或者一個集中式中介擁有解密密鑰的FHE網絡。

(我們將有權限的區塊鏈納入可信類別,但其他解決方案與無權限的區塊鏈相關)。

區塊鏈網絡中的信任最小化隱私

信任最小化的方法通過一個可信的中介來避免單點失敗,這可以提供更強的保證。然而,從技術角度來看,實施起來要困難得多。在大多數情況下,它需要結合現代加密解決方案和結構性變化,例如使用不同的帳戶結構。

現有的解決方案主要圍繞著專用用例,比如:

  • 金融:私人轉帳、付款和交換旨在隱藏身份、輸入和/或輸出(誰發送了什麼、多少和給誰)。不同解決方案之間的取捨包括單資產與多資產的隱藏池以及隱私程度。此處的示例包括ZcashNamada,和Penumbra.
  • 身份:對於任何需要我們將鏈外身份與鏈上身份聯繫起來或試圖在鏈上存儲身份文件的解決方案,隱私都是不容妥協的。私營部門(例如,護照驗證全名along with政府的興趣增加支持隱私保護的數字身份解決方案。
  • 治理:私有鏈上投票的概念是隱藏誰投了什麼,並在投票結束前保持總計數的私密性,以免影響任何個人的投票決定。下面的圖表列出了一些具有不同特性和信任假設的示例:

  • 一些現有解決方案概觀 ( 來源)

然而,許多應用案例都依賴共享狀態,當我們嘗試將最小化信任的隱私擴展到這些通用用例時,情況會變得更加具有挑戰性。

另一件需要注意的事情是,雖然專門的用例(支付、投票、身份等)可能單獨運行良好,但它們要求使用者在不同用例的遮罩集(信任區域)之間移動。這是次優的,因為大部分的資訊都外洩了當進出一個被保護的組合時。

因此,目標應該是為通用計算(包括需要共享狀態的所有用例)啟用隱私,擴展隱藏集合並添加細粒度訪問管理控制(表達能力)。

如何評估不同的解決方案?

雖然最終目標很明確,但要到達那裡的道路很漫長。與此同時,我們需要框架來評估當前的解決方案以及它們所做的取捨。我們認為取捨空間可以分為三個大類:

  1. 什麼是私有的 - 與區塊鏈相關的不同類型的隱私:
  1. 私人輸入(訊息)
  2. 私有輸出(狀態更改)
  3. 私人對手方
    1. 用戶
    2. 功能
    3. 程式

解決方案能夠滿足的盒子越多,越好。理想情況下,您希望擁有所有盒子,但這通常需要做出一些妥協。函數和程序隱私之間的區別在於一些系統允許隱藏調用了哪個函數(例如用戶使用的競標邏輯),但仍然顯示用戶與之交互的程序。程序隱私是這一形式的更嚴格的形式,其中所有函數調用以及與之交互的程序都是私有的。這個類別也是圍繞匿名性(誰)與機密性(什麼)的討論所在。

重要的是要注意,用戶可以選擇性地向某些方​​式披露其中一些(或全部),但如果它們中沒有一個是默認為私人的,則用戶就沒有這個選擇權。

  1. 可編程性-您可以使用隱私進行什麼?

這個類別著重於私人計算的可編程性以及其局限性所在:

  • 你能在加密的數據上進行計算嗎?私有程序之間有任何可組合性嗎?
  • 私人和公共状态可以以任何方式互动吗?这样做的限制和权衡是什么?
  • 你可以有多複雜的程式有什麼限制(燃氣限制,表達能力等)?

如前所述,許多應用程序(在現實世界中)需要一些共享狀態,這在最大程度上難以以最小化信任的方式實現。在這個領域有許多正在進行的工作和研究,幫助我們從僅需要本地狀態(例如支付)的特定應用程序隱私解決方案轉向具有共享狀態的通用可編程隱私。

可編程性還涉及具有細粒度工具,以有選擇性地披露某些信息並在需要時撤銷訪問權限(例如,當員工辭職時,我們希望確保他們不再能夠訪問公司特定或其他敏感信息)

  1. 隱私保證的可靠性 - 隱私有多可靠?

核心問題是:我們能有多大的把握,現在的隱私在未來仍然能夠保持私密(前向隱私),並且有什麼樣的保證支持這一點?

這包括像這樣的東西:

  • 用戶需要向可信任的第三方或中介分享哪些信息(如果有的話)?有哪些保證可以確保中介會如預期般行事?
  • 盾牌集有多大?(Multichain > 網絡(L1/L2)> 應用程序 > 單一資產)
  • 審查的風險是什麼?(應用程式對基礎層隱私)
  • 這個證明系統是量子證明的嗎?
  • 證明系統是否需要可信設置?如果是,有多少參與者?
  • 系統是否以隱私為默認,或者是否有其他激勵措施來最大化在受保護集合內的互動次數?

正如我們在上面所看到的,這個類別包括技術問題(例如,選擇哪種證明方案)和基於設計的問題(例如,添加增加隱藏集大小的激勵措施)。

這個權衡框架如何映射到帖子開頭提出的四個問題?

  • 如果需要,可以透露什麼以及透露給誰?這個問題涉及到私密性和可程式化的問題。如果所有信息默認為公開,那麼用戶與隱私相關的唯一選擇就是是否參與網絡。我們需要默認隱私來有選擇地披露信息(至少對其他用戶/外部觀察者的隱私)。可程式化可以被表示為細粒度的披露規則,即信息何時、向誰、披露什麼以及如何(以及撤銷)。
  • 誰有權透露資訊?這主要與隱私保證的強度有關,當只有使用者有權共用資訊(信任最小化隱私)時最強。
  • 必須向誰揭示什麼才能使系統發揮作用?主要與可程式設計性有關。理想情況下,您需要盡可能少地顯示資訊,同時仍然能夠計算共享狀態,在不同程式之間具有可組合性,並能夠建立新的信任關係。實際上,情況並非如此(至少在今天),需要做出一些權衡。
    • 從區塊鏈之外的更大範圍來看,零知識證明可以對隱私方面產生範式轉移,因為它們使我們能夠證明某些事情是真實的,而不必透露過多的信息。例如,當我們租房時,我們需要向房東證明我們有足夠的收入支付租金。今天,這需要我們發送整個銀行帳單,這會洩露很多額外的信息。未來,這種信任關係可能建立在簡明零知識證明的基礎上。
  • 有什麼保證可以確保今天的隱私在明天仍然是如此?“前向隱私”概念主要與隱私保證的強度有關。更大的保護集合將有助於此,並使外部觀察者更難提取信息。對中介機構的信任較少可能有所幫助,但不一定,即使用戶完全控制其數據,他們的密鑰可能會洩漏,數據可能會意外洩漏,或者洩漏的數據可能會被拷貝。這個領域仍然相對未被探索和研究,但隨著區塊鏈網絡中的隱私越來越廣泛地被採用,其重要性將增加。

總結

最終,它歸結為誰應該控制共用哪些數據 - 用戶或仲介。區塊鏈試圖增加個人主權,但這是一場具有挑戰性的鬥爭,因為最終控制是權力,而權力鬥爭是混亂的。這也與監管方面和合規性有關 - 這是非仲介或信任最小化隱私具有挑戰性的一個重要原因(即使我們解決了技術障礙)。

今天,討論的範圍廣泛集中在金融使用案例(付款、轉帳、交換等)的隱私上 - 部分原因是這是大多數採用的地方。然而,我們認為非金融使用案例同等重要,甚至可能比金融化的使用案例更重要,而且它們並沒有相同的負面假設。需要私人輸入或狀態(撲克、戰艦等)的遊戲或個人希望保護其原始文件安全的身份解決方案可以成為推動區塊鏈網絡中隱私正常化的強大動力。同一應用程序中可以有不同隱私級別的選項,用於不同的交易,或者在滿足某些條件時揭示一些信息。今天,大多數這些領域仍然未被充分探索。

在理想的世界裡,用戶對於什麼是私密的,以及對誰私密,應該具有充分的表達能力,同時還能夠強有力地保證被設置為私密的內容始終如一。在我們的隱私系列的第二部分中,我們將更仔細地研究不同的技術是如何實現這一點,以及它們之間的取捨。

區塊鏈上實現去信任化、私有化的通用計算還需要很長時間和艱苦努力,但最終值得。

免責聲明:

  1. 本文轉載自[平衡],原標題[當我們談論區塊鏈網络中的隱私時,我們實際上意味著什麼(以及為什麼很難實現)?],所有版權均屬於原作者[Hannes Huitula]. 如果對此轉載有異議,請聯繫。門學習團隊會盡快處理。
  2. 免責聲明:本文中表達的觀點和意見僅代表作者的觀點和意見,不構成任何投資建議。
  3. 文章的翻譯工作由 Gate Learn 團隊完成。未經許可,複製、分發或抄襲翻譯的文章是被禁止的。
Mulai Sekarang
Daftar dan dapatkan Voucher
$100
!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Thailand, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.