Danksharding

Sharding 是以太坊技術藍圖中的最後一塊拼圖，而 Danksharding 是最新一個 Sharding 的設計提案，比之前的設計都來的更簡潔。更多關於 Danksharding 的介紹可以參考：

Rollup 的主要成本之一為上傳資料的成本，而在 Sharding 推出後，Rollup 勢必得改用 Sharding 的交易資料格式（也稱作 Blob）來上傳資料，因為會比目前用 calldata 的方式便宜很多。

而這也代表未來 Rollup 仍免不了要做一次系統更新：將資料上傳方式從 calldata 改成 Blob。那我們短期可以做的就是：(1) 降低 calldata 成本，也就是上一篇提到的 EIP-4488，及 (2) 讓 Rollup 提早切換至新資料格式（Blob），這樣未來就不必再做一次系統更新，而這就是 EIP-4844 Proto-Danksharding 在做的。

所以其實可以把 Proto-Danksharding 理解成一個提前為 Sharding 做準備，又能同時在中短期內大幅降低 Rollup 成本，一石二鳥的解方。

Eth 2.0 CL/EL 的調整

在實作 Sharding 的過程中，以太坊包含 Consensus Layer (CL)及 Execution Layer (EL) 的客戶端都會需要進行升級。而身為在為 Sharding 提前做準備的 Proto-Danksharding 除了引進新的 Shard Blob Transaction 格式外，還順便更新了 CL 及 EL 的架構及實作。

在 EL 這一端，包含 Blob 的 Fee Market（Blob 有獨立的手續費市場，後面會介紹）、新的 Opcode 及 Precompile 合約、P2P 網路的新資料格式及 EL/CL之間的溝通驗證機制等等，基本上 Sharding 會需要的 EL 改動都已涵蓋在這個 EIP 當中。

在 CL 這一端，包含保存及傳遞 Blob 的資料（Blob 資料只在 CL 間傳遞，不經過 EL）、引進資料可用性的接口等等，大部分 Sharding 會需要的 CL 改動都已涵蓋在這個 EIP 當中。

Blob Sidecar 及相容 DAS 的接口

Blob 資料是在 Consensus Layer 間傳遞，但它不是被編碼成區塊的其中一部分，而是另外以稱為「Sidecar」的形式傳送，也就是區塊資料和 Blob 資料會是走兩個不同的資料通道。

為什麼要這樣做？為什麼不把 Blob 資料編碼成區塊的一部分一起傳送就好？這是為了能向前兼容 Sharding 的設計所做的調整。未來 Sharding 中 Blob 資料會比現在還大上很多倍，也因此節點將不會下載完整的 Blob 資料（所以不該編碼成區塊的一部分，否則會需要下載完整資料），而是透過 Data Availability Sampling 的方式一起來確保資料是可用的，並且節點會加入檢查資料可用性的接口（is_data_available），用來確認資料是否可用。

這個 EIP 引進了 Sidecar 這個設計，提早讓節點適應新的模式並能做一些效能的監測。目前節點都還是會下載完整的 Blob 資料，所以接口會依是否有完整 Blob 資料來回傳 True/False，未來在 DAS 中則是會透過 Sampling 及在 P2P 網路溝通的結果來回傳 True/False。

剩下的 Sharding 會需要但還沒實作的部分包含（幾乎都是最上面的 Danksharding 介紹文章提到的技術）：

• 2 Dimension KZG commitments
• Data Availability Sampling (DAS) 的實作
• Proposer-Builder Separation (PBS)
• Proof of Custody 機制

多維度手續費市場

Blob 資料量很大但又不會被合約存取，而且具有有效儲存期限，要給它訂個公平合理的 Gas 值也不容易。例如如果訂一個固定 Gas 值，那有可能會被攻擊者利用來放一堆無意義資料，造成節點磁碟空間的負擔。因此這個 EIP 引進一個新的資源計算維度，讓原本的 EIP-1559 變成一個多維度的 EIP-1559。

在這個多維度的 1559 中，原本的 Max Gas Per Block 及 Target Gas Per Block 還是存在，只是又多了一組新的 Max 及 Target，也就是給 Blob 資料的 Max 及 Target。目前設計中，Target 為每個區塊 8 個 Blob，Max 為 16 個。

Blob 維度中變動的是 Gas 大小

當前 1559 中隨著機制變動的是 BASE_FEE，而在 Blob 維度中隨著機制變動的則是 Blob 的 Gas 大小。如果 Blob 數量超過 Target Blob 數量，則 Blob 的 gas 大小會以指數成長！

註：Blob 的收費單位還是 Gas，並沒有新增一個計價單位，而且也是併入原本的 Gas 消耗一起計算。

不一樣的數據參考來源

當前 1559 機制裡所參考的是「上一個區塊的 Gas 消耗量」，而 Blob 的維度中，數據參考來源是「歷史總 Blob 數」，差別主要也就是考量的是短時間週期的影響還是長時間週期的影響。

Blob Gas 計算方式

如果歷史總 Blob 數（以 total_blobs 代稱）小於預期 Blob 數（預期 Blob 數為預期均值乘上區塊總數，以 target_blobs 代稱），則 Blob 的 Gas 為 0（基本上就是不收費），否則 Gas 為 2**((total_blobs — target_blobs) / 64)，即當 total_blobs 增長太快超過 target_blobs 時，Blob 的 Gas 大小將指數增長直到其降回低於 target_blobs。

註：64 為 GASPRICE_UPDATE_FRACTION_PER_BLOB 這個系統參數當前設定的值，有可能會改變。

每個區塊結束系統都會去更新 total_blobs 值，且更新的 total_blobs值不能低於 target_blobs值（即 new_total_blobs = max(old_total_blobs, target_blobs），以避免過去一段時間都沒 Blob 導致接下來的一段時間裡 Blob Gas 都為零。

詳細的算法可以參考這裡。

Block Builder 該如何挑選交易？

兩種交易，兩種不同限制

Block Builder 是否會需要跑複雜的演算法來計算最優的一般交易及 Blob 交易的組合？原本單維度的手續費市場 Block Builder 只需要按照手續費高低來收入交易，但在多維度手續費市場裡 Block Builder 要面對兩種變數、兩種限制來找出手續費最高的組合，也就是背包問題（Knapsack Problem）。

Vitalik 目前推測是不用的，有幾個原因：

• EIP-1559 的設計確保在大部分的時候是不會碰到上限的，因此大部分的時間 Block Builder 都可以直接選擇收入他們能接受的所有交易（但不代表每筆交易都會收入，Block Builder 還是會考量收入一筆交易是否划算）
• 這份分析也顯示，盡可能收入交易的策略與使用最佳解算法（背包問題算法）的策略，在收益上差距並不大（收益為純手續費收入，不包含 MEV）
• MEV 會是最大的收入來源，而不是單純交易本身手續費的收入。而 MEV 都會是由更專業的角色去計算，他們本身就具備足夠的知識和經驗去算出最優組合。另外 Proposer-Builder Separation 也能透過分工來避免 Block Proposer 因為這些 MEV 收入與競爭導致變得中心化 — Proposer 賺的是 Block Builder 的競標費用而不是 MEV。

兼容問題與挑戰

Web3 API 存取不到 Blob

Blob 會在 CL 之間的 P2P 網路傳遞，也就是 EL 節點基本上不會存取到 Blob，也因此是沒辦法透過 web3 API 來拿到 Blob 資料的。

Mempool 的 DoS 風險

因為 Blob 的 Gas 消耗會變動，導致一個 Blob 交易可能在某個時間點還是可以收入的，但後面就因為 Gas 消耗超過指定的 Gas Limit 而被判定為無法被收入而丟棄。為了避免有人利用這個機制來攻擊 Mempool，EIP 裡建議只廣播交易裡指定的 Gas Limit 至少是當前 Blob Gas 最小值兩倍的交易。

註：攻擊方式為送很多筆 Gas Price 很低，且 Gas Limit 設得很接近當前 Blob Gas 值的 Blob 交易，這些交易會被視為合法因此散播到網路中其他節點，佔據 Mempool，但沒多久就因為 Blob Gas 值上升導致這些交易被丟棄。

另外因為 Blob 本身資料量很大，所以攻擊者可以送具有相同 Nonce 值的多筆 Blob 交易，並且每一筆新的都比前一筆的手續費多上 10%，因此其他節點會一直接收每一筆新的交易，也就表示每一筆 Blob 交易都會被廣播到網路中每個角落，因此對網路造成負擔。不過其實當前用一筆普通交易並塞滿大量無意義的 calldata 就能做到一樣的攻擊效果。EIP 建議如果這個情況變嚴重的話，可以考慮把 Replacement 交易的手續費門檻由 10% 調升至 100%，也就是新的同 Nonce 值交易的手續費要高過舊的一倍，節點才會接受並廣播出去。

資料大小對磁碟大小需求的影響

EIP-4488 及 Proto-Danksharding 都會造成一個效果是：長期下來平均每一個 slot（即每 12 秒）會有 1MB 大小的傳輸需求，一年下來就是 2.5 TB 的大小，遠比目前 Ethereum 每年新增的資料大小還大上許多。

如果 EIP-4488 被採用了，那 EIP-4444：清除節點歷史數據的手段就必須被納入，來避免硬碟空間需求暴增。

如果 Proto-Danksharding 被採用了，CL 節點可以透過定期清除舊的 Blob 資料方式來避免硬碟需求暴增（不管 EIP-4444 有沒有被納入）。

這兩種方式都能將硬碟需求降至一年數百 GB。不過 Sharding 遲早會來，屆時資料大小將會再大上許多，像是 EIP-4444 這樣的手段還是無可避免。

目前這個 EIP 還在持續討論及實作中

這個 EIP 還有許多要測試和討論的部分，包含測試網、多維度手續費市場、KZG 套件庫、P2P 網路傳送 Blob 資料的測試及優化等等。

這一份文檔裡有這個 EIP 的定期會議的議程及討論內容。