以太坊 Blob 与 Calldata：费用和数据保留的区别

Blob是独立数据通道

Blob承载交易为Rollup提供与普通Calldata不同的数据通道，并通过承诺将数据与交易联系。它不是把所有内容变成普通合约存储，读取方式和费用机制也不同。

承诺用于检验取得的数据是否对应交易，但有承诺不等于任何时候都能找到正文。可用性、完整性和长期保存是三个不同问题，说明时应分别列负责方和时间范围，避免将密码学保证扩展成存储服务承诺。

执行层不能随意读取全文

EVM可取得Blob版本化哈希，却不能把Blob全文像普通Calldata一样直接读取。应用设计需要考虑数据在哪里提供、由谁取得和验证，不应只看到低费用就认为接口相同。

应用若只读取版本哈希，需要另有流程取得Blob并解释编码。普通合约调用无法任意加载正文，开发文档中的接口边界应保留。对非技术读者可以用收据编号与包裹内容的差异解释，而不暗示编号能重建丢失内容。

保留期限不是永久归档

协议要求的数据可用时间具有期限，不能当作无限历史存储承诺。需要长期重放或研究的服务应另外安排归档，核对恢复渠道，而不是等节点停止提供后才发现资料缺口。

长期归档要关注多份副本、可导出性和恢复测试，单一服务的网址并不证明永久保存。归档费用和服务停用情景也需考虑；研究者若依赖历史数据，应在保留期内保存合法可得资料并检验副本完整。

费用需要分层计算

Blob费市场与执行费分开，但用户还可能承担执行Gas和应用收费。某次发布便宜不代表Rollup整体更安全，排序、证明、升级和退出条件仍需独立评估。

总成本可以拆成数据发布、执行、证明和应用加成，但不同系统并非都向用户分别收费。比较时明确哪些已含、哪些额外，不把一次低价交易宣传为长期固定费率。拥堵与参数变化都可能影响后续成本。

建立长期检索检查

示例工作流分别保存交易、承诺、获取时间和归档位置，并检验缺少Blob正文时哪些分析不能继续。不要将找不到历史数据直接解释为链上记录不存在，检索失败与验证失败是不同情况。

公开示例可选一个历史交易说明承诺与外部正文的关联，记录获取时点。若下载失败，仅报告本次检索未成功，不断言数据已经全网消失。没有充分来源时，不给当前Blob费、容量或保留天数编造实时数字。

技术检查单依次记录“临时数据”“版本承诺”“保留期限”“归档安排”，把标准规定、软件实现和这次实际观察分栏。先做无资金、只读的小范围检验，保存版本与区块引用，出现缺失就说明无法确认的环节。不同客户端的结果不一致时核对参数和资料范围，不凭一个页面断言整个协议失效。解释应让读者理解边界，而不是让复杂术语成为安全保证。