什么是托管證明？

感謝  Vitalik Buterin、Chih-Cheng Liang 和 Alex Stokes 富有助益的評論

托管證明 (Proof of Custody) 是一種有助於解決“懶惰驗證者“問題的構造。懶惰的驗證者有這樣的表現：他們不做他們應該做的工作，例如確保一些數據是可用的 (與數據分片有關) ，或一些執行是正確的 (用於執行鏈)——他們假裝他們已經做了，並對結果籤名，例如無論如何，證明都聲稱數據是可用的。

托管證明這個構造是一個改變博弈論的加密經濟學基元，使懶惰驗證不再是一個有吸引力的策略。

懶惰驗證者的策略

假設我們有一條運行良好的以太坊2.0鏈 (你可以代入你最喜歡的其他 PoS 區塊鏈)。我們通常不期望壞事發生——出現數據被扣留，生成無效區塊的情況。事實上，你可能甚至沒看過這些情況的發生，因為只要系統由大多數的誠實驗證者來運行，甚至沒有必要試圖以這些方式攻擊它。因為這種攻擊幾乎可以確定會失敗，這樣做時沒有意義的。

現在假設你運行一個驗證者。這會有不同的成本——明顯會有質押資金，但還有硬件成本、電力和網絡寬帶，這些都或直接 (你的供應商按每 GB 收費) 或間接 (當你的驗證者在運行時，你的 netflix 播放會網速不夠) 此需要支付。你能把开銷壓得越低，你就能從運行驗證者獲得越多的淨收益。

在分片 Eth2 裏你要做的其中一個任務是，保證分片數據的可用性。每個證明委員會都會分到一個 blob 的數據需要做驗證，大小大約是 512kB 到 1 MB。每個驗證者的任務就是下載它並存儲 90 天左右。

但是，如果你只是簡單地對分片數據的全部證明籤名，而不是真的下載那些數據，會發生什么？你還會獲得全部的獎勵，但你的成本會突然減少了。我們假設網絡處於良好狀態，這樣你的懶惰不會馬上對網絡造成什么影響。假設你運行驗證者的收益是每投一次票獲得 1 美元，而每年下載所有區塊的开銷是 0.10 美元。現在，你的收益就增加到 1.1 美元。

這個問題被稱為驗證者困境，並由 Luu 等人在論文《解密共識計算機中的激勵機制 (Demystifying Incentives in the Consensus Computer)》中提出。

但我決不會這樣做！誰會這樣作弊啊？

在我們看來，在這樣的博弈中，你肯定不會去做賄賂這樣的事，而是保持誠實履行職責。但事情往往比這更微妙。

讓我們假設，在運行了驗證者多年後，有一個新客戶端出現了，並聲稱其成本效益提高了 10%。人們運行它，發現它真的有效，而且似乎也是安全的。而它實際做到這一點的方法就是不下載分片區塊。

這甚至可能是意外發生的。有人在开發過程中偷工減料，一切看起來都很正常，它只是沒有加入正確的分片子網且沒有人在意這點，因為它不會在正常運行中造成任何故障。

有些人可能會運行這個客戶端。

其他可能發生的事情是，會出現幫你下載的服務。每個分片數據 0.01 美元，他們會下載那些數據，存儲 90 天，然後給你發送信息說數據可用，你可以對證明籤名了。這種情況有多壞？

這相當糟糕。因為隨着很多人开始使用這項服務時，它就成了一個單點故障。或更糟糕的是，它可能成為攻擊的一部分。如果它能讓超過 50% 的驗證者對一個分片數據的可用性投票，而不發布該數據，這將構成一次扣留攻擊 (withholding attack)。

如通常情況一樣，不誠實行為可以有很多僞裝，因此我們最好的措施是在使誠實的策略是理性的，從而達到平衡。

托管證明與新的博弈

托管證明的工作原理是這樣的：想象一下，我們可以在一個分片數據裏放入一個“炸彈”——如果你對這個數據籤名，你會遭受很嚴重的懲罰 (你會被罰沒)，3000 美元。這樣，你肯定不會想對這個數據籤名。

那這會讓你想下載數據嗎？這肯定是避免對炸彈籤名的一個方法。但是，如果任何人都能檢測到這個炸彈，然後有人就可以簡單地寫這樣一個服務：如果它是一個炸彈的話，在你對證明籤名前警告你。因此，炸彈需要是針對某個個人驗證者，且沒有其他人可以計算出這個分片數據是否是一個炸彈。

好了，現在我們有了托管證明的基本素材了。我們需要：

• 一個臨時祕密 (ephermeral secret)，每個托管周期 (約 90 天) 後都要對其重新計算，對每個驗證者來說都是獨立的，然後在過期後再披露 (這樣其他驗證者就有機會檢查托管證明了)

  
  

• 一個函數，它獲取整個分片 blob 數據還有臨時密鑰 (ephemeral key)，輸出是 0 (表示不是炸彈)，或以極小的概率輸出 1 (表示這個 blob 是炸彈)

這裏的關鍵是，臨時祕密是不能讓其他人知道的，因此會有三個罰沒條件：

• 如果任何人知道了當前的臨時祕密，該驗證者會被罰沒

  
  

• 臨時祕密必須在托管周期結束後公布，沒有做到這點也會被罰沒

  
  

• 對炸彈籤名會導致罰沒

我們如何創建這個函數？一個簡單的構造會這樣運作：計算一個默克爾樹的葉子節點 (data0, secret, data1, secret, data2, secret, ...) ，如下所示：

然後把前 10 位輸入到邏輯函數  AND。然後它會給你一個比特，在預期的 1024 次中有 1 次是 1。

如果不知道祕密和數據，就無法計算出這個函數的結果。

(因為我們確實想實現在驗證者間共享祕密，所以在優化這個函數方面已經做了大量的工作，以便它可以在 MPC 中進行有效計算，而默克爾樹則不能。因此，我們建議採用基於通用哈希函數和勒讓德 (Legendre) 符號的結構：https://ethresear.ch/t/using-the-legendre-symbol-as-a-prf-for-the-proof-of-custody/5169)

新的博弈

好了，現在有了托管證明，任何分片數據都有 1/1024 的機會是炸彈，不下載它你就不知道哪個是。

當數據不是炸彈時，懶惰的驗證者不會有什么問題。但是，當它是炸彈時，我們會看到巨大的差異：誠實驗證者只會跳過這個證明，因為它影響很小，只是將收益設為 0。但是，懶惰的驗證者對它籤名就會被罰沒，造成巨大損失。現在的收益矩陣看起來是這樣的：

在第三欄，我們看到懶惰驗證者的預期收益現在是負數。由於懶惰的所有原因是通過減低成本來增加收益，這意味着懶惰驗證者現在不再是一個吸引人的策略。

用於執行的托管證明

驗證者的另一個任務是驗證區塊的正確執行。這意味着需要驗證新的狀態根，它是應用所有事務後驗證區塊是否正確的一部分。托管證明這個想法還能應用到這種情況：驗證者將不需以上述同樣的方式計算托管證明，但是數據是執行痕跡。執行痕跡是由一步步區塊執行生成的一些輸出。它在任何意義上都不需要是完整的；我們只想要它的兩個特性：

• 在沒有實際執行區塊的情況下應該是難以猜到執行痕跡的。

• 執行痕跡的總大小應該足夠大，以至於簡單地將其累加到正常區塊上是不理想的。

要這樣做還有一些簡單的選項；例如，簡單地輸出 EVM 執行的每一單條指令字節，可能會導致每個執行區塊有幾 MB 的執行痕跡。另一個選擇是使用棧頂。

有了欺詐證明，執行上我們還需要托管證明嗎？

當我們把執行鏈升級到無狀態，這意味着區塊驗證可以不用到當前的狀態，欺詐證明變得很容易。(如果沒有無狀態，就很難：欺詐證明總是必須被打包到不同於欺詐所發生的鏈，因此當欺詐證明必須被驗證時，實際的前狀態將不可用了。)

這意味着，如果一個驗證者出了一個無效執行區塊，他有可能會被罰沒。此外，我們還可以懲罰任何對此區塊做過證明投票的驗證者。這是否意味着不再需要監護證明呢？

它肯定會改變雙方的權衡。但即使有了這項懲罰，懶惰驗證仍然是一個理性策略。對於驗證者來說，簡單地對每個區塊籤名而不驗證不是一個好主意，因為攻擊者只需犧牲他們自己一個驗證者，你就會遭受罰沒。

但是，你可以採用以下策略：在每個新區塊上，在你自己籤名前，等一小部分其他驗證者先對它籤名。那些最先對它籤名的不太可能是懶惰的驗證者，因為他們會採用相同的策略。在大多數情況下，這將給你帶來相當好的保護，但在系統層面上，區塊鏈仍然會在一些極端情況下容易遭到攻擊。

欺詐證明的情況因此得到了改善，但托管證明對於確保懶惰驗證不能成為一個理性策略來說仍然更勝一籌。

它與數據可用性檢查有何不同？

我寫過一篇關於數據可用性檢查的入門文章。用於分片數據的托管證明似乎嘗試解決一個非常相似的問題：確保提交到分片 blob 頭的數據在網絡上是確實可用的。

所以我們可能會想知道：我們是否同時需要托管證明和數據可用性檢查？

不過，這兩種構造之間有一個重要區別：

• 數據可用性檢查確保數據可用性獨立於誠實大多數的假設。即使是一個控制了全部押金的強大攻擊者也無法騙過所有節點，讓它們接受實際上被扣留的數據是可用的。

  
  

• 相比之下，如果大多數的權益都在進行攻擊的話，監護證明並沒有幫助。攻擊的大多數可以計算出監護證明，而無需向任何人披露該數據。

因此，從理論上講，數據可用性檢查嚴格來說是優於分片數據的托管證明的：它們是無條件成立的，而後者只是為了讓理性的驗證者保持誠實，是攻擊事件的發生幾率更低。

為什么我們仍然需要用於分片數據的監護證明呢？它可能不一定需要。然而，在數據可用性檢查方面存在一些實際問題，使得它需要一個防止丟失數據的“第一道防线”：

其原因是，數據可用性檢查的工作原理是將不可用的區塊通過分叉選擇規則中排除出去。但是，這不可能是永久性的：數據可用性檢查只能確保最終，每個人都會看到相同的結果，但不是即時的。

這樣做的原因是，發布一個部分可用的區塊，可能會導致有些節點以為它是可用的 (他們看到所有的樣本)，而其他一些節點認為它是不可用的 (缺乏一些樣本)。數據可用性檢查確保在這些情況下，數據總是可以被重構的。然而，這需要一些節點首先獲得足夠的樣本來重構數據， 然後重新播種樣本，這樣每個人都可以看到；這個過程需要幾個 slot。

為了避免少數驗證者(擁有少於 1/3 的押金)參與的攻擊  造成這樣破壞，我們只想在鏈被最終敲定時應用數據可用性檢查，而不是立即應用。同時，監護證明可以確保誠實的大多數將僅會構建一條可用的鏈，其中的分片數據已經播種在委員會裏；由於委員會准備重新播種所有樣本，即使初始的 blob 生產者不這樣做，攻擊者也不能輕易強迫一個部分可用的區塊這樣做。

在這個構造中，監護證明和數據可用性檢查有兩個正交功能：

• 用於分片數據的監護證明確保了誠實的大多數驗證將只會構建一條鏈，其中所有的分片數據都是可用的，並會穩妥地播種到各個委員會。一個少數驗證者構成的攻擊不能輕易造成破壞。

  
  

• 數據可用性檢查將保證，即使佔大多數押金的驗證者參與攻擊，它們也不能迫使剩余的全節點認為有扣留數據的區塊鏈是被最終敲定的。

來源 | dankradfeist.de

作者 | Dankrad Feist

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。