這一刻,即將發生。

作者:Kylo,Zonff Partners 投資經理

封面: Photo by Luca Nicoletti on Unsplash

ETH 2.0 的 Merge 階段近在咫尺,官方預計約在 9 月 15 日左右實現 POW 到 POS 的轉換。此次 POS 轉換與以往公鏈分叉所用的方式不同,並沒有採用在特定區塊高度分叉的方式,而是規定了 TTD 並設置 “難度炸彈”。TTD 全稱為 Total Terminal Difficulty,即以往所有區塊難度的總和。當全網積累的挖礦難度值達到 TTD 時,ETH 主網會啟動 “難度炸彈”。“難度炸彈” 是進行以太坊難度調整的後門函數。以太坊的 POW 出塊時間並沒有固定,而是根據全網算力大小對挖礦難度進行動態調整,通過這種方式把區塊時間固定在一個大致的範圍。難度炸彈的部署則是通過後門函數將挖礦難度調整到一個極大的值,使得沒有礦工可以在該挖礦難度下生產區塊,從而推動著礦工放棄 POW。POW – POS 的轉換並沒有設置一個固定的區塊高度,而是規定 TTD 作為 Merge 發生的時刻,部分原因其實在於防止有人刻意破壞 Merge 的進程。

1.1 分叉聲浪以及可能的延期利空

社區關於 ETH 分叉之爭主要集中在 POW 與 POS 誰更加符合區塊鏈自身的定義以及特性,即 POS 是否違背了區塊鏈去中心化的精神以及是否具有抗審查性。但無論爭論的結果如何,目前已經有多方勢力包括礦工群體、交易所群體以及 ETH 大戶在為各自的利益用腳投票。

可能的延期利空則是因為 8 月的 Goerli 測試網合併時出現了一些問題,這些問題並沒有影響測試網的合併。但對於 Merge 這種會影響以太坊未來發展的重要事件,小問題可能會使主網合併推遲數月。此外,合併的推遲也相當於為 POW 分叉創造了時間,增加了整個體系的混亂度。

若最後真的實現了 POS/POW 分叉,可能存在的情況包括:

  • ETH POW 鏈分叉鏈缺少預言機,DeFi 失效;
  • 分叉鏈中由中心化機構發行的資產,如 WBTC 資產等沒有了實際價值支撐;
  • ETH POW 鏈缺少 RPC 接口,用戶無法與 ETH POW 進行鏈上交互;
  • AMM DEX 的定價不依賴於預言機,因此 Uniswap POW 可以獨立運行,但是由於大多數 DeFi 幣沒有價值,因此搶先將所有 AltcoinPOW 換成 ETH POW 將能獲得最大收益;
  • 由於缺少連接 ETH POW 的 RPC 接口,釣魚攻擊的頻率會增加。黑客可能利用用戶在 RPC 上授權,ID 為 1 的 TX,在 POS 鏈上展開重放攻擊,騙取用戶 ETH 2.0 主網的資產;
  • 交易所是最大的受益者,ETHPOW 的變現必須通過交易所實現,這意味著交易所只要支持 ETHPOW 的買賣就可以獲取交易手續費;
  • ETH POW 生態的虛無也給了各個項目方可乘之機,例如在 ETH POW 鏈上發行以 ETHPOW 為抵押品的穩定幣;
  • ETH 主網上關於 ETH 的借貸利率暴增;

普通交易者在整個過程中可做的事情其實並不多,最重要的還是注意不要被釣魚攻擊和重放攻擊。

1.2 ETH 2.0 的實現路線圖

ETH 2.0 自提出到開始實行經歷了一次大改,最初 ETH 2.0 的設計(以下均稱 Sharding 1.0)是實現狀態分片。狀態分片可以簡單理解為將以太坊主網拆成多條子鏈,並將其命名為 Shard1、Shard2 ……,每條 Shard 都有以太坊主網的全部功能,擁有獨立的狀態並且獨立處理各自的交易,最後利用信標鏈將所有的子鏈統籌起來,也就實現了狀態分片。但在 2020 年隨著 Rollup 潛力的凸顯,以太坊便改變了其實現狀態分片的路線圖,而將數據分片(以下稱為 Sharding 2.0)作為 ETH 2.0 的最終目標。數據分片類似於模塊化區塊鏈,即將以太坊分成多個數據分片,每個數據分片連接一個或多個 Rollup,Rollup 作為執行層而以太坊則成為數據層與共識層的底層。

因此目前 Sharding 2.0 的整個路線圖大致分為三部分:Merge、Proto-Danksharding 和 Danksharding。

Merge 預計發生於 9 月 15 日,而 Proto-Danksharding(EIP-4844)預計在兩年內完成,Danksharding 的實現更是在未來的 3-4 年。實現 Danksharding 後以太坊的 TPS 有望達到互聯網級別,從而奠定了區塊鏈應用的未來。

Harmony/Near 分片

2.1 Harmony

Harmony 的分片模式與 ETH 的 Sharding 1.0 版本極為類似,若 ETH 2.0 沒有改變路線圖,則未來以太坊主網關於 Sharding 的形態機制將與 Harmony 大體一致。Harmony 利用信標鏈統籌分片鏈的狀態,不同的分片可以理解為同質化子鏈,子鏈內部的交易由管理子鏈的驗證者進行驗證。每個分片在出塊後都需要將分片區塊的區塊頭存儲在信標鏈對應位置的區塊中,這樣使得信標鏈區塊可以存儲所有分片的狀態信息。除了統籌分片鏈的狀態外,信標鏈還需要執行的功能包括提供隨機數用於隨機輪換各個分片的驗證者和區塊提議者、記錄每個分片的 BLS 聚合簽名以及驗證者的狀態。

信標鏈確立區塊提議者以及與各個區塊對應的委員會的方式是通過隨機數實現的。區塊提議者將負責提議區塊,負責該分片的委員會在分片內部達成 FBFT 共識,並在確認後將達成的共識上傳信標鏈(FBFT 共識指的是挑選一個領導者節點,領導者節點收集其他驗證者的簽名,因此通訊複雜度為 O(n),方便快速達成共識)。

具體步驟如下圖所示:

圖片
製圖:Zonff Partners,來源:https://harmony.one/whitepaper.pdf
  • 區塊提議者在其所屬的 Slot 中提議一個區塊,並將該區塊頭信息向其他驗證者傳播;
  • 驗證者在收到消息後確認該區塊頭,並附上自己的簽名,表示接受該區塊提議者提議區塊;
  • 這些簽名匯集到區塊提議者那裡,計算合成為一個 BLS 聚合簽名;
  • 區塊提議者將 BLS 簽名發送給驗證者,當 BLS 簽名中包含超過 2/3 的驗證者權重時,驗證者將對區塊內的交易進行驗證,驗證結束後附上自己的簽名,表示交易驗證完成,並將簽名發送給區塊提議者;
  • 區塊提議者收集 BLS 簽名,在 BLS 簽名超過 2/3 的權重時確認該區塊,並將該區塊以及所有的 BLS 簽名廣播給所有的驗證者,分片鏈上的 Slot 成功出塊;
  • 分片鏈上的 Slot 出塊時,該區塊頭信息以及生成該區塊時各個驗證者的 BLS 聚合簽名將會被記錄在信標鏈對應的 Slot 中。同時其他分片也會收到該分片的區塊頭信息並記錄在區塊內,方便跨片交易的驗證;

在所有的分片都出塊後,對應位置的信標區塊將收集所有的區塊頭信息、BLS 聚合簽名以及所有驗證者的狀態並將這些信息打包成信標鏈區塊。但這個過程中其實存在著分片鏈出塊與信標鏈出塊的協同性問題。由於分片鏈過多,短時間裡信標鏈可能沒有辦法收集全所有的分片鏈頭信息,從而出現漏塊的情況。為解決這個方面的問題,Harmony 從兩個方面給出了解決方法:一是用 FBFT 共識取代 PBFT 快速達成分片區塊內的共識;二是利用高性能節點快速協同信標鏈區塊和分片鏈區塊的信息。Harmony 的問題其實是所有分片鏈都會遇到的問題,針對這個問題 Near 和 ETH 2.0 分別給出了自己的答案。

儘管 Harmony 與 ETH 2.0 的 Sharding 1.0 版本在結構上有些相似,但其仍然具有不同於 ETH 2.0 的特點,具體包括:

  • 驗證者質押的幣會隨機分配到不同的分片,這意味著發動攻擊的人沒有辦法把幣集中在某一個分片上;
  • 驗證者質押獲得的獎勵並不與質押的幣的數量線性相關,而是具有凹性,即邊際質押收益遞減;
  • 新入駐的節點可以通過 Hashlink 連接每個 Epoch 的 Checkpoint 以實現快速狀態同步;
  • 跨分片交易時可以繞過信標鏈直接進行分片鏈之間的交易;

2.2 Near

Near 一直以來以分片作為該公鏈的特色,但直到目前為止 Near 還沒有實現像 Harmony 那樣的狀態分片。Near 在架構上也與 Harmony 這些以信標鍊為協調樞紐的分片結構不同。Near 的分片集中在一個區塊內,即將一整個區塊做分割,分成不同的 Chunk。而 Chunk 其實也就可以被認為是一個分片。

Near 的逐步分片過程呈以下幾個階段:

  • 2021 年第四季度實現 Simple Nightshade,將 Near 的區塊空間分成四個 Chunk;
  • 2022 年第一、二季度在 Near 生態引入 Chunk-Only-Producer;
  • 2022 年第三季度通過 Nightshade 真正實現分片;
  • 2022 年第四季度實現動態分片,即根據容量需求動態調整 Chunks 的大小;

上述概念可能會讓人有一些疑惑,其實直到 2022 年第三季度 Near 的 Nightshade 開始實行前,Near 都沒有做到狀態分片,狀態分片的實行是逐漸推行的。Simple Nightshade 階段只是把區塊空間分片,但是交易的確定與驗證與其他 Layer1 POS 公鏈沒有太大差別,驗證者同時處理所有的交易。接著在 2022 年第二季度,Near 引入了新的角色- “Chunk-Only-Producer”,其本質上也是驗證者,只不過作用範圍局限在單個分片內,用於專門驗證每個 Chunk 內的交易。該階段裡 Near 生態裡總共有兩大類驗證者,第一類是可以出塊的高性能驗證者,負責整合所有的 Chunk 塊並彙總成整區塊以及跟踪所有分片狀態並進行交易驗證;第二類就是局限在分片內的 Chunk-Only-Producer,負責分片內 Chunk 的出塊以及 Chunk 內交易的驗證。第二類驗證者對於節點性能的要求並不高,因此 Near 公鏈在 Chunk-Only-Producer 層面可以做到一定程度的去中心化,但仍然需要高性能的第二類驗證者負責大區塊的生成。第三階段 Near 將實行 Nightshade,此時 Near 才真正實現了狀態分片。

圖片
製圖:Zonff Partners,來源:https://near.org/downloads/Nightshade.pdf

狀態分片的實現意味著每個分片可以被看作是一條 “鏈”,該分片上的交易由負責該分片的 Chunk-Only-Producer 進行驗證。為更近一步降低驗證者節點的性能要求,Near 使用糾刪碼技術對 Chunk 的數據進行處理,而沒有選擇對 Chunk 內的所有數據進行廣播。直接廣播 Chunk 的所有數據可能會使性能較低的出塊節點出現丟包的現象,而通過糾刪碼技術,驗證節點只需接受 Chunk 的碎片信息即可,從而降低了節點的性能負擔。糾刪碼是一種對於數據的冗餘處理辦法,將一整塊數據處理成 n 份,當需要進行數據還原時只需要其中任意的 f 份即可。在某個 Chunk 數據的廣播過程中,Chunk 數據被冗餘處理,每個驗證節點隨機獲取一份糾刪碼。當大多數的驗證節點收到來自所有分片內 Chunk 數據的糾刪碼時,這些節點會發動共識投票,匯總各個節點手中的 Chunk 糾刪碼數據段,恢復原來的 Chunk,並按照分片順序對所有的 Chunk 進行排列,確立 Near 的主區塊並附上聚合簽名。

Near 為解決驗證者網絡中心化問題使用的糾刪碼技術目前已經被多種協議或者公鏈所使用,ETH 2.0 的 Danksharding 也同樣使用糾刪碼技術以達到去中心化驗證以及可拓展的效果。

ETH 2.0 基本機制

3.1 客戶端的變化

Merge 代表著信標鏈與目前以太坊主網的合併,以太坊網絡將 “無感” 轉換為 POS 共識機制。“無感” 主要針對的是用戶,但對於礦工以及驗證者節點而言,他們仍需要為 POS 轉換做一些客戶端層面的改變。

製圖:Zonff Partners,來源:https://ethresear.ch/t/eth1-eth2-client-relationship/7248

類似於模塊化區塊鏈將執行與共識分離一樣,Merge 之後以太坊客戶端也會做到執行與共識的分離。POW 階段的以太坊客戶端被稱為 ETH 1.0,其包含挖礦、POW 共識、交易驗證、內存交易池等多個功能。但當共識機制轉向 POS 後,ETH 1.0 Client 中關於挖礦以及 POW 共識的部分將全部被廢除,剩下的部分作為執行客戶端繼續運行在以太坊網絡中。共識層則是由共識客戶端負責,也稱為 ETH 2.0 Client,運行在信標鏈節點上,主要負責達成 POS 共識。共識客戶端與執行客戶端合併起來共同組成了 Merge 後的以太坊客戶端,兩者之間的連接是通過 API 實現的,並通過 JWT 私鑰進行驗證。

共識客戶端與執行客戶端可以做到分離,驗證者可以只運行執行客戶端並把共識客戶端託管在信標節點上,也可以選擇在同一台機器上同時運行執行客戶端和共識客戶端。

如下表所示,運行客戶端並不要很高的性能,消費級別電腦即可。

ClientCPU UsageMinimum RAM UsageSync Time
LighthouseModerate2 GBModerate (normal sync)Instant with checkpoint sync
NimbusLow0.75 GBModerate (normal sync)Instant with checkpoint sync
PrysmModerate2 GBModerate 
TekuModerate4 GBSlow (normal sync)Instant with checkpoint sync
ClientTypeCPU UsageMinimum RAM UsageSync Time
GethFullModerate 4 GBModerate 
BesuFullModerate 16 GBModerate 
NethermindFullModerate 16 GBFast
Infura*LightLowNone
Pocket*LightLowNone
圖片
製表:Zonff Partners,來源:https://docs.rocketpool.net/guides/node/eth-clients.html#execution-clients,圖片來源:ethos.dev

3.2 出塊模式的改變

POW 出塊是通過求解哈希難題實現的,在全網算力動態變化的情況下,每個區塊出塊時間也會動態變化。但由於 POS 是指定出塊者,每個區塊的時間間隔是固定的。Merge 之後以太坊會以 6.4 分鐘為一個 Epoch,共 32 個 Slot,因此每個 Slot 為 12s,理想情況下每個 Slot 都應該有一個區塊。

信標節點通過 RANDAO 和 VDF 確立每個 Slot 的驗證者委員會以及區塊提議者,一個 Epoch 需要挑選 32 個提議者和 32 個驗證者委員會。每個 Slot 都應該有一個區塊,如果沒有則說明區塊提議者沒有盡到自己的義務,將會被罰沒部分 ETH。根據泊松分佈,在考慮可能存在區塊丟塊的情況,區塊的生成時間平均下來約為 13s。

對於如何理解 RANDAO 和 VDF,以下舉個簡單的例子,

RANDAO 是一種生成隨機數的方式,假設班級裡有 10 個同學,老師想隨機挑選一名學生給其發放獎勵。老師給出的挑選方法是所有的同學同時給出一個隨機數,老師將得到的 10 個隨機數加和,最後得到的數字對 10 求餘,剩下的數字就是應該挑選的同學。但是從上述 RANDAO 的運行過程中其實可以發現一個問題。如果某個同學作弊,後於 9 個同學給出隨機數,那麼其就可以根據 9 個同學給出的隨機數信息,挑選一個最有利於自己的數字,使最後的結果指向自己。因此 RANDAO 的有效運行是需要引入防作弊機制的,即需要用一定的方式保證所有人同時給出答案。VDF 也就派上了用場。VDF 全稱為可驗證延遲函數,該函數的重要特徵在於得到結果的計算過程無法並行計算,即無法加速。但得到結果後,驗證該結果的計算量卻又非常小。VDF 是通過哈希函數實現的,哈希函數計算慢驗證快的特性也跟 VDF 的性質一致。

VDF 的具體實現過程比較複雜但有一種簡單的理解方式:F(x) = (((x)^2)^2)^2………^2

上述函數的 () 並非簡單算術中表示的 (),而是某個複雜函數。計算 F(x) 的值只能串行運算多次。在單次計算時間確定的情況下,計算該函數所需要的時間是固定的,這也就因此解決了 RANDAO 可能存在的作弊問題。

研究特定的 VDF 算法,維持 VDF 計算時間的穩定性對於 ETH 2.0 網絡的穩定非常重要。Ethereum Foundation 曾與 Filecoin 合作研發 ASIC 化的 VDF 算法。穩定後的 ASIC 算法可以將 VDF 計算時間限制在 102 分鐘。

3.3 Gasper FFG 與 LMD GHOST

Gasper FFG 在 ETH 2.0 中主要實現區塊的最終確定性,而 LMD GHOST 則是通過分叉選擇規則,選擇某個區塊接入當前的鏈。這兩個機制都是以投票的形式達成共識。每個驗證者在驗證區塊時需要向信標鏈提供三個信息:確認區塊內交易的簽名、Gasper FFG 投票以及 LMD GHOST 投票。上傳確認各個驗證者簽名的原因在於,當驗證者提供錯誤證明後,上傳信標鏈的簽名將成為罰沒該驗證者 ETH 的證據。

Gasper FFG 投票是每個 Epoch 內所有的驗證者必須參與的投票,一個 Epoch 只投一次,作用是確立該 Epoch 以及上一個 Epoch 的 Checkpoint。Checkpoint 指每個 Epoch 內的第一個區塊。由於可能存在區塊信息傳輸不及時的情況,對於不同的驗證者而言其觀察到的每個 Epoch 內的第一個區塊可能並不一樣。因此 Gasper FFG 投票的本質就是統一這種可能存在的信息差,把每個 Epoch 的 Checkpoint 定下來。

在當前的 Epoch 結束時,若有超過 2/3 權重的驗證者為該 Epoch 的某個區塊背書,認為其為該 Epoch 的 Checkpoint 並投票給上個 Epoch 的 Checkpoint 時,上個 Epoch 的區塊被認為達到最終確定,而該 Epoch 的區塊則被定義為 Justification 的狀態,可譯為待最終確定。因此在以太坊實現 Merge 之後其區塊最終確定的時間反而變長了,至少為 6.4 分鐘,最多為 12.8 分鐘。在 Merge 之前,以太坊區塊的最終確定性是通過最長鏈原則實現的,6 個區塊即可確定最長鏈,因此最終確定時間只需要約 1 分鐘。但實際上 POW 的最終確定和 POS 的最終確定性是有一定差異的。雖然 POS 達到最終確定性的時間較長,其一旦達成便不可回滾。而對於 POW 而言,其達成最終確定的區塊永遠都有回滾的風險。

LMD GHOST 又稱分叉選擇規則,每個 Slot 內的驗證者都需要根據權重選擇當前 Slot 連接主鏈的區塊,LMD GHOST 投票也是為了解決區塊確認過程中存在的信息差的問題。舉個簡單的例子,Slot 1 位置生成了區塊 A,Slot 2 位置生成了區塊 B,但由於信息傳遞不及時,小部分 Slot 2 的驗證者並沒有收到區塊 B 生成的任何信息,因此錯把區塊 A 當作 Slot 2 對應位置的區塊,此時由於區塊 B 獲取了最多的票數,其將在 Slot 2 的位置與主鏈連接。

3.4 ETH 通脹率、GAS、TPS 的變化

以太坊主網轉向 POS 後每年 ETH 的產量將大幅度降低,而且由於 EIP-1559 在不斷銷毀 ETH,ETH 有望由通脹轉為通縮。但在 Merge 後以太坊主網的 GAS 和 TPS 並沒有很顯著的變化。由於出塊時間固定為 12s,相比於 POW 階段 12-30s 的浮動出塊時間而言,單位時間內可以容納的交易增多,TPS 增加。TPS 的增加也使得以太坊主網沒有那麼擁堵,使得 Basegas Fee 略有下降,每筆交易更加便宜。總體而言 Merge 對於 ETH 流通量的影響遠遠大於其對 GAS 和 TPS 的影響。TPS 和 GAS 的革命性調整還得等到 Danksharding 的落地。

3.5 Proto-Danksharding

Proto-Danksharding 也被稱為 EIP-4844 提案,主要內容是向以太坊區塊中引入 Blob 交易格式。EIP-4844 提案是為以太坊徹底實現 Danksharding 做出的準備,其並未將以太坊做到分片,驗證者節點仍然需要下載並且驗證所有的數據。

目前階段以太坊的區塊大小是由 Gas 容量確定的,在 EIP-4844 實施後 Blob 的數量成為決定區塊大小的另一個維度。Blob 是一種二元數據結構,大小約為 128 KB。以太坊區塊對每個區塊內可以容納的 Blob 做出了限制,目標 Blob 數量為 8,最大為 16。因此每個區塊將額外增加 1-2 MB 的存儲空間。Blob 主要用於存儲 Layer2 數據,在此之前其數據的存儲是通過 Calldata 實現的,而一個區塊內 Calldata 的容量只有約 10 KB 。這意味著在引入 Blob 后區塊內可用於存儲的空間將增加至少 100 倍。但由於單位空間內 Calldata 與 Blob 的信息密度不一樣,雖然 Blob 空間比 Calldata 大 100 倍,但實際可以容納的交易數量可能並不能達到 100 倍。Blob 數據較大,每個區塊將引入至少 1 MB 的 Blob 數據,一個月將多出數 TB 的數據。為解決數據量快速增加的問題,每月產生的 Blob 數據將會離線存儲。

EIP-1559 是針對區塊大小調整的提案,其對區塊內可容納的 Gas 量做出了調整,設置了目標 Gas 以及最大 Gas 量。當區塊內的 Gas 量高於目標 Gas 時,每筆交易的基礎 Gas 費將上調 12.5%,產生的基礎 Gas 費將會被銷毀(基礎 Gas 費被銷毀的原因在於防止礦工惡意發送垃圾交易擁堵 ETH 網絡從而獲取高額手續費)。EIP-4844 也為區塊大小做出了調整,當 Blob 的數量超過 8 時,下一個區塊的基礎 Gas 費將升高,產生的基礎 Gas 費也同樣被銷毀。EIP-1559 與 EIP-4844 的整合將為以太坊區塊大小以及 Gas 費率引入更加動態的調整機制。

TargetMaxBase Gas
Blob816Variable
Gas15m30mVariable

3.6 Danksharding

“中心化出塊、去中心化驗證” 是 V 神對於以太坊未來形態的構想,這種構想通過 PBS、Crlist 以及 DAS 則有機會變成現實。

PBS 全稱 “Proposer-Builder- Separation”,即構建區塊時區塊提議者與區塊構建者的分離。其核心思想在於向系統中引入 Builder 角色(Builder 必須是高性能驗證者),由 Proposer 提議區塊,Builder 競拍交易的排序權併計算區塊頭,Proposer 根據 Builder 的計算結果打包交易並將區塊頭寫入區塊完成出塊。

PBS 的引入主要是為了解決以下四個問題:

  • ETH 2.0 面臨的 MEV 問題:Proposer 既負責打包交易又負責交易的排序,可通過其特殊身份獲取 MEV;
  • 分片與信標鏈的同步問題:Sharding 1.0 的構想中,64 條分片鏈在 12s 的時間內出塊並將驗證後的區塊頭信息、簽名、驗證器的狀態、交聯等數據發送給信標鏈,由信標鏈打包出塊。整個過程較為複雜可能會出現漏塊的情況(交聯即為 Crosslink,每個分片區塊都要與信標鏈區塊產生交聯,方便跨分片通信);
  • 驗證者子集分離的安全性問題:Sharding 1.0 的 64 個分片中的每個分片在一個 Epoch 的時間裡被分成了 32 個 Slot,每個 Slot 都需要一個委員會進行投票驗證。因此原本的驗證者群體被分割成 (64+1) x 32 個驗證者子集,每個驗證者子集需要負責一個 Slot 內區塊的生成與驗證;
  • 中心化引起的是否抗審查的議題;

上文解釋了 Harmony 對於信標鏈與分片鏈出塊的協同性問題的解決方法,其核心想法在於利用 FBFT 快速達成共識以及高性能節點快速打包區塊。這種解決方案的缺點在於不能解決抗審查問題、沒有考慮 MEV、驗證者網絡仍然分離。Danksharding 解決協同性問題的方式也是通過中心化的方式,但卻考慮了以上可能存在的問題。相比於 Sharding 1.0 每 12s 挑選 64+1 個 Proposer 和委員會,分別負責所有分片和信標鏈的出塊以及區塊驗證,Danksharding 每 12s 只挑選 1 個 Proposer、1 個 Builder 和 1 個委員會。信標鍊和所有分片的區塊都由 Proposer 提議,由一個 Builder 構建,由 1 個委員會驗證。由於所有的出塊信息最後都只匯集到 1 個 Proposer 手中,信標鍊和分片鏈的出塊可以做到同步進行。此外原本 64+1 個委員會子集在 Danksharding 後被匯集成一個,驗證者子集過於分散的問題可得到解決。

Proposer 和 Builder 共同承擔所有區塊的構建任務,但是為了保證 Proposer 的去中心化,其不可處理高性能計算的問題。因此高性能計算的任務也就交給了 Builder。Builder 在整個系統中充當的角色是 “無情的計算機”,主要原因在於其不能篩選交易,只能對 Crlist 內的交易進行排序,並進行哈希計算。Proposer 在發布構建區塊的競拍任務時會發布 Crlist,該 Crlist 包含 Proposer 可見的所有的交易,Builder 在交易排序時必須將該 Crlist 的所有交易囊括在內,否則無法參與競拍。由於 Proposer 是隨機且去中心化的,而 Builder 只是排序打包機器,並不能對交易的篩選起任何作用,因此也就維持了交易的抗審查性。

對於 MEV 的問題,通過使用 PBS,ETH 2.0 中的 MEV 流通路徑可以歸結為:交易者向 Builder 尋租- Builder 競拍排序權- 市場化競價下,Builder 可以獲取的額外收益與拍賣成本基本持平,Builder 尋租收益接近於 0 – 收益由驗證者網絡獲取。最後的 MEV 收益由全網驗證者共享而不是流入個人錢包。這種解決方法也很契合 MEV 的本質。畢竟 MEV 是一個公共系統產生的額外收益,這部分公共收益更應該由維持網絡運行的人共享。

數據可用性抽樣(DAS)是解決區塊鏈狀態爆炸的有效方法。狀態爆炸指隨著時間的積累以太坊主網積累的太多的交易數據以及賬戶歷史餘額數據,使得節點的負擔過重,驗證節點的進駐門檻升高,不利於驗證者網絡的拓展。而利用 DAS 技術,驗證節點在同步以及驗證區塊數據時無需下載所有數據,只需要下載區塊的部分冗餘片段即可,需要進行區塊重構時多個節點互相配合。

但 DAS 在數據碎片重構時可能遇到一些問題。大區塊的碎片化重構需要高性能的處理器,這與 DAS 低性能去中心化要求的初衷相違背。因此 DAS 需要一種不需要高性能節點的大區塊重構算法。

Danksharding 的 DAS 採用的方式是 RS 編碼以及 KZG 多項式承諾。大區塊數據利用 RS 先進行一維拓展,再利用 KZG 多項式承諾進行二維拓展。二維拓展多引入了一個維度,因此可以基於該維度對冗餘數據進行分割,分成多個片區。當需要區塊中的某一部分數據時,只需要挑選出該區塊對應的片區,對該片區進行重構即可。也正是因為每個分區都可以做到單獨重構,整個大區塊的重構可以通過不同分區並行重構的模式進行,從而降低了重構數據對於節點的性能要求。

由於 DAS 可以做到對區塊數據的並行化處理,未來即使增加 Sharding 的數量也不會很顯著的增加驗證節點的性能負擔,這部分負擔可以通過增加驗證者的數量來解決,但 Builder 的性能則需要進一步提升。

4.0 公鏈的終局?

Danksahrding 通過 PBS 實現以太坊的中心化出塊,通過 DAS 實現去中心化的驗證,讓以太坊成為可拓展的數據可用性底層,使得以太坊未來可以容納應用鏈 Rollup,智能合約平台 Rollup 等多種 Rollup。EIP-4844 中 Blob 交易格式的引入也將顯著降低 Rollup 的成本。由此看來 Danksharding 實際上在為模塊化區塊鏈的未來下注。目前大多數公鏈的主流選擇仍然是共識與執行層耦合,Danksharding 關於模塊化區塊鏈劍走偏鋒的選擇是否正確則有待時間的考驗。

文中提及項目,均不構成任何投資建議

參考文章:

https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/

https://ethresear.ch/t/phase-one-and-done-eth2-as-a-data-availability-engine/5269

https://blog.ethereum.org/2020/03/27/sharding-consensus/

https://ethereum.org/en/upgrades/

https://ethresear.ch/t/questions-pertaining-to-danksharding-validation-committees/13230

https://ethresear.ch/t/rollup-as-a-service-opportunities-and-challenges/1305

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