我从预承诺阶段就开始质押 RLS,读官方材料算是习惯。Sovereign 这个名字出来之后,讨论大多停在"是不是只是改了个名"。我觉得这问题问反了。名字不重要,重要的是底下换了什么、以及一家机构在做尽调时能拿到多少可以自己核的东西。这篇里的每个数字我都给了确切出处,你可以照着复现一遍。
先说明一件事,因为上周我写过一篇关于可审计性的文章,有读者可能看过。
这篇里绝大部分内容是新的,来自 Axyl 的代码仓库、仓库里的审计目录、以及 Axyl 性能基准那一页文档,这三处我此前都没有碰过。只有讲密钥托管的那一小节是延续上一篇的结论,我会在那里标出来。把新旧分开说,是因为"我这周查到了什么"和"我以前查过什么"应该让读者自己能分辨。
先把时间线摆正
这不是一次改名。
Axyl 是 2026 年 4 月份末尾先在 Rayls 公链主网上线的,Sovereign 迁移到 Axyl 是 2026 年 7 月,发生在公链之后。官方文档写明迁移分阶段进行,期间机构照常运行。底层换完之后才有了新名字。
文档那段 What changed 列了五项,下面挑两项讲,因为这两项改变的是机构的处境,不只是技术栈参数。
变化一:从一个节点变成一个委员会
文档原话:更早的 Rayls Sovereign 账本以单个 Geth 节点、单个验证者的形式运行。Axyl 跑的是跨委员会的拜占庭容错共识,单节点可用性风险不再适用。同一段还写了 EVM 节点从 Geth 换成 Reth,Clique 权威证明换成 Axyl。
我去仓库里核了 Axyl 是什么。一个 Rust 写的协议客户端,单个二进制 rayls-network 同时跑两半:共识层是 Narwhal 与 Bullshark 的实现,走 libp2p 的 QUIC;执行层建在 reth 和 alloy 上,产出标准以太坊 EVM 区块。节点分验证者和观察者,后者通过状态同步跟随链但不进委员会。工具链锁定 Rust 1.91。
对一家银行,这一项的意义不在吞吐量,在运营韧性。 单节点单验证者的账本,一次机器故障就是账本停摆,没有冗余可言,而这恰好是最难向监管方交代的一类设计。换成委员会之后,这个问题从没有答案变成有标准答案,拜占庭容错是风控和监管都熟悉的语言。
代价也具体。仓库 README 给的推荐最低配置是 8 个物理核心、16 GiB 内存、500 GiB 固态盘、10 Gbps 以上带宽,而且这是每个委员会成员的要求,不是一台机器。文档另给了 Sovereign 账本本身的两级部署配置,轻量级 2 vCPU、4 GB、100 GB,企业级 4 核以上、16 GB、500 GB。
还有一处容易漏:私有网络枢纽没有跟着换,文档单独说明它继续运行 Besu 和权威证明,不受 Axyl 迁移影响。机构自己那层现在是拜占庭容错,机构之间那层还是权威证明,两层的信任模型不同,评估时要分开看。
变化二:密钥从传输组件里搬了出来
这一节是延续我上一篇的结论,不是本周的新发现,放在这里是因为 brief 要求举两项变化,而这一项确实是五项之一。
文档那一条写的是密钥管理模块变成 Cryptographic Trust Suite,一个解耦的密钥托管组件,Relayer 不再直接处理或存储密钥。我上一篇在源码里核过这条,relayer 和治理服务两个仓库的 cryptography 目录能对上。
对机构的意义有两点。Relayer 是对外通信、最暴露的组件,旧结构里它同时碰密钥,新结构里它拿不到,传输层被攻破不再等于密钥被攻破。另一点是密钥存储可插拔到机构自己已经在用的 KMS 或硬件安全模块,因而机构现成的审计轨迹就覆盖了 Rayls 的密钥操作,不需要为此新建一套审计面。
本周真正的新材料:审计目录
Axyl 仓库里有个 audits/ 目录,里面有一份 README 和三份 PDF。我把那份 README 读完了,内容比"做过第三方审计"这句话具体得多。
三份报告都由 Halborn 出具,执行窗口在 2026 年 2 月到 3 月,整改复审在 4 月到 5 月完成。
共识协议那份文件名是 halborn-2026-03-consensus-protocol.pdf,范围是共识相关的 Rust 代码路径、证书同步、gossip 处理和验证者密钥管理,执行期 3 月 2 日到 3 月 20 日,5 个发现,其中 1 个严重、3 个中等、1 个低,全部解决。
网络节点那份是 halborn-2026-03-network-node.pdf,范围是网络、worker、状态同步、执行、编排和存储模块,执行期 2 月 18 日到 3 月 24 日,22 个发现,其中 1 个严重、2 个高、7 个中等、6 个低、6 个提示性,20 个解决,2 个低风险接受。
智能合约那份是 halborn-2026-03-smart-contracts.pdf,范围是 rayls-contracts/src/ 下的 ConsensusRegistry、StakeManager、DelegationPool 和手续费分配等合约,执行期 3 月 2 日到 3 月 13 日,15 个发现,其中 1 个严重、2 个高、7 个中等、2 个低、3 个提示性,14 个解决,1 个中等风险接受。
加起来是 42 个发现:3 个严重、4 个高、17 个中等、9 个低、9 个提示性。39 个解决,3 个风险接受。三个严重级全部解决。
我把这些数字逐一列出来,是因为对采购而言"有没有做过审计"和"审了什么、审了多久、发现了多少、有几个没修"是完全不同的问题。第一个问题几乎所有项目都能答是,第二个能答的不多,而这里每一项都是公开可查的。三个严重级全部修掉,这是个实打实的正面事实。
同一份 README 里还披露了一件事
这一段我认为是全文对尽调最有用的。
那份 README 有一节专门讲提交记录和 pull request 引用的问题。原文的意思是:这些审计是针对未公开前的私有仓库做的,项目开源时,仓库历史被压缩成了单个初始提交。因此报告里作为整改证据引用的提交哈希和 pull request 链接,在这个公开仓库里解析不出来。
Rayls 同时说明,所有经 Halborn 验证的整改都包含在公开仓库的初始提交里,而那个提交的时间晚于整改复审;PDF 按 Halborn 出具的原样发布,未经修改。
对一家做尽调的机构,这是个具体而真实的限制:报告可读、未经修改,但报告指向的整改证据链在公开仓库里走不通。 你能看到 Halborn 说某个问题已修复,但你没法顺着它给的链接去看那次修复的实际代码变更。
我想强调这不是隐瞒,恰恰相反,是 Rayls 自己在 README 里主动写清楚的,而且给出了原因和补偿说明。我把它写出来,只是因为这正是安全团队会问的第一个问题,而答案已经在那儿了,只是在一个大多数人不会点开的文件里。
那个吞吐量数字,条件也是公开的
这一项我单独说,因为八月社区总结点名过:两个 TPS 数字在流传,大家引用比较大的那个。
我把三处来源理了一遍。官方文档在讲 Sovereign 性能时写的是 Axyl 下 15,000+ TPS、亚秒级最终性。Axyl 仓库 README 写的是协议目标为 10,000+ TPS,用词是 targets,目标而非实测。而条件在第三个地方,一页叫 Axyl Performance Benchmarks 的文档,那一页明确写着这是共识层的原型基准测试,记录条件是四节点委员会、512 字节交易、500 KB 批量大小、最大 50 毫秒批延迟,另外单独给了测试网上的共识数据。
所以完整表述应该是:共识层在这四个条件下的原型基准,不是端到端的生产实测。 需要说明的是那一页的具体数值以图片形式给出,我读不到图里的数字,能确认的是条件本身。
顺带一个我自己跑出来的旁证。 9 月 12 日我调了公链浏览器的 stats 接口,返回的平均出块时间是 500 毫秒左右。这跟亚秒级的说法是一致的,而且任何人调同一个接口都能自己看一遍。出块时间不等于交易最终性,但它至少是一个可以独立取得的实测值,而不是转述。
一个采购部门会问但很少被提的细节
Axyl 的许可证是 BUSL-1.1,商业源码许可证,不是通常意义上的开源。
仓库许可证一节写得很具体:允许的生产用途是在 Rayls 公链主网及其官方测试网上运行节点,包括验证者、观察者、relayer 和 RPC 四类;其他生产用途需要商业许可。每个版本首次公开发布四年后为变更日期,届时转为 Apache 2.0。
顺着读下来,一家银行在自己的 Sovereign 部署里跑 Axyl,属于其他生产用途。
这不是批评。Rayls 对外就说过核心平台开源而 Axyl 和 Enygma 是商业组件,BUSL 加四年转 Apache 也是业界成熟做法。写出来只是因为"开源"这个词在传播中经常被当成随便用,而边界在许可证文件里写得清清楚楚。
代码从哪来,仓库自己说了
Axyl 仓库的致谢一节坦率得少见。共识部分的 Rust 工作区衍生自 Telcoin Network,而后者建立在 Sui 的 Narwhal 与 Bullshark 之上,Rayls 在此基础上做了大幅重组和修改;Bullshark 的实现大量衍生自 Mysten Labs 的 Sui 代码库,依据 Apache 2.0;执行层用 reth 和 alloy;LayerZero 的 OFT 接口保留原始 MIT 许可。
把血统写清楚比声称一切自研更容易被工程团队信任,因为审计方可以顺着这条线去看上游的成熟度。
哪些是新的,哪些是延续,哪些没核到
本周新查的:Axyl 仓库 README 的全部内容,包括架构、角色、配置、许可证与致谢;audits/README.md 的三份报告表格与提交历史压缩的说明;doc/index.md 的系统总览;Axyl Performance Benchmarks 页的基准条件;官方文档 Rayls Sovereign 页的 What changed 五项与两级部署配置。
延续上一篇的:Cryptographic Trust Suite 的密钥边界,以及 Relayer 不持有密钥这一条,那是我上周在 relayer 和治理服务两个仓库源码里核过的。这一节没有新增证据。
我的推断:单节点改委员会的主要价值在运营韧性而非吞吐量;整改证据链在公开仓库走不通是尽调层面的实际限制;把代码血统写清楚是正面
信号。这三条资料里没有这么写。
没能核实的:我没有任何一家机构实际运行该配置的证据,本文谈的全部是文档与代码所记载的能力。
复现路径:GitHub 搜 raylsnetwork/axyl,根目录的 README 和 audits/README.md 两个文件覆盖本文大部分数字;官方文档搜 Rayls Sovereign 与 Axyl Performance Benchmarks 两页;出块时间调公链浏览器的 /api/v2/stats 即可。
