我は事前の約束の段階からRLSをステークしていました。公式ブログを読むのは習慣ですね。9月12日に公開された、可監査性について書かれたこの記事では、後半に6つの基準が挙げられており、「数学的に構成によって強制され、すべての条件が完全に満たされる」と述べています。この考え自体は私も同意しますが、「構成によって満たされる」というのは、確認できる主張であって、ただ信じるしかない主張ではありません。だから私は1週間かけて、この6つの条件をそれぞれ公開ソース、技術ドキュメント、そしてチェーン上のインターフェースの中から対応する根拠を探しました。ここで皆さんに共有します。
まず分類から話しますが、私はそれが「プライバシーか透明性か」といった議論の多くよりも有用だと思います。可監査性には3つの道があります。数学的強制——暗号学的な構成の中に書き込むこと。ハードウェアへの信頼——信頼できる実行環境の完全性に頼ること。方針によるアクセス制御——誰が何を見られるかは、ネットワーク運営側の設定で決まることです。
それに基づいて、組織レベルで監査可能性が担保される6つの基準を提示し、続けて数学的な強制が構成によってその6つすべてを満たす、と述べています。
言い逃れを増やさないため、固定したシナリオを置きます。銀行が中央銀行のデジタル通貨のパイロットに参加し、中央銀行の監査員がその銀行のネットワーク上の取引を閲覧する、というケースです。ブラジルの Drex がまさにこのシナリオで、Rayls がその中で実証を進めています。答えるべき問いは1つだけです。監査員が見えるものは、いったい何によって信頼できるのか。
1つ目と2つ目：選択的開示と範囲限定
この2つの着地点は同じもの：観測鍵です。
Rayls の GitHub は公開されています。relayer リポジトリの cryptography ディレクトリに mlkem.go があります。ここには、GenerateSalt が受信者の ML-KEM-768 観測公開鍵を使って封装共有鍵を生成し、RecoverSalt がローカルの ML-KEM-768 観測秘密鍵で封を解いて共有鍵を回復します。呼び出しているのは Go 標準ライブラリの NewEncapsulationKey768 と NewDecapsulationKey768 です。変数名は view public key と view secret key と書かれています。
つまり、観測鍵の暗号学的な土台は ML-KEM-768 であり、この点は根拠があります。
この主張の意味をもう一言だけ。8月30日の Rayls の「量子準備」に関する記事では、量子セキュアという言い方がパラメータのレベルまで書かれていないなら、それは主張ではなくラベルに過ぎない、と特に強調されていました。そして挙げられている例がまさに、ML-KEM-512 と ML-KEM-1024 は別物だというものです。その記事で、自分たちのアップグレードについては「ML-KEM に置き換えた」としか書いていませんでした。しかしコードには、768 と明記されています。これは欠陥ではありません。768 は NIST の公式パラメータセットであり、業界が企業デプロイに推奨するデフォルト値でもあります。つまり、以前はコードを読まないと分からなかったが、今はそのまま引用できる事実になっただけです。
区分が確定しているなら、乗り換えコストも計算できます。FIPS 203 はサイズを固定で書いています。768 のカプセル化公開鍵は1184バイト、暗号文は1088バイト、1024の2つはどちらも1568バイトです。
ポイントは頻度です。しかも鍵管理のドキュメントがこれも書いています。封装（カプセル化）は、各“ペアの参加者”がネットワーク構築時に1回だけ行われ、暗号文はプライベート・ネットワークのハブに保存されます。その後は、各メッセージに付くのは小さなタグ1つだけです。つまり取引量に比例して増えません。30の機関のネットワークならペアは435組で、2つの区分の差は約215KBです。仮に60の機関で1770組でも、その差は1MB未満で、しかも一度だけです。
この量は意味のないほど小さく、そしてそれが結論です。あるデプロイがより高い区分を必要とするなら、抵抗は帯域やストレージには出ず、単にコードを変更するだけです。汎用のポスト量子移行の議論では、パラメータ選択はしばしば性能のトレードオフですが、この層では違います。
この範囲はこの一条に限定されます。技術ドキュメントに残りの半分が追記されています。観測能力は、時間ウィンドウまたは口座ごとに制限できる、ということです。
第3条：可視性と権限の分離
技術ドキュメントの言い方はブログよりも強いです。支出鍵と観測鍵は数学的に互いに独立しており、一方から他方を導けません。セキュリティ審査の要約にも、観測権限と支出権限は暗号学によって分離されていて、設定によるものではない、とより直接的に書かれています。だから一度設定を間違えても、読み取り権限が書き込み権限に変わることはありません。
鍵管理のドキュメントは、私の思い込みを1点修正もしてくれました。機関側のすべての鍵素材は、Cryptographic Trust Suite というコンポーネントが統一的に扱い、機関自身の境界の内側で動作します。Relayer は鍵を一切保持せず、単に暗号化・復号を代行するだけです。監査員の読み取り権限は次の仕組みから生まれます。各機関が自分の観測鍵を運営者の公開鍵で暗号化し、さらに認証コードを付けてプライベート・ネットワークのハブに保存します。これは参加者の記録の一部として扱われ、監査サービスは起動時にそれを取り戻します。
ここには副産物としてのドキュメントが自分で示していることがあります。機関は、ハブ上でどの参加者レコードが存在するかを見られるため、何が自分にとって可読な状態に設定されているのかが分かります。可視性を付与するという行為自体が可視です。
ついでに、このページの3種類の鍵表も、私がコードで見た内容を裏付けています。署名鍵は secp256k1 上の ECDSA、観測鍵は ML-KEM、支払いに使う鍵は BN254 上の Baby JubJub。ドキュメントとソースは完全に一致しています。
4つ目：検証可能な正しさ
このブログはゼロ知識証明に依存しており、Rayls には Groth16 の証明生成と検証のための専用 gnark-api サービスがあります。
Enygma 取引のそのドキュメントには、普段は参照されない具体的なパラメータがいくつか載っています。匿名集合の規模は2または6で、つまり1回の送金はもう1件（または5件）の取引と一緒に束ねられ、観測者は誰が送信したのか判別できません。1回の crossTransfer は最大で5つのターゲットチェーンを指し、5つまで呼び出せるアクションを運びます。バッチの原子性は、プライベート・ネットワークのハブ上の Enygma コントラクトが保証します。まずバッチ全体の証明を検証し、どの到達先でも、証明の検証が通った場合にのみミント（発行）が行われます。
もうひとつ運用上のコスト。ドキュメントはかなり率直に書いてあります。バッチ処理、証明生成、ハブでの検証を合計すると数十秒のオーダーなので、その前提で計画すべきで、機関内取引のようなサブ秒級の最終性に合わせるべきではありません。検証可能な正しさは無料ではなく、その価格がこの数十秒です。
ただし、ここには別枠で取り上げる価値のある言い回しがあります。というのも、それが4つの資料に関わっているからです。
技術ドキュメントの説明は、ブログよりも硬いです。Pedersen のコミットメントについて「値を隠し、同時にコミット主体をその値に結び付けることで、事後に変更できないようにする」と述べています。結び付け性を“成立の性質”として陳述しています。8月の量子記事では、この項目を「処理不要」としており、つまり元々量子耐性があるという意味です。コードの enygma_math.go では、それが BabyJubJub 曲線上の2つの独立した生成元を使って、v×G に r×H を足す（標準で正しい Pedersen 構成である）ことが示されています。Rayls の2本の学術論文（IACR 番号 2025/1639 と 2025/1638）では、この設計全体に使われている語が quantum-private、つまり「量子プライバシー」で、説明としては、量子の対手は取引の支払人・受取人・金額を推測できないということです。これは純粋に“秘匿性”に関する主張です。
私の読みでは、4つの資料のうち、論文だけが用語を正確に使っています。BabyJubJub は BN254 のスカラー体上に構築されているので、秘匿性は量子対手にも成立します。これは論文が主張している部分です。結び付け性は離散対数に依存しており、これも論文が主張していない部分です。
ある組織が、対抗的な監査に耐えうるコンプライアンス体制を「証明」したいのなら、「量子の対手は自分の残高を見られない」と「量子の対手は偽の残高をでっち上げられない」は別の話です。そしてそれらがドキュメントやブログでは一つにまとめて書かれてしまっています。論文はその合体を犯していません。
第5条：撤回可能
この件はとても長く調べました。Rayls のドキュメントには「プライベート・ネットワーク設計オプション」と題する1ページがあり、そこで答えが見つかりました。ただし、それはブログが言っていることと同じではなく、しかも私はそちらの方がより興味深いと思っています。
監査員は運営側が指名するロールで、並び立つのは参加者側や発行者側です。ポイントは、監査員の可視性がスイッチではなく「区分」で決まること。このドキュメントは3つの実例で区分を描き出しています。
中央銀行のデジタル通貨ネットワークのその区分では、監査員はノード間の取引を復号できます。トークン化された資産取引プラットフォームの区分では、監査員は各ノードがハブに公開する Pedersen のコミットメントを検証することで監視します。ドキュメントには監査員が暗号化された取引ペイロードデータに直接アクセスする権限はなく、証明のみを見て内容は見ないと明記されています。DAO運営のNFTマーケットの区分が最も極端で、監査ロールはパブリックチェーンの証明ベリファイアが担い、デフォルトではアクセス権がゼロです。証明の検証で詐欺が示された場合に限って、その取引についてのみ復号が有効化されます。
3つの区分を並べると、監査員のブラウザのところにある「復号の程度は構築段階で設定可能」という文が、そのまま実装として落ちています。
ブログのあの一段に戻りましょう。ブログでは可視性は回収（取り消し）可能で、回収は暗号学的に強制される、と言っています。ドキュメントが提示する設計は別です。可視性はネットワーク構築の時点で区分ごとに設定され、事後に回収されるのではありません。どちらも監査員を制限します。一つは事前の制約、もう一つは事後の撤回です。
統治層の取り消し手段は確かにあります。ロールは更新可能で、メンバーの状態はアクティブ／凍結／停止と分かれます。凍結は、運営側が ParticipantStorage の統治（ガバナンス）コントラクトを通じて実行します。ただし、すでに監査員が取得した可視性を取り戻して無効化する、暗号学的な強制を伴う実装については、私は記述を見つけられませんでした。この問題が具体的になる細部があります。ドキュメントによると、監査員は新しいノードが参加するたびに1回、Diffie-Hellman の鍵交換を受け取り、アクセス能力は鍵素材として引き渡されます。ロールを外せば今後の付与は止められますが、すでに渡された鍵素材を無効化できるかどうかは、まだ調べています。
第6条：永続性
この一条は第5条と逆です。ブログは自分の言い分を控えめに言い過ぎています。
それは「永続性は鍵管理に属し、解決可能だ」と言っています。読んでいると空白のように見えます。でも、鍵管理のドキュメントはこの「解決可能」を、具体的な手順にまで落とし込んでいます。鍵の保管は、組織がすでに持っているものに差し替え可能です。AWS KMS、Google Cloud KMS、Azure Key Vault、ローカルHSM。開発環境だけがローカルファイルを使います。静的には封筒（エンベロープ）暗号を使い、永続化されるのは鍵素材ではなく暗号文です。
最重要なのはこの一文です。なぜなら、毎回の加減算（暗号処理）が機関自身の鍵管理サービスを経由するからです。これらのサービスが元々作っている監査トレースは、Rayls の鍵操作を覆い隠すのではなく、機関自身で他のものを運用して出てくる監査と同じように“上書き”されます。ドキュメントがコンプライアンス部門に出した結論は「これのために新しい監査面を構築する必要はない」です。これが永続性に求められているものです。監査トレースは機関自身の仕組みに紐づいており、どこかのベンダの独自ログに依存していません。
ローテーションについてもかなり細かく書かれています。各チェーンには複数の署名鍵を持てて、利用状況に応じてローテーションします。各鍵ごとに nonce を個別に追跡し、処理待ちの取引に署名済みの鍵は、その取引の決済が完了するまで有効に保たれます。これが解決しているのは、ローテーションでいちばん事故が起きやすい“継ぎ目”です。
ただし境界が1つあります。ローテーションを説明している章は署名鍵のことを指しており、このページ群では観測鍵のローテーションは見当たりませんでした。一方で、永続性が気にしているのは「何年も経った後に監査トレースが読めるかどうか」で、それは観測鍵側により強く依存します。
監査員が実際に使っているツール
これまでずっと暗号を読んでいましたが、監査員が実際に腰を据えて使うのはひとつのツールです。ドキュメントには、プライベート・ネットワークの監査員ブラウザは監査員だけがアクセスでき、運営者や他の参加者はアクセスできないことが明記されています。クロスチェーン取引の復号後の俯瞰（リプレイ）ビューを提供します。
範囲は限定されています。プライベート・ネットワークのハブに記録されるクロスチェーン取引だけを対象にし、ある特定の機関自身の Sovereign 台帳の内部で行われる取引については、その取引の監査員はアクセスできません。つまり監査の可視面は機関間であって、機関内部ではありません。
では、完全に検証できる実例はあるのか
あります。しかも1つだけ。というのも、アーキテクチャ自体が大部分のものが見えないことを決めているからです。
公式ドキュメントでは理由が説明されています。Enygma 取引は各機関の Sovereign 台帳から発出されます。各機関は自分のその台帳に対するブラウザをそれぞれ独自にデプロイして監視し、クロスチェーン部分はプライベート・ネットワークのハブ上で監査員ブラウザが閲覧します。機関の活動は設計上公チェーン上に存在しないため、公チェーンのブラウザでは Enygma 取引を見つけられません。これは欠落ではなく、3層アーキテクチャの必然的な結果です。
ただし Parfin のロック・コントラクトはパブリックチェーン上にあり、しかもそれは「数学的強制」の完全なサンプルそのものです。
アドレス 0x1463889D で始まるもの、コントラクト名 RlsTokenLock。ソースは検証済みで、プロキシ契約ではありません。これは、コードを読めてかつ現在の状態も追える数少ない対象であることを意味します。私は両側を突き合わせました。
コンストラクタで totalAmount は 1,070,493,535 RLS と宣言されています。現在コントラクトが実際に保有している RLS も 1,070,493,535 です。1wei も差がなく、完全に満額です。
解錠スケジュールの方が、もっと語る価値があります。コンストラクタに48個のタイムスタンプがあり、私は全部デコードしました。最初の区分は2027年12月1日、その後は毎月1日が各区分のタイミング。最後の区分は2031年11月1日で、期間は約3.92年、各区分あたり約2230万RLSです。以前の公開資料ではロックは2027年12月までだと強調されており、それは第1区分として正確でした。しかしコンストラクタが示す完全な全体像では、第1区分の後、約4年近くが月次でリリースされます。
コントラクト自身の注釈に、設計意図がとても率直に書かれています。アップグレード不可。デプロイ時の条項は永遠に条項であり、事前の解錠もないので、どんな鍵も満了日より前に1段上へ移動することはできません。私はこの2点をコードで一つずつ突き合わせました。スケジュールは constructor に書かれていて setter はありません。さらに、コントラクトは確かにプロキシではありません。
これが「数学的強制」の、私が完全に検証できる実例での姿です。主張はコードと一致しており、しかもコードの方が説明よりも具体的です。6つの基準のうち、私がソースとドキュメントの痕跡としてしか辿れなかったものが、ここでは最後まで見通せます。
さらに2か所での外部参照
ブログがTEEについて語るとき、Intel SGX が隔離保証を破ると記録されている既知の脆弱性を持っていたと言っています。この一文は正しいですが、ブログは自分の論点を控えめに言い過ぎています。隔離系には Foreshadow、Plundervolt、EPIC Leak、SmashEx があり、番号はそれぞれ CVE-2018-3615、CVE-2019-11157、CVE-2022-21233、CVE-2021-0186、CVE-2021-33767 です。真に致命的なのは 2020 年の SGAxe で、CVE-2020-0549 を用いて Intel のプロダクション環境にある認証エンクレーブから認証鍵そのものを抽出し、その後 Intel 自社の認証サービスが正当と判断する任意の宣言を発行できるようになります。
ブログの論証は、TEE の担保はハードウェアが提示する証明によって与えられるという話です。一方で SGAxe が攻破したのは、まさにその証明を出す段階です。最も深刻な失敗はデータが盗まれることではなく、担保そのものが偽造されることでした。公平に言えば、これらはマイクロコード更新と TCB recovery によってすでに修復されています。今日の SGX は2018年のSGXではありません。正確に言えば、ハードウェアの信頼の根（信頼起点）には、ローリングな脆弱性面があるということです。
もう一か所は、BIS の Project Agora が同じアーキテクチャに収束していくと言っているところです。私は BIS の 5月27日のプロトタイプ報告を読み返しましたが、トポロジとしては確かに似ています。二層構造で、共有台帳と各管轄ごとの独立台帳があります。ただし Agora の境界は“管轄権”で切っており、報告書には管轄台帳の内部アクセス制御がどのように実現されるかが説明されていません。そのため、収束が信頼モデルの層まで拡張されるのかどうかは、現時点の公開資料からは分かりません。
何が確定で、何が私の推測か
確認できたこと：ML-KEM-768 は観測鍵に使われており、relayer の cryptography/mlkem.go を参照。Pedersen は BabyJubJub の生成元を双方向（双生成元）で構成しており、eny gma_math.go を参照。監査の秘密鍵は relayer が暗号化して配布し、ガバナンスサービスの cryptography/service.go を参照。支出鍵と観測鍵の数学は独立しており、観測範囲は時間と口座で限定でき、監査員ブラウザはクロスチェーン取引のみを対象にし、復号の程度は構築段階で設定可能である――いずれも公式の技術ドキュメントに記載があります。Cryptographic Trust Suite が鍵を統一的に保持し、Relayer は鍵を保持しない。鍵の保管は KMS または HSM へ差し替え可能。静的に封筒（エンベロープ）暗号を使い、永続化されるのは鍵素材ではなく暗号文。監査ログ（機関が持つ鍵管理サービスが出すログ）こそが、鍵操作の監査トレースです。署名鍵は利用状況に応じてローテーションし、署名済みで決済待ちの取引の鍵は、その決済が完了するまで有効。封装は参加者ごとに、新規に構築するネットワークの段階で一度だけ完了。匿名集合の規模は2または6。1回の crossTransfer は最大で5つのターゲットチェーン。最終性は数十秒オーダー。参加者の凍結は、運営者が統治コントラクト ParticipantStorage により実行。いずれも公式技術ドキュメント。RlsTokenLock の検証状態、非代理属性、48区分の時間割、申告金額と実際の残高は、いずれも 2026年9月12日に公開ブラウザのインターフェース経由で読み取れます。SGX 各脆弱性番号は CVE 記録と SGAxe 論文から。Agorá の構造とデータは BIS の公開資料から。
私の推測：4つの資料のうち、Pedersen について語っている用語が正確なのは論文だけです。「境界は数学的な強制によって規定される」という記述は、分配ではなく実行の話です。SGAxe は隔離系の脆弱性よりも、ブログの主張を支える材料になっています。この3つの資料には、そのようには書かれていません。
検証できなかったもの：第5条の事後取り戻し（回収）メカニズム。私は鍵管理、監査員ブラウザ、Enygma の暗号学的基礎、参加者の凍結、プライベート・ネットワークの設計オプション、プライベート・ネットワーク・ハブの6つのドキュメントを調べ、加えて relayer とガバナンスサービスの2つのコードリポジトリも確認しました。可視性の3段階設定、付与メカニズム、参加者の凍結と停止については見つかりましたが、付与済みの可視性を回収し、かつ暗号学的な強制で無効化する実装については見つかりませんでした。観測鍵の長期ローテーションについても同様で、ローテーションを説明している章は署名鍵の話でした。
最後に、技術とは関係ないことを1つ
この文章を書いた週と同じタイミングで、公式が「ステーキング区分の55%を9月15日まで延長する」と発表し、ステーキング・メカニズムの調整期間中も早期の支持者がこの分のリターンを引き続き得られるようにする、と述べました。その後のステーキングや、より広いトークン経済（バーンを含む）に関するアップデートは別途公表されるとのことです。
私は事前コミットの段階からステーキングしており、3か月間フルに参加しました。もともとの区分は9月9日で終了する予定でしたが、その数日、画面上で上限が使い切られていて追加できず、フロントエンドの不具合だと一度思いました。いま見ると、仕組みが調整されているようです。
ここからは私の個人的な見解で、事実の断定ではありません。仕組みを変えるウィンドウの期間中は、延長ではなく直接切断するのではなく選択し、かつ日付を明確に書くのは誠意のあるやり方だと思います。仕組み調整の期間でいちばん起きやすいのは曖昧な表現で、確定した日付を出せば、期限が来たら約束どおり決着するか、もう一度説明する必要が出ます。
これは単なる具体的な出来事であり、いかなる長期的な取り決めについても判断を構成しません。私はリターンを予測せず、また誰かがそれを根拠に意思決定することも勧めません。
参考出典：Rayls公式ブログ “Auditability without surveillance: why mathematical enforcement beats trusting the code”、2026年9月12日。Rayls公式技術ドキュメントの Enygma 暗号学的基礎と、プライベート・ネットワーク監査員ブラウザの2ページ。GitHub 組織 raylsnetwork の rayls-sovereign-relayer と rayls-sovereign-pnh-governance の各リポジトリ。Raylsパブリックチェーンのエクスプローラ explorer.rayls.com の addresses と smart-contracts インターフェース（取得日時：2026年9月12日）。NIST FIPS 203。CVE 記録 2018-3615、2019-11157、2020-0549、2021-0186、2021-33767、2022-21233 と SGAxe 論文。BIS Project Agorá のプロトタイプ報告 othp110。IACR の暗号学電子アーカイブ 2025/1638 と 2025/1639。Rayls公式 X アカウントの 2026年9月12日公告。
