熱度飆升的EIP-4844究竟是什么 ？V神親自詳細解答_GAS:SHA

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

作者：Vitalik Buterin

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

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

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

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

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 使用量競爭，因此仍然有很大的可擴展性好處。

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

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

Baby Doge 位居幣安新聞熱度排名榜首:據官方消息，根據幣安新聞熱度排名，Baby Doge 連續2周排名第一。此外，Baby Doge將于2月1日將迎來新的一輪代幣燃燒。[2022/1/18 8:56:38]

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 跟進它。

引用 EIP-4844：

此 EIP 中已經完成的工作包括：

一種新的交易類型，其格式與“全分片”中需要存在的完全相同。

全分片所需的所有執行層邏輯。

全分片所需的所有執行/共識交叉驗證邏輯。

BeaconBlock 驗證和數據可用性采樣 blob 之間的層分離。

完全分片所需的大部分 BeaconBlock 邏輯。

blob 的自調整獨立 gasprice。

實現完全分片尚需完成的工作包括：

共識層中 blob_kzgs 的低度擴展以允許 2D 采樣。

數據可用性采樣的實際實現，

 PBS（提議者/構建者分離）,以避免要求單個驗證者在一個插槽中處理 32 MB 的數據。

每個驗證者的托管證明或類似的協議內要求，以驗證每個區塊中分片數據的特定部分。

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

ETH谷歌趨勢熱度已上升至100 近10天漲幅超60%:據谷歌趨勢數據顯示，7月19日后ETH熱度從60開始上升，現已增加到100，近10天漲幅超60%。[2020/8/1]

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 數據，因此用戶實際上只能將其中的一小部分存儲一段時間。 因此，值得盡早設定對此的期望。

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

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

存儲完整歷史記錄并使其易于訪問的一些實用方法包括：

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

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

以太坊門戶網絡（目前正在開發中）可以很容易地擴展到存儲歷史。

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

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

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

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

一個 blob 是一個包含 4096 個字段元素的向量，范圍內的數字：

0 <= x < 52435875175126190479447740508185965837690552500527637822603658699938581184513

行情 | BNB在幣熱度榜上排名上升至第二:據TokenClub數據顯示，目前BTC在幣熱度榜上排名第一，24小時內訪問量為23650；BNB排名第二，24小時內訪問量為15676；ETH排名第三，24小時內訪問量為15083；EOS排名第四，24小時內訪問量為13202；TCT排名第五，24小時內訪問量為12718。[2019/3/5]

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

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

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

EIP-4844 沒有使用 KZG 直接表示 blob，而是使用版本化哈希：單個 0x01 字節（表示這個版本）后跟 KZG 的 SHA256 哈希的最后 31 個字節。

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

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

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

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

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

看：

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 大小。

動態 | 區塊鏈百度搜索熱度整體同比上漲182% 比特幣反而下跌:今日百度搜索熱度中，“區塊鏈”的搜索熱度近7日整體日均值為8316，整體同比上漲182%，環比上漲22%。“比特幣”的搜索熱度近7日整體日均值為16322，整體同比下跌15%，環比上漲5%。整體而言，“比特幣”熱度高于“區塊鏈”，而“區塊鏈”熱度增勢遠大于“比特幣”。[2018/11/16]

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

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

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

IPA 可能與數據可用性采樣兼容，但它會導致更復雜的方案具有更弱的屬性（例如，自我修復和分布式區塊構建變得更加困難）

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

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

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 驗證不需要復雜的“新工作”

有四個主要組成部分：

1. 執行層共識發生更改（詳見 EIP）：

包含 blob 的新交易類型

輸出當前交易中第 i 個 blob 版本化哈希的操作碼

2.共識層共識更改（請參閱 repo 中的此文件夾）：

BeaconBlockBody 中的 blob KZG 列表

“sidecar”機制，其中完整的 blob 內容與來自 BeaconBlock 的單獨對象一起傳遞

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

3.內存池

BlobTransactionNetworkWrapper（參見 EIP 的網絡部分）

獨家 | 龐氏游戲熱度不減 山寨合約抬頭:區塊鏈大數據評級機構RatingToken最新數據顯示，2018年7月20日全球共新增9552個合約地址，其中317個為代幣型智能合約，另外值得關注的是同一個賬戶創建了7900個完全相同的智能合約，共消耗Gas費22 ETH。根據RatingToken團隊發布的“新增代幣型智能合約風險榜”，風險榜單第一名的FOMO Short是近日大火的龐氏游戲FOMO 3D的山寨合約，且均存在18個安全漏洞，風險等級極高。

除此之外，登上該風險榜TOP10的還包括Ai Coin、Coin Pay、Gov2.0、ADventure Capital、Coin Crunch India、Specialist Coin、GSCW、和programer。如需查看更多智能合約檢測結果，請訪問RatingToken官網。[2018/7/21]

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

4.區塊構建邏輯

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

應對二次元手續費市場

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

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 調整基礎費用 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 的代碼：

這里是用數學重新表達的核心機制，去掉了四舍五入：

目標是將(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% 范圍內：

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

所有主要的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 本身的范圍，因為對于實現者來說，這種設置“只是一個常數”，但仍然需要完成）。

Tags：BLOGASINGSHAVR Blocks0XGAS價格DINGO價格ShareAt

Gate交易所