Rayls の公式サイトのサプライヤー比較表には9行あり、私は「プライバシー」という項目を選びました。理由はとても簡単で、プライバシーは重要であり、そして Besu はオープンソースなので、そのドキュメントとコードを自分で調べられるからです。

比較表では、Rayls は「分離型プライバシー」と「暗号学的プライバシー」の2行にチェックを入れていますが、Besu は前者の1行にしかチェックを入れていません。相手方の独自ドキュメントで確認するつもりだったので、私はまず Besu のドキュメントを調べ、それからコードをダウンロードして数えました。

結論は「Besu はダメ」ではありません。真の違いは、これら2社がプライバシーを別のレイヤーに置いていること、そして Besu が移行(引き上げ)したタイミングが、多くの人が思っているよりも早いことです。

Besu 側:ドキュメントからコードへ

Besu 公式ドキュメントでは、プライバシー関連ページの上部に今は同じバナーが掛かっている。「Tessera に基づくプライバシー機能は、24.12.0 以降 非推奨」。

本当の削除は 25.6.0 で起きた。このバージョンのリリースノートでは、それを破壊的変更として挙げている。Tessera のプライバシー機能を削除する、という内容で番号は #8369。同じバッチで、オンチェーンの権限管理も削除された。

私が自分で確認した部分はこうだ。まず、3 つのバージョン番号で同じファイルを取り出す。25.4.0 では PrivateTransaction.java と Enclave.java がどちらも 200 を返し、25.6.0 と 26.2.0 はどちらも 404。次にインターフェースを見る。25.4.0 の RpcMethod 列挙には、priv_、eea_、privx_ で始まるメソッドが 23 個あるが、26.2.0 の同じファイルには 1 つもない。コマンドラインも同様で、25.4.0 には --privacy で始まる起動パラメータが 12 個あるが、26.2.0 の BesuCommand.java では privacy という語を探しても見つからない。規模として、25.4.0 のプライバシーと enclave に関連する非テストの Java ファイルは 153 本、合計 17,875 行。


Besu はなぜこんなことをするのか

この段落は必ず書かないと、言いがかりになってしまう。

Besu のメンテナーが 2024 年 9 月 24 日の公告で挙げた理由はこうだ。コードベースが、巨大なスイスアーミーナイフになってしまった。Tessera のような機能は、本来それが解決すべきユースケースでは性能が足りない。一方でアプリケーション層には、成熟した、そして新しい提案がすでにある。公告ではさらに、EVM 向けのプログラマブルなオープンソースのプライバシープロジェクトを LF Decentralized Trust 実験室へ近日中に提出するとも述べている。

そのプロジェクトは Paladin。すでに実験室から LF Decentralized Trust の正式プロジェクトへ昇格した。Apache 2.0 のライセンスで、ゼロ知識証明または発行者側の事前検証の 2 方式でプライバシー・トークンを実装し、あらゆる EVM チェーンの上で動く。

だから正確に言うと:Besu はプライバシーを捨てたのではなく、プライバシーをクライアントからアプリケーション層へ移した。

2 通りの置き方、それぞれの値段

Rayls のやり方は、プライバシーをプロトコルに組み込むことだ。Enygma は AES-256 で取引内容を暗号化し、Pedersen で残高をコミットし、Groth16 でこの帳尻が正しいことを証明する。通常のトランザクション経路を使う。

この道のコストは定量化できる。前回は証明生成について実測した。単一コア環境で 6 人匿名セットなら 1 取引あたり 1.96 秒。今日は別件も計ってみた。証明そのものは 164 バイトしかない。2 人枠も 6 人枠と同じ大きさだ。Groth16 の証明が固定長だからだ。ただし、証明と一緒に公開されるデータは固定長ではない。2 人枠は 588 バイト、6 人枠は 1,612 バイト。

この数字は、ついでによくある言い方を訂正するものでもある。プライベート環境から出るのは「1 つの証明」だけではない。暗号化されたペイロード、証明、そして必要な公開データもある。内容は隠されたままだが、システムは引き続き検証と清算ができる。

ついでに、比較表の別の行の話。Rayls は「隔離式プライバシー」にチェックしている。根拠はデプロイ構造だ。各機関の Sovereign 台帳が自分自身の境界内に収まり、公式の説明では、プライベートデータはそのインスタンスから外に出ない。取引 1 件を成立させるのに必要な最小限のペイロードだけが外部ネットワークへ送られる。だからこの 2 行は Rayls にとっては 2 層の関係で、機関間はデプロイの分離で、機関をまたぐ清算は暗号学で実現する。私はこの点について、公式サイトとドキュメントだけを見ており、実際のデプロイはしていない。

ライセンス側も明示しておく必要がある。Rayls のオープンスタックは Apache 2.0 だが、Enygma と Axyl の 2 つのモジュールは BUSL 1.1。テストは無料、本番は認可が必要で、各バージョンのリリースから 4 年後に自動で Apache 2.0 へ移行する。Paladin は Apache 2.0。

これはある機関にとって何を意味するのか

ある機関のプライベートネットワークが Besu 上で動いていて、priv_ または eea_ インターフェースを使っているなら、25.6.0 へのこの一歩はアップグレードではなく移行。23 個のインターフェースと 12 個の起動パラメータが同時に消え、プライバシーロジックはアプリケーション層へ移して書き直す必要がある。移さなければ、25.4 系にとどまるしかなく、その後のすべての性能改善やセキュリティ修正はあなたとは無関係になる。

Rayls を選ぶなら、プライバシーと台帳は同じ一式の中にある。バージョン、監査、サポートが一つのラインでつながっていて、自分で組み合わせる必要がない。代償は、機密取引を 1 件ごとに先に証明を計算すること。匿名セットが大きいほど公開データは増え、さらに Enygma 側の部分は BUSL のライセンスに従う必要がある。

あの「より多い」がどれくらい多いのかを見積もってみる。以下は私の計算だ。6 人の機密送金 1 件につき、証明と公開データの合計は約 1,776 バイト。英国 CHAPS 2025 年の日平均 210,483 件という規模に当てはめると、1 日あたり約 374 MB、年間で約 136 GB。機関のストレージにとっては大したことではないが、送信数に比例して増える固定のオーバーヘッドだ。そして匿名セットは調整可能で、2 人枠に下げれば各取引は 752 バイトにまでなる。ここでは、1 取引につき 1 つの証明だけが発生すると仮定し、入金・出金・DvP のような回路は数えていない。

この行から抽出できる一般的な問題はわずか三つの字:どの層か。ベンダーのプライバシー機能はどの層にあり、誰がメンテしていて、そのライフサイクルはどうなっていて、台帳がそれと一体になっているのか。Besu のこの 2 年の変化が示すのは、答えは変わるということ、しかも変化は破壊的だということ。


確認したこと、推測したこと

確認したこと:異なるバージョンでのファイルの有無、インターフェースと起動パラメータの数、公式公告とリリースノートの内容、証明と公開データのバイト数、前回の証明にかかった時間。これらは、スクリーンショットにあるコマンドをそのまま打ち直せば再現できる。

推断的部分:アップグレードによって既存のプライバシー業務が中断される、これはインターフェースが消えたことから推測した。私は本当に、25.4 のプライベートネットワークを 25.6 に上げて試したわけではない。Paladin が特定の機関の具体的なケースを受け止められるかどうかも、評価していない。

範囲としては、送金回路とプライバシーの行だけを見た。Besu のユーザーは、自分でフォークをメンテしたりプラグインを書いたりできる。これはそのライセンスが許している。比較表の残り 8 行は触っていない。


私の見解

比較表は静的な図で、オープンソースプロジェクトの能力は動く。この行は 2 年の間に「クライアント内蔵」から「アプリケーション層の自己対応」へ変わったのに、表はチェックひとつしか表示できない。

なので私は、こういう表をチェックリストの起点として見る方が好きだ。各行について相手のリポジトリで、現在のバージョンが何かを一度確認する。このとき使った時間は 1 時間未満で、コマンドはスクリーンショットに載せてある。次に Rayls がこの表を更新するときに見るべきは、Besu の欄にバージョン説明を追加したかどうかだ。

参考:Rayls 公式サイトの Sovereign 製品ページと、サプライヤー比較表。Besu 公式ドキュメントのプライバシー章にある、非推奨を示すバナー。Besu 25.6.0 リリースノート、項目 #8369。LF Decentralized Trust の 2024 年 9 月 24 日公告(Sunsetting Tessera and Simplifying Besu)と Paladin プロジェクト公告。hyperledger/besu リポジトリの 25.4.0、25.6.0、26.2.0 の 3 つのタグ(2026 年 9 月 24 日に読み取り)。raylsnetwork/rayls-sovereign-gnark-api のコミット 67c4c26(ローカルで実測)。

#Rayls $RLS