如果 AI Agent 每调用一次 API、购买一次数据或使用一次算力，都留下可核验的交易记录，区块链需要承载多少数据？这正是 Celestia 希望通过 Fibre 回答的问题。
2026 年 10 月 1 日，Celestia 公布 Fibre 的新一轮端到端测试：120 个验证者在 143 秒负载窗口内，平均完成 3.07 Tb/s 的数据吞吐。这篇文章从架构和运营两个角度解读这一结果，帮助读者把性能数字放回实际应用的上下文。
本文由 NodeStake 根据 Celestia 官方博客与协议文档整理。文中的测试成绩来自 Celestia，配图为 NodeStake 绘制；主网参数与上线安排以官方后续发布为准。
先理解 DA：应用的数据能否被取回？
数据可用性（Data Availability，DA）关心的是：应用发布的数据，是否能够被需要它的人获取并用于验证。对 Rollup 来说，只公布一个新的状态结果还不够，验证者也需要交易数据，才能检查这个结果是如何产生的。
可以把应用想象成一家需要公开账目的商店。计算新的余额属于执行；证明计算遵守规则属于验证；让其他人拿到账目，才是数据可用性。Fibre 主要扩展的是最后这一部分的容量。
这也解释了为什么不能只拿一个带宽数字判断应用有多快。交易计算、状态更新、证明生成、数据读取与钱包交互，都可能影响用户最终感受到的速度。关于 DA 和测试口径，可参考 Celestia 的 Why Blockchain Benchmarks Are Usually Deceiving。
Fibre 的设计：把数据传输和链上记录分开
Fibre 是由 Celestia 验证者运行的数据可用性协议，与 Celestia 原有的 DA 路径并行。它面向需要发布大量数据的应用：客户端直接把编码后的数据碎片发送给验证者，再把数据承诺和验证者签名提交到 Celestia。
其中，blob 可以理解为一批待发布的数据；数据承诺（commitment）则是与这批数据绑定的紧凑密码学记录。承诺便于核验数据身份，真正的数据仍需要由存储与读取服务提供。
- 编码数据。 客户端将 blob 编码成碎片，并加入用于恢复数据的冗余信息。
- 直接分发。 验证者接收分配给自己的碎片，检查相关证明与支付承诺，并存储数据。
- 收集签名。 客户端收集验证者的确认签名，默认安全门槛为总投票权的三分之二。
- 链上确认。 客户端通过 PayForFibre 消息提交签名和数据承诺，等待交易被链上确认。
读取时，客户端向验证者请求碎片，验证收到的数据，收集足够的有效碎片后重建原始 blob。这使单个节点能够只承担部分数据的存储与传输。流程依据 Fibre 客户端规范 与 服务端规范。
纠删码让碎片丢失后仍有恢复空间
Fibre 使用的编码方案基于 ZODA。这里一个关键概念是纠删码：它会在原始数据之外生成恢复信息，让接收方在缺少部分碎片时，仍有机会还原完整数据。恢复需要足够的有效碎片，并依赖协议规定的诚实节点与安全假设。
可以把它想象成一份分散保存的拼图，同时附带帮助补齐缺失部分的信息。拼图不必全部放在同一台机器上，但读取方仍需要核验收到的碎片，并达到恢复条件。
冗余信息也会占用带宽和存储。因此，衡量原始数据的有效吞吐量时，应当同时关注编码后的实际网络流量与存储开销。Fibre 的协议概览见 官方介绍 和 DA 规范。
3 Tb/s 测试到底测了什么？
这轮测试覆盖新数据的编码、分发、存储、签名收集和链上提交。统计只计入已经获得链上确认的原始 blob 数据，额外的恢复数据与传输流量没有计入这一吞吐量。
单位也需要读准确：Tb/s 中的小写 b 表示 bit（比特）。按十进制单位换算，3 Tb/s 等于约 375 GB/s。大小写相差八倍，不能把这个数字写成每秒 3 TB。
测试提速来自整条处理链路的优化：ARM NEON 加速纠删码编码，签名检查复用与并行验证减少链上处理工作，S3 存储通过合并碎片和分散写入降低请求压力。官方还调整了区块容量与出块时间。具体成绩与设置见 Celestia Fibre Hits 3 Tb/s。
如何理解“接近每秒 20 亿笔交易”？
官方用交易数量描述这一带宽的潜在规模。我们也可以做一个独立估算：假设每笔交易的数据大小为 200 字节，那么 375 GB/s 可以容纳约 18.75 亿份这样的交易数据。换一个交易大小，换算结果就会改变。
示例假设：每笔交易占用 200 字节
3 Tb/s ÷ 8 = 375 GB/s
375,000,000,000 字节/秒 ÷ 200 字节
= 1,875,000,000 份交易数据/秒这里得到的是数据容量的换算。实际执行这些交易还需要应用的计算与状态管理系统跟得上。一次复杂合约调用和一次简单转账可能有不同的计算成本，发布相同大小的数据也不意味着它们具有相同的执行速度。
从测试成绩到主网服务，还需要哪些条件？
官方说明，本次使用实验性能分支、2 GiB blob、1 秒出块及每区块最多 2,000 次 Fibre 提交；内存与并发设置也针对测试机器调优。初期主网 blob 上限计划为 128 MiB，容量将随需求逐步提高。
143 秒的负载窗口证明了这套配置在短期测试中的表现。要把它转化为可持续服务，还需要观察长期运行、节点故障、存储增长、数据读取与恢复等场景。Celestia 在 关于区块链基准测试的文章 中也讨论了存储、索引和节点同步对实际容量的影响。
- 应用开发者： 用自己的数据大小和负载测量上传、确认与读取时间，并评估发布费用。
- 节点运营者： 同时观察网络、编码 CPU、存储写入、读取能力和故障恢复，找出真正限制容量的环节。
- 基础设施服务商： 明确数据保留周期、历史数据的获取方式，以及服务中断后的恢复目标。DA 和长期归档需要分别设计。
Fibre 可以为哪些应用打开空间？
Celestia 的官方介绍列举了 AI Agent 支付、按调用付费的数据服务和高吞吐市场等方向。更充裕的数据发布能力，让开发者有机会尝试更细粒度的记录方式。下面是基于这些方向的应用设想，具体可行性仍需要各应用自行验证。
- AI Agent 服务交易： 在购买数据、调用模型和支付算力时，保留可核验的记录，支持后续对账与审计。
- 高吞吐 Rollup： 为密集交易或应用事件提供数据发布容量，同时为执行、证明和索引系统规划相应的能力。
- 按使用量计费的数据市场： 将数据访问与支付记录关联起来，让服务提供方和使用方更容易核对实际消费。
这些应用还需要合适的费用、隐私与访问控制设计。敏感数据如何保护、哪些记录需要公开、保存多久，都应由应用结合自身需求确定。
NodeStake 的观察：容量要沿着整条链路扩展
从基础设施运营的角度，我们更关注性能提升后，下一处瓶颈会出现在哪里。编码更快后，网络和存储可能承压；数据确认更快后，读取和索引又需要匹配。实际服务能力取决于这些环节如何协同。
Fibre 给出的一个值得关注的方向，是把大规模数据传输交给分布式的数据服务，让链上处理紧凑的承诺与确认记录。对开发者和节点运营者而言，接下来最有价值的工作，是用实际负载验证这套架构如何满足自己的需求。
参考资料
- Celestia Fibre Hits 3 Tb/s — 2026 年 10 月 1 日，最新测试结果、优化与测试条件。
- Introducing Fibre: 1Tb/s of blockspace — 2026 年 1 月 13 日，协议设计与潜在应用方向。
- Why Blockchain Benchmarks Are Usually Deceiving — 2026 年 7 月 3 日，测试吞吐量与生产容量的区别。
- Fibre DA Specification — 官方协议文档入口；实现细节与参数可能随版本更新。
- Fibre Client 与 Fibre Server — 上传、签名、存储与数据取回流程。