以太坊創始人vitalik buterin近日針對與proto-danksharding（又名 eip-4844）有關的疑問近了解答。danksharding為以太坊提出的新分片設計，這種技術究竟能帶來什麼？
作者：vitalik buterin
什麼是 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 個欄位元素的向量，範圍內的數字：
0 <= x < 52435875175126190479447740508185965837690552500527637822603658699938581184513
blob 在數學上被視為表示具有上述模數的有限域上的次數 < 4096 多項式，其中 blob 中位置 i 處的場元素是對該多項式在 wi 處的評估。 w 是滿足 w=1 的常數。
對 blob 的承諾是 kzg 承諾對該多項式的一個雜湊。 然而，從實現的角度來看，關注多項式的數學細節並不重要。 相反，只會有一個橢圓曲線點的向量（基於拉格朗日的可信設定），而 kzg 對 blob 的承諾將只是一個線性組合。 引用 eip-4844 的程式碼：
def blob_to_kzg(blob: vector[blsfieldelement, 4096]) -> kzgcommitment: computed_kzg = bls.z1 for value, point_kzg in zip(tx.blob, kzg_setup_lagrange): assert value < bls_modulus computed_kzg = bls.add( computed_kzg, bls.multiply(point_kzg, value) ) return computed_kzg
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，其中 e≈2.71828。 在 x 值較小時，exp(x)≈1+x。 但是，它具有與交易置換無關的便利特性：多步調整
僅取決於總和 u1+...+u/n，而不取決於分佈。 要了解原因，我們可以進行數學運算：
因此，包含的相同交易將導致相同的最終基礎費用，無論它們如何在不同區塊之間分配。
上面的最後一個公式也有一個自然的數學解釋：術語 (u1+u2+...+u/n-nt) 可以看作是多餘的：實際使用的總gas與打算使用的總gas之間的差異。
當前基本費等於
的事實清楚地表明，超出部分不能超出一個非常窄的範圍：如果超過 8t?60，那麼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 的程式碼：
def fake_exponential(numerator: int, denominator: int) -> int: cofactor = 2 ** (numerator // denominator) fractional = numerator % denominator return cofactor + ( fractional * cofactor * 2 + (fractional ** 2 * cofactor) // denominator ) // (denominator * 3)
這裡是用數學重新表達的核心機制，去掉了四捨五入：
目標是將(qx)的許多例項拼接在一起，其中一個為每個 [2^k,2^(k+1)] 範圍適當地移動和放大。 q(x) 本身是 0≤x≤1 的 2^x 的近似值，選擇用於以下屬性：
- 簡單性（這是一個二次方程）
- 左邊緣的正確性 (q(0)=2^0=1)
- 右邊緣的正確性 (q(1)=2^1=2)
- 平滑斜率（我們確保 q’(1)=2?q’(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 本身的範圍，因為對於實現者來說，這種設定“只是一個常數”，但仍然需要完成）。
