觀點 | 為什麼說數據可用性檢查對區塊鏈擴容方案很重要?

來源 | dankradfeist.de

作者 | Dankrad Feist

原標題:《數據可用性檢查

數據可用性檢查須知

本文旨在解釋數據可用性檢查,以及為什麼區塊鏈的擴容方案,例如以太坊 2.0,需要它們。本文預設了讀者具有區塊鏈 (例如比特幣和以太坊) 的基本背景知識、最好對現在使用的共識算法 (工作量證明和權益證明) 也有所了解。為了簡單起見,解釋內容將建基於權益證明鏈——由所有具有相同權重的全節點運行共識協議,具有 2/3 誠實假設;但這些分析同樣適用於工作量證明和其他協議。

入門知識

想想看,區塊鏈有全節點和輕客戶端,還有一個點對點網絡,它可能對數據是有損的,但不會自適應地審查數據。相對於全節點來說,輕客戶端是一個更便宜的選擇。在傳統的區塊鏈協議里,我們假設所有客戶端都運行全節點,驗證在狀態轉換中的每一筆交易。運行一個全節點要求計算機有大量的內存、算力和帶寬。對於移動客戶端和許多資源受限的環境來說,這個成本可能太高了。

輕客戶端是只需下載每個區塊的區塊頭的節點,它們信任全節點對狀態轉換的檢查是正確的——並假設共識算法不會產生違背這點的區塊鏈。輕客戶端依賴全節點為任何相關交易提供區塊內的信息。這很可能只佔鏈上所有數據很小的百分比。

為了解釋地更清楚,我介紹這裡的三類角色:

  • 全節點通過對每個區塊的共識生成一條區塊鏈,並始終下載所有數據和驗證所有狀態。每當它們看到區塊里有不一致的狀態 (例如,區塊的最終狀態與區塊內的交易不一致),它們會生成一個欺詐證明,以警告輕客戶端。
  • 輕客戶端只下載區塊頭 (非交易數據和狀態),除了它們想知道的交易和部分狀態。它們與全節點連接,以請求所需要的數據。
  • 點對點網絡傳播區塊頭,並允許隨機訪問上傳到它的數據塊。

一個全節點具有下列安全保證:

  • 與其他全節點形成的共識 (絕對) 多數可以構建另一條區塊鏈,從而進行雙花攻擊;更廣泛來說,它們可以任意對交易進行重新排序,創建另一個版本的交易歷史。
  • 由於要檢查狀態,即使是其他全節點形成超級多數對不一致的狀態達成共識,也不可能讓一個誠實全節點同意這條鏈。

因此,一個全節點的安全假設是 2/3 的誠實全節點可以保證交易不會被重新排序,但正確的狀態執行是不需要任何的誠實假設來確保的 (一個全節點根本不可能被欺騙接受一個不正確的狀態轉換)。

對於輕客戶端來說,情況略有不同,因為它們不下載和驗證狀態。因此,在沒有欺詐證明 (詳見下文)的情況下,“天真” 的輕客戶端會被騙,相信由絕對多數 (2/3) 的全節點達成共識的區塊鏈是沒有問題的,即使它實際上有一個不正確的狀態轉換。

欺詐證明

欺詐證明能是給輕客戶端一個更好的安全模型,使其安全性接近於全節點。其目的是,只要至少有一個誠實的全節點 (比 2/3 多數假設弱得多),輕客戶端也可以被保護,免受無效鏈的影響。

欺詐證明是如何實現這點的?假設區塊鏈執行區塊 B 內的交易 t1,…,tn,且區塊頭為 H。如果我們增加一個執行跟蹤,用來存儲每筆交易前和后的狀態的默克爾根,我們把它叫做 s0,…,sn,如果有任何交易被錯誤執行(即其結果沒有正確應用於狀態)就可以構建一個虛假證明:如果說交易 ti 是有問題的交易,給出三元組 (si−1,ti,si),再加上在區塊頭 H 里顯示已被打包的默克爾證明,這將構成一個欺詐證明。事實上,我們僅需要打包 ti 需要和影響到的 si-1si。這個欺詐證明的大小比原來的區塊 B 要小得多,因此容易在網絡里廣播,警告輕客戶端不要跟隨這條鏈。

所以,現在輕客戶端的安全假設就比之前的要強很多了:

  • 2/3 的不誠實全節點可以構建另一條鏈,從而改變交易歷史或給交易重新排序 (例如,發起雙花攻擊)。
  • 但是為了防止出現不正確的狀態轉換,現在的假設是至少有一個誠實全節點 (它可以創建欺詐證明),且網絡是同步的 (這樣你就能即使接受到欺詐證明)。

數據可用性問題

用欺詐證明保護輕客戶端不受錯誤狀態轉換影響這個方法其實有一個缺口。如果絕對多數的全節點都已經對一個區塊頭簽名了,但不發布部分數據 (特別是,這可能是欺詐性交易,它們將晚點發布,以騙過別人接受印出來的或偷來的錢)?顯然,誠實全節點將不會跟隨這條鏈,因為它們不會下載該數據。但輕客戶端不會知道數據是否可用,因為它們只下載區塊頭,不下載數據。因此,現在的情況是誠實全節點知道有貓膩,但它們無法警告輕客戶端,因為它們缺少可能需要用來創建欺詐證明的數據。

難道它們就不能用其他信息警告輕客戶端,告訴它們:“嘿,小心,這個區塊的數據不可用。”嗎?是的,但問題在於它們無法證明——不存在數據不可用的證明,所以上述的簡單欺詐證明機制是不起作用的。

更糟糕的是,這不是可歸責的問題。有些數據可能因為網絡條件不好而丟失了,而這些數據可能在以後再次出現。因此,如果你是一個誠實節點,看到數據不可用的警報,然後檢查發現數據實際上在那裡,你不能確定是誰出錯了:可能是出塊者沒有在開始時上傳數據,而是在警報產生后才上傳 (出塊者的錯),或者這是一個錯誤的警報。

由於這不是可歸責的問題,我們不能因為警報的結果懲罰出塊者或挑戰者。這很煩人,因為這基本上意味着增加這個功能會增加一個 DOS 向量 (Vitalik 的這篇文章對這個問題進行了非常好的說明。)

解決方案:用糾刪碼進行數據可用性檢查

要解決這個難題,就要確保輕客戶端可以知道數據是否真的可用。因為如果它們知道這個數據是可用的,它們也就知道很可能有一個誠實全節點看到並檢查了該數據——如果該數據是不正確的或是欺詐性的,誠實全節點就會廣播一個欺詐證明。

當然我們不想要輕客戶端必須下載整條區塊鏈和狀態來實現這點——因為這樣它們就不再是輕客戶端了。因此,我們將讓它們下載隨機的數據塊,並檢查它們是否可用。如果你嘗試下載 100 個不同的數據塊,並全部都獲取了,你就可以很確定大部分的數據都是可用的 (例如,如果少於 50% 的數據是可用的,你能成功下載 100 個數據塊的概率是 2-100≈10-3,這是一個非常小的數字)。

然而,這隻能證明大多數的數據是可用的——比方說,10 兆字節的數據塊中僅有 100 字節丟失了,在這種情況下,你對那一點數據發出請求的可能性非常低。而 100 字節足以為作惡交易作掩護,躲過誠實的欺詐證明者。

因此,我們需要對這些數據做一些處理,以確保那些檢查切實保證所有的數據都將是可用的。我們可以用糾刪碼 (erasure code) 實現這點。一個糾刪碼以更大量的數據 E 取代區塊數據 B,其特性是某固定百分比 q<1 將總足以重構整個數據。因此,即使有些數據丟失了,只要輕客戶端確保足夠大部分數據是可用的,它們就知道區塊數據 B 是可被重構的。

現在,我們準備定義輕客戶端在數據可用性檢查中的行為。對於每個它們下載的區塊頭,它們將嘗試下載數據 Ek 個隨機數據塊,以評估數據是否實際可用。如果它們可以下載全部的數據塊,那麼,在網絡里有實際上足夠的數據重構整個區塊的概率是 1- qk

使用這個機制就無須全節點警告輕客戶端數據是否可用了。只需要下載少量數據,輕客戶端就可以自行測試並知道答案了。

糾刪碼實例: RS 碼

我們實際上是如何構建糾刪碼的呢?一個簡單且為人熟知的實例是 Reed-Solomon codes (縮寫為 RS 碼)。它們是基於這樣一個簡單的事實:在一個域里,任何次數是 d 的多項式都僅由其在 d+1 點的估值確定。例如,多項式的次數為 1 (即一條線),然後只需要知道多項式兩個點的值就足以知道整個多項式了 (只有一條線穿過兩個不同的點)。

我們必須在一個有限閾里解多項式,否則係數和估值都會變得任意大。幸運的是,有大小為 2m 的域可用 (即所謂的二進制域或伽羅瓦域 F2) ,這樣我們就不需要研究素域 Fp (儘管我們可能在一定方案里因為其他原因需要)。

因此,假設我們有 n 個數據塊 d0,…,dn−1,我們想對其進行糾刪編碼。為了用一個 RS 碼來實現,我們將插值一個多項式

觀點 | 為什麼說數據可用性檢查對區塊鏈擴容方案很重要?

次數為 d=n-1,估值 d00,即 f(0)=d0f(1)=d1,這樣下去。我們知道有這樣的多項式存在,事實上拉格朗日插值多項式 (Lagrange interpolation polynomials) 給了我們建構它的明確方法(儘管還有更高效的方法)。

現在,我們通過對多項式在更多的點上估值來拓展數據——比方是 n 多個點,如果我們想把比率設為 q=0.5。那麼就會有 dn=f(n), dn+1=f(n+1)…, d2n−1=f(2n−1)。由此我們得出它的一個特性,即任何 n 個點將足以重構這個多項式——如果我們有多項式 f(x),我們也可以輕易對它在 0,…,n-1 進行估值,得到我們的原始數據。

就這些內容了!RS 碼不過是一些多項式插值。這實際上就解決了數據可用性問題了,因為它們在編碼效率上是最優的,除了一個小問題——欺詐事件可以以另一種方式發生,即產生錯誤的編碼。而對於 RS 碼,為了證明編碼是錯誤的,你必須提供 n 個數據塊,並足以用一個多項式對其中的 n-1 插值,並顯示最後一個不在這個多項式上。這就是為什麼我們現在做大量的研究,旨在找出避免必須做這些不正確編碼證明或使它們儘可能小的方法。

在分片上的應用

數據可用性檢查對於許多不同區塊鏈擴容方案是很重要的,因為即使節點不能檢查所有或甚至下載所有數據,它也能給這些節點提供安全。由於這是區塊鏈的一個根本性瓶頸 (共識節點必須下載所有數據),這是一個重要的擴容要求。

例如,在以太坊 2.0 里,驗證者只需對信標鏈上的數據進行完全驗證,分片上的驗證工作由委員會負責。這個結構旨在減輕驗證者必須驗證所有數據的負擔。但是,這意味着驗證者在多數分片上實際上是輕客戶端 (除了活躍驗證者)。因此,數據可用性檢查是需要的。在這種情況下,以太坊 2.0 的驗證者實際上同時是“全節點”和輕客戶端。那些下載並檢查所有分片數據的節點是“超級節點 (supernodes)"——這些節點可能只會由組織或做了大量質押的人來運行,他們會驗證所有分片。我們當然不會想要只是信任這一小部分人是誠實的來運行以太坊 2.0。

因此,有數據可用性檢查和欺詐證明是絕對必要的,這樣一般人都可以運行驗證者節點。

擴展閱讀

1. Vitalik Buterin 的這篇文章解釋了欺詐證明和糾刪碼

  • 它介紹了多維 RS 碼如何形成更小的不正確編碼證明
  • 這是論文版本

2. 多為代碼替代方案的最新想法:

  • 使用 STARKs
  • 使用 FRIs
  • 使用 Kate’s polynomial commitment 方案

原文鏈接:https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html

本文鏈接:https://www.8btc.com/article/6660149

轉載請註明文章出處

(0)
上一篇 2021-07-13 09:55
下一篇 2021-07-13 10:28

相关推荐