Stellar開発財団、11月24日のBellプロトコル30投票に向け運用者別のソフトウェア要件を提示

稼働前に課される3つの対応

ステラ開発財団(Stellar Development Foundation)は10月23日(金曜日)、Bellアップグレードガイドを更新し、Bellプロトコル30アップグレードの投票前にネットワーク側で必要となるソフトウェアを運用者ごとに明示した。この更新は、取引所、ウォレット、台帳データを直接読み取るサービスに、それぞれ異なる作業を課す内容になっている。ガイドはインフラと開発者向けツールをサポート対象バージョンと対にし、すべての運用者に自社の統合環境での検証を求める。この検証はバリデータ投票とは別の工程として位置づけられている。スケジュールはテストネット投票が11月4日(水曜日)、メインネット投票が11月24日(火曜日)だが、両日とも変更される可能性があり、アップグレードの適用はバリデータの承認次第だ。ここには実務上の空白がある。プロトコル30の稼働を決めるのはバリデータの承認だが、利用者が変更に気づくかどうかを決めるのは取引所やウォレットが日々動かすソフトウェアの側だ。ガイド自体はネットワーク上で何も変更しない。提案内容を、サービスごとのソフトウェアとデータ形式のチェックリストに翻訳したものにすぎない。

変更の下流に位置する各主体に対し、ガイドは責任の範囲を3つの線で引き分ける。まずホットウォレット基盤を運用する取引所とカストディアンは、新しいW形式のコントラクトアドレスへ出金を送れることを確認しなければならない。次に、ウォレットと資産発行者は、アドレス入力を受け付ける機能と送金記録を処理する機能を検証対象とする。3つ目として、インデクサー、エクスプローラー、分析ツールなど台帳データを直接読み取るサービスには別の義務が生じる。プロトコル30は台帳ヘッダーに新しい値形式を導入するため、既存のXDR定義に据え置いたままのデコーダーは、稼働後に台帳データを読めなくなる恐れがある。XDRはStellarネットワークがトランザクションと台帳データを表現するために使う形式であり、財団が投票後ではなく投票前に定義の更新を求めているのはこのためだ。

WアドレスとXDRデコーダー

最も見えやすい変更は、「W」で始まるコントラクトアドレス形式だ。各スマートコントラクトアドレスは64ビットの識別子を持ち、1つのコントラクトが複数の顧客からの入金を区別できる。SDKの更新によって新しいアドレスは読み取り可能になるが、ブロックチェーン上のウォレットアドレスを検査、表示、保存するアプリケーションコードや、送金先を読み取るコードは、W形式への対応を自前で実装しなければならない。対象にはハードウェアウォレットの表示部分も含まれる。一方、既存のスマートコントラクトはアップグレード後も動作を続け、新しいコントラクト機能を取り込むかどうかは開発者の判断に委ねられる。

財団が示した必須バージョンは、stellar-coreがv30.0.0、Horizon、RPC、Galexieがv30.0.0、JavaScript SDKがv17.3.0、Go SDKがv0.8.0だ。メンテナンスリリースのv16.4.0は新しい台帳を読めるもののWアドレスには対応しないため、W対応が必要なサービスはv17.3.0へ移行するしかない。HorizonとRPCエンドポイントは台帳をアプリケーションへ公開する入口であり、生のXDRを自前で解析しないサービスにとって、両者のv30.0.0への整合は重要になる。Soroban Rust SDK 30.0.0-rc.1もリストに加わっており、安定版はメインネット投票までに提供される予定だ。ガイド更新の時点では、プロトコル30向けStellar CLIビルドが未提供だったことも付記されていた。アドレス対応以外では、Bellはスマートコントラクト向けのML-DSA署名検証と、ミリ秒単位の台帳時刻記録を運んでくる。ネットワークのトランザクション署名はEd25519のまま変わりなく、時刻記録の変更だけでは台帳生成の間隔は短縮されない。なお、送金テストの合格とデコーダーの耐性は独立した準備項目であり、片方が他方を保証しない。

リリースノートそのものに照らすと、プロトコル30は付加的な変更だ。既存コントラクトは稼働をそのまま通過し、新機能の利用は開発者の選択に留まる。現実のリスクはオフチェーン、つまりプロトコル変更が一切触れないコード側にある。したがって11月24日の投票時点で移行を終えていないデコーダーやアドレス検証器こそ監視すべき失敗モードであり、バリデータ数ではない。単一のコントラクトが多数の顧客の入金を区別できるWアドレス方式は、従来型金融(TradFi)の決済をStellar(XLM)へ載せるカストディと取引所の経路を意識した設計だ。この経路は、Stellarで初めて機関投資家のレポ取引が決済された事例や、2027年に控えるDTCCの30兆ドル規模トークン化サービスとの連携と同じレーンである。未提供のStellar CLIビルドと未リリースの安定版Soroban SDKが残るなか、運用者に残された準備期間はメインネット投票で閉じる。稼働後にようやく移行したサービスは、自らのツールが解析できるはずのない台帳を読むことになる。