很多人對 DA 的理解是錯誤的:DA=數據發佈,而不是數據可檢索

作者:Faust,極客 Web3

封面:Photo by Conny Schneider on Unsplash

導語:到底什麼是數據可用性?  可能絕大多數人第一印象是「可以獲取某個時刻的歷史數據」,但這其實是對 DA 概念最大的誤解。  近期 L2BEAT 聯創與 Danksharding 提出者、Celestia 創始人都對這一誤區做出了澄清,他們指出,Data Avalibity 實際上應該指「數據發佈」,但大多數人把 DA 理解成了「歷史數據可檢索」。,而後者實際上涉及到數據存儲問題。

比如,前一陣子 Dankrad 曾提到了 Layer2 的強制提款/逃生艙機制,他指出,Validium 的強制提款需要獲取最新的 L2 狀態來構造 Merkle Proof,但 Plasma 只需要 7 天以前的(這和兩者的合法 Stateroot 判定方式有關)。

借此,Dankrad 明確指出,Validium 需要 DA 保障用戶資金安全,而 Plasma 不需要。 在此處,Dankrad 用案例指出了 DA 和歷史數據可檢索的不同之處,即 DA 往往只涉及新發佈的數據。

在 L2BEAT 那裡,數據可用性 DA 與數據儲存 DS 的區別被進一步加強。 L2BEAT 的 Bartek 多次強調,DA 和數據存儲/歷史數據可查是兩碼事,而使用者能夠獲取到自己需要的 L2 數據,只是因為那些提供數據的節點 “對你足夠好”。 此外,L2BEAT 還計劃把「是否有許可權開放的數據存儲節點」當做 DA 之外的一個測評 Rollup 的新指標。

乙太坊社區/乙太坊基金會成員的上述言辭,表明瞭他們要在未來對 Layer2 相關概念進行規範化的梳理,並對 Layer2 本身進行更詳實的定義。 因為圍繞著 Rollup 和 L2 的很多名詞其實都沒有被很好的解釋清楚,比如多久前的數據算「歷史數據」——有人認為,因為智慧合約只能調用 256 個 block 內的過往區塊數據,所以 256 個區塊(50min)前的數據都算「歷史數據」。

而 Celestia 和乙太坊基金會口中的 “Rollup”,嚴格來說都是兩種東西。 本文旨在澄清 DA 概念和數據存儲的區別,從 DA 的來源、數據可用性採樣、Rollup 的 DA 實現方式,來為大家解釋到底什麼才是數據可用性——數據發佈。

DA 概念的來源

關於「數據可用性」問題到底指什麼,Celestia 創始人 Mustafa 如此解釋:DA 就是,當區塊生成者提出新 block 時,如何確保區塊裡的所有數據都發佈到了網路中? 如果區塊生成者不 Release 區塊中的所有數據,就無法檢測區塊裡是否包含錯誤交易。

Mustafa 還指出,乙太坊 Rollup 簡單地將 L2 區塊數據發佈到乙太坊鏈上,並依賴 ETH 來保障數據可用性。

而在乙太坊官網,有關於 DA 的如下概括:可以把數據可用性難題概括為一個問題:“我們如何驗證一個新區塊的數據是否可用? ”...... 對於輕客戶端來說,數據可用性問題是指在無需下載整個區塊的情況下,驗證區塊的可用性。

乙太坊官網還明確區分了數據可用性與可檢索性的區別:數據可用性是指區塊被提出時,節點下載區塊數據的能力。 換句話說,數據可用性與區塊尚未達成共識時相關...... 數據可檢索性是指節點從區塊鏈中檢索歷史資訊的能力...... 雖然存檔可能需要區塊鏈歷史數據,但節點無需使用歷史數據就可以驗證區塊並處理交易。

在 Celestia 中國貢獻者——W3Hitchhiker 合夥人任泓毅看來,Layer2 事先假設 Ethereum 足夠安全和去中心化,排序器可以放心大膽的把 DA 數據發到乙太坊,這些數據會無阻礙的傳播給所有乙太坊全節點。 而 L2 全節點本身就要運行 Geth 用戶端,算是乙太坊全節點的子集,所以可以接收到 Layer2 的 DA 數據。

而在 EthStorage 的創始人 Qi Zhou 博士眼裡,DA 的定義是沒有人可以把使用者提交到網路里的交易數據扣留住。 對應的信任模型是,我們只需要信任 L1 的協定本身,不需要再引入其他信任假設。

Qi Zhou 指出,現在乙太坊的 DA 實現方式其實就是 P2P 廣播(gossip 流言協定),每個全節點都會下載並傳播新 block,並存儲 Rollup 的數據。 當然,乙太坊全節點並不會永久存儲歷史區塊,在 4844 上線後可能會自動刪除一段時間前的數據(貌似是 18 天)。  存放全部歷史數據的檔案節點,現在全世界也沒有多少,EthStorage 則打算填補乙太坊體系的這一空白,並助力 Layer2 設置自己專屬的數據永存節點。

乙太坊基金會關於數據可用性 Data availability 的早期討論,可見於 Vitalik 在 2017 年的推文與 github 文檔。 當時他認為,如果要保證區塊鏈可拓展/高效率,就要抬高全節點的硬體配置(全節點就是下載完整 block 並驗證其有效性的節點,做共識的 Validator 是全節點的子集)。 但如果提高全節點硬體配置,就會提升運行成本,導致區塊鏈變得中心化。

關於這一點,Vitalik 說,可以設計一種方案,解決高性能全節點趨於中心化帶來的安全隱患。  他打算引入糾刪碼和數據隨機抽樣來設計一套協定,使得低配硬體的輕節點即便不獲知完整的 block,也可以得知 block 沒有問題。

他最開始的想法其實和比特幣白皮書裡提到的 idea 有關。 這個 idea 說,輕節點可以不接收完整 block,而當 block 有問題時,誠實全節點會發出「警報」,通知輕節點。 這個思路可以引申到後來的欺詐證明,但不能保證誠實全節點始終可以獲得足夠數據,也無法事後判斷區塊提議者是否扣留了某些數據沒發佈。

比如,某個節點 A 可以發佈欺詐證明,聲稱從節點 B 那收到了不完整的 block。 但此時無法判斷,這個不完整的 block 是 A 自己偽造的,還是 B 發出去的。 Vitalik 指出可以用數據可用性採樣 DAS 解決這個問題(顯然數據可用性實質涉及數據發佈問題)。

Vitalik 在「A note on data availability and erasure coding」一文中對這些問題及其解決方案進行了粗略討論。  他指出,DA 證明實質是對欺詐證明的一種「補完」。

數據可用性採樣

但顯然,DA 概念不是那麼好解釋的,因為 Vitalik 的這篇 github 文檔前後後進行了 18 次更正。 記錄顯示,最後一次更正提交於 2018.9.25。 而就在前一天的 2018.9.24,Celestia  創始人 Mustafa 與 Vitalik 聯名發表了日後聲名大噪的論文——Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities.

有趣的是,這篇論文第一作者是 Mustafa 而不是 Vitalik(另一名作者現在是 Sui 公鏈的研究員)。 文中提到了欺詐證明 Fraud Proof 的概念,並解釋了數據可用性採樣 DAS 的原理,粗略設計了一套 DAS +二維糾刪碼+欺詐證明的混搭協定。  論文中則明確提到,DA 證明系統實質是欺詐證明之上的必要補充。

如果我們從 Vitalik 的視角出發的話,這套協定的作用可以概括如下:

假設一條公鏈有 N 個高配硬體的共識節點 Validator,它們的數據輸送量很大,效率很高。 這樣的區塊鏈雖然 TPS 高,但共識節點數量 N 比較少,是比較中心化的,節點串謀概率高。

但是,N 個共識節點中起碼會有 1 個是誠實的。  只要至少 1/N 的 Validator 誠實,檢查出 block 無效,並願意在必要時刻廣播欺詐證明,輕節點或誠實 Validator 都能知道網路出現了安全問題,並可以通過 Slash 惡意節點、社會共識分叉等方式讓網路恢復正常。

可是,就像之前 Vitalik 提到的,如果誠實全節點接收到一個 block 且發現它缺乏某些部分,併發佈欺詐證明,此時不好判斷出是 block 提議者沒發佈這部分數據,還是中途被其他節點扣留了,亦或是發佈欺詐證明的節點自導自演。

此外,如果多數節點串謀,1/N 的誠實 Validator 被孤立,可能無法獲取新的 block,這算是一種數據扣留攻擊場景。 需要注意的是,此時誠實節點不知道是網路狀況不好,還是其他人串謀搞數據扣留,他也不知道其他節點是否也被孤立,不好判斷多數人是否已經串謀搞數據扣留。

綜上,要有一種辦法,以極高概率保證誠實 Validator 能獲取到驗證 block 所需的數據; 同時,要能判斷出是誰在搞數據扣留攻擊——是 block 提議者沒發佈足量數據,還是說被其他節點扣留了,亦或是多數節點在搞串謀。 顯然,這種安全模型比普通 POS 鏈的「誠實多數假設」多了很多保障,而數據可用性抽樣 DAS 就是具體的實現方式。

我們現在假設,網路中輕節點很多,可能是 10 N,每個輕節點都連接了多個 Validator(為了方便分析,假設每個輕節點都連接了全部 N 個 Validator)。 這些輕節點會向 Validator 多次發動數據抽樣,每次隨機請求一小部分數據(假設只佔一個 block 的 1%)。 隨後,它們會把抽到的碎片傳播給沒有這些數據的 Validator。  只要輕節點足夠多,且數據抽樣次數足夠頻繁,即便某些請求可能被拒絕,但只要大部分被回應,就可以保證所有 Validator 最終都能獲取到驗證 block 所需的足量數據。 這樣可以抵消掉 Block 提議者以外的其他節點扣留數據的影響。

(圖源:W3 Hitchhiker)

而如果多數 Validator 搞串謀,拒絕回應大多數輕節點的請求,此時人們很容易意識到鏈出了問題(因為就算一部分人的網速不好,也不至於差到大部分輕節點的請求都被拒絕)。 所以前述方案可以極高概率判斷出多數串謀行為,當然這種情況本身極少發生。

到了這裡,我們可以解決掉來自 Block 提議者之外的不確定性因素。  如果 Block 提議者搞數據扣留,比如他沒有在 block 里發佈驗證區塊所需要的足量數據(引入二維糾刪碼后,一個區塊里包含 2k*2k 個片段,而還原出區塊的原始數據至少需要約 k*k 個片段,佔 1/4。 提議者想讓其他人不能還原出原始數據,最少需要扣留 k+1*k+1 個片段),最終肯定會被誠實 Validator 檢測出來,而後者會廣播欺詐證明警告其他人。

按照 vitalik 和 mustafa 的說法,他們其實是把此前就有人提出的想法結合了起來,並在此之上做出了一定的創新。 而從整個構思的出發點與實現方式來看,顯然所謂的「數據可用性」指的是驗證最新 block 所需的那些數據,是否都有被區塊提議者發佈出去,且能不能被驗證者們接收到。  這關乎「數據是否完整發佈」而不是「歷史數據是否可以被檢索到」。

乙太坊 Rollup 的 DA 怎麼實現

有了前面的論斷,我們再來看乙太坊 Rollup 的 DA 實現方式,其實就比較清晰了:Rollup 裡的區塊提議者就是排序器 Sequencer,它每隔一段時間就會在乙太坊上發佈驗證 Layer2 狀態轉換所需要的數據。  準確的說,是向指定的合約發起一筆 Transaction,在自定義的輸入參數里塞進 DA 所涉及的數據,並最終被記錄進乙太坊區塊裡。 由於乙太坊足夠去中心化,可以確信定序器提交的數據會被「驗證者」順利接收到。 但不同 Rollup 網路中充當「驗證者」角色的東西是不同的。

(Arbitrum 排序器向乙太坊上某合約 post 的交易批次,合約本身不驗證這些數據,只拋出一個事件讓 L2 全節點來監聽,讓後者知道排序器發佈了交易批次)

具體而言,ZK Rollup 採用乙太坊上的 Verifier 合約充當「驗證者」。。 ZKR 最少只需要發佈 State Diff + Validity Proof,也就是狀態變化情況+有效性證明,Verifier 合約會檢測有效性證明,判斷它能否和 State Diff 對上號。 驗證通過後,定序器發佈的 L2 Block/Batch 就被認作有效。

(來源:前 Polygon Hermez 白皮書)

樂觀 Rollup 要在乙太坊發佈更多數據,因為它只能靠 L2 全節點去下載數據並驗證 Block 有效性。  這樣的話,至少要披露 每筆 L2 交易的數位簽名(現在一般用聚合簽名)、如果有調用合約的話,還要披露輸入參數,此外還要披露交易轉帳位址、防重放攻擊的 Nonce 值等。 但相較於完整的 Transaction data,還是有一些修剪。

相比於 ZK Rollup,樂觀 Rollup 的 DA 成本更高,因為 ZK Rollup 只需要披露一批交易執行後的最終狀態變化,附帶一個有效性證明,利用到了 ZK SNARK/STARK 的簡潔性; 而樂觀 Rollup 只能採用最笨重的方式,讓所有交易都在其他 L2 全節點身上重新執行一遍。

此前 W3hitchhiker 曾粗略估算过,不考虑未来的 4844 和 blob,ZKR 的扩容效应可以达到 OPR 的数倍,而如果考虑到 4337 相关的智能钱包(用指纹、虹膜数据取代私钥签名),ZKR 的优势会更明显,因为它不需要把指纹、虹膜的二进制化数据 post 上以太坊,而乐观 Rollup 需要)。

至於 Validium 和 Plasma/Optimium,其實是用乙太坊鏈下的 DA 層來實現 DA。 比如,採用了有效性證明系統的 ImmutableX 自己搭建了一組 DAC 節點(數據可用性委員會),專門發佈 DA 涉及的數據; Metis 則在 Memlabs 上發佈 DA 數據,Rooch 和 Manta 則採用 Celestia。 而目前看來,由於有 DAS 和欺詐證明系統的存在,Celestia 是以太坊之外可信度最高的 DA 層專案之一。

參考文獻

1.https://coinmarketcap.com/alexandria/article/what-is-data-availability 

2.https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding

3.https://www.youtube.com/watch?v=xV2XVCtQIGw&t=2977s

4.https://www.chainfeeds.xyz/feed/detail/45ca8444-113b-4d81-b3eb-cd90a1297f8d

5. https://arxiv.org/abs/1809.09044

6.https://ethereum.org/zh/developers/docs/data-availability/

免責聲明:作為區塊鏈資訊平臺,本站所發佈文章僅代表作者及嘉賓個人觀點,與 Web3Caff 立場無關。 本文內容僅用於資訊分享,均不構成任何投資建議及要約,並請您遵守所在國家或地區的相關法律法規。