私は事前の約束（プレ承諾）段階からRLSをステークしてきました。公式資料を読むのも習慣になっています。Sovereignという名前が出てからというもの、議論の多くは「ただ名前を変えただけなのでは？」で止まっています。でも、この問い方は逆だと思います。名前は重要ではありません。重要なのは、その下で何が変わったのか、そしてある機関がデューデリジェンス（尽調）を行う際に、自分で検証して確認できる材料をどれだけ持ち帰れるかです。この記事の中にある各数字については、すべて確実な出典を添えました。あなたはそれに沿って一度再現できます。
まず1つ説明します。先週、私は可監査性についての記事を書いたので、それを読んだ方がいるかもしれません。
この記事の大部分は新しい内容で、Axylのコードリポジトリ、リポジトリ内の監査ディレクトリ、そしてAxylのパフォーマンスベンチマークのページに由来します。この3点は、私はこれまで触れたことがありません。鍵の保管（キー・マネジメント）についての短い一節だけが、前回の記事の結論を引き継いだものなので、そこで明示します。新旧を分けて話すのは、「今週調べて分かったこと」と「以前調べていたこと」を読者自身が区別できるようにするためです。
まず時系列を正します。
これは改名ではありません。
Axyl は 2026 年 4 月末にまず Rayls 公鏈メインネットへ導入されます。Sovereign の Axyl への移行は 2026 年 7 月で、公鏈の後に起きます。公式ドキュメントには、移行は段階的に行われ、その間は組織が通常どおり稼働していると明記されています。基盤を入れ替えた後に初めて新しい名前になりました。
ドキュメントの What changed には 5 項目が列挙されており、そのうち 2 項目を選んで説明します。なぜなら、この 2 項目は技術スタックのパラメータだけでなく、組織の立場（状況）を変えるからです。
変更 1: 1 台のノードから 1 つの委員会へ
ドキュメントの原文: より早い段階の Rayls Sovereign 台帳は、単一の Geth ノード、単一のバリデータという形で動作していました。Axyl は、複数委員会間のビザンチンフォールトトレランス・コンセンサスで、単一ノードの可用性リスクは適用されません。同じ段落内で、EVM ノードが Geth から Reth に置き換わり、Clique の権威証明が Axyl に置き換わったとも書かれています。
私はリポジトリを見て「Axyl が何か」を確認しました。Rust で書かれたプロトコルクライアントで、単一のバイナリ rayls-network が 2 つの部分を同時に動かします。コンセンサス層は Narwhal と Bullshark の実装で、libp2p の QUIC を使います。実行層は reth と alloy の上に構築され、標準的なイーサリアム EVM ブロックを生成します。ノードはバリデータとオブザーバに分かれ、オブザーバは状態同期でチェーンに追随しますが委員会には入りません。ツールチェーンは Rust 1.91 に固定されています。
銀行にとって、この項目の意味はスループットではなく、運用のレジリエンス（継続耐性）です。単一ノード・単一バリデータの台帳は、1 台のマシン障害で台帳が止まります。冗長性がない設計であり、これは規制当局に説明するのが最も難しいタイプの設計です。これを委員会に置き換えると、この問題は「答えがない」状態から「標準的な答えがある」状態へ変わります。ビザンチンフォールトトレランスは、リスク管理と規制の両方にとって馴染みのある言語です。
コストも具体的です。リポジトリ README にある推奨する最低構成は、物理コア 8 個、メモリ 16 GiB、SSD 500 GiB、帯域 10 Gbps 以上です。しかもこれは各委員会メンバーの要件で、1 台のマシンではありません。別途、Sovereign 台帳自体について 2 段階のデプロイ設定がドキュメントにあります。軽量級は 2 vCPU、4 GB、100 GB、企業級は 4 コア以上、16 GB、500 GB です。
そして見落としやすい点がもう 1 つあります。非公開のネットワークのハブは、入れ替えが追随していません。ドキュメントでは、それが引き続き Besu と権威証明を実行し、Axyl の移行の影響を受けないことを別途明記しています。組織側の層は現在はビザンチンフォールトトレランスで、組織間の層は依然として権威証明です。2 層で信頼モデルが異なるので、評価時は分けて見る必要があります。
変更 2: 鍵を伝送コンポーネントから移した
この節は、前回の記事での結論の続きであり、今週の新しい発見ではありません。brief の要件として 2 つの変更を挙げる必要があるため、ここに置いています。そしてこの項目は確かに 5 つのうちの 1 つです。
ドキュメントのその一文は、キー管理モジュールが Cryptographic Trust Suite になったこと、つまり疎結合な鍵の保管コンポーネントになったことを述べています。Relayer は鍵を直接扱ったり、鍵を保存したりしなくなります。前回はソースコードの中でこの点を確認しました。relayer とガバナンスサービスの 2 つのリポジトリにある cryptography ディレクトリが一致していました。
機関にとっての意味は 2 点あります。1 つは Relayer です。これは対外通信で最も露出度が高いコンポーネントで、旧構造では鍵にも触れていましたが、新構造では鍵を取得できません。伝送層が攻撃を受けても、それが鍵の侵害を意味しなくなったのです。もう 1 つは、鍵の保管が、機関自身がすでに使っている KMS やハードウェアセキュリティモジュールに差し替え可能であることです。したがって、機関が既に持っている監査トレースが、Rayls の鍵操作もカバーしており、新しくこのための監査面を作る必要がありません。
今週の本当の新しい材料: audits ディレクトリ
Axyl リポジトリには audits/ ディレクトリがあり、その中に README 1 本と PDF 3 本があります。私は README を読み終えましたが、「第三者による監査を受けた」という文言よりも、はるかに具体的です。
3 つのレポートはいずれも 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 件がリスク受容です。重大レベルの 3 件はすべて解決済みです。
私はこれらの数字を 1 つずつ列挙しました。なぜなら、調達にとっては「監査をしたか」「何をどれくらい監査したか」「何件見つかって、いくつ直してないか」はまったく別の問題だからです。1 つ目の質問に対しては、ほとんどのプロジェクトが Yes と答えられます。2 つ目に Yes と答えられるのは多くありませんが、ここでは各項目がすべて公開で検証できます。重大レベルの 3 件はすべて修正済みです。これは、ありのままの肯定的な事実です。
同じ README の中で、さらにもう 1 つ開示されていることがあります
この段落は、全文でデューデリジェンスに最も役立つ部分だと思います。
あの README には、提出記録と pull request の参照に関する問題を扱うセクションがあります。原文の趣旨は次のとおりです。これらの監査は、公開される前の非公開リポジトリに対して行われたものです。プロジェクトがオープンソース化されたとき、リポジトリの履歴は 1 つの初期コミットに圧縮されています。そのため、レポート内で是正の証拠として引用されているコミットハッシュや pull request リンクは、この公開リポジトリでは解決できません。
Rayls は同時に、Halborn が検証した是正はすべて公開リポジトリの初期コミットに含まれており、またそのコミットの時刻は是正の再審査より後であること、PDF は Halborn が出した原本どおりに公開されており改変されていないことも明記しています。
調査（デューデリジェンス）をする機関にとって、これは具体的で現実的な制約です。レポートは読めますし、改変されていません。しかしレポートが指し示す是正の証拠チェーンは、公開リポジトリ上で辿れません。Halborn が「ある問題は修正済み」と言っているのは見えますが、提示されたリンクを辿って、その修正の実際のコード変更を見ることはできません。
強調したいのは、これは隠蔽ではありません。むしろ逆で、Rayls が README 自身に自発的に明記しており、理由と補償の説明も示されています。私が書き出したのは、まさにセキュリティチームが最初に聞く質問であり、答えはすでにそこにあるからです。多くの人が開かないファイルに載っているだけです。
あのスループット数字で、条件も公開されています。
この項目は私があえて別立てで言います。8 月のコミュニティまとめで名前が挙がっていたからです。2 つの TPS 数値が流通していて、人々は比較的大きい方を引用しがちです。
私は 3 つの情報源を一つずつ整理しました。公式ドキュメントでは Sovereign の性能について、Axyl 下で 15,000+ TPS、秒未満級の最終性と書いています。Axyl リポジトリの README には、プロトコル目標は 10,000+ TPS で、用語は targets（目標）であり、実測ではありません。条件については 3 つ目の場所にあり、Axyl Performance Benchmarks という 1 ページのドキュメントです。そのページでは明確に、これはコンセンサス層のプロトタイプベンチマークテストであり、記録された条件は、4 ノードの委員会、512 バイトのトランザクション、500 KB のバッチサイズ、最大 50 ミリ秒のバッチ遅延です。さらに、テストネット上でのコンセンサスデータも別途提示されています。
したがって、完全な表現はこうあるべきです。『コンセンサス層は、この 4 つの条件下でのプロトタイプベンチマークであり、エンドツーエンドの本番実測ではない』。なお、その 1 ページに載っている具体的な数値は画像として提示されており、私は画像内の数字を読み取れません。確認できるのは条件自体です。
ついでに、自分で回して確認できた傍証もひとつあります。9 月 12 日に公連ブラウザの stats インターフェースを調べたところ、平均のブロック生成時間は 500 ミリ秒前後でした。これは「秒未満」という説明と整合していますし、同じインターフェースを誰でも調べれば自分で確認できます。ブロック生成時間は取引の最終性そのものではありませんが、少なくとも独立して取得できる実測値であり、伝聞ではありません。
購買部門が聞くが、あまり話題にされない細部
Axyl のライセンスは BUSL-1.1、商用のソースコードライセンスであり、一般的な意味でのオープンソースではありません。
リポジトリのライセンス節はかなり具体的に書かれています。許可された商用の本番用途は、Rayls の公鏈メインネットおよびその公式テストネットでノードを実行すること（バリデータ、オブザーバ、relayer、RPC の 4 種類を含む）です。その他の商用の本番用途には商用ライセンスが必要です。各バージョンが初回の公開から 4 年後の変更日が起点で、その時点で Apache 2.0 に転換されます。
読み進めると、銀行が自社の Sovereign デプロイで Axyl を動かしており、これは別の生産用途に該当します。
これは批判ではありません。Rayls は外向けに、コアプラットフォームはオープンソースで、Axyl と Enygma は商用コンポーネントだと言っていました。BUSL に 4 年上乗せして Apache へ移行するのも、業界として成熟した一般的なやり方です。書き出したのは、「オープンソース」という言葉が流通の過程で“気軽に使われがち”だからであり、その境界がライセンスファイルにきちんと書かれているからです。
コードはどこから来たのか、リポジトリ自身が言っています
Axyl リポジトリの謝辞（attribution）セクションは、率直に言って珍しいほど正直です。コンセンサス部分の Rust ワークスペースは Telcoin Network から派生しており、Telcoin Network は Sui の Narwhal と Bullshark を土台にしています。その上で Rayls は大幅な再編と修正を行いました。Bullshark の実装は、Mysten Labs の Sui コードベースに由来する部分が多く、Apache 2.0 に基づきます。実行層は reth と alloy を使用します。LayerZero の OFT インターフェースは元の MIT ライセンスを保持しています。
“すべてを自社開発した”と主張するより、血統（来歴）をはっきり書く方が、エンジニアリングチームから信頼されやすいです。監査側は、この線に沿って上流の成熟度を確認できます。
どれが新しいのか、どれが継続なのか、どれが検証できなかったのか
今週新たに調べたもの: Axyl リポジトリ README の全内容（アーキテクチャ、役割、設定、ライセンス、謝辞を含む）。audits/README.md の 3 つのレポートの表と、コミット履歴圧縮に関する説明。doc/index.md のシステム全体概要。Axyl Performance Benchmarks ページのベンチマーク条件。公式ドキュメント Rayls Sovereign ページの What changed の 5 項目と、2 段階デプロイ設定。
前回の続きです。Cryptographic Trust Suite の鍵境界、そして Relayer は鍵を保有しない、という点は、先週 relayer とガバナンスサービスの 2 つのリポジトリのソースコードで確認済みです。この節では新たな証拠はありません。
私の推測: 単一ノードから委員会への変更の主な価値はスループットではなく運用のレジリエンスです。公開リポジトリ上で是正の証拠チェーンが辿れないのは、デューデリジェンスレベルでの実際の制約です。コードの血統をはっきり書くことはプラス材料です
シグナル。この 3 つの資料にはそのようには書かれていません。
検証できなかったもの: 私は、いかなる組織がこの設定を実際に運用していることを示す証拠を持っていません。本稿で述べているのは、すべて文書とコードに記載されている能力です。
再現パス: GitHub で raylsnetwork/axyl を検索し、リポジトリ直下の README と audits/README.md の 2 つのファイルがこの記事中の大部分の数字をカバーしています。公式ドキュメントは Rayls Sovereign と Axyl Performance Benchmarks の 2 ページを検索します。ブロック生成時間は、公連ブラウザの /api/v2/stats を参照すれば分かります。
