Eu comecei a fazer staking de RLS desde a fase de compromisso anterior; ler materiais oficiais já virou hábito. Depois que o nome “Sovereign” foi anunciado, a maior parte das discussões ficou presa em “será que só trocaram um nome?”. Eu acho que a pergunta está invertida. O nome não é o mais importante; o que importa é o que foi alterado embaixo e quanto uma instituição, ao fazer due diligence, consegue obter de coisas que ela própria pode verificar. Para cada número deste texto, eu forneci uma fonte exata. Você pode reproduzir tudo seguindo isso.
Primeiro, vou esclarecer uma coisa: como na semana passada eu escrevi um artigo sobre auditabilidade, talvez alguns leitores tenham visto.
A maior parte do conteúdo aqui é nova: vem do repositório de código da Axyl, do diretório de auditoria dentro do repositório e do documento da página de benchmarks de desempenho da Axyl. Eu ainda não tinha mexido nesses três lugares. Só a pequena seção sobre custódia de chaves dá continuidade às conclusões do artigo anterior; eu vou marcar isso lá. Eu separo “novo” e “antigo” assim porque “o que eu pesquisei esta semana” e “o que eu já tinha pesquisado antes” devem permitir que o leitor identifique por conta própria.
先把时间线摆正
这不是一次改名。
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 即可。
