DAS 在 Danksharding 中是怎麼被實現的?
先備知識:
以下會以 資料發布(Data Publication)來稱呼 資料可得性(Data Availability),但某些 Data Availability 相關的詞彙例如 DAS、DAC 則會保留原字,避免讀者無法和英文原文連結。關於 Data Publication 這個名稱的介紹可以參考:
資料可得性重新命名:用 Data Publication 取代 Data Availability
上一篇介紹了為什麼我們會需要 DAS 以及 DAS 所帶來的好處,這一篇將會介紹 DAS 如何在 Ethereum 的 Danksharding 中實現。
Data Availability Sampling(一):為什麼會需要 DAS?
當 Ethereum 實作完成 Danksharding 後,區塊大小會比現在大上許多,因此即便是參與到共識運作的驗證者也不會被要求要下載完整的區塊,否則區塊變大的負擔等於是提高成為驗證者的門檻,也就會降低網路的去中心化程度。所以在 Danksharding 中驗證者會和輕節點一樣進行 DAS,只會採樣片段的區塊資料,不過細節上會有一些差異,待會會介紹到。
更多關於 Danksharding 的介紹可以參考:
如果讀者想進一步了解目前正在為 Danksharding 鋪路的 EIP-4844 Proto-Danksharding 可以參考:
Rollup 的大補帖:Proto-Danksharding(一)
在第一篇文章中有提到,如果惡意的出塊者(Proposer)藏住一小部分的區塊資料(例如只發布了 99% 的資料),那仍然是沒有完整發布的區塊、不會被承認的區塊,但很多輕節點會因此上當。假設惡意出塊者只公布 X% 的資料,且輕節點會採樣 s 個片段資料,那這 s 個片段剛好都屬於被公布資料的一部分(因此讓輕節點相信區塊有被完整發布)的機率會是 X 的 s 次方:X^s。
如果 X=99,那 s 是 5、10、25、75 時輕節點會上當的機率分別約是 95%、90%、78%、47%。可以看到即便 s 提高到 75 次,也就是輕節點下載了 75 個片段,仍然有接近一半的機會會上當。
糾刪碼被用來增加資料的可靠性:經過糾刪碼編碼後的資料,即便有部分資料遺失或錯誤,仍然可以透過剩下的部分來還原出完整資料。糾刪碼被使用在通訊系統、CD 或 QR Code 等等,有些讀者可能有印象:即便 CD 有些許刮痕,資料還是能被正常讀取,不過一但刮痕太多就無法正常讀取了。透過糾刪碼,輕節點們只要湊滿例如 50% 的資料就能還原出完整資料,這表示惡意出塊者最多就只敢發布接近但少於 50% 的資料,因為再多就能被還原出完整資料。在這個情況(X=50)下,輕節點在 s 是 5、10、25、75 時會上當的機率就會大大降低至 3%、0.09%、0.000003%、3*(10^-23)%。
糾刪碼編碼的方式是將原始的資料分成 k 等份,再編碼轉換成 n(n>k)份資料,之後從這 n 份資料中任意的 k 份都能還原出原始的完整資料。以上面的 X=50 例子來說,假設固定將區塊資料切成 100 份(k=100),那出塊者就會需要將它編碼轉換成 200 份的資料(n=200),而每個輕節點會來採樣這 200 份資料中任 s 份,只要有 200 份中的任 100 份都可以還原出完整的 200 份資料。
Danksharding 中會使用 Reed-Solomon Codes 這個糾刪碼來實現,Reed-Solomon Codes 透過多項式來將 k 份資料做成一個 k-1 次多項式,然後在多項式上的 n 個點取值,如此 n 個點中任意 k 個點都可以還原出原本的多項式(因為同一個 k-1 次多項式上的任 k 個點都能組出同樣一個多項式),也就能還原出完整的 n 份資料,包含原始的 k 份資料。
透過糾刪碼增加資料的可靠性後,我們就不需要擔心惡意出塊者藏住 1% 的區塊資料還能「輕易」誘騙很多輕節點上當了。但有一個問題:輕節點要怎麼知道它採樣的 s 個片段資料真的是經過糾刪碼編碼後的資料,而不是惡意出塊者任意填入的無意義資料?因為如果輕節點沒辦法知道的話,那即便輕節點們合力湊滿了 50% 的資料也還原不出原始的資料。
首先,出塊者在發布區塊時,會將區塊內容進行 Commit 的動作,產生一個 Commitment,並把這個 Commitment 放在區塊的標頭檔(Block Header)裡。為什麼會需要做 Commit 的動作?因為要讓其他人能驗證比對其收到的區塊內容,否則出塊者可以告訴 Alice 區塊內容是 X、告訴 Bob 區塊內容是 Y,Alice 和 Bob 以為他們收到的是同一個區塊但其實區塊內容並不一樣。
像是 Ethereum 每個區塊裡的所有交易會被做成一棵 Merkle Tree,這就是一個 Commit 的動作,而 Merkle Tree Root 就是 Commitment。節點們可以透過 Commitment 檢查這個區塊收錄的是哪些交易、驗證某一筆交易存在於 Merkle Tree 裡,也就是驗證該區塊真的有收錄該筆交易。在 Danksharding 中區塊內容會先經過糾刪碼的編碼變成一個更大的區塊內容,接著出塊者會對編碼後的內容進行 Commit,最終得到一個 Commitment 再把它放在區塊標頭檔裡。
Commit 的其中一種方法是用常見的 Merkle Tree,將編碼後的每個片段當成葉節點,然後組出一棵 Merkle Tree:
但如同前面提到的,輕節點不會下載全部片段,那它要怎麼確認它下載的片段資料真的是從一個經過糾刪碼編碼的區塊資料,而不是出塊者隨便填的無意義資料?
答案是沒辦法,只有下載全部片段的人可以驗證這些片段真的有經過糾刪碼編碼 — 這個人就是全節點。因此輕節點必須仰賴全節點幫忙驗證資料是否有經過糾刪碼編碼。如果沒有的話,全節點會產生一個詐欺證明來證明「資料沒有經過編碼」。所以如果是以 Merkle Tree 來 Commit 資料,那輕節點在採樣片段資料的同時就必須要等待一段挑戰期,如果挑戰期內出現「資料沒有經過編碼」的詐欺證明,那就丟棄這個區塊,如果沒有出現詐欺證明那就相信「資料有經過編碼」。
Polynomial Commitment 是另外一種 Commit 的方式。相較於 Merkle Tree Commitment 是將分段資料視為葉節點並做出一棵 Merkle Tree,Polynomial Commitment 是將分段資料先轉換成一個 Polynomial(就是多項式),再對這個多項式進行 Commit 得到 Commitment。和 Merkle Tree Root 搭配 Merkle Proof 可以驗證那棵 Merkle Tree 某個葉節點的值一樣,Polynomial Commitment 中透過 Commitment 和 Proof 也可以驗證這個多項式在不同點上的取值。
Reed-Solomon Code 糾刪碼正好就是使用多項式。Reed-Solomon Code 編碼過程會得到一個多項式,而 Polynomial Commitment 就是直接對這一個多項式進行 Commit,因此這個 Commitment 本身就能確保這些點都屬於同一個多項式!意思就是 Reed-Solomon Code 搭配 Polynomial Commitment 的組合本身就自帶驗證「資料有經過糾刪碼編碼而不是任意資料」的特質,不像搭配 Merle Tree Commitment 那樣還需要全節點再去產生詐欺證明來證明「資料沒有經過編碼」。
在 Danksharding 中會採用 KZG Commitment 作為 Polynomial Commitment,更多關於 KZG Commitment 的介紹可以參考這個 Thread 和裡面提供的文章連結:
So you might have heard that it is time to learn about KZG commitments. Maybe you even looked at the "gentle" intro by @dankrad but you were put off by not-so-gentle math there. Let me try to ELI5 KZG in this thread 🧵👇https://t.co/UnG8fSeamS
註:計算 KZG Commitment 比計算 Merkle Tree Commitment 還耗費更多運算資源,也就是需要更強大的機器。因此如果不希望計算 Commitment 的節點因為性能要求而變得中心化的話,就得考慮採用 Merkle Tree Commitment 的方式,例如目前 Celestia 便是採用 Merkle Tree Commitment。
現在我們有了糾刪碼讓我們可以還原資料,以及檢驗資料有經過糾刪碼編碼的方式,還剩下兩個小問題:
如果我們將資料排列成一個 m*m 的二維陣列,再針對每一行、每一列都進行糾刪碼以延展成兩倍,最後得到一個 2m*2m 的陣列,那就可以解決上述的兩個小問題。
註:當我們把原本一維的 k 份資料排列成 m*m 的二維陣列,每一行或每一列的長度都是 m,也就是 sqrt(k),比 k 小上許多。
在二維 Reed-Solomon 編碼中,資料都是一行或一列進行編碼,而不是所有資料進行編碼,所以編碼的資料量都是一行或一列的資料量,也就是 sqrt(k)。相比於在一維編碼中,編碼的資料量是 k,二維編碼不管是產生詐欺證明或是嘗試還原來提供某個沒人有的片段資料,所需的資料量都少了許多:
不過要注意的是二維編碼並沒有一定比一維好。二維編碼的缺點是會需要至少 75% 的資料才能還原出完整的資料,比一維的 50% 門檻還高(門檻越高表示攻擊者越高機率騙輕節點上當)。因此如果不需要詐欺證明(例如使用 Polynomial Commitment)且還原出完整(k 份)資料的負擔並不大的話,那一維編碼在這種情況就會比二維來的有優勢。
在 Danksharding 中因為區塊大小會變得很大,為了避免運行驗證者的節點性能要求提高導致網路中心化,所以驗證者不會被要求要下載完整區塊,但會被賦予保管指定區域的片段資料的任務。相比於輕節點是隨機抽樣區塊任意位置的片段資料,驗證者會被隨機分配指定的某兩行加上某兩列的片段資料,如果驗證者沒有辦法獲得那兩行兩列的資料,那它就不會投給這個區塊。
如果一個二維編碼的區塊資料有超過 75% 的部分有公布,那驗證者們一定可以合力靠手上的資料還原出完整區塊;如果一個二維編碼的區塊資料只有不到 75% 的部分有公布,那這個區塊將無法獲得超過十六分之一的驗證者的票,也就一定不會被共識所接受。所以惡意的出塊者基本上是騙不到驗證者們的,因此不用擔心「即便大多數驗證者是好人也會被騙」的情況。
註:為什麼是十六分之一?假設超過 25% 的區塊資料沒被發布(假設就是缺少四個象限中左上角的部分),則一個驗證者被分配到的兩行兩列剛好都沒經過左上角部分的機率是 (1/2)^(2*2) = 1/16,因為一行或一列沒經過左上角的機率都是二分之一,兩行兩列就是二分之一的四次方,也就是十六分之一。
假設一個使用者不相信驗證者們,那他就必須要運行一個輕節點並對區塊資料進行抽樣。假設網路隱私有被保護或使用者沒有被攻擊者針對的情況,則使用者抽樣越多次,他被騙的機率就越低。
假設區塊資料是經過二維編碼,且惡意出塊者只發布了接近 75% 的資料導致完整資料其實無法被還原,則一個輕節點抽樣 s 次結果都剛好抽到有發布的片段的機率 P 會是 0.75 的 s 次方:(0.75)^s。當 s 是 10、25、50、75 時 P 分別是:5.6%, 0.075%, 0.000057%, 0.000000043%。當然抽樣次數越高越不容易被騙,但也代表要下載的資料更多,所以使用者得在安全性與頻寬之間取一個平衡。
前面提到使用 p2p 網路來採樣、分享片段資料都把它當作一個神奇又美好的工具來使用,只要有人有保存你想要的片段資料,你一定保證能拿到手。但現實的 p2p 網路卻不是這麼一回事,實際上目前 Ethereum 的 p2p 網路是毫無隱私的、脆弱的 — 仰賴於 IP 資源稀缺並以封禁 IP 的方式嚇阻 p2p 中的惡意行為。
當區塊資料隨著 Danksharding 到來而變得更大,在 p2p 網路中傳遞的資料量也就越來越大、p2p 的負荷也就越來越重。如何確保 p2p 的設計能夠應付 Danksharding 所帶來的頻寬負荷和對網路穩定性的挑戰還處在研究階段。
目前評估中的幾種設計包含:Gossip、Distributed Hash Table (DHT) 及 Replicate。
在 Gossip 網路中,節點會將收到的資料分享給自己的鄰居節點(和自己有建立連結的節點),如此不斷擴散下去直到整個網路的節點都收到同樣的資料。而如果一份資料是只有網路中部分節點有興趣的話,那將資料都分享給所有鄰居節點的方式就不太適合,這時候可以採用以主題(Topic)來分群的方式:p2p 網路中節點們會互相連接,但在這一層基礎連結之上還會有另一層網路覆蓋,上面這層覆蓋網路會以主題分群,屬於某一個主題的資料就會只在對該主題有興趣的節點之間分享,就像現實生活中同班同學或同事之間都一樣會再有小圈圈形成,有些是分享追星資訊小圈圈、有些是分享動漫興趣的小圈圈等等。在 Ethereum 的例子中,驗證者在 p2p 網路裡都會和數個其他驗證者形成連結,而每個 Epoch 驗證者都會被分派到 32 個 Slot 其中一個,被分配到同一個 Slot 的驗證者們彼此會形成一個委員會並共同進行投票,而同一個 Slot 的驗證者們彼此就會形成一個該 Slot 專屬的覆蓋網路,用來分享並搜集投票。
註:目前 Ethereum p2p 網路中沒有像是身份驗證機制的方式,所以任何對某一個 Slot 投票有興趣的節點都可以加入到該 Slot 所屬的覆蓋網路中獲得資訊。
在 DHT 網路中,節點會為自己產生一個 ID(像在區塊鏈中你為自己產生一把公私鑰一樣),這個 ID 將會決定該節點要負責存哪些資料:可以想像每份資料也都有一個 ID,而節點 ID 與資料 ID 「越相似」的節點要負責保存該資料。因為節點不可能和網路中所有節點相連,因此它不可能知道網路中誰的 ID 和它手上這份資料 ID 「最相似」,所以它得靠鄰居的協助去找到網路中誰和資料 ID 最相似,並將資料交給對方保管(如果發現自己是最相似的話那就是自己保管)。
註:通常不會將資料交給「一個最相似」的節點來保存,而是「最相似的幾個」節點都要負責保存,避免單點故障的風險。
當大家照著這個規則傳遞資料,最終整個網路會像是有一份巨大的表格,裡面記錄著哪個節點保存哪份資料。當某個節點想要某份資料時,它就可以照著該份資料的 ID,請鄰居去幫忙尋找和該份資料 ID 最接近的節點們,直到找到有保存該份資料的節點。
相較於前面兩種去中心化網路的方式,Replicate 則是以中心化換取效率和使用體驗。在 Replicate 中,我們就相信某些厲害的節點會保存所有完整的資料,我們只要和它們任一個建立連線並索取我們要的資料即可。如此不論是效率還是使用體驗都大幅提升,網路中的節點們不必再一個傳一個,把資料傳給(Gossip 中)有興趣的人或(DHT 中)要負責保管的人;在索取資料時,也不需在(Gossip 中)覆蓋網路中切換,或是(在 DHT 中)一個問一個來找到保存資料的人。
Gossip 和 DHT 都無法防止女巫攻擊(Sybil Attack),也無法防止節點進行惡意行為:在去中心化的 p2p 網路裡(Gossip 或 DHT),因為沒辦法限制或驗證參與者的身份,攻擊者便可以產生很多節點滲透到 p2p 網路中來進行不同攻擊。例如攻擊者可以在 Gossip 的某個主題的覆蓋網路裡加入很多節點,讓其他人以為有很多節點在幫忙傳播資料,但可能下一秒攻擊者的節點就直接消失了,造成資料很可能突然就下載不到。又或是在 DHT 中攻擊者可以故意不保存資料(即便它 ID 和資料 ID 最相似)、不將資料傳遞給 ID 更相似的其他節點、說謊(說它查不到「和該資料 ID 更相似的鄰居節點」)。
在區塊產出的那段時間,資料一定得在 p2p 網路裡能被找到,如此區塊才會獲得驗證者投票、被節點承認。但過了一個禮拜、一個月或一年以後呢?輕節點們都還是要永遠保存著手上的資料嗎?要怎麼確保保存某個資料的輕節點們都會至少有一個是在線的?要怎麼避免惡意索取大量歷史資料造成 DoS 攻擊?
雖然目前 Danksharding p2p 的架構還在設計中,或甚至連個大概也沒有,可能是 Gossip、可能是 DHT、可能是 Replicate,也有可能是混合式的、或甚至分層(例如分成實時和歷史資料的網路)再加上混合式的。但至少我們明年會看到 EIP-4844 Proto-Danksharding 先上線,在 EIP-4844 上線後便可以持續優化 Ethereum p2p 網路針對區塊加大後的處理方式,累積的經驗也會對 Danksharding p2p 的架構有很大幫助。
更多關於 DAS p2p 的介紹與挑戰可以參考 2022 年 EF 研究團隊的介紹,以及這篇 Paradigm 的 DAS 介紹文,另外以太坊基金會也列出了針對 DAS p2p 的設計提案請求,社群也提出了像是利用現有的 Ethereum p2p 結構的 PeerDAS 提案,以及採用 Gossip 主題覆蓋網路的 SubnetDAS 提案。
網路的隱私也是非常重要的一個功能,沒有辦法隱藏是誰來索取這個片段資料的話,攻擊者就能選擇性地給予輕節點資料。它可以只提供資料給它想要欺騙的輕節點,這些輕節點因為拿到所有採樣的資料,所以他們會相信資料是有完整發布的,但當有人嘗試還原出該區塊時就會發現持有的資料不足以成功還原。
當然這個受騙上當的輕節點數量會有一個上限,否則攻擊者用來騙這些輕節點的資料加起來就足以成功還原了,而這個數量上限的估計可以參考彩券搜集問題(Coupon Collector Problem):如果有 n 種不同的彩券,每一盒麥片盒裡有隨機一張彩券,則預期要買多少盒麥片才能收集到所有 n 種彩券?答案是 n*log(n)。對應到 DAS 裡的採樣:原始的資料切分成 n 份(即 n 種彩券),每次輕節點來採樣(也就是買一盒麥片)就是隨機拿到其中一份(彩券)。因此如果我們設計成輕節點每次採樣會拿到 0.1% 資料(則 n = 100/0.1 = 1000 份),那我們可以預期攻擊者最多只能騙到約 1000*log(1000) = 3000 個輕節點;如果每次輕節點採樣資料量再多一點,變成 1%,那預期攻擊者最多可能騙到的輕節點數量就會降低至 100*log(100) = 200 個。
如果沒有隱私功能,那我們就得接受有可能有些輕節點就會受騙上當,但好消息是受騙的輕節點數量有個上限;如果有隱私功能,那我們就可以放心攻擊者要能騙到任何一個輕節點的機率都非常低。不過加入隱私的功能勢必會影響到效能,節點採樣的時間會被拉長,這對安全性的影響還需要再進一步評估。
下一篇將會介紹其他實作 DAS 的協議像是 Celestia、Avail DA 與 Eigen DA 是採取什麼樣的設計來建構這三個基底,以及不同設計之間的 Trade-off。
TEM Medium 目前正在進行有獎徵稿!詳情請參考:
Special thanks to Kimi Wu and Kevin Mai-Hsuan Chia for reviewing and improving this post
Data Availability Sampling(二):DAS in Danksharding was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。