介紹

以太坊的路線圖包含了一種名爲“數據可用性採樣 (DAS) 。DAS 引入新的 @djrtwo/das-requirements">需求4 ，需要實現 專用網絡協議 7。其中一位重要的@dankrad/S-Kademlia-DAS">協議提案 4 使用基於分布式哈希錶（DHT）Kademlia2 來存儲和檢索數據樣本。

然而，DHTs4 容易受到 Sybil 攻擊：控製大量 DHT 節點的攻擊者可以使 DAS 樣本不可用。爲了應對這種威脅，可以建立一個高信任的網絡層，僅由信標鏈驗證器組成。這樣的安全措施極大地提高了攻擊者的門檻，因爲他們現在必鬚抵押自己的 ETH 來攻擊 DHT。

在這篇文章中，我們介紹了一個驗證者的證明 協議，使 DHT 參與者能夠以零知識證明他們是以太坊驗證者。

動機：對 DAS 的“樣本隱藏”攻擊

在本節中，我們進一步激勵驗證者的證明協議，描述了針對數據可用性採樣的女巫 (Sybil) 攻擊。

DAS 協議圍繞區塊構建器展開，確保區塊數據可用，以便客戶端可以穫取它們。目前的方法涉及將數據畫分爲樣本，併且網絡參與者僅穫取與其興趣相關的樣本。

考慮這樣一種場景：Sybil 攻擊者希望阻止網絡參與者從負責提供樣本的受害者節點穫取樣本。如上圖所示，攻擊者生成了許多與受害者節點ID接近的節點ID。通過用自己的節點包圍受害者的節點，攻擊者阻止客戶端髮現受害者節點，因爲作惡的節點會故意隱瞞有關受害者存在的信息。

有關此類 Sybil 攻擊的更多信息，請參閲此最近的研究論文2 關於 DHT Eclipse 攻擊。此外，@dankrad/S-Kademlia-DAS#SKademlia-modifications">Dankrad 的 DAS 網絡協議提案 8 描述了 S/Kademlia DHT 協議如何遭受此類攻擊，併錶明需要一種驗證者的證明協議。

驗證者證明（Proof of Validator）

上述攻擊激髮了對驗證者的證明協議：如果隻有驗證者可以加入DHT，那麽想要髮起Sybil攻擊的攻擊者也必鬚質押大量的ETH。

使用我們的驗證者的證明協議我們確保隻有信標鏈驗證器可以加入 DHT，併且每個驗證器都穫得唯一的 DHT 身份。

此外，爲了驗證者 DoS 彈性，我們還緻力於在網絡層隱藏驗證者的身份。也就是説，我們不希望攻擊者能夠知道哪個 DHT 節點對應於哪個驗證器。

爲了實現這些目標，驗證者協議的證明必鬚滿足以下要求：

• 獨特性：每個信標鏈驗證器必鬚能夠派生出一個唯一的密鑰對。此屬性不僅限製 Sybil 攻擊者可以生成的節點數量，還使網絡參與者能夠通過將其派生密鑰對列入黑名單來在本地懲罰行爲不當的節點
• 隱私：對手必鬚無法了解哪個驗證器對應於特定的派生公鑰
• 驗證時間：協議的驗證過程必鬚高效，每個節點花費的時間少於200ms，使每個節點每秒至少學習5個新節點

這樣一個驗證者的證明 Bob 在 DHT 層中建立連接期間將使用協議，以便 Alice 知道她正在與驗證者進行通信。

驗證者協議證明 (Proof of Validator protocol)

我們的驗證者的證明 協議實際上是一個簡單的匿名憑證方案。其目標是使 Alice 能夠生成唯一的派生密鑰，錶示爲D，當且僅當她是驗證者時。隨後，愛麗絲使用這個派生密鑰D 在網絡層內。

在設計此協議時，我們的目標是創建一個易於實施和分析的解決方案，確保其有效地滿足概述的要求。

協議概述

該協議採用了會員證明子協議，其中 Alice 通過使用零知識證明證明來證明她是驗證者，證明她知道一個秘密哈希前像。然後，Alice 根據該秘密前像構建了一個唯一的密鑰對。

這會員證明子協議 可以通過不衕的方法實例化。在這篇文章中，我們展示了一個使用的協議Merkel 樹和一種使用查找的第二種協議。

雖然這兩種方法都顯示出可接受的效率，但它們具有明顯的權衡。 Merkle 樹依賴於 SNARK 友好的哈希函數，如 Poseidon（可能被認爲是實驗性的）。另一方麵，高效的查找協議依賴於與驗證者集合大小相等的powers-of-tau可信設置（目前爲70萬個驗證者，但會增長）。

現在讓我們深入研究協議：

方法#1：默剋爾樹 (Merkle Tree)

Merkle 樹已廣泛用於成員證明（例如，參見Semaphore3）。以下是使用 Merkle 樹設計成員資格證明時的權衡空間：

• 優點：不需要可信設置
• 優點：簡單易懂
• 缺點：依賴於 SNARK 友好的哈希函數，如 Poseidon
• 負麵：證明創建速度較慢

下麵我們描述基於 Merkle 樹的驗證器協議的證明：

使用 Merkle 樹的驗證者證明協議

在協議結束時，Alice 可以使用 D 在 DHT 中對消息進行簽名併派生出她唯一的 DHT 節點身份。

現在讓我們來看一個稍微覆雜一些，但更高效的解決方案，使用查找。

方法#2：查找 (Lookups)

這是使用 Lookup 2 （如Caulk 2）的權衡空間：

• 正麵：極其高效的證明創建（使用預處理階段）
• 正麵：協議可以調整爲使用常規哈希函數而不是 Poseidon
• 負麵：需要大尺寸的可信設置（理想情況下等於驗證器的大小）

下麵我們描述一個具體的驗證者協議證明：

使用查找的驗證器協議證明

就像 Merkle 方法一樣，每個驗證器我 註冊一個新值p我 在區塊鏈上：

效率

我們對會員證明協議的運行時間進行了基準測試（鏈接6 到 基準代碼5）。我們主要關註證明的創建和驗證時間。請註意，雖然成員證明隻是我們驗證者協議的一部分，但我們預計它將主導整體運行時間。

下麵我們提供了使用 Halo2 證明繫統和 IPA 作爲多項式承諾方案的 Merkle 樹成員資格證明的基準測試結果。 IPA 是一種比 KZG 慢的方案，但它不需要可信設置，可以最大限度地髮揮 Merkle 樹方法的優勢。

我們觀察到證明者和驗證者的時間都符合我們的效率要求。因此，我們決定不對基於 Caulk 的方法進行基準測試，因爲預計其在所有類別（尤其是證明時間和證明大小）中的性能都會明顯更好。

基準測試是在運行 Intel i7-8550U（五年前的 CPU）的筆記本電腦上收集的。

討論

輪換身份

這獨特性 的財産驗證者的證明 協議確保每個網絡參與者擁有不衕的派生密鑰對。然而，對於某些網絡協議，允許驗證者具有輪換身份可能是有利的，其中它們的派生密鑰定期（也許每天）更改。

在這種情況下，如果 Eve 在某一天行爲不端，Alice 可以將她當天列入黑名單。但是，第二天，Eve 可以生成一個新的派生密鑰，該密鑰未列入黑名單。如果我們希望能夠根據輪換身份將驗證器永久列入黑名單，我們將需要更先進的匿名憑證方案，例如SNARKBlock 1。

爲什麽不使用身份 BLS12-381 公鑰？

另一種方法（也許更簡單）是從所有驗證者身份 BLS12-381 密鑰中構建承諾，併對該承諾進行成員資格證明。

然而，這種方法需要驗證者將其身份私鑰插入到零知識證明繫統中，以創建有效的成員身份證明併計算唯一的派生密鑰。

我們決定不採用這種方法，因爲將敏感的身份密鑰插入覆雜的加密協議中併不是一個好的做法，而且這也會使驗證者更難保持其主要身份密鑰離線。

未來的研究方曏

• 我們能否完全避免 SNARK 電路，併以純代數的方式執行成員資格證明和密鑰派生？
• 相關問題：我們能否在沒有可信設置和不依賴於SNARK友好哈希函數的情況下，擁有高效的“成員證明”協議？

緻謝

感謝 Enrico Bottazzi、Cedoor、Vivian Plasencia 和 Wanseob 在瀏覽會員證明代碼庫網絡方麵提供的幫助。

聲明：

1. 本文轉載自[ethresear]，著作權歸屬原作者[George Kadianakis , Mary Maller, Andrija Novakovic, Suphanat Chunhapanya]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。