5

認識 Danksharding -以太未來擴容的新方案

 2 years ago
source link: https://medium.com/taipei-ethereum-meetup/danksharding-90c88b949c6b
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

認識 Danksharding -以太未來擴容的新方案

本篇以科普的角度介紹 Danksharding,不會有複雜的數學或密碼學

0*9qBA1iRBx626Z266
Photo by Laula Co on Unsplash

在 The Merge 後,原本最令人期待的就是分片鏈的來臨,分片鏈上線後可以大大增加以太坊的吞吐量。在原本 Eth 2.0 的規劃是分片鏈加上全新的執行層,因為執行層的實作遇到難題,加上 rollups 隨著時間技術越趨成熟,Vitalik 於 2020 年 10 月提出以 rollup 為中心的規劃,後來的方向朝向分片鏈(儲存資料)加上 rollups。去年(2021)底,以太坊研究員 Dankrad Feist 提出 Danksharding,完全顛覆了原本分片鏈的設計,進而成為以太坊未來擴容新的方向。本文會一步步分析何謂 Danksharding,及其優異之處。

這篇 Delphi Digital 的文章,對於 Danksharding 技術細節與未來以太藍圖有非常詳盡的解釋,欲更深入瞭解者,推薦一讀(文長請小心服用)。

現在 PoW 主鏈負責了共識,執行跟資料儲存。Eth 2.0 的設計是將這三個功能分開,共識層由信標鏈(Beacon chain)負責,資料層由分片鏈(shard chains),在分片鏈上做各自的執行層有研究上的挑戰,且執行的服務可由 rollups 提供,所以不作執行層的分片。

0*Ur5Bz0f8xnUCG51V.png
source: https://vitalik.ca/general/2021/04/07/sharding.html

分片鏈有 64 條,每條有自己的資料跟一組的驗證節點,驗證節點們負責驗證所屬分片鏈。為避免驗證節點被買通或互相串通,所以每過一段時間,驗證節點就會被分配到到不同的分片鏈上,對不同分片做驗證。切換到不同的分片,需要先同步新的分片鏈上的資料,所以每一段時間,就會有一次大範圍節點間的同步,而這過程複雜,難以確保時間內都能及時同步完成。此外,跨分片鏈的溝通也是一個複雜的問題,而此設計也加深了 MEV 問題

以 rollups 為中心的藍圖

Vitalik 這個提案奠定了以太坊未來發展的方向,將 L1 定位成資料公證的鏈,任何 rollups、L2 的交易或是任何需要公證的資料,都放到鏈上,驗證節點不需驗證資料的有效性*,只需要確保資料可取用性(data availability),而資料有效性的驗證都讓其他 rollups 或 L2 處理。

* 以 optimistic rollups 來說,sequencer 可以放一個不合法的 state 到鏈上,宣稱自己帳戶(憑空)多了 100 萬,但正常運作的節點都能驗證這是一個不合法的 state。

當時的時空背景,各家 optimistic rollups 已經準備主網上線,zk rollups 不支援合約的版本也已經上線一陣子,rollups 的技術已相對成熟。以安全性、複雜度或完成度來說,將主鏈的交易在不同的分片執行,最終再由信標鏈對跨分片交易取得共識的方式,不如把主鏈當作資料公證層,再單純對資料做共識 ,並將執行的責任就交給已經準備上線的 rollups,如此設計會更加簡單且快速。

Danksharding

Danksharding 由以太坊研究員 Dankrad Feist 於 2021 年底提出,是一個全新的設計,不再是補強原本分片鏈的設計,而是取代原本分片的設計。Danksharding 不把資料放在不同的鏈,而是把所有的資料都放一起,產生一個超大區塊,區塊中資料會被分成 256 組(每組可容納 ~125KB,目前區塊平均大小約 ~90KB)。可以想像一組資料對應原本的一個分片鏈,所以相當於擴展成 256 條分片鏈的交易量,而且 256 條鏈會同時完成驗證(因為是同一個區塊),不像先前設計,還需要互等(因為會有跨鏈交易,所以自己分片驗證完後,還需要等其他分片也驗證完)。不過可以想像的是,如果全部資料都塞成到一個區塊,在網路頻寬、儲存空間跟運算能力等都會有問題。我們下面一一來解釋。

新的設計中沒有了分片鏈,因此,資料可取用性(data availability)的責任就落在信標鏈身上了。

1*IGV9gfWd3qrS_CrD45ARfg.png
source: https://docs.google.com/presentation/d/1-pe9TMF1ld185GL-5HSWMAsaZLbEqgfU1sYsHGdD0Vw/edit#slide=id.g1150d91b32e_0_690

如圖中所示,所有資料都在綠色的這個大區塊中,包含了原本的 beacon block 跟分組後的資料,且所有驗證者都一起驗證,不再是分開不同委員會來做驗證。

透過抽樣挑戰來驗證資料可取用性(Data Availability Sampling)

資料抽樣挑戰這個概念在當初設計 Eth 2.0 輕節點時就有提出了,概念上不變,細節可以參考這篇

快速介紹一下,這個設計使用了糾刪碼(Erasure Coding)的技術。糾刪碼是現今常使用的一項技術,例如磁碟陣列或是網路通訊。簡單來說,就是將原本資料做複製,所以遺失了部分資料,仍能重組回原本資料。

使用糾刪碼的好處是,就算是區塊建造者窩藏部分資料也沒關係。舉例來說,把資料被分成 100 份,沒有使用糾刪碼,驗證節點在抽樣時,就要確保資料要 100% 都有被取到,只要缺了 1 份,資料就無法再重組起來。但是透過糾刪碼,將資料延展為 200 份,只需要確保總抽樣數有 50% +1 份,剩下的就算是區塊建造者窩藏起來,也沒關係,因為只要有 50% +1 份資料,就足夠能重建回原本的資料。而這 50% +1 的抽樣總數,就需要有足夠的驗證節點一起來做抽樣挑戰。糾刪碼加上足夠的抽樣挑戰,就能確保資料可取用性。

寫的資料可得性,寫得很清楚且簡單易懂,十分推薦!

2 維 KZG 機制

使用了糾刪碼,會將原本的資料加了備用的資訊,使資料量變大,但是要怎麼確保備用資訊是使用糾刪碼產生的還是只是無意義的垃圾資料呢?我們可以透過密碼學的承諾,來確保資料是如我們預期的。這邊選用了 KZG 承諾來作為資料有效的確認。(何謂密碼學的承諾,可以參考下文 “多項式承諾” 一節。)

在實務上,不會產生一個大的 KZG 承諾,因為重建區塊可能會很常發生,而重建後需要確認承諾是否一致,但要產生整個大區塊的 KZG 承諾需要強大的節點才能完成(除了產生區塊的節點需要產生承諾,驗證節點也需要產生承諾,來確保下載的資料是正確的),因此這樣一個區塊一個承諾並不符合需求,強大的驗證節點也不符合去中心化的願景。所以會將每個分片資料產生一個 KZG 承諾,當驗證節點需要重建資料時,只需確認多個分片的 KZG 承諾即可。為了更有效率,採用 2 維 KZG 的機制,將 256 個分片的 KZG 承諾也使用了糾刪碼,擴展成 512個。

1*uFEllLo800y7WQyADVUsBw.png
source: https://docs.google.com/presentation/d/1-pe9TMF1ld185GL-5HSWMAsaZLbEqgfU1sYsHGdD0Vw/edit#slide=id.g1150d91b32e_0_705

擴展成 2 維後,經過計算,所需的抽樣挑戰數就會增加為 75 次,才能確保資料可取用性,如此驗證節點所需頻寬則為

512 bytes * 1 block * 75 samples / 16 secs = 2.5 KB/s *

相較於之前 64 個分片需要頻寬 60KB/s 減少了許多。

*在 Danksharding 中,提議將 slot 的時間從 12 秒改為 8 秒,這裡分母的 16 秒則是兩個 slot 的時間,原因下面章節會再解釋。

剛剛 75 次的抽樣挑戰是在說明,512 x 512 組資料中一節點若任意取 75 組且都有取得,有非常高的機率代表資料的可取用性(完整存在且可取得的)。但若只有單一節點成功完成抽樣挑戰,仍無法保證資料可取用性,需要整個網路一起抽樣挑戰,當有足夠多的抽樣總數時(這裡我們需要 75% + 1 組),就算區塊建造者藏資料,依然可以透過已取得的樣本來重建區塊。

在每個 epoch 有 32 個 slot,驗證者會被平均分配到這 32 slots 中,每個驗證者需要任意取兩個橫列及兩個直行做驗證,驗證節點需要確保這四組資料在 32 slots(一個epoch )的時間內都一直存在,才在所屬的 slot 中對此區塊做投票。整個網路上需要足夠多的驗證者,才能確保區塊的可取用性,因此降低對驗證節點的需求,以提升驗證者數量是非常重要的,而 2 維 KZG 的設計正是大大的減輕了驗證節點的負擔。

有了抽樣挑戰的設計,網路中人人都可以是輕節點(除了少數的出塊的節點),使得運行節點變得更容易、成本更低。

分離區塊發佈者跟區塊建造者(Proposer-Builder Separation, PBS)

在現今,礦工為了得到最大利潤,會有很多複雜的策略從交易中提取額外獲利,在未來區塊變大後,提取額外利潤的可能性更多了,即使運行相同的策略對節點的負擔也更吃重,再加上產生 KZG 承諾需要強大的運算能力,如此會使節點更加中心化。為了降低節點的硬體需求,使得網路更加去中心化*,將生產區塊跟發布區塊的角色分開。區塊建造者(builder),在利潤最大化的前提下將交易排序,產生出區塊,而區塊發佈者(proposer),負責發布由區塊建造者所產生的區塊。若同時有多位區塊建造者產生區塊,則透過競價機制來決定發布誰的區塊。這個分工有沒有覺得很熟悉?這個跟現在 Flashbots 的機制一樣,將產塊的功能獨立出來,讓區塊建造者可以從交易中抽取他們利益,礦工只需發布區塊。在這個分離的架構中,區塊建造者的收入是 priority fee 跟他們從交易中抽取的價值,區塊發佈者則收區塊建造者給的競價費。但是在協議層做這樣的分工設計,會加重 MEV 的現象及造成審查攻擊。

*在 Vitalik Endgame 一文中也認為需要部分的中心化來擴大規模,但只需要去中心和去信任的驗證,就可以維持權力的平衡。因此在 Danksharding 中強大的區塊建造者也呼應了 Vitalik 的想法。

兩階段 PBS

1*waup5HETs1cgjPQFFTGW5A.png
source: https://docs.google.com/presentation/d/1-pe9TMF1ld185GL-5HSWMAsaZLbEqgfU1sYsHGdD0Vw/edit#slide=id.g1150d91b32e_0_673

為了使整個網路更有效率,且進一步減少 MEV 的產生,使用 commit-reveal 兩階段的機制。就是在競價的階段,區塊建造者只提供區塊標頭(block header)給區塊發佈者,等此區塊標頭贏得競標後,到下一個 slot 區塊建造者再將區塊內容公開,驗證者再對區塊內容做驗證。此兩階段的方法,一方面降低網路流量,另一方面可避免被再度 MEV。因為如果區塊發佈者將整個區塊內容都散佈到網路中,其他的區塊建造者就可拆解其交易策略,再做微調,提出一個更有競爭力的區塊。甚至,區塊發佈者可以直接複製其區塊內容,就不用再給區塊建造者任何費用了。

但兩階段最大的缺點就是交易會被延遲確認,本來只需要一個 slot(12 秒) 就會可以確認打包,現在就變成兩個 slot(24 秒) 了。目前有在計畫將一個 slot 改為 8 秒,這樣就可以減少確認的時間,不過仍在討論中。

抗審查清單(Censorship Resistance List, crList)

PBS 的架構,給予了區塊建造者更高的審查交易能力,他們可以根據自己的喜好,選擇想要打包的交易或是忽略特定的交易。因此,提出了混合式 PBS(hybrid PBS),建立在原本的兩階段 PBS 之上。兩個方案最大的差異是,區塊建造者可以打包的交易受到限制,區塊發佈者會提供交易清單,而區塊建造者必須將清單內的交易都打包才行,如下圖

1*5e289BRWVEWkP1l7ct5f4A.png
source: https://docs.google.com/presentation/d/1-pe9TMF1ld185GL-5HSWMAsaZLbEqgfU1sYsHGdD0Vw/edit#slide=id.g1150d91b32e_0_780
  1. 區塊發佈者提供一份抗審查清單,清單內的所有交易要盡可能地被打包(原則上是都要被打包,不過可能有些例外狀況可以不用,但目前規格也尚未確定)
  2. 區塊建造者根據抗審查清單產生出區塊,然後競價,競價內容必須包含抗審查清單的雜湊值(如同二階段 PBS,只有揭露區塊標頭)
  3. 區塊發佈者接受區塊建造者的出價
  4. 區塊建造者發布其區塊,證明包含了所有來自抗審查清單裡的交易,否則不會被驗證者接受
  5. 驗證者確認區塊內容的有效性

但此提案還是有些漏洞,例如說,區塊發佈者提交了一份空的清單,那這個機制就被繞過了。最終 PBS 的設計還在討論中,還需要更多的研究。

Proto-Danksharding(EIP-4844)

proto-danksharding 就是 EIP-4844,是 post-merge 一個重要的更新。 Danksharding 大幅引進了新的技術,將複雜度大大增加,這項 EIP 可以視為將 Danksharding 拆成兩階段,將有解決方案且風險較低的的部分先更新,替為未來的 Danksharding 的上線做鋪路。此外,此 EIP 也能大幅降低 rollups 的上鏈成本。現今 rollups 都是使用 calldata 將交易資料永久儲存在鏈上,但對 rollups 來說,這些歷史交易其實只需要儲存一段時間就足夠,不需要永久儲存,若對歷史交易有需求的人,可以自行下載並儲存。

proto-danksharding 主要是引進了一種新的交易類別,這個交易類別可以攜帶新的資料類型 blob,且此類型資料會在固定時間(30 至 60 天)後被刪除。blob 跟 calldata 的不同在於,blob 可攜帶資料量非常大(有 128KB)但成本很低(120K gas),此外,EVM 也無法取得 blob 的內容。

應該不少人會有疑問,為什麼不降低 calldata 成本就好?因為要預防在最極端狀況下,區塊會變超大。目前最大的 gas limit 是 30M,calldata 每 byte 需 16 gas,以此狀況,區塊約是 1.8MB,若我們將 calldata 成本便宜 5倍甚至 10 倍,那極端狀況下區塊大小就會是 9MB 或 18MB。一般狀況下兩者沒有太大的差距,但在極端狀況下,這是 calldata 成本降低後會碰到最直接的問題。

那我們來算算 proto-Danksharding 極端狀況下的資料量。每個 blob 會有 4096 個 32 bytes 的資料,目前規格每個區塊最多有 16 個 blob(Danksharding 後預計有 256 個),因此我們可以得出 4096 * 32 * 16 = 2MB,相較於直接降低 calldata 成本,blob 的形式可以乘載的資料更多,在極端狀況卻不會讓區塊大小增長太大。

此外,歷史資料的儲存不該是協議層需要在意的,有需求者可以透過其他第三方專案(例如,etherscan, the graph)獲取歷史資料,加上在 PoS 的設計下,交易是有最終確定性的,因此歷史資料對於協議層來說,更加沒意義。

像是 Mina 使用零知識證明的方式證明區塊的有效性,新的同步節點並不需要去下載全部交易並跑過一次做確認,只需要從有被證明過的區塊開始進行同步即可。Mina 設計之初就是以不需歷史資料為目標。

未來,在以 rollups 為主軸的路線下,鏈上的資料將都是 blob,而 blob 過一段時間後,就會被刪除,解決了因歷史交易而日益增長的儲存空間。而透過 PBS 機制,讓需要強大運算的責任外包給區塊建造者(builder),加上產生多組 KZG 承諾,減少了驗證節點在重建時的運算需求。透過二維糾刪碼,雖然抽樣挑戰次數變多,但只須對單一鏈做抽樣挑戰,所以頻寬要求也減少了。原本分片設計把驗證者拆分成 32 組,分組做驗證,而現今的設計,全部的驗證節點一起驗證資料,也因此有更高的安全性。

此外,比起原本分片鏈的設計,現在只有一個大的信標鏈區塊,所以 L2 的交易被打包成 blob 寫進 L1 後會直接被確認(原本需要等待所有分片的結果),因此 zk-rollups 可以做到與 L1 做即時互動。

不過,這個全新設計,引入了不少的未知數,至於什麼時候能上線,可能還需要再等等。

Thanks to

and for feedback and for the review.

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK