【英文】Spire Labs：共享 Blob 压缩与聚合的详细信息

Chainfeeds 导读：

随着应用链（appchain）采用率的不断增长，链与链之间在数据处理上的协同变得尤为重要。Spire Labs 阐述了通过将多个应用链的 Blob 数据进行聚合和压缩所带来的诸多优势。并制定一个中立的规范，允许不同的应用链根据自身需求选择支持的数据可用性（DA）层、压缩算法及其他关键参数。

文章来源：

https://paragraph.xyz/@spire/shared-blob-compression

文章作者：

Spire

观点：

Spire：随着应用链（appchain）采用率的增长，各链之间对选择性地将其 blobs 与其他应用链的 blobs 进行聚合和压缩的需求也在增加。聚合带来了以下好处： 提高数据提交频率：应用链无需等待足够的交易数据填满一个 blob 即可更频繁地向其选择的数据可用性（DA）层提交交易，减少了提交部分填充 blob 的成本。 优化 Blob 空间利用率：特别是对于交易量较低的链，能够更高效地使用 blob 空间。 确保数据提交的可靠性：应用链不再需要担心 L1 区块中的 blob 槽位耗尽，因为它们的 blobs 将与其他应用链的 blobs 进行聚合。 除了聚合 blobs，这还允许应用链指定额外的参数，例如它们支持哪些 DA 层、使用哪些数据压缩方案、目标 L1 区块，以及如何选择更新其状态。 在此设计中，一个 Rollup 将会： 将其 Blob 数据发送到链下聚合服务，同时附带每个 Blob 的承诺、其 Rollup / 链 ID、支持的压缩方案、目标数据可用性（DA）层、目标 L1 区块以及其他可能的字段。 聚合服务随后根据 Blob 的大小、目标 DA 层、压缩方案等对传入的 Blob 进行排序。具体的实现细节可能有所不同。 聚合服务将针对相同 DA 层的 Blob 进行串联，形成一个「超级 Blob」，并生成并存储一个命名空间 Merkle 树（NMT），以便 Rollup 通过其 Rollup-ID 快速识别超级 Blob 中的各自 Blob。 超级 Blob 通过辅助链（sidecars）发送到各自的 DA 层。针对 Blob 聚合器的收件箱合约的 L1 交易及其对超级 Blob 的承诺将被发送到 L1。注意，如果 Rollup 指定了目标 L1 区块，聚合器可能需要在此阶段获取某种预先确认（preconf）。 Rollup 更新其状态（例如，推导管道等），以识别来自聚合服务地址的批量交易或证明。与该 Rollup 相关的 Blob 数据将从超级 Blob 中获取，可以由 Rollup 自身完成，或通过聚合服务提供的某个端点进行获取。 Rollup 负责提供一种机制，以确认检索到的 Blob 与其最初发送的 Blob 匹配。例如，提供一个可以用公钥验证的 Blob 承诺。可能需要额外的确认。例如，基于 Rollup 的机制可能需要确认 Blob 中的原始 L2 数据是由正确的选举获胜者为 L1 区块排序的，等等。 Rollup 随后使用解压后的数据更新其状态并推进规范推导。【原文为英文】