TxPipe 为 Cardano 的 Rust 基础设施做好 Leios 准备

9月16日, TxPipe 在 Pallas 1.2.0 中发布了 LeiosNotify 和 LeiosFetch, 同时引入了初始的 Dijkstra 账本结构。这些新增内容为 Rust 团队提供了交换 Leios 数据并处理拟议区块格式的工具。Dijkstra 组件仍被明确标注为实验性, 可通过一个 unstable 功能标志启用。

Pallas 为 Rust 引入 Leios 网络

Pallas 是一组用于 Cardano 网络、密码学操作和区块链数据处理的 Rust 库。开发者使用它来构建索引器、数据服务以及与 Cardano 节点交互的其他应用。

这些新协议位于 pallas-network2 中。LeiosNotify 用于宣布 endorser 区块并提供可用数据。LeiosFetch 允许已连接的对等体请求区块体、相关交易和投票。

该网络实现于6月30日合并, 在纳入9月发布版之前已针对一个 Musashi 中继进行了测试。作者确认实现了成功的协议协商、获取一个 endorser 区块体, 以及接收内联投票。

交易检索存在另一个限制: 当请求的数据不可用时, 该中继可能会失败。示例应用已调整为只请求该中继已提供的交易, 但由于 Leios 活动处于空闲状态, 在报告的实测中这一路径仍未得到确认。

为什么 Pallas 对 Cardano 的 Leios 升级很重要

Leios 引入与 Cardano 现有 Praos 结构并存的 endorser 区块, 以提升交易容量。要支持这一变更, 需要在检索和处理链上数据的各个系统中提供兼容的软件。

Input Output 的影响分析将 Pallas 列为受 Leios 影响的库之一。它还将 Oura 和 Mithril 列为使用 Pallas 的系统。Oura 处理链上事件, 而 Mithril 的官方文档将 Pallas 列为其默认的链观察器。

所需更改取决于各个应用与网络的连接方式。直接读取网络消息或区块的服务需要兼容的库和解码器。通过中间 API 访问 Cardano 的钱包和 dApps 可能在提供方更新其后端时维持现有接口不变。

兼容性只是工作的一部分。更高的吞吐量会带来额外的存储、索引和处理需求。因此, Input Output 呼吁在高负载下尽早进行测试, 以便基础设施团队在部署前识别瓶颈。

Pallas 的网络支持为 Rust 团队提供了在启用 Leios 的节点上开始进行该集成工作的途径。下游产品中的采用和测试仍是独立的任务。

实验性 Dijkstra 支持使用真实测试网区块

Pallas 1.2.0 还引入了 Dijkstra 区块、区块头、交易及相关账本数据的结构。由于该纪元的编码规范仍在变化, 它们仍位于 unstable 功能标志之下。

测试使用了在 Musashi 上记录的13个 Dijkstra 区块以及一个之前的 Conway 区块。测试核查了数据在解码并重新编码后字节不发生变化、区块头哈希与节点记录一致, 以及 Dijkstra 解码器会拒绝该 Conway 区块。

还有一些结构依据规范实现, 但在这些记录的区块中没有对应示例。引入该功能的 pull request 也未改动 Pallas 共享的多纪元解码层, 更广泛的集成将作为单独的任务推进。

1.3.0 和 1.4.0 版本于9月17日随后发布, 并在处理深度嵌套的数据和脚本时加入了防止栈耗尽的保护措施。

对于试验 Dijkstra 格式的开发者, 这些新类型提供了一个明确的验证点: 已记录的测试网区块可以被读取、重建, 并与其原始哈希进行校验。这样在账本规范持续演进的过程中, Rust 集成便拥有了可测试的基础。