Stellar「Bell（Protocol 30）」とは？量子耐性の範囲と11月アップグレード対応

Stellarの「Bell（Protocol 30）」は、Sorobanで耐量子署名を検証する機能、入金先を識別しやすくするWアドレス、台帳終了時刻のミリ秒化をまとめた次期プロトコルです。事業者側が未対応のまま有効化されると、新しいXDR（Stellarのデータ記述形式）を読めず、入金反映や残高更新が止まる可能性があります。一方、一般利用者は通常、XLMの移動や秘密鍵の変更をする必要はありません。

BellだけでStellar全体が耐量子化するわけではなく、対応ソフトウェアの公開とネットワーク投票による有効化も別です。本稿は3変更の意味と、2026年11月の投票予定までに必要な行動を立場別に整理します。XLMの価格や投資成果を予測する記事ではありません。

背景から確認したい場合は、スマートコントラクトの仕組みとブロックチェーンの耐量子移行も参照してください。

StellarのBell（Protocol 30）とは

BellはStellarのプロトコルを30へ進めるアップグレード名です。中心となる仕様はCAP-84、CAP-87、CAP-88の3本で、それぞれアドレス、署名検証、時刻表現という異なる層を変更します。Stellar Core v30.0.0は2026年10月16日に公開されましたが、公開された実装を入れただけで全ネットワークの規則が即座に変わるわけではありません。

Bellを構成する3つの変更

CAPは「Core Advancement Proposal」の略で、Stellarの中核プロトコルを変える提案文書です。Bellを短く整理すると、CAP-87はSorobanコントラクトがML-DSA署名を検証できるようにし、CAP-84はコントラクトIDへ顧客別などの64ビットIDを組み合わせたWアドレスを導入し、CAP-88は台帳終了時刻をミリ秒精度で表現します。

仕様	変更点	主に影響する対象
CAP-87	ML-DSA-44・65・87の署名検証	Soroban開発者、耐量子認証を設計するサービス
CAP-84	W接頭辞の多重化コントラクトアドレス	ウォレット、取引所、ランプ、エクスプローラー
CAP-88	台帳終了時刻のミリ秒精度化	XDRを読むデータ基盤、SDK、インデクサー

3つは同じProtocol 30に含まれますが、目的は一つではありません。「量子対策のアップグレード」とだけ覚えると、WアドレスやXDR移行の実務を見落とします。反対に、一般の利用者が3仕様すべてを自分で実装する必要もありません。利用中のウォレットや取引所が対応版を提供するかを確認するのが基本です。

Core v30.0.0公開だけでは有効化されない理由

プロトコル変更には、仕様の提案・審査、実装、ソフトウェア配布、ネットワーク参加者による更新、バリデーターの投票という段階があります。Core v30.0.0はBellを実装するソフトウェアですが、ネットワークがProtocol 30を選ぶまでは、従来の規則で動く局面があります。

この区別は障害を避けるうえで重要です。「リリース済み」を「メインネット有効化済み」と読み替えると、まだ受け付けられないデータ形式を本番へ送ったり、対応期限を誤ったりします。逆に運用者が更新を先送りすると、投票後の新しいXDRやピア接続条件に追従できない恐れがあります。最新状態は公式アップグレードガイドとネットワーク別のソフトウェア版一覧で照合してください。

CAP-87：Sorobanに追加されるML-DSA署名検証

ML-DSAは、格子問題を基礎にしたデジタル署名方式です。NISTはFIPS 204としてML-DSAを標準化し、大規模な量子コンピューターを持つ攻撃者も想定した署名方式として位置付けています。CAP-87はこの方式の署名をSorobanホスト側で検証する関数を追加します。

ML-DSA-44・65・87で検証できるもの

CAP-87はML-DSA-44、ML-DSA-65、ML-DSA-87という3つのパラメータセットを扱います。コントラクトは公開鍵、署名、検証対象のメッセージを使って、署名が条件を満たすかを確認できます。署名者本人しか知り得ない秘密鍵をコントラクトへ渡す仕組みではなく、署名生成もホスト関数の役割ではありません。

たとえば、コントラクトウォレットや認証ルールがML-DSAの公開鍵を登録し、外部で生成した署名をコントラクト上で確かめる構成が考えられます。ただし、関数が使えることと、安全なウォレット設計が完成することは別です。鍵の生成・保管、復旧、鍵交換、複数署名、古い方式からの移行は、アプリケーション側で設計しなければなりません。

3つのパラメータセットと負荷の違い

44・65・87は、同じものに別名を付けたのではありません。FIPS 204では安全性の区分が異なり、一般に高い区分ほど公開鍵や署名、検証処理に必要な資源も大きくなります。そのため、数字の大きい方式を無条件に選ぶのではなく、保護対象、互換性、保存容量、通信量、コントラクト実行費用を一緒に評価します。

Sorobanでは計算や読み書きが資源として計測されます。ML-DSAは既存のEd25519検証より計算・データ負荷が大きいという設計上の論点があり、署名を何件まとめるか、入力をどこに保持するか、失敗時にどの費用が発生するかをテストネットで測る必要があります。概念上の耐量子性だけで本番採用を決めず、実際の取引サイズと予算内で動くことを確認してください。

既存コントラクトと新規実装への影響

既存コントラクトは、ML-DSAを使わないからといって直ちに動かなくなるわけではありません。新しい検証関数を利用したいコントラクトは、Protocol 30対応のSDKやツールチェーンを使って再ビルドし、テストする必要があります。従来機能だけを使うコントラクトでも、依存ライブラリと実行環境の互換性確認は欠かせません。

新規実装では「将来の量子リスクへ備える」目的と、「今の利用者が鍵を安全に扱える」目的を分けて考えます。署名アルゴリズムを追加しても、フィッシング、端末侵害、誤送金、管理者鍵の集中といった現在の危険が消えるわけではありません。複数方式を併用するなら、どの署名条件で資産を動かせるかを明文化し、片方の方式が迂回路にならないかも確認します。

BellでStellar全体が耐量子化するわけではない

CAP-87の範囲を、対象・対象外・将来計画に分けると次の通りです。「耐量子」という言葉だけで、既存アカウントやXLMが自動移行すると受け取らないでください。

区分	Bellでの扱い	読者の判断
対象	SorobanコントラクトがML-DSA-44・65・87署名を検証する機能	使う開発者が対応鍵、署名生成、認可条件を実装する
対象外	通常取引のEd25519署名、既存Gアドレスの自動変換、鍵管理全般	一般利用者はBellを理由に資産や秘密鍵を移さない
将来計画	全アカウントへのネイティブな耐量子署名者追加	2027年末までの計画であり、実装・採択・有効化の保証ではない

ML-DSAを使っても、フィッシング、端末侵害、誤送金、管理者鍵の集中、実装不具合が消えるわけではありません。鍵の生成・保管・復旧や認可設計は別に必要です。一般利用者は秘密鍵の安全な管理を守り、アップグレードを口実に秘密鍵やリカバリーフレーズを求める案内には応じないでください。

要点は、Bellがコントラクト向けの検証手段を増やす一方、通常取引のEd25519は継続することです。より広い移行は別の仕様・実装・投票を待つ必要があります。

CAP-84：Wアドレスでコントラクト入金を識別する

CAP-84は、多重化コントラクトアドレスを導入します。文字列表現はWで始まるため、本稿ではWアドレスと呼びます。目的は、取引所やランプなどが共有コントラクトを入金先として使う際に、顧客や注文を識別する情報を標準化することです。

W接頭辞と多重化コントラクトアドレスの構造

Wアドレスは、32バイトのコントラクトIDと64ビットの多重化IDを組み合わせます。コントラクトそのものを指すC接頭辞のアドレスに、追加の識別番号を持たせるイメージです。Stellarの識別子を文字列へ変換するStrkeyの規則では、既存のG、C、Mなどと区別できるW接頭辞が割り当てられます。

64ビットIDは秘密情報ではありません。台帳上の処理や入金照合に使う識別子であり、パスワードや認証コードを埋め込む場所ではありません。また、W文字列を単に長いCアドレスとして切り詰めたり、大文字小文字を独自変換したりすると、検査に失敗するか別の送付先として扱う危険があります。公式のエンコード・デコード実装を使い、チェックサムを含めて検証します。

共有コントラクトで顧客別IDを扱う利点

一つの入金コントラクトを多くの顧客が共有すると、サービス側は「どの入金が誰の残高か」を特定する必要があります。従来はメモ、別の呼び出し引数、顧客ごとのアドレス、サービス独自の対応表などで補ってきました。Wアドレスなら、コントラクトIDと顧客別IDを一つの標準的な宛先表現として渡せます。

利用者にとっては、サービスが提示した宛先をそのままウォレットへ入力でき、事業者にとっては受取コントラクトと照合IDを一緒に解釈できます。ただし、UIがWアドレスを途中までしか表示しない、DBの列長が足りない、QRコード生成が古い形式しか受けない、バリデーションがC接頭辞だけを許可するといった箇所が残れば、標準化の利点を得られません。

また、多重化IDがあるからといって、誤った顧客IDへの入金を自動で取り消せるわけではありません。サービスは未登録ID、重複ID、入金額不足、資産種別の違いをどう扱うかを決め、利用者向けの復旧窓口も用意する必要があります。

利用できる操作と利用できない操作

CAP-84の中心的な適用先はStellar Asset Contract（SAC）のtransferです。議論段階で検討されたすべての操作へ一律に拡張されたわけではなく、mintやtransfer_fromなどで同じようにWアドレスを使えるとは限りません。操作ごとの引数型と仕様を確認してください。

ここで「アドレスとして解読できる」と「その操作がWアドレスを受理する」を分ける必要があります。ウォレットが文字列を表示できても、送金経路の途中にあるSDK、RPC、コントラクト、監視基盤が対象型を扱えなければ処理は完了しません。導入試験では、入力から署名、送信、イベント取得、台帳反映、顧客残高への計上までを一続きで確認します。

CAP-88：台帳終了時刻がミリ秒精度になる

CAP-88は、台帳が閉じた時刻をミリ秒精度で表せるようにします。Stellarでは台帳の進行が速くなり、同じ秒の中で複数の台帳が閉じる場面を区別する必要が高まりました。秒だけの時刻では順序を十分に表せないため、新しいXDR型で精度を上げます。

ミリ秒精度になるデータと新XDR型

XDRは、Stellarが取引や台帳データを一定の形式で表すための仕組みです。CAP-88では台帳終了時刻を表す新しいunion型が導入され、Protocol 30への移行直後から新しいarmを扱う必要があります。古いXDR定義しか持たないデコーダーは、未知のarmに遭遇すると復号に失敗する可能性があります。

影響を受けやすいのは、SDKを通さず生XDRを読むインデクサー、データウェアハウスへの取り込み、監査ツール、エクスプローラー、履歴アーカイブ解析です。アプリケーションが時刻を整数としてDBへ格納している場合、単位、桁数、型の上限、APIでのシリアライズ、JavaScriptなどでの数値精度も確認します。値を読めるだけでなく、「秒」と「ミリ秒」を取り違えない命名が必要です。

秒単位のまま維持される時刻項目

取引のtime bounds、claimable balanceに関する時刻、Sorobanのledger_timestampは引き続き秒単位です。したがって、台帳終了時刻がミリ秒になったことを理由に、これらの値へ1000を掛けて送ると誤った期限になります。

システム内に複数の時刻表現が共存するため、変数名をtimestampだけで済ませず、close_time_ms、ledger_timestamp_secのように単位を明示すると事故を減らせます。API仕様書、DBスキーマ、監視グラフ、ログにも単位を記載し、変換処理を一か所へ集約するのが安全です。

同じ秒に複数台帳が存在する実装上の注意

秒精度の値だけで台帳を一意に並べる実装は見直しが必要です。同じ秒に閉じた台帳が複数あれば、秒のタイムスタンプだけでは順序を決められません。台帳シーケンス番号を主な順序キーとし、ミリ秒時刻は観測や表示に利用するなど、用途を分けます。

「次の台帳は必ず1秒後」という前提も成立しません。差分計算、レート制限、ローソク足生成、遅延監視、重複排除、カーソル処理が時刻だけに依存していないかを確認してください。境界試験では、Protocol 29最後の台帳とProtocol 30最初の台帳、同じ秒に複数台帳があるケース、再同期で過去データを読み直すケースを含めます。

ウォレット・取引所・データ基盤に必要な対応

実務では「SDKを最新版へ上げた」で終わらせず、データが通る経路全体を点検します。Wアドレスは利用者入力からDB、送金、イベント解析まで影響し、CAP-88は台帳の取り込みからAPI出力まで影響します。外部サービスとの境界も含めた結合試験が必要です。

優先度	まず完了すること
投票前に必須	Protocol 30対応XDRで台帳を復号し、Wアドレスを入力から入出金照合まで通す
該当機能を使う場合	Wアドレスの64ビットID、SAC transfer、ミリ秒時刻を扱う経路を試す
推奨	再取り込み、未登録入金、ロールバック、利用者通知を訓練する

Wアドレスの入力・表示・保存・送金経路を点検する

• 入力：W接頭辞、長さ、チェックサムを公式仕様に従って検証する。
• 表示：省略表示だけで確認させず、コピー時は完全な文字列を保持する。
• 保存：DB列長、索引、正規化、ログのマスキング規則を見直す。
• 送金：SAC transferで使う経路と、未対応操作へ渡さない制御を試す。
• 照合：64ビットIDを符号付きに誤変換せず、未登録・重複時の扱いを決める。

QRコード、アドレス帳、CSV入出力、モバイルアプリのディープリンク、問い合わせ画面も忘れやすい箇所です。エクスプローラーはWアドレスをコントラクト部分とIDへ解釈しつつ、元の文字列を再現できる必要があります。取引所は入金検知だけでなく、出金先としてWアドレスを受け付けるか、未対応なら明確に拒否するかを決めます。

旧XDRデコーダーと時刻依存ロジックを更新する

Protocol 30対応XDRを取り込み、テストネットの台帳ヘッダーとメタデータを実際に復号します。エラーが出ないことに加え、ミリ秒が失われていないこと、秒単位の項目が誤変換されていないことを確認します。古いサービスが同じメッセージキューを読む構成では、消費者ごとの対応状況を一覧化してください。

アップグレード境界で復号に失敗すると、チェーン自体が正常でも入金反映や残高表示が止まる可能性があります。ロールバック手順、未処理キューの保持、再取り込み方法、アラート条件を事前に決めます。未知のデータ形式の分岐を無視して処理を続ける実装は、誤った時刻を保存する恐れがあるため、明示的に失敗させたうえで更新する方が検知しやすい場合があります。

利用言語ごとに対応SDKの公開状況を確認する

JavaScript、Goなど、SDKごとにProtocol 30対応版の公開時期は同じとは限りません。リポジトリの既定ブランチにコードが入ったことと、安定版パッケージとして配布されたことも別です。パッケージ名やメジャー番号だけで判断せず、リリースノートと含まれるXDR定義を確認します。

複数言語を使うサービスでは、フロントエンドがWアドレスを受理してもバックエンドが拒否する、Goのインデクサーだけが新XDRを読めない、といったずれが起こり得ます。対応表には言語、パッケージ版、XDR版、テスト結果、担当者を記録し、本番デプロイ済みかまで追跡してください。

Soroban開発者・ノード運用者に必要な対応

Soroban開発者はコントラクトの機能と費用を、ノード運用者は合意参加とピア接続を中心に確認します。両者に共通するのは、Protocol、Core、Sorobanホスト、SDK、Wasmの版を名前だけでなく実際の互換性ルールで揃えることです。

優先度	開発者・運用者の作業
投票前に必須	対応Core・SDK・XDRを揃え、再起動、同期、復旧まで確認する
ML-DSAを使う場合	対応ツールで再ビルドし、正常・異常署名と最大件数の費用を測る
推奨	監視、段階展開、機能フラグ、成果物の版記録を整える

ML-DSA利用時の再ビルドと費用検証

ML-DSAを利用するコントラクトはProtocol 30対応ツールで再ビルドし、44・65・87それぞれの正常署名と不正署名を試します。公開鍵や署名の長さが違う入力、改変されたメッセージ、空入力、上限近くの複数検証も含め、期待どおり拒否されることを確かめます。

費用試験では、単発の成功例だけでなく、実際の最大件数を想定します。CPU、メモリー、台帳エントリー、取引サイズ、シミュレーション結果と本番相当設定の差を記録してください。タイムアウトや予算超過時に途中状態が残らないか、エラーを利用者へどう返すかも重要です。

Core・Soroban・Wasmのバージョンを揃える

Stellar CoreとSorobanホストのメジャー版は整合させ、コントラクトWasmが要求する最低プロトコル版も確認します。開発端末、CI、テストネット、ステージング、本番で別の版が残っていると、ローカルでは成功してネットワークで失敗する原因になります。

依存関係の固定ファイル、コンテナイメージ、キャッシュされた生成コードも更新対象です。再現可能なビルドを作り、成果物がどのSDKとXDRから作られたかを記録します。Protocol 30を必要とする機能は、有効化前のネットワークへ送らないよう機能フラグで分けると移行を管理しやすくなります。

Core v30.0.0の互換性変更を確認する

ノード運用者はCore v30.0.0のリリースノートを読み、CAP-84・87・88だけでなくピア接続の下限や安定性修正も確認します。合意へ参加するバリデーター、履歴を提供するノード、読み取り専用ノードでは停止許容時間と更新順序が異なります。クォーラムの可用性を損なわないよう、組織内で段階的な更新計画を作ります。

旧ノードとの接続条件が変わる場合、更新していないピアが切断される可能性があります。ピア数、同期遅延、台帳追従、履歴公開、負荷、エラーログを監視し、投票前にテストネットで再起動と再同期を試してください。バイナリの配置だけでなく、設定ファイル、監視ルール、バックアップ、復旧手順までを変更管理に含めます。

11月の投票日程とアップグレード前の最終確認

公式発表時点の投票予定は、テストネットが2026年11月3日17:00 UTC（日本時間11月4日2:00）、メインネットが11月23日17:00 UTC（日本時間11月24日2:00）です。準備状況やバリデーター判断で変わる可能性があるため、各段階の直前に公式ガイドを確認してください。

テストネット前から投票直後までの4段階

段階	対象者	完了条件
テストネット投票前 11月3日17:00 UTCまで	事業者・開発者・ノード運用者	対応版を用意し、新XDR復号、Wアドレス、ML-DSA、再起動を試せる
テスト期間 11月3日投票後〜23日前	同上	実台帳で境界試験を完了し、不具合修正、再取り込み、費用計測の記録が残る
メインネット投票前 11月23日17:00 UTCまで	全対象者	事業者は本番展開と告知、運用者は同期・復旧、一般利用者は利用先の案内確認を終える
投票直後	事業者・運用者	入出金、復号、台帳追従、ピア、エラーを監視し、滞留分を安全に再処理できる

テストネットで成立してもメインネットの有効化が自動確定するわけではありません。テスト期間は、Protocol 29最後とProtocol 30最初の境界、同一秒の複数台帳、未登録WアドレスID、不正なML-DSA署名、停止からの再同期を実データで確かめる期間です。外部ライブラリも「マージ済み」「正式リリース済み」「自社で本番導入済み」を分けて管理します。

メインネット前、一般利用者は利用中のウォレットや取引所のメンテナンス案内だけ確認してください。通常は秘密鍵の変更や資産移動は不要です。偽の移行案内が不安な場合は、仮想通貨詐欺の見分け方も確認できます。

対象者別の最終チェック

対象	必須	該当時・推奨
一般利用者	公式案内を確認する	秘密鍵を求める偽案内を避ける
ウォレット・取引所	新XDRとWアドレスを結合試験する	未登録入金、停止、再処理を訓練する
データ基盤	新しいデータ形式の分岐を復号する	秒・ミリ秒、同一秒台帳、再取り込みを試す
Soroban開発者	利用SDKとWasmの版を揃える	ML-DSA利用時だけ再ビルドと費用検証を行う
ノード運用者	Core更新、同期、ピア接続を確認する	合意形成に必要なノード群を損なわない順序で段階更新する

投票直後は、チェーンの進行だけでなく、利用者に見える入出金や残高更新まで監視します。新形式の復号失敗を検知したら未処理データを捨てず、修正版で再取り込みできる状態を保ちます。日程が変わった場合は本稿より公式情報を優先してください。

最終検証日：2026年10月22日。本稿は公開技術資料に基づく一般的な解説です。仕様、対応版、投票予定は変更される可能性があります。