擴容背景：#
- 單個區塊的 Gas 有上限。以太坊是按照 Gas 費來規定一個區塊的數據量上限的，一個區塊最高可以承載 3000 萬 GAS 的數據量
- 大區塊是有代價的。以太坊不希望每個區塊的數據量都太大，所以每個區塊都有一個 Gas Target（目標 Gas）為 1500 萬 Gas 的數據量
- Gas 自動化調節機制。一個區塊的 Gas 消耗一旦超過了 Gas Target （也就是 1500 萬 Gas），那麼下一個區塊的基礎費用就會貴 12.5%，如果低於的話就會降低基礎費用。這樣可以在交易高峰時一直增加成本去緩解擁堵，同時在交易低迷時降低成本來吸引更多交易。
擴容方案（Layer2+Sharding）：#
Layer2：
- Optimism Rollup：假設所有交易都是誠實可信的，把許多筆交易壓縮成一筆交易提交給以太坊，在提交後會有一段時間窗口（挑戰期 - 目前是一周），任何人都可以質疑發起挑戰來驗證交易的真實性，但用戶如果要將 OP Rollup 上的 ETH 轉到以太坊上則需要等待挑戰期結束後才可以得到最終確認。
- ZK Rollup：只需要上傳一個零知識證明和最終的狀態變化的數據即可，意味著在可擴展性上可以比 OP Rollup 壓縮更多的數據，並且也不需要像 OP Rollup 那樣等待長達一周的挑戰期。但技術上開發難度較大。
分片（Sharding）：
在講解 Sharding 之前，我們先來回顧下 ETH 的出塊過程。
合併後的以太坊從 PoW 轉為 PoS ，12 秒出一個塊（Slot），6.4 分鐘出 32 個區塊為一個周期（Epoch）。當礦工質押 32 個 ETH 成為驗證節點後，信標鏈就會通過隨機算法來選擇驗證節點作為出塊節點來打包區塊，每一個區塊都會隨機選擇一次出塊節點。同時在每一個周期 Epoch 中，每個區塊（Slot）會被分配所有節點數量的 32 分之 1 數量的驗證節點組成的 “委員會（Committees）” 委員會需要對每個區塊出塊節點打包的區塊進行驗證投票。當出塊節點打包區塊後，超過三分之二以上的驗證節點投票通過即可成功出塊。
- Sharding 1.0（已廢棄，可以跳過直接閱讀）
Sharding 1.0，是對 Danksharding 出現之前的以太坊分片設計方案的統稱，對此做些大概了解是有必要的。在初始的分片方案 Sharding1.0 的設計理念中，本質上是想實現「狀態分片」。以太坊從原本的一條主鏈被設計為了最多 64 條分片鏈，通過增加多條新鏈的方式來實現擴容。在這個方案中，每條分片鏈負責處理以太坊的數據並交給信標鏈，信標鏈則負責整個以太坊的協調，每一條分片鏈的出塊節點和委員會都是由信標鏈來隨機分配，但存在的核心問題就是數據同步和不斷增長的 MEV 。
Danksharding（今天的主角）#
Danksharding 使用了一套新的分片思路去解決以太坊的擴容問題，即圍繞著 Layer2 的 Rollup 進行擴容的分片方案，這套新的分片方案可以在不大量增加節點負擔且保證去中心化和安全性的同時解決可擴展性問題，同時也解決了 MEV 帶來的負面影響。
EIP-4844：#
EIP-4844 給以太坊引入了一種新的交易類型 —Blob Transcation，這種新的交易類型 Blob 可以為以太坊提供了一個額外的外挂數據庫（md，本質還真是大區塊）：
- 一個 Blob 的大小約為 128 KB（平均一個區塊是 60~70kb 左右的數據大小）
- 一個交易可以最多攜帶兩個 Blob（256KB）
- 每一個區塊的 Target Blob 為 8 個（1MB），最大可承載 16 個 Blob（2MB）
- Blob 不需要像 callData 一樣作為 history log 被永久存儲（目前社區建議為 30 天）
Blob 給以太坊帶來的額外存儲空間是巨大的，要知道以太坊所有賬本的總數據量大小從以太坊誕生至今也只有大約 1TB 左右，而 Blob 每年可以為以太坊帶來 2.5TB~5TB 的額外數據量，是整個以太坊賬本數據量的好幾倍。
EIP-4844 引入的 Blob 交易可以說是為 Rollup 量身定制的，Rollup 的數據以 Blob 的形式上傳至以太坊，額外的數據空間可以使 Rollup 實現更高的 TPS 和更低的成本，同時也將原本 Rollup 占據的區塊空間釋放給了更多用戶。
Danksharding 擴容方案#
完整的 Danksharding 方案將 Blob 可以承載的數據量從每個區塊 1~2MB 進一步擴充至 16MB~32MB，並且提出了新的機制出塊者 - 打包者分離（PBS）去解決 MEV 帶來的問題。
Danksharding 提出了一个方案 —— 數據可用性採樣（Data Availability Sampling）來實現降低節點負擔的同時也保證了數據可用性。
- 數據可用性採樣（DAS）降低節點存儲負擔避免節點過於中心化（糾刪碼技術和 KZG 多項式承諾）
數據可用性採樣（DAS）的思想是將 Blob 中的數據切割成數據碎片，並且讓節點由下載 Blob 數據轉變為隨機抽查 Blob 數據碎片，讓 Blob 的數據碎片分散在以太坊的每個節點中，但是完整的 Blob 數據卻保存在整個以太坊賬本中，前提是節點需要足夠多且去中心化。
舉個例子：比如 Blob 的數據被切割成了 10 個碎片，全網有 100 個節點，每個節點都會隨機抽查下載一個數據碎片並且將抽查的碎片編號提交到區塊中，只要一個區塊中可以湊齊所有編號的碎片，那麼以太坊就會默認這個 Blob 的數據是可用的，只要將碎片拼湊起來就可以還原出原始數據。但也會有極低的概率出現 100 個節點都沒有抽到某一個編號的碎片的情況，這樣數據就會缺失，在一定程度上降低了安全性，但在概率上是可以接受的。
但這就存在一個問題，是誰來負責對原始數據編碼？
- 出塊者 - 打包者分離（PBS）解決打包數據和分發數據的分工問題
如果要對 Blob 原始數據進行編碼的話前提是進行編碼的節點手裡必須有完整的原始數據，要做到這一點的話就會對節點有較高的要求。那么菠菜之前提到，Danksharding 提出了一个新的機制 ** 出塊者 - 打包者分離（PBS）** 去解決 MEV 帶來的問題，那麼其實這個方案在解決 MEV 問題的同時，其實也解決了編碼的問題。
1、性能配置高的節點可以成為打包者（Builder），打包者只需要負責下載 Blob 數據進行編碼並創建區塊（Block），然後廣播給其他的節點來進行抽查，對於打包者（Builder）來說，因為同步數據量和帶寬要求較高，所以會相對中心化。
2、性能配置較低的節點可以成為提議者（Proposer），提議者只需要驗證數據的有效性並創建和廣播區塊頭（Block Header），但對於提議者（Proposer）來說，同步數據量和帶寬要求較低，所以會去中心化。
- 抗審查清單（crList）限制解決出塊者 MEV 的能力
但對於打包者（Builder）來說其實是擁有了更大的審查交易的能力，打包者可以故意忽略掉某些交易並且隨意排序並插入自己想插入的交易去獲取 MEV，但抗審查清單（crList）解決了這些問題。
抗審查清單（crList）的機制如下：
1、在打包者（Builder）打包區塊交易之前，提議者（Proposer）會先公布一個抗審查清單（crList），這個 crList 中包含著 mempool 中的所有交易
2、打包者（Builder）只能選擇打包並對 crList 裡的交易進行排序，這意味著打包者不能插入自己的私有交易去獲取 MEV，也不能去故意拒絕某個交易（除非 Gas limit 滿了）
3、打包者（Builder）打包好之後將最終版本的交易列表 Hash 廣播給提議者（Proposer），提議者選擇其中一個交易列表生成區塊頭（Block Header）並廣播
4、節點同步數據時會從提議者（Proposer）那獲取區塊頭，然後從打包者（Builder）那獲取區塊 Body，確保區塊 Body 是最終選擇的版本
寫在最後#
Danksharding 為以太坊解決 “區塊鏈不可能三角” 提供了一種變革性的解決方案，即在確保以太坊去中心化和安全性的同時實現可擴展性：
- 通過前置方案 EIP-4844：Proto-Danksharding 引入了新的交易類型 Blob，Blob 攜帶的 1MB~2MB 額外數據量可以幫助以太坊在 Rollup 上實現更高的 TPS 和更低的成本
- 通過糾刪碼和 KZG 多項式承諾實現了數據可用性採樣（DAS），讓節點只需要抽查部分數據碎片即可驗證數據的可用性並降低了節點的負擔
- 通過實現了數據可用性採樣（DAS），Blob 的額外數據量擴充至 16MB~32MB，讓擴容效果更上一層樓
- 通過提議者 - 打包者分離（PBS）將驗證 - 打包區塊的工作分離為兩個節點角色，實現了打包節點偏去中心化、驗證節點去中心化
- 通過抗審查清單（crList）和雙槽 PBS 極大降低了 MEV 帶來的負面影響問題，打包者無法插入私有交易或審查某一筆交易
如果不出意外的話 Danksharding 的前置方案 EIP-4844 將會在以太坊上海升級之後的坎昆升級中正式落地，在 EIP-4844 方案落地實現後最直接的利好便是 Layer2 中的 Rollup 以及 Rollup 上的生態。更高的 TPS 和更低的成本十分適合鏈上的高頻應用，我們不妨想象可能會誕生出一些 “殺手級應用”。