本文將介紹一種相當簡單且集成良好的以太坊歷史記錄分佈式存儲方法，以及對狀態存儲的擴展。
步驟 1：將塊內容放入 blob 中
我們將以太坊的歷史記錄放入 blob 中。實現這一目標的自然方法是使用一個函數get_blobs(block_body) -> List[Blob] ，該函數序列化The Block主體並將其拆分為 blob。然後，我們要求區塊頭 blob 版本化哈希列表中的第一個 blob 版本化哈希等於[get_versioned_hash(blob) for blob in get_blobs(block.body)] 。
為了方便起見，我們可以將精簡共識（CL）主體的二進制數據塊（blob）與執行有效負載（EL）主體的二進制數據塊（即ExecutionPayload ）分開，這樣，零知識證明執行驗證（ZK-EVM）證明就可以只包含這些版本化的哈希值作為公共見證。這使得區塊的驗證可以完全通過以下步驟完成：（i）下載區塊頭；（ii）對二進制數據塊進行分佈式哈希驗證（DAS）；（iii）僅下載並直接驗證精簡共識部分；（iv）驗證零知識證明執行驗證。當精簡共識的完整功能引入後，精簡共識部分也將獲得零知識證明，屆時我們將擁有一個完整的“區塊頭、分佈式哈希驗證和證明”鏈。
我們可以通過有效載荷分塊和調整一些常量來簡化上述代碼。具體來說，如果我們 (i) 執行EIP-7976並對零字節和非零字節使用相同的 gas 價格，以及 (ii) 在將 blob 升級為抗量子傳輸時（甚至更早）增加 blob 的大小，那麼我們就可以保證每個有效載荷塊都能裝入一個 blob 中（！！）。例如，如果我們把 calldata 的成本設置為每字節 64 gas，那麼根據EIP-7825 ，序列化交易的大小上限為 256 kB，因此如果我們把 blob 的大小設置為 256 kB，就能得到這個保證。
我們還需要對塊級訪問列表執行相同的操作，包括確保每個組件和組合都體現出“每字節 64 gas”的硬性不變性。
步驟 2：隨機 blob 歷史記錄存儲
我們添加一條規則，要求每個客戶端必須存儲其看到的每個數據塊中隨機選擇的一個樣本。如果我們：
- 將樣本大小設置為 512 字節（較當前的 2048 字節有所減少），以最大化 PeerDAS 帶寬。
- 假設每個插槽平均有 64 個 256 kB 大小的 blob（16 MB），這足以使 L2 blob 空間比現狀增加約 20 倍，或使當前 gas 限制增加約 128 倍，或者兩者兼而有之。
然後我們得到：
- 每個客戶端存儲每個 blob 的 1/512，因此需要約 710 個誠實節點（由於重疊，需要超過 512 個）來存儲 >= 50% 的 blob，才能恢復所有 blob。
- 每個客戶端的負載（假設每個槽位處理 128 個數據塊）將為
512 * 62 * 31556926 / 12字節 = 80 GB/年，這與對共識節點施加的合理額外負載大致相當。
可以通過重新利用現有的 DAS 機制來查詢 blob，也可以通過創建更適合同步過程的專用協議來查詢。
步驟 3：添加存儲空間
實際上，這不需要任何額外工作。如果數據塊中包含塊級訪問列表，那麼就可以從已知的最新狀態（如果需要，可以使用合併時的快照）同步數據塊，並重放更新以計算當前狀態。如果需要，我們還可以添加一個“從左到右重複遍歷樹”的機制，但目前尚不清楚這樣做是否值得增加複雜性。
