ERC-8179: Blob Space Segments (BSS)
Ethereum Magicians
This ERC introduces a minimal interface to declare sub-ranges within EIP-4844 blobs, enabling multiple protocols to efficiently share blob space and reduce data availability costs.
ERC-8179: Blob Space Segments (BSS)
AI 生成摘要
此 ERC 定義了一個極簡介面，用於在 EIP-4844 blob 中宣告欄位元素子範圍（分段），讓多個協定能有效共享 blob 空間並降低數據可用性成本。
ERC-XXXX: Blob 空間分段 (BSS)
類別： ERCs | 類型： 標準軌道 | 狀態： 草案
作者： Vitalik Buterin (), Skeletor Spaceman ()
摘要
本 ERC 定義了一個最小化介面，用於在 EIP-4844 Blob 中宣告域元素（field element）子範圍（即「分段」）。透過一個函數 —— declareBlobSegment —— 發出一個事件，將一個 [startFE, endFE) 的半開區間綁定到一個 Blob 的版本化雜湊（versioned hash）。零存儲成本，每次宣告約耗費 3,500 gas。
多個協議可以共享單個 Blob。這為它們提供了一種標準方式來宣告誰在使用哪些域元素，而無需自行發明協調機制。
問題背景
EIP-4844 Blob 大小為 128 KiB（4,096 個域元素）。大多數 Blob 提交者並未將其填滿。一項針對 26 個 Rollup 為期六個月的實證研究 () 發現了雙峰分佈（大型 Rollup 接近滿載，小型 Rollup 低於 5%），透過共享可實現 80-99% 的 DA 成本節省。
值得注意的是：引用的研究反映的是 PeerDAS 之前的 Blob 經濟學（目標為每區塊 3 個 Blob）。PeerDAS 和未來的擴容升級將增加 Blob 吞吐量並降低單個 Blob 的成本。這並未消除協調問題 —— 它使共享變得更便宜，而非變得不必要。隨著 Blob 成本下降，更多協議可以負擔得起 Blob 交易，這使得子 Blob（sub-blob）的協調變得更加相關，而非更不重要。
目前缺乏協議間協調子 Blob 使用的標準。每個想要共享 Blob 空間的專案都在自行發明方案 —— 私有事件、自定義註冊表、專屬索引器。索引器無法跨協議追蹤分段使用情況，工具無法組合，生態系統也失去了標準化帶來的網絡效應。
本 ERC 解決了一個特定問題：宣告誰在使用哪些域元素。它不涵蓋 Blob 構建（如何封裝數據）、費用分攤（誰付費）或分段協商（協議在提交前如何就範圍達成一致）。這些是可以在此原語之上構建的獨立協調層。
設計摘要
介面 (BSS = Blob Space Segments)
關鍵設計決策
僅限事件（零存儲）。 無 SSTORE 操作。一次宣告的成本約為 3,500 gas，而有狀態的替代方案（EIP-2929 後冷啟動 SSTORE 為 22,100 gas）約為 25,600 gas —— 便宜約 7 倍。分段宣告與已經花費 21,000+ gas 的 Blob 交易同時發生，因此保持極低的開銷至關重要。
半開區間 [startFE, endFE)。 標準計算機科學慣例。範圍組合時無縫銜接：[0, 2000) + [2000, 4096) = [0, 4096)。在平鋪排列時不會出現差一錯誤（off-by-one errors）。
BLOBHASH 綁定。 BLOBHASH 操作碼僅對當前交易中的 Blob 返回非零值。分段只能為執行交易中的 Blob 進行宣告（調用鏈中的所有合約共享對 BLOBHASH 的訪問權限）。無需額外的訪問控制邏輯。
bytes32 contentTag。 透過 keccak256("protocol.version") 進行協議識別 —— 無需治理管理的註冊表即可避免衝突。在事件中建立索引，以便根據協議進行高效的日誌過濾。
鏈下重疊檢測。 鏈上允許重疊的宣告。重疊是「自我懲罰」的（兩個協議的數據都會被損壞），而鏈上強制執行則需要存儲空間以及用於爭議解決的治理。索引器可以輕易地檢測並標記重疊。
使用 uint16 作為 FE 索引。 4,096 個 FE 需要 12 位元。uint16 是能容納該數值且能在存儲擴展中實現更緊湊封裝的最小標準 Solidity 整數類型。每個 Blob 的 FE 數量與 KZG 多項式階數掛鉤 —— 未來的擴容是增加每區塊的 Blob 數量，而非單個 Blob 的大小。
鏈上事件而非 Blob 內標頭。 另一種設計是將分段元數據直接嵌入 Blob 中（例如，在前幾個域元素中設置標頭）。我們考慮過這一點，但最終選擇了鏈上事件，原因如下：(1) Blob 對 EVM 是不透明的 —— 如果沒有 KZG 證明，你無法從合約中讀取 Blob 標頭（儘管對於小分段可以進行 KZG 驗證；見下文「透過 KZG 證明進行鏈上驗證」）；(2) 鏈上事件利用了現有的索引器基礎設施 (eth_getLogs)；(3) 協議無需更改其 Blob 編碼即可採用此標準。代價是每次宣告需要額外的合約調用（~3,500 gas）。對於已經緊密協調 Blob 構建的協議，Blob 內標頭可能更簡單 —— 但通用標準應使用最易於索引和採用的原語。
可選擴展
- 可查詢 (Queryable) (
IERC_BSS_Queryable)：透過帶分頁的存儲進行鏈上分段查詢 (getSegments(versionedHash, offset, limit))。成本較高；僅適用於需要在鏈上驗證宣告的合約。 - 批量 (Batch) (
IERC_BSS_Batch)：在一次調用中宣告多個分段。當 L2 和社交協議原子化地宣告各自的部分時非常有用。
使用案例
L2 + 社交協議
一個 L2 定序器使用 FE [0, 2000) 作為 Rollup 批次數據。剩餘的 [2000, 4096) 未被使用但已付費。一個社交協議以零邊際 Blob 成本填充剩餘空間。
雙方的索引器透過過濾 contentTag 來發現各自的分段。如果社交協議補償一半的 Blob 費用，DA 成本可節省約 50%。
多協議平鋪
三個協議共享一個 Blob，零浪費：
- FE [0, 1500) -> Base Rollup 數據 (46,500 字節)
- FE [1500, 3000) -> Social-Blobs 訊息 (46,500 字節)
- FE [3000, 4096) -> Celestia 命名空間 (33,976 字節)
126,976 可用字節，3 個協議，1 個 Blob。每個索引器按其 contentTag 過濾。
向後兼容性
使用完整 Blob 的協議只需添加一個宣告即可採用此標準：
無需更改 Blob 使用方式 —— 只是在現有交易之上添加一個宣告。
透過批量擴展進行原子平鋪
聚合器合約使用批量擴展來原子化地宣告 L2 + 社交協議的分拆：
透過 KZG 證明進行鏈上驗證
分段宣告不僅僅是為了協調 Blob 共享。因為 BlobSegmentDeclared 會發出 (versionedHash, startFE, endFE)，而 EIP-4844 的點評估預編譯 (0x0A) 以版本化雜湊和域元素索引作為輸入，因此任何宣告也可以作為鏈上數據驗證的錨點。
驗證者合約讀取 BlobSegmentDeclared 事件以獲取其感興趣分段的版本化雜湊和 FE 範圍。證明者為該範圍內的相關域元素生成 KZG 證明。驗證者使用 (versionedHash, z, y, commitment, proof) 調用預編譯。如果成功，則該域元素索引處的字節在加密學上被證明與 Blob 中承諾的內容一致。
考慮一個宣告了 [2000, 4096) 的社交協議。一個治理合約想要證明一條 26 字節的訊息在該 Blob 中。它讀取該版本化雜湊的 BlobSegmentDeclared 事件，獲取包含該訊息的單個域元素的 KZG 證明，並調用預編譯。成本：約 50,000 gas。合約現在擁有了這些字節確實在 Blob 中的加密保證，而無需信任任何預言機或索引器。
成本隨規模線性增長：4 個 FE 約耗費 200k gas，10 個 FE 約 500k gas。一個完整的 Blob [0, 4096) 將耗費約 200M gas（超過區塊 gas 限制），因此這僅適用於小分段。需要根據已證明的 Blob 內容採取行動的智能合約（治理、爭議、DeFi 觸發器）可以使用它。批量讀取仍應通過鏈下索引器進行。
Sepolia 上已存在一個工作實現：KZGVerifier.sol 封裝了預編譯，BLSExposer.sol 使用它來驗證並從 Blob 分段中提取單個訊息。
本 ERC 不定義驗證方式。它提供錨點。如何驗證取決於使用該數據的合約。
與現有工作的關係
(Blob 交易元數據)。 互補關係。ERC-7588 描述 Blob 中有什麼（關於 Blob 交易的元數據）。本 ERC 宣告誰在使用哪些域元素。一個 Blob 可以同時攜帶兩者 —— 它們解決不同的協調問題。
(ethresear.ch)。 Shared Blob Registry 原型使用帶有存儲支持狀態的鏈上分配，用於 Rollup 特定的 Blob 聚合。本 ERC 採取了不同的方法：僅限事件的宣告、無鏈上狀態、通用型（非 Rollup 特定）、無分配治理。權衡之處在於重疊解決被委託給了鏈下索引器。
(Nethermind)。 一個使用 EIP-7702 扇出（fan-out）進行共享 Blob 提交的工作演示。本 ERC 可以作為此類方法的分段宣告層 —— 它標準化了「誰擁有什麼」的部分，而不規定 Blob 是如何構建或提交的。
BlobFusion / Ephema。 帶有基於競價定價的 Blob 空間共享服務。本 ERC 對定價保持中立；它提供了市場可以構建其上的宣告原語。
(Poster)。 哲學上相似 —— 以太坊上的極簡社交媒體。Poster 使用 calldata 且不感知 Blob。本 ERC 解決了 Poster 不需要解決的 Blob 特定協調問題，但這些協議共享「極簡足跡、事件驅動」的設計理念。
。 激發這項工作的實證分析。26 個 Rollup，六個月，透過 Blob 共享可節省 80-99% 的 DA 成本。
參考實現
提供了一個獨立的參考實現（約 20 行 Solidity 代碼）。完整的源代碼（合約、介面、測試）包含在 ERC PR 的 assets/ 目錄下。關鍵文件：
BlobSpaceSegments.sol— 參考合約IERC_BSS.sol— 核心介面IERC_BSS_Queryable.sol— 可選的可查詢擴展（帶分頁）IERC_BSS_Batch.sol— 可選的批量擴展
參考實現已部署在 Sepolia 上，並通過了完整的 Forge 測試套件驗證，包括模糊測試和 gas 基準測試。
局限性與開放性問題
坦誠說明本提案未解決的問題：
- 無鏈上排他性。 多方可以宣告重疊的分段。這是設計使然（為了避免存儲和治理成本），但協調是一個鏈下問題。
- 無費用分攤機制。 宣告了分段，但未說明誰為 Blob 付費。
- 無 Blob 構建標準。 協議實際上如何將數據封裝到共享 Blob 中（排序、填充、編碼）不在討論範圍內。這僅宣告結果。
- 依賴 BLOBHASH。 僅在支持 EIP-4844 的鏈上有效。不能在 L2 或沒有
BLOBHASH操作碼的鏈上使用。 - 重組敏感性。 分段宣告與包含它的 Blob 交易具有相同的最終性。索引器需要處理區塊重組。
- 過度宣告。 協議可以宣告比其實際填充範圍更大的區塊。EVM 無法檢查 Blob 內容，因此宣告是「聲明」而非「證明」。索引器應據此處理。
- Blob 修剪。 Blob 數據在大約 18 天後會被修剪。分段宣告作為鏈上事件會持久存在，但它們引用的底層數據可能無法從共識層節點獲取。
- ContentTag 的宣告者真實性。 任何人都可以為任何標籤發出宣告。消費者應維護每個
(chainId, contentTag)的規範宣告者允許列表。
徵求反饋
尋求社區對以下方面的意見：
- 僅限事件 vs 存儲。 我們認為 7 倍的 gas 節省證明了僅限事件的合理性，但構建 Blob 空間市場或需要鏈上查詢的分配系統的團隊可能會持不同意見。
- 內容標籤慣例。
keccak256("protocol.version")是正確的方法嗎？輕量級註冊表可以防止意外衝突，但會增加治理開銷。 - 重疊處理。 當前設計將重疊視為自我懲罰，並將檢測留給索引器。是否有任何使用案例能從鏈上重疊預防中受益？
- 擴展設計。 Queryable 和 Batch 擴展是正確的可選插件嗎？社區是否還需要其他擴展點？
- 協商層。 本 ERC 在事後宣告分段，但無助於協議在提交前就範圍達成一致。是否需要單獨的協商標準？或者您期望聚合器在鏈下處理提交前的協調？
- PeerDAS 經濟學。 隨著 PeerDAS 增加 Blob 吞吐量並降低成本，子 Blob 共享是否仍具價值？我們的假設是更便宜的 Blob 會吸引更多協議，使協調變得更相關 —— 但我們希望聽取針對 PeerDAS 後經濟學進行規劃的團隊的意見。
- 集成經驗。 如果您的協議提交 Blob 且有未使用空間，我們想了解您的協調挑戰，以及此介面是否解決了這些問題。
- 鏈上驗證使用案例。 協議是否需要智能合約根據已證明的 Blob 內容採取行動（例如治理、爭議、DeFi 觸發器），還是鏈下索引對大多數案例來說已經足夠？我們想了解對宣告分段進行基於 KZG 的鏈上驗證的需求。
相關連結
- 完整 ERC 草案：
- 研究動機：
- EIP-4844：
- ERC-7588：
- Blob 聚合 (Blobsy)：
- 基於 Based Rollup 的 Blob 共享：