以太坊 Blob 與 Calldata：費用和資料保留的區別

Blob是獨立資料通道

Blob承載交易為Rollup提供與普通Calldata不同的資料通道，並通過承諾將資料與交易聯繫。它不是把所有內容變成普通合約存儲，讀取方式和費用機制也不同。

承諾用於檢驗取得的資料是否對應交易，但有承諾不等於任何時候都能找到正文。可用性、完整性和長期保存是三個不同問題，說明時應分別列負責方和時間範圍，避免將密碼學保證擴展成存儲服務承諾。

執行層不能隨意讀取全文

EVM可取得Blob版本化哈希，卻不能把Blob全文像普通Calldata一樣直接讀取。應用設計需要考慮資料在哪裡提供、由誰取得和驗證，不應只看到低費用就認為接口相同。

應用若只讀取版本哈希，需要另有流程取得Blob並解釋編碼。普通合約調用無法任意加載正文，開發文檔中的接口邊界應保留。對非技術讀者可以用收據編號與包裹內容的差異解釋，而不暗示編號能重建丟失內容。

保留期限不是永久歸檔

協議要求的資料可用時間具有期限，不能當作無限歷史存儲承諾。需要長期重放或研究的服務應另外安排歸檔，核對恢復渠道，而不是等節點停止提供後才發現資料缺口。

長期歸檔要關注多份副本、可導出性和恢復測試，單一服務的網址並不證明永久保存。歸檔費用和服務停用情景也需考慮；研究者若依賴歷史資料，應在保留期內保存合法可得資料並檢驗副本完整。

費用需要分層計算

Blob費市場與執行費分開，但用戶還可能承擔執行Gas和應用收費。某次發佈便宜不代表Rollup整體更安全，排序、證明、升級和退出條件仍需獨立評估。

總成本可以拆成資料發佈、執行、證明和應用加成，但不同系統並非都向用戶分別收費。比較時明確哪些已含、哪些額外，不把一次低價交易宣傳為長期固定費率。擁堵與參數變化都可能影響後續成本。

建立長期檢索檢查

示例工作流分別保存交易、承諾、獲取時間和歸檔位置，並檢驗缺少Blob正文時哪些分析不能繼續。不要將找不到歷史資料直接解釋為鏈上記錄不存在，檢索失敗與驗證失敗是不同情況。

公開示例可選一個歷史交易說明承諾與外部正文的關聯，記錄獲取時點。若下載失敗，僅報告本次檢索未成功，不斷言資料已經全網消失。沒有充分來源時，不給當前Blob費、容量或保留天數編造實時數字。

技術檢查單依次記錄“臨時資料”“版本承諾”“保留期限”“歸檔安排”，把標準規定、軟體實現和這次實際觀察分欄。先做無資金、只讀的小範圍檢驗，保存版本與區塊引用，出現缺失就說明無法確認的環節。不同客戶端的結果不一致時核對參數和資料範圍，不憑一個頁面斷言整個協議失效。解釋應讓讀者理解邊界，而不是讓複雜術語成為安全保證。