Cardano Leios 测试网达到主网吞吐量的六倍

根据 Leios 产品经理 Carlos Lopez de Lara 的说法，Cardano 的公共 Leios 测试网在已完成的 Earth 阶段达到了 26.8 交易千字节每秒。该观测速率几乎是当前 Cardano 主网约 4.5 TkB/s 限制的六倍。

该结果出现在 Input Output 与社区参与者同时施加负载期间，而不是在一次正式的最大吞吐量测试中。MusashiNet 现已进入 Water 阶段，团队正准备不同的协议配置，以及通过 Dijkstra 硬分叉让 Leios 进入 Cardano 所需的治理路径。

Leios Earth 阶段交付其首个公开吞吐量结果

Ouroboros Leios 是 Cardano 提出的基础层扩容协议。它与 Ouroboros Praos 并行运行，并引入 endorser 区块，使更大量的交易数据可并行处理，同时 Praos 仍作为网络的底层安全与结算机制。

MusashiNet 是一个公共环境，用于将 Leios 原型从受控的开发网络迁移到暴露于真实延迟、硬件与网络条件的基础设施中。Earth 阶段重点验证在该环境下完整的协议设计是否能够持续运作。

Input Output 使用名为 TX Centrifuge 的交易生成器创造了足够的流量以激活 Leios。社区参与者同时使用 TX Firehose，这是一款用于公众测试的更简单的负载生成工具。所报告的吞吐量出现在两种来源同时生成交易的某一时段。

该测量并非 TPS 指标。TkB/s 表示每秒处理的交易数据体量，而交易笔数会随其大小与复杂度而变化。由于此次运行并未被设计为正式的压力测试，观测到的速率并不构成 Leios 的已发布容量上限。

在 Earth 阶段，网络包含 62 名出块者，开发团队在六周内发布了 10 个原型版本。Lopez de Lara 还报告了 5 起事件，包括分叉与测试网暂停。

据其更新，每起事件均被追溯为在较小的本地环境中未出现的实现缺陷。团队未将任何一例认定为 Leios 协议设计的根本性失败。这些问题已被分析与修复，并随后的原型版本已发布更新。

一支专门的红队也在依据其威胁模型对 Leios 进行测试，在原型转化为生产级代码之前对系统发起攻击以识别薄弱点。

Water 阶段增加参数测试与 SPO 激励

Water 阶段将重心从验证基础协议设计转向探索不同配置。团队将调整计时设置、区块大小与组件实现，以确定哪些组合能够提供稳定且可持续的吞吐量。

测试将包括重设计的 mempool，旨在解决在更高交易负载下更为凸显的限制。该新组件将随着测试网活动的进一步增加而一并评估。

Input Output 还为权益池运营者开放了 Musashi Testnet Rewards Program。该计划会奖励在 MusashiNet 上维护基础设施并分享其节点运行数据的运营者。

所需的遥测预计包括出块、投票与扩散日志，节点版本，时钟偏移与主机资源。汇集多位运营者的信息可使团队重建区块、投票与证书如何在地理分布式网络中传播。

该计划最多支持 100 个池。运营者必须证明对其池的控制权，注册 BLS 验证密钥，并提供用于支付的主网 ADA 地址。测试网水龙头会向每个已注册的池委派一百万测试 ADA，以便其出块并参与 Leios 投票委员会。

申请现已开放，但月度详细资格标准仍在最终敲定中。官方文档称，奖励基于参与与数据共享，而非技术性能。

Dijkstra 推出带来治理依赖

Lopez de Lara 确认，Leios 计划在 Dijkstra 时代，即 Cardano 的下一次硬分叉中部署。启用之前，团队打算向 Cardano Constitution 提交一项技术性更新，涵盖新的协议参数及其防护边界。

该更新预计将在九月下旬至十月上旬期间提交。Lopez de Lara 表示，其应仅限于 Dijkstra 所需的技术性变更，不应与无关的宪法修订捆绑。

推出计划还要求以保守的初始 Leios 设置开始，随后随着运营证据的积累逐步提升容量。部分参数日后可以上调，但若无再次硬分叉则无法下调，而更高的基础设施要求将直接提高权益池运营者的成本。

该时间表与 Cardano 的 Update Constitutional Committee 行动相交。该委员会的七个席位中有四个将于九月一日到期。若更替行动未获批准，委员会人数将低于正常治理运作所需的至少五名成员。

人员不足的委员会将阻止计划中的技术性宪法更新推进，直至委员会恢复。为此，Lopez de Lara 呼吁 DReps 与 SPOs 就当前行动进行投票，将该委员会的决定与拟议的 Leios 时间线直接关联。

Earth 以一个可运行的公共原型、十次发布以及团队未识别出任何根本性协议失败而收官。接下来 Water 必须将初始吞吐量结果转化为稳定的主网配置，同时，委员会投票与技术性宪法更新将决定这些参数能否按拟定进度进入 Dijkstra 治理。