對Layer2有關鍵影響的EIP-4844，V神是如何解讀的？

原文標題：《 Proto-Danksharding FAQ 》

原文作者：Vitalik Buterin

原文編譯： Kyle，巴比特

以太坊創始人 Vitalik Buterin 近日針對與 Proto-danksharding（又名 EIP-4844）有關的疑問近了解答。 Danksharding 為以太坊提出的新分片設計，這種技術究竟能帶來什麼？

什麼是 Danksharding？

Danksharding 是為以太坊提出的新分片設計，與先前的設計相比，它引入了一些顯著的簡化。

自2020 年以來的所有最近的以太坊分片提案（包括Danksharding 和之前的Danksharding）與大多數非以太坊分片提案的主要區別在於以太坊以匯總（Rollup）為中心的路線圖：以太坊分片沒有為交易提供更多空間，而是為數據提供，以太坊協議本身不會嘗試解釋。驗證 blob 只需檢查 blob 是否可用，即是否可以從網路下載。這些 blob 中的資料空間預計將由支援高吞吐量事務的第 2 層（Layer2）Rollup 協定使用。

Danksharding 引入的主要創新是合併費用市場：不再有固定數量的分片，每個分片都有不同的區塊和不同的區區塊提議者，在Danksharding 中，只有一個提議者選擇進入該槽的所有交易和所有數據.

為避免這種設計對驗證者提出高系統要求，我們引入了提議者/構建者分離(PBS)：稱為區塊構建者的一類特殊參與者競標選擇slot 的權利，提議者只需要選擇出價最高的有效header 即可。只有區塊建構者需要處理整個區塊（在這裡，也可以使用第三方去中心化預言機協議來實現分散式區塊建構者）；所有其他驗證者和用戶都可以透過資料可用性採樣非常有效地驗證區塊（請記住：區塊的「大」部分只是數據）。

什麼是 proto-danksharding（又稱 EIP-4844）？

Proto-danksharding（又名EIP-4844）是一個以太坊改進提議（EIP），用於實現構成完整Danksharding 規範的大部分邏輯和“腳手架”（例如交易格式、驗證規則），但尚未實際實現任何分片。在 proto-danksharding 實作中，所有驗證者和使用者仍然必須直接驗證完整資料的可用性。

proto-danksharding 引入的主要特徵是新的交易類型，我們稱之為一種帶有 blob 的交易。帶有 blob 的交易與常規交易類似，不同之處在於它還攜帶稱為 blob 的額外資料。 Blob 非常大（~125 kB），並且比類似數量的 calldata 便宜得多。但是，EVM 執行無法存取 blob 資料；EVM 只能查看對 blob 的承諾。

因為驗證者和客戶端仍然需要下載完整的blob 內容，所以proto-danksharding 中的資料頻寬目標是每個插槽1 MB，而不是完整的16 MB。然而，由於這些數據沒有與現有以太坊交易的 gas 使用量競爭，因此仍然有很大的可擴展性好處。

為什麼要為每個人都必須下載的區塊添加 1 MB 資料是可以的，而不是讓 calldata 便宜 10 倍？

這與平均負載和最壞情況負載之間的差異有關。今天，我們已經遇到了平均區塊大小約為 90 kB 的情況，但理論上可能的最大區塊大小（如果區塊中的所有 30M gas 都用於呼叫資料）約為 1.8 MB。以太坊網路過去處理的區塊接近最大值。但是，如果我們簡單地將calldata gas 成本降低10 倍，那麼儘管平均區塊大小會增加到仍然可以接受的水平，但最壞的情況會變成18 MB，這對於以太坊網路來說實在是太坊多了。

目前的gas 定價方案無法將這兩個因素分開：平均負荷與最壞情況負載之間的比率取決於用戶在calldata 與其他資源上花費多少gas 的選擇，這意味著gas 價格必須是根據最壞情況的可能性設置，導致平均負載不必要地低於系統可以處理的負載。但是，如果我們改變 gas 定價以更明確地創建一個多維費用市場，我們可以避免平均情況/最壞情況負載不匹配，並在每個區塊中包含接近我們可以安全處理的最大數據量的數據。 Proto-danksharding 和 EIP-4488 就是兩個這樣做的提議。

proto-danksharding 與 EIP-4488 相比如何？

EIP-4488 是解決相同平均情況/最壞情況負載不匹配問題的較早且更簡單的嘗試。 EIP-4488 使用兩個簡單的規則來做到這一點：

Calldata gas 成本從每位元組16 gas 降低到每位元組3 gas

每個區塊1 MB 的限制加上每個交易額外的300 位元組（理論最大值：~1.4 MB）

硬限制是確保平均情況負載的較大增加不會導致最壞情況負載增加的最簡單方法。天然氣成本的降低將大大增加總和的使用，可能會將平均區塊大小增加到數百 KB，但硬限制將直接阻止包含 10 MB 的單一區塊的最壞情況可能性。事實上，最壞情況下的區塊大小會比現在小（1.4 MB 對 1.8 MB）。

Proto-danksharding 而是創建了一種單獨的事務類型，可以在大型固定大小的blob 中保存更便宜的數據，並限制每個區塊可以包含多少blob。這些 blob 無法從 EVM 存取（只有對 blob 的承諾），且 blob 由共識層（信標鏈）而不是執行層儲存。

EIP-4488 和proto-danksharding 之間的主要實際區別在於EIP-4488 試圖最小化今天所需的更改，而proto-danksharding 今天進行了大量更改，因此將來升級到完全分片需要很少的更改。儘管實現全分片（使用資料可用性採樣等）是一項複雜的任務，並且在 proto-danksharding 之後仍然是一項複雜的任務，但這種複雜性包含在共識層中。一旦 proto-danksharding 推出，執行層客戶端團隊、rollup 開發人員和用戶不需要做進一步的工作來完成向全分片的過渡。

請注意，兩者之間的選擇不是非此即彼的：我們可以盡快實施EIP-4488，然後在半年後使用proto-danksharding 跟進它。

proto-danksharding 實現了完整 danksharding 的哪些部分，還有哪些需要實現？

引用EIP-4844：

此EIP 中已完成的工作包括：·一種新的交易類型，其格式與「全分片」中需要存在的完全相同。 ·全分片所需的所有執行層邏輯。 ·全分片所需的所有執行/共識交叉驗證邏輯。 ·BeaconBlock 驗證和資料可用性採樣 blob 之間的層分離。 ·完全分片所需的大部分 BeaconBlock 邏輯。 ·blob 的自調整獨立 gasprice。實現完全分片尚需完成的工作包括：·共識層中 blob_kzgs 的低度擴展以允許 2D 取樣。 ·資料可用性採樣的實際實現，· PBS（提議者/建構者分離）, 以避免要求單一驗證者在一個插槽中處理 32 MB 的資料。 ·每個驗證者的託管證明或類似的協議內要求，以驗證每個區塊中分片資料的特定部分。

請注意，所有剩餘工作都是共識層更改，不需要執行客戶端團隊、使用者或 Rollup 開發人員的任何額外工作。

所有這些非常大的區塊都會增加磁碟空間需求怎麼辦？

EIP-4488 和 proto-danksharding 都會導致每個插槽（12 秒）的長期最大使用量約為 1 MB。這相當於每年約 2.5 TB，遠高於以太坊今天所需的成長率。

在EIP-4488 的情況下，解決此問題需要歷史記錄到期方案(EIP-4444‌)，其中不再需要客戶端儲存超過某個時間段的歷史記錄（已提出從1 個月到1 年的持續時間）。

在proto-danksharding 的情況下，無論是否實施EIP-4444，共識層都可以實施單獨的邏輯以在一段時間（例如30 天）後自動刪除blob 資料。但是，無論採用何種短期資料擴充解決方案，都強烈建議盡快實施 EIP-4444。

這兩種策略都將共識客戶端的額外磁碟負載限制在最多幾百 GB。從長遠來看，採用一些歷史過期機製本質上是強制性的：完整分片每年會增加大約 40 TB 的歷史 blob 數據，因此用戶實際上只能將其中的一小部分儲存一段時間。因此，值得儘早設定對此的期望。

如果資料在 30 天後被刪除，使用者將如何存取舊 Blob？

以太坊共識協議的目的不是保證所有歷史資料的永久儲存。相反，目的是提供一個高度安全的即時公告板，並為其他去中心化協議留出空間進行更長期的儲存。公告板的存在是為了確保在公告板上發布的數據可用時間足夠長，以便任何想要該數據的用戶或任何備份數據的長期協議都有足夠的時間來獲取數據並將其導入到他們的其他應用程式或協定中。

一般來說，長期歷史儲存很容易。雖然每年 2.5 TB 對常規節點的要求太大，但對於專用用戶來說非常易於管理：您可以以每 TB 約 20 美元的價格購買非常大的硬碟，這完全可以滿足業餘愛好者的需求。與具有 N/2-of-N 信任模型的共識不同，歷史儲存具有 1-of-N 信任模型：您只需要其中一個資料儲存者是誠實的。因此，每條歷史資料只需要儲存數百次，而不是完整的數千個正在做即時共識驗證的節點。

儲存完整歷史記錄並使其易於存取的一些實用方法包括：

特定於應用程式的協定（例如Rollup）可能要求其節點儲存與其應用程式相關的歷史記錄部分。遺失的歷史資料對協定沒有風險，只會對單一應用程式造成風險，因此應用程式承擔儲存與自己相關的資料的負擔是有意義的。

在 BitTorrent 中儲存歷史數據，例如。每天自動產生和分發一個 7 GB 的文件，其中包含來自區塊的 blob 資料。

以太坊入口網站網路（目前正在開發中）可以輕鬆擴展到儲存歷史。

區塊瀏覽器、API 提供者和其他資料服務可能會儲存完整的歷史記錄。

個人愛好者和從事資料分析的學者可能會儲存完整的歷史記錄。在後一種情況下，將歷史儲存在本地為它們提供了重要的價值，因為它使直接對其進行計算變得更加容易。

TheGraph 等第三方索引協定可能會儲存完整的歷史記錄。

在更高層級的歷史儲存（例如每年500 TB）下，一些資料被遺忘的風險會變得更高（此外，資料可用性驗證系統會變得更加緊張）。這可能是分片區塊鏈可擴展性的真正極限。然而，目前所有提出的參數都距離這一點非常遠。

blob 資料的格式是什麼，它是如何提交的？

一個blob 是一個包含4096 個欄位元素的向量，範圍內的數字：

blob 在數學上被視為表示具有上述模數的有限域上的次數< 4096 多項式，其中blob 中位置i 處的場元素是對該多項式在wi 處的評估。 w 是滿足 w=1 的常數。

對 blob 的承諾是 KZG 承諾對該多項式的一個雜湊。然而，從實現的角度來看，關注多項式的數學細節並不重要。相反，只會有一個橢圓曲線點的向量（基於拉格朗日的可信設定），而 KZG 對 blob 的承諾將只是一個線性組合。引用EIP-4844 的程式碼：

BLS_MODULUS 是上述模數，而KZG_SETUP_LAGRANGE 是橢圓曲線點的向量，它是基於拉格朗日的可信設定。對於實現者來說，現在將其簡單地視為一個黑盒專用雜湊函數是合理的。

為什麼使用 KZG 的哈希而不是直接使用 KZG？

EIP-4844 沒有使用KZG 直接表示blob，而是使用版本化雜湊：單一0x01 位元組（表示這個版本）後跟KZG 的SHA256 雜湊的最後31 個位元組。

這樣做是為了EVM 相容性和未來相容性：KZG 承諾是48 位元組，而EVM 更自然地使用32 位元組值，如果我們從KZG 切換到其他東西（例如，出於量子抗性的原因），KZG 承諾可以繼續為32 位元組。

proto-danksharding 中引入的兩個預編譯是什麼？

Proto-danksharding 引進了兩種預編譯：blob 驗證預編譯和點評估預編譯。

Blob 驗證預編譯是不言自明的：它將版本化雜湊和Blob 作為輸入，並驗證提供的版本化雜湊實際上是Blob 的有效版本化哈希。此預編譯設計為 Optimistic Rollup 使用。引用 EIP-4844：

Optimistic Rollup 只需要在提交詐欺證明時實際提供基礎資料。詐欺證明提交功能將要求詐欺 blob 的全部內容作為 calldata 的一部分提交。它將使用 blob 驗證功能根據先前提交的版本化雜湊驗證數據，然後像今天一樣對該數據執行詐欺證明驗證。

點評估預編譯將版本化雜湊、x 座標、y 座標和證明（blob 的 KZG 承諾和 KZG 評估證明）作為輸入。它驗證證明以檢查 P(x) = y，其中 P 是由具有給定版本化哈希的 blob 表示的多項式。此預編譯旨在供 ZK Rollup 使用。引用EIP-4844：

ZK rollup 將為其交易或狀態增量資料提供兩個承諾：blob 中的KZG 和使用ZK rollup 內部使用的任何證明系統的一些承諾。他們將使用等價協議的承諾證明，使用點評估預編譯，來證明 kzg（協議確保指向可用數據）和 ZK rollup 自己的承諾引用相同的數據。

請注意，大多數主要的 Optimistic Rollup 設計都使用多輪防詐騙方案，其中最後一輪只需要少量資料。因此，可以想像，Optimistic Rollup 也可以使用點評估預編譯而不是 blob 驗證預編譯，而且這樣做會更便宜。

KZG 可信任設定是什麼樣的？

看：

https://vitalik.ca/general/2022/03/ 14/trustedsetup.html 

powers-of-tau 可信任設定如何運作的一般描述

https://github.com/ethereum/research/blob/master/trusted_setup/trusted_setup.py 

所有重要的可信任設定相關計算的範例實現

特別是在我們的例子中，目前的計劃是並行運行四個大小（n1=4096,n2=16）,（n1 =8192,n2=16）,（n1=16834,n2=16）和（n1=32768,n2=16）的儀式（有不同的秘密）。理論上，只需要第一個，但是運行更多的更大的尺寸，透過允許我們增加 blob 來提高未來的適用性尺寸。我們不能只是有一個更大的設置，因為我們希望能夠對可以有效提交的多項式次數有一個硬限制，這個限制等於 blob 大小。

可能的實用方法是從 Filecoin 設定開始，然後執行一個儀式來擴展它。包括瀏覽器實作在內的多種實作將允許許多人參與。

我們不能在沒有可信任設定的情況下使用其他一些承諾方案嗎？

不幸的是，使用 KZG 以外的任何東西（例如 IPA 或 SHA256）會使分片路線圖變得更加困難。這有幾個原因：

非算術承諾（例如雜湊函數）與資料可用性取樣不相容，因此如果我們使用這樣的方案，當我們轉向完整分片時，無論如何我們都必須更改為KZG。

IPA 可能與資料可用性取樣相容，但它會導致更複雜的方案具有更弱的屬性（例如，自我修復和分散式區塊建置變更得更困難）

哈希和IPA 都不相容點評估預編譯的廉價實作。因此，基於雜湊或 IPA 的實作將無法有效地使 ZK Rollup 或支援多輪 Optimistic Rollup 中的廉價詐欺證明。

因此，不幸的是，使用 KZG 以外的任何東西的功能損失和複雜性增加遠大於 KZG 本身的風險。此外，任何與 KZG 相關的風險都包含在內：一個 KZG 故障只會影響 Rollup 和其他依賴 blob 資料的應用程序，而不會影響系統的其餘部分。

KZG 有多「複雜」和「新」？

KZG 承諾是在 2010 年的一篇論文‌中介紹的，並且自 2019 年以來已廣泛用於 PLONK 類型的 ZK-SNARK 協議中。然而，KZG 承諾的基礎數學是橢圓曲線運算和配對的基礎數學之上的一個相對簡單的算術。

使用的特定曲線是 BLS12-381‌，它是由 Barreto-Lynn-Scott 在 2002 年發明的。橢圓曲線配對是驗證 KZG 承諾所必需的，是非常複雜的數學，但它們是在 1940 年代發明並自 1990 年代以來應用於密碼學。到 2001 年，提出了許多使用配對的加密演算法。

從實現複雜性的角度來看，KZG 並不比IPA 更難實現：計算承諾的函數（見上文）與IPA 的情況完全相同，只是使用了一組不同的橢圓曲線點常數。點驗證預編譯更複雜，因為它涉及配對評估，但數學與EIP-2537（BLS12-381 預編譯）實作中已經完成的部分相同，並且非常類似於bn128 配對預編譯（另請參閱：優化的Python實現）。因此，實現 KZG 驗證不需要複雜的「新工作」

proto-danksharding 實現的不同軟體部分是什麼？

有四個主要組成部分：

1. 執行層共識發生變更（詳請參閱EIP）：

包含blob 的新交易類型

輸出目前交易中第i個blob 版本化雜湊的操作碼

Blob 驗證預編譯

點評估預編譯

2. 共識層共識變更（請參閱repo 中的此資料夾）：

BeaconBlockBody 中的blob KZG 清單

「sidecar」機制，其中完整的blob 內容與來自BeaconBlock 的單獨物件一起傳遞

執行層中的blob 版本化雜湊與共識層中的blob KZG 之間的交叉檢查

3.記憶體池

BlobTransactionNetworkWrapper（請參閱EIP 的網路部分）

更強大的反DoS 保護以補償大的blob 大小

4. 區塊建構邏輯

接受來自記憶體池的交易封裝器，將交易放入ExecutionPayload，將KZG 放入信標區塊和sidecar 中的主體

應對二次元手續費市場

請注意，對於最小的實現，我們根本不需要記憶體池（我們可以依賴第二層交易捆綁市場），我們只需要一個客戶端來實現區塊建構邏輯。只有執行層和共識層的共識變更需要廣泛的共識測試，相對輕量級。在這樣的最小實現和所有客戶端都支援區塊生產和記憶體池的「完整」部署之間的任何事情都是可能的。

proto-danksharding 多維費用市場是什麼樣的？

Proto-danksharding 引入了一個多維的EIP-1559 費用市場，其中有兩種資源，gas 和blob，具有單獨的浮動gas 價格和單獨的限制。

也就是說，有兩個變數和四個常數：

blob 費用以gas 收取，但它是可變數量的gas，它會進行調整，以便從長遠來看，每個區塊的平均blob 數量實際上等於目標數量。

二維性質意味著區塊建構者將面臨一個更難的問題：與其簡單地接受具有最高優先權費用的交易，直到它們用完交易或達到區塊gas 限制，他們將不得不同時避免達到兩個不同的限制。

這是一個例子。假設 gas 限制為 70，blob 限制為 40。 mempool 有很多交易，足以填滿區塊，有兩種類型（tx gas 包括per-blob gas）：

優先費5 per gas, 4 blobs , 4 total gas

優先費3 per gas, 1 blob, 2 total gas

遵循幼稚的「降低優先費用」演算法的礦工將用第一種類型的10 筆交易（40 gas）填充整個區塊，並獲得5 * 40 = 200 gas 的收入。因為這 10 筆交易填滿了 blob 完全限制，他們將無法包含更多交易。但最優策略是採取第一種類型的 3 筆交易和第二種類型的 28 筆交易。這為您提供了一個包含 40 blob 和 68 gas 的區塊，以及 5 * 12 + 3 * 56 = 228 的收入。

現在執行客戶端是否必須實施複雜的多維背包問題演算法來優化他們的區塊生產？不，有幾個原因：

EIP-1559 確保大多數區塊不會達到任何一個限制，因此實際上只有少數區塊面臨多維優化問題。在記憶體池沒有足夠（足夠的付費）交易達到任一限制的通常情況下，任何礦工都可以透過包含他們看到的每筆交易來獲得最佳收入。

在實務上，相當簡單的啟發式方法可以接近最優。在類似的情況下，請參閱 Ansgar 的 EIP-4488 分析‌以取得有關此的一些資料。

多維定價甚至不是專業化帶來的最大收入來源——MEV 是。透過專用演算法從鏈上DEX 套利、清算、搶先NFT 銷售等中提取的專用MEV 收入佔「可提取收入」（即優先費用）總額的很大一部分：專用MEV 收入似乎平均約為0.025 ETH 每個區區塊，總優先權費用通常在每個區塊0.1 ETH 左右。

提議者/建造者分離‌是圍繞高度專業化的區塊生產而設計的。 PBS 將區塊建立過程轉變為拍賣，專業參與者可以競標創建區塊的特權。常規驗證者只需要接受最高出價。這是為了防止 MEV 驅動的規模經濟蔓延到驗證者中心化，但它處理了所有可能使優化區塊建置變得更加困難的問題。

由於這些原因，更複雜的費用市場動態不會大幅增加中心化或風險；事實上，更廣泛應用的原則‌實際上可以降低DoS攻擊的風險！

指數型 EIP-1559 blob 費用調整機制如何運作？

今天的EIP-1559 調整基礎費用b 以達到特定的目標gas 使用水準t，如下所示：

其中b(n) 是目前區塊的基本費用，b( n+1) 是下一個區塊的基本費用，t 是目標，u 是使用的gas。

這種機制的一個大問題是它實際上並沒有針對 t。假設我們得到兩個區塊，第一個 u=0，下一個 u=2t。我們得到：

儘管平均使用量等於t，但基本費用下降了63/64。所以 basefee 只有在使用率略高於 t 時才會穩定；在實踐中顯然高出約 3%，儘管確切的數字取決於方差。

更好的公式是指數調整：

exp(x) 是指數函數e^x，其中e2.71828。在 x 值較小時，exp(x)1+x。但是，它具有與交易置換無關的便利特性：多步驟調整

只取決於總和u1+...+ u/n，而不取決於分佈。要了解原因，我們可以做數學運算：

因此，包含的相同交易將導致相同的最終基礎費用，無論它們如何在不同區塊之間分配。

上面的最後一個公式也有一個自然的數學解釋：術語(u1+u2+...+u/n-nt) 可以看作是多餘的：實際使用的總gas 與打算使用的總gas 之間的差異。

目前基本費用等於

的事實清楚地表明，超出部分不能超出一個非常窄的範圍：如果超過8t60，那麼basefee 變為e^60，高得離譜，沒有人可以支付它，如果它低於0，則資源基本上是免費的，並且鏈將被垃圾郵件發送，直到超出部分回到零以上。

調整機製完全按照這些術語工作：它追蹤實際總計(u1+u2+...+u/n) 併計算目標總計(nt)，並將價格計算為差異的指數。為了讓計算更簡單，我們不使用 e^x，而是使用 2^x；事實上，我們使用了 2^x 的近似值：EIP 中的 fake_exponential 函數。假指數幾乎總是在實際值的 0.3% 以內。

為了防止長時間的未充分使用導致長時間的2 倍完整區塊，我們增加了一個額外的功能：我們不會讓多餘的區塊低於零。如果 actual_total 低於 targeted_total，我們只需將 actual_total 設為等於 targeted_total。在極端情況下（blob gas 一直下降到零），這確實破壞了交易順序的不變性，但增加的安全性使得這是一個可接受的折衷方案。也要注意這個多維市場的一個有趣的結果：當最初引入proto-danksharding 時，最初可能只有很少的用戶，因此在一段時間內，一個blob 的成本幾乎肯定會非常便宜，即使是「常規的」以太坊區塊鏈活動仍然很昂貴。

作者認為這種費用調整機制比目前的方法更好，因此最終 EIP-1559 費用市場的所有部分都應該轉向使用它。

有關更長更詳細的解釋，請參閱 Dankrad 的帖子‌。

fake_exponential 是如何運作的？

為方便起見，這裡是fake_exponential 的程式碼：

這裡是用數學重新表達的核心機制，去除了四捨五入：

目標是將(QX) 的許多實例拼接在一起，其中一個為每個[2^k,2^( k+1)] 範圍適當地移動和放大。 Q(x) 本身是0x1 的2^x 的近似值，選擇用於以下屬性：

- 簡單性（這是二次方程式）

- 左邊緣的正確性(Q(0)=2^0=1)

- 右邊緣的正確性(Q(1)=2^1=2)

- 平滑斜率（我們確保Q’(1)=2Q’( 0)，因此Q 的每個移位+縮放副本在其右邊緣的斜率與下一個副本在其左邊緣的斜率相同）

最後三個要求給出三個未知係數的三個線性方程，上面給出的Q(x) 給出了唯一的解。

近似值出奇地好；對於除最小輸入之外的所有輸入，fake_exponential 給出的答案在2^x 實際值的0.3% 範圍內：

proto-danksharding 中有哪些問題仍在爭論中？

注意：此部分很容易過時。不要相信它會就任何特定問題給出最新的想法。

所有主要的 Optimistic Rollup 都使用多輪證明，因此它們可以使用（便宜得多的）點評估預編譯而不是 blob 驗證預編譯。任何真正需要blob 驗證的人都可以自己實現它：將blob D 和版本化哈希h 作為輸入，選擇x=hash(D,h)，使用重心評估‌計算y=D(x) 並使用點評估預編譯驗證h(x)=y。因此，我們真的需要 blob 驗證預編譯，還是可以直接刪除它並只使用點評估？

該鏈在處理持久的長期 1 MB+ 區塊方面的能力如何？如果風險太大，是否應該在一開始就減少目標 blob 數？

blob 應該以 gas 還是 ETH（被燒毀）計價？是否應該對費用市場進行其他調整？

應該將新的交易類型視為 blob 還是 SSZ 對象，在後一種情況下將 ExecutionPayload 更改為聯合類型？ （這是「現在做更多工作」與「以後做更多工作」的權衡）

可信任設定實現的確切細節（技術上超出EIP本身的範圍，因為對於實現者來說，這種設定“只是一個常數”，但仍然需要完成）。

原文連結

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia