newsence
來源篩選

ERC-XXXX: Blob Space Segments (BSS)

Ethereum Magicians

This ERC proposes a minimal interface to define sub-ranges within EIP-4844 blobs, enabling multiple protocols to efficiently share blob space and reduce data availability costs.

newsence

ERC-XXXX：Blob 空間分段 (BSS)

Ethereum Magicians
大約 4 小時前

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)

solidity
interface IERC_BSS {    event BlobSegmentDeclared(        bytes32 indexed versionedHash,        address indexed declarer,        uint16 startFE,        uint16 endFE,        bytes32 indexed contentTag    );    error InvalidSegment(uint16 startFE, uint16 endFE);    error NoBlobAtIndex(uint256 blobIndex);    function declareBlobSegment(        uint256 blobIndex,        uint16 startFE,        uint16 endFE,        bytes32 contentTag    ) external returns (bytes32 versionedHash);}

關鍵設計決策

僅限事件（零存儲）。 無 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 內標頭可能更簡單 —— 但通用標準應使用最易於索引和採用的原語。

可選擴展

  • 可查詢 (IERC_BSS_Queryable)： 透過帶分頁的存儲進行鏈上分段查找（getSegments(versionedHash, offset, limit)）。成本更高；僅適用於需要在鏈上驗證宣告的合約。
  • 批量 (IERC_BSS_Batch)： 在一次調用中宣告多個分段。當 L2 和社交協議原子化地宣告各自的部分時非常有用。

使用案例

L2 + 社交協議

L2 定序器使用 FE [0, 2000) 作為 Rollup 批次數據。剩餘的 [2000, 4096) 未被使用但已付費。社交協議以零邊際 Blob 成本填充剩餘空間。

solidity
bss.declareBlobSegment(0, 0,    2000, keccak256("optimism.bedrock"))     // L2bss.declareBlobSegment(0, 2000, 4096, keccak256("social-blobs.v4"))      // 社交

雙方的索引器透過過濾 contentTag 來發現各自的分段。如果社交協議補償一半的 Blob 費用，則可節省約 50% 的 DA 成本。

多協議平鋪

三個協議共享一個 Blob，零浪費：

  • FE [0, 1500) -> Base Rollup 數據 (46,500 bytes)
  • FE [1500, 3000) -> Social-Blobs 消息 (46,500 bytes)
  • FE [3000, 4096) -> Celestia 命名空間 (33,976 bytes)

126,976 可用字節，3 個協議，1 個 Blob。每個索引器按其 contentTag 過濾。

回溯相容性

使用完整 Blob 的協議只需添加單個宣告即可採用此標準：

solidity
bss.declareBlobSegment(0, 0, 4096, keccak256("myprotocol.v1"));

無需更改 Blob 使用方式 —— 僅在現有交易之上添加一個宣告。

透過批量擴展進行原子平鋪

聚合器合約使用批量擴展來原子化地宣告 L2 + 社交協議的分拆：

solidity
IERC_BSS_Batch.BlobSegmentParams[] memory segments =    new IERC_BSS_Batch.BlobSegmentParams[](2);segments[0] = IERC_BSS_Batch.BlobSegmentParams({    blobIndex: 0, startFE: 0, endFE: 2000,    contentTag: keccak256("optimism.bedrock")});segments[1] = IERC_BSS_Batch.BlobSegmentParams({    blobIndex: 0, startFE: 2000, endFE: 4096,    contentTag: keccak256("social-blobs.v4")});bytes32[] memory hashes = bssBatch.declareBlobSegments(segments);// 兩者同時成功或失敗 —— 無部分平鋪

透過 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 約耗費 20 萬 gas，10 個 FE 約 50 萬 gas。一個完整的 Blob [0, 4096) 將耗費約 2 億 gas（超過區塊 gas 限制），因此這僅適用於小分段。需要根據已證明的 Blob 內容採取行動的智能合約（治理、爭議、DeFi 觸發器）可以使用它。批量讀取仍應通過鏈下索引器進行。

Sepolia 上已存在一個工作實現：KZGVerifier.sol 封裝了預編譯，BLSExposer.sol 使用它來驗證並從 Blob 分段中提取單條消息。

本 ERC 不定義驗證方式。它提供錨點。如何驗證取決於使用該數據的合約。

與現有工作的關係

(Blob 交易元數據)。 互補關係。ERC-7588 描述了 Blob 中有什麼（關於 Blob 交易的元數據）。本 ERC 宣告了誰在使用哪些域元素。一個 Blob 可以同時攜帶兩者 —— 它們解決了不同的協調問題。

(ethresear.ch)。 共享 Blob 註冊表原型使用鏈上分配和基於存儲的狀態來進行 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 上，並通過了包含模糊測試和 gas 基準測試的完整 Forge 測試套件驗證。

局限性與開放性問題

坦誠說明本標準未解決的問題：

  • 無鏈上排他性。 多方可以宣告重疊的分段。這是設計使然（為避免存儲和治理），但協調屬於鏈下範疇。
  • 無費用分攤機制。 宣告了分段，但未說明誰為 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 草案： 待定 (ERC PR 連結)
  • 動機研究：
  • EIP-4844：
  • ERC-7588：
  • Blob 聚合 (Blobsy)：
  • 基於 Based Rollup 的 Blob 共享：

1 則貼文 - 1 位參與者