在區(qū)塊鏈網(wǎng)絡中,節(jié)點如何確保新提出的區(qū)塊的所有數(shù)據(jù)都是可用的?這為什么重要?

在這篇文章中,我們將深入探討數(shù)據(jù)可用性問題及其如何影響以太坊的擴展性。

數(shù)據(jù)可用性問題是什么?

數(shù)據(jù)可用性(DA)問題:區(qū)塊鏈網(wǎng)絡中的節(jié)點如何確保新提出的區(qū)塊中的所有數(shù)據(jù)實際上是可用的?如果數(shù)據(jù)不可用,該區(qū)塊可能包含由區(qū)塊生產(chǎn)者隱藏的惡意交易。即使區(qū)塊包含非惡意交易,隱藏它們也可能威脅到系統(tǒng)的安全。

例如,假設 Alice 是一個 ZK-Rollup 的運營者。她在以太坊上提交了一個 ZK-Proof 并得到驗證。如果她沒有在以太坊上提交所有交易數(shù)據(jù),盡管她的證明證實了在 rollup 中進行的所有狀態(tài)轉(zhuǎn)換都是有效的,但 rollup 的用戶仍可能對他們當前的賬戶余額一無所知。因為零知識的特性,提交的證明無法揭示當前狀態(tài)的信息。

在 Optimistic Rollup 的場景中,也存在類似的例子,其中 Alice 在以太坊上提交了一個聲明(assertion),但是由于交易數(shù)據(jù)不可用,OPR 的參與者無法重新計算或質(zhì)疑該聲明。

為了應對上述情況,OPR 和 ZKR 的設計都要求運營者將所有交易細節(jié)作為“calldata”提交到以太坊上。雖然這使它們在短期內(nèi)避免了 DA 問題,但隨著 rollup 內(nèi)部交易數(shù)量的增加,需要提交的數(shù)據(jù)量也會增長,限制了這些 rollup 能夠提供的擴展量。

更糟糕的是,數(shù)據(jù)不可用是一種無法唯一歸因的錯誤。這意味著參與者無法向其他節(jié)點證明特定數(shù)據(jù)塊缺失。這是因為 Bob 可以廣播 Alice 提交的區(qū)塊缺少數(shù)據(jù),但當 Charlie 向 Alice 查詢時,她可能會提供數(shù)據(jù)給他。

數(shù)據(jù)可用性問題怎么影響當前的區(qū)塊鏈?

為回答這個問題,讓我們首先回顧一下類似以太坊的區(qū)塊鏈的一般區(qū)塊結(jié)構(gòu),以及任何區(qū)塊鏈網(wǎng)絡上存在的客戶端類型。

一個區(qū)塊可以分為兩個主要部分:

• 區(qū)塊頭:一個小的區(qū)塊頭包含與區(qū)塊中包含的交易相關(guān)的摘要和元數(shù)據(jù)。

• 區(qū)塊體:包含所有交易數(shù)據(jù),構(gòu)成區(qū)塊的主要部分。

在傳統(tǒng)的區(qū)塊鏈協(xié)議中,所有節(jié)點都被視為完整節(jié)點,它們同步整個區(qū)塊并驗證所有狀態(tài)轉(zhuǎn)換。它們需要花費大量資源來檢查交易的有效性并存儲區(qū)塊。優(yōu)點是,這些節(jié)點不會接受任何無效的交易。

可能還有另一類節(jié)點,它們沒有(或不想花費)資源來驗證每筆交易。相反,它們主要對了解區(qū)塊鏈的當前狀態(tài)和一些對它們有關(guān)的交易是否被鏈包含感興趣。理想情況下,這些輕客戶端也應該被保護不受包含無效交易的鏈的欺騙。這實際上可以使用所謂的欺詐證明來實現(xiàn)。這些簡潔的信息顯示特定的區(qū)塊體包含無效的交易。任何完整節(jié)點都可以產(chǎn)生這樣的欺詐證明,因此輕客戶端不必信任某個特定的完整節(jié)點是誠實的。它們只需確保它們與一個能夠確保如果有區(qū)塊頭的欺詐證明可用,它們將接收到它的八卦網(wǎng)絡連接良好。

然而,這個系統(tǒng)存在一個問題:如果一個區(qū)塊生產(chǎn)者不透露一個區(qū)塊背后的全部數(shù)據(jù)怎么辦?在這種情況下,完整節(jié)點顯然會拒絕這個區(qū)塊,因為在它們看來,如果一個區(qū)塊不附帶區(qū)塊體,那么它甚至不是一個區(qū)塊。然而,輕客戶端可以被展示區(qū)塊頭鏈,并且無法注意到數(shù)據(jù)缺失。同時,完整節(jié)點不能產(chǎn)生欺詐證明,因為它們?nèi)鄙賱?chuàng)建欺詐證明所需的數(shù)據(jù)。

為了應對這一問題,我們需要一種機制來讓輕客戶端驗證數(shù)據(jù)可用性。這將確保隱藏數(shù)據(jù)的區(qū)塊生產(chǎn)者不能通過說服輕客戶端來逃避。這也會迫使區(qū)塊生產(chǎn)者透露部分數(shù)據(jù),使整個網(wǎng)絡以協(xié)作的方式訪問整個區(qū)塊的數(shù)據(jù)。

讓我們通過一個例子更深入地了解這個問題。假設區(qū)塊生產(chǎn)者 Alice 構(gòu)建了一個包含交易 tx 1、tx 2、...、txn 的區(qū)塊 B。假設 tx 1 是一個惡意交易。如果 tx 1 被廣播,任何完整節(jié)點都可以驗證它是惡意的,并將這個信息作為欺詐證明發(fā)送給輕客戶端,輕客戶端會立即知道這個區(qū)塊是不可接受的。然而,如果 Alice 想要隱藏 tx 1 ,她就只透露頭部和除 tx 1 之外的所有交易數(shù)據(jù)。完整節(jié)點無法驗證 tx 1 的正確性。

有人可能會認為一個簡單的解決方案是讓所有輕客戶端隨機抽樣交易,如果他們發(fā)現(xiàn)他們的樣本是可用的,他們就可以確信區(qū)塊是可用的。但是讓輕節(jié)點隨機查詢?nèi)我庖还P交易,輕客戶端查詢 tx 1 的概率是 1/n。因此,Alice 幾乎總能欺騙輕客戶端接受一個惡意交易。換句話說,大多數(shù)輕客戶端都會被欺騙。由于不可歸因的性質(zhì),完整節(jié)點無法以任何方式證明 tx 1 是不可用的。不幸的是,增加樣本數(shù)量也并不能使情況變得更好。

那么,我們該如何解決這個問題呢?

解決這個問題的方法在于在區(qū)塊中引入冗余。在編碼理論,特別是擦除編碼方面,有一套豐富的文獻可以幫助我們解決這個問題。

簡而言之,擦除編碼允許我們將任何 n 個數(shù)據(jù)塊擴展成 2 n 個數(shù)據(jù)塊,這樣任何 2 n 中的 n 個就足以重構(gòu)原始數(shù)據(jù)(參數(shù)是可調(diào)的,但這里我們?yōu)榱撕喕紤]這種情況)。

如果我們迫使區(qū)塊生產(chǎn)者對交易 tx 1、tx 2、...、txn 進行擦除編碼,那么要隱藏單個交易,它需要隱藏 n+ 1 個數(shù)據(jù)塊,因為任何 n 個數(shù)據(jù)塊都足以構(gòu)建整個交易集。在這種情況下,少量的查詢就能讓輕客戶端非常有信心地知道底層數(shù)據(jù)確實是可用的。

Woah, 所以就這樣嗎?

不。盡管這個簡單的技巧使隱藏數(shù)據(jù)變得更加困難,但仍有可能區(qū)塊生產(chǎn)者故意以錯誤的方式進行擦除編碼。然而,完整節(jié)點可以驗證這種擦除編碼是否正確進行,如果沒有,它可以向輕客戶端證明這一點。這就是另一種類型的欺詐證明,就像上面提到的惡意交易一樣。有趣的是,只需一個誠實的完整節(jié)點作為輕客戶端的鄰居,就能確保如果區(qū)塊是惡意的,那么它將收到一個欺詐證明。這確保了輕客戶端能夠以非常高的概率訪問一個沒有惡意交易的鏈。

但有一個問題。如果做得過于簡單,一些欺詐證明的大小可能會和區(qū)塊本身的大小一樣大。我們對輕客戶端的資源假設禁止我們使用這樣的設計。通過使用多維擦除編碼技術(shù),已經(jīng)有了改進,這些技術(shù)降低了欺詐證明的大小,但代價是增加了承諾的大小。為了簡潔起見,我們不在這里詳細介紹這些,但這篇論文對此進行了詳細的分析。

基于欺詐證明的解決方案的問題在于,輕客戶端永遠無法完全確定任何它尚未收到欺詐證明的區(qū)塊。同時,它們繼續(xù)信任其完整節(jié)點是誠實的。誠實的節(jié)點也需要得到激勵,以持續(xù)審核區(qū)塊。

我們在這里關(guān)注的是那些系統(tǒng),它們保證如果區(qū)塊編碼無效,完整節(jié)點可以檢測到并向輕客戶端提供證明,以說服它們存在不當行為。然而,在下一部分中,我們將關(guān)注那些保證只有有效編碼能被提交到鏈上的區(qū)塊編碼。這消除了需要證明編碼錯誤的欺詐證明的需求?；谟行宰C明的解決方案使應用程序能夠在不必等待完整節(jié)點提供這類欺詐證明的情況下使用系統(tǒng)。

那么,這些解決方案是如何工作的?

近期,多項式承諾在區(qū)塊鏈領(lǐng)域引起了重新的興趣。這些多項式承諾,特別是對多項式的恒定大小的 KZG/Kate 承諾,可以用來設計一個不需要欺詐證明的整潔的數(shù)據(jù)可用性(DA)方案。簡而言之,KZG 承諾允許我們使用單個橢圓曲線群元素來承諾一個多項式。此外,該方案支持我們證明在某個點 i 上,多項式 φ 的值為 φ(i),使用恒定大小的見證。這種承諾方案在計算上是約束性的,并且也是同態(tài)的,允許我們巧妙地避開欺詐證明。

我們強制區(qū)塊生產(chǎn)者將原始交易數(shù)據(jù)排列成一個大小為 n x m 的二維矩陣。它使用多項式插值將每列的大小 n 擴展為大小 2 n 的列。這個擴展矩陣的每一行生成一個多項式承諾,并將這些承諾作為區(qū)塊頭的一部分發(fā)送。下面給出了區(qū)塊的示意性表示。

輕客戶端查詢這個擴展矩陣的任何一個單元格以獲取證明,這使得它能夠立即根據(jù)區(qū)塊頭進行驗證。恒定大小的成員身份證明使得采樣極為高效。承諾的同態(tài)特性確保只有在區(qū)塊構(gòu)建正確時,證明才能被驗證,而多項式插值確保了恒定數(shù)量的成功樣本意味著數(shù)據(jù)可用性的可能性非常高。

區(qū)塊的示意性表示

這個方案的更細節(jié)部分,以及進一步的優(yōu)化和成本估算,超出了本文的范圍。然而,我們想指出的是,雖然我們在這里討論的是一個二維方案,但類似的保證也可以通過一個一維方案提供,一維方案的區(qū)塊頭大小更小,但代價是減少了并行性和輕客戶端采樣效率。我們將在后續(xù)文章中更深入地探討這一點。

其他替代方案是什么?接下來會發(fā)生什么?

高維擦除編碼和 KZG 承諾并不是解決數(shù)據(jù)可用性問題的唯一方法。我們在這里略過了其他一些方法,如編碼默克爾樹、編碼交錯樹、FRI 和基于 STARK 的方法,但每種方法都有其優(yōu)點和缺點。

在 Avail,我們一直在使用 KZG 承諾開發(fā)數(shù)據(jù)可用性解決方案。在后續(xù)的文章中,我們將介紹實現(xiàn)細節(jié),如何使用它,以及我們?nèi)绾斡媱澑淖償?shù)據(jù)可用性問題空間。欲了解更多關(guān)于 Avail 的信息,請在 Twitter

Twitter 是源于美國的社群網(wǎng)路服務平臺。2022 年 10 月 27 日,馬斯克完成了對推特的收購案并將其并入了新成立的“X”公司。據(jù)馬斯克此前的推特信息,他將會創(chuàng)建一個包含一切的應用程序,并提到購買 Twitter 可以加速實現(xiàn)這一愿望。

上關(guān)注我們,并加入我們的 Discord 服務器。

Twitter:https://twitter.com/AvailProject

Discord:https://discord.com/invite/jTkvDrZ54r

也歡迎關(guān)注 Modular 101 的 Twitter 賬號:@Modular 101