ソラナの取引上限が3.3倍に｜対応しないと取引所も影響か

ソラナのトランザクション形式「v1」が、メインネット有効化の直前段階に入りました。1トランザクションあたりの最大サイズを1232バイトから4096バイトへ、およそ3.3倍に引き上げる変更です。

ソラナの公式アップグレードページは9月4日時点でメインネット未有効と表示しており、テストネットでは稼働、devnetはエポック1140で有効となっています。開発元のAnzaは8月29日に9月9日のメインネット有効化を目標として示していますが、この日程は暫定的なものとされています。

仕様はSIMD-0296がサイズ上限を、SIMD-0385がv1メッセージ形式を定義しており、いずれもAnzaのエンジニアが起案しました。従来のlegacyとv0は挙動が変わらないため、既存形式を使い続けるアプリや利用者に移行義務は生じません。問題は、送信側ではなく読み取り側にあります。

エラーで止まる障害と、静かに壊れる障害

RPCを利用する側は、getTransaction、getBlock、blockSubscribeで整数値のmaxSupportedTransactionVersion:1を渡す必要があります。文字列の「1」では型チェックに失敗し、0を指定した場合や省略した場合と同様に処理できません。指定がないとgetTransactionはエラー-32015を返し、ブロック内に1件でもv1が含まれればgetBlockはブロック全体が失敗します。blockSubscribeはblock:nullを返して最初の該当スロットで進行を停止します。

より厄介なのは、エラーを出さない側の障害です。v1では計算ユニット上限、ロード対象アカウントのデータ上限、優先手数料がComputeBudget命令ではなくtransactionConfigオブジェクトに移されます。従来どおり命令列を走査するインデクサーは、すべてのv1取引について計算予算をゼロと記録しながら例外を投げません。GeyserやgRPCの利用者はさらに注意が必要で、protobufのversionedフラグはv0とv1の双方でtrueになるため、古い実装はv1をv0と誤ラベルしたまま空の予算を保存します。

protobufスタブを再生成し、フィールド7のMessage.configの有無を先に確認する対応が求められます。なお、Geyserプラグインの15.1.1はv1をv0形式へ降格させる一時的な互換ブリッジを提供します。

手数料スポンサーの上限が拘束力を失う

さらに実務上の影響が大きいのがリレイヤーやペイマスターです。ComputeBudget命令を走査して手数料上限を課してきたスポンサーは、v1では上限が拘束力を失います。該当する命令がv1に含まれていても、実行時には何もしない命令として扱われるためです。サーバー側は0x81というv1のバージョン識別子を判定し、transactionConfig内の手数料と資源上限を強制する必要があります。これはコンセンサスの欠陥ではなく、アプリケーション側の制御失敗であり、資金が自動的に危険にさらされるという話ではありません。

オンチェーンプログラムの制約はより厳しく、現時点でv1メッセージ設定を参照できるsysvarやsyscallは存在しません。ComputeBudget命令の内観を条件に挙動を分けている設計は、v1稼働後に成立しなくなります。読み取り対応の最低バージョンは@solana/kit 8.0.0、@solana/web3.js 3.0.0-rc.3、Rustのsolana-*系4.2.x、Pythonのsolders 0.29.0、solana-go 1.23.0などです。v1の作成は任意ですが、読み取りは任意ではありません。

取引所やカストディ、分析事業者を含め、他者のv1取引を読み・記録し・スポンサーする可能性があるすべてのサービスにとって、これは互換性テストの期限となりそうです。

記事ソース：資料