Solanaのnonce移行計画：配送が期限切れでも承認は残る
Solanaはオフライン署名を残しつつdurable nonceを廃止する計画を進める。候補となるプログラム方式は、長く有効な承認と、それを運ぶ短命な取引を分ける。
内容を変えずに承認カプセルを期限切れの運搬ケースから新しいケースへ移すAI生成の概念図。実際のウォレット画面やSolanaの移行完了を示すものではない。
要点
- 10月16日の開発情報で廃止計画が紹介された。最終的な代替方式と廃止日は未定で、約6カ月の移行期間は適切な代替手段が整う時点を条件とする。
- オフラインの権限者がメッセージに署名し、リレイヤーが通常の取引で運ぶ。外側のブロックハッシュを更新しても、承認への署名をやり直す必要はない。
- 候補プログラムは派生アドレスと内部呼び出しを使う。互換性、署名が固定する範囲、承認の取り消しは別々に考える必要がある。
出来事のタイムライン
Solana Foundationの10月16日の開発情報がdurable nonceの廃止発表を紹介。これは計画であり、削除完了ではない。
条件付きの移行時計
オフラインで承認を集める時間は、通常のSolana取引が有効である時間を超えることがある。現在はdurable nonceがこの隔たりを埋める。Solana Foundationは2026年10月16日の開発情報で廃止計画を紹介したが、アップグレードページの状態は依然として開発中だ。オフライン署名をオンチェーンのプログラムで検証する方式を示し、AnzaのProgrammatic SignerとBlueshiftのVectorを候補に挙げる。最終的な代替方式も廃止日も決まっていない。[1][2]
ページが見込む廃止時期は、適切な代替手段が整ってから約6カ月後だ。代替手段が監査を受けてメインネットで稼働するまで、durable nonceは利用可能だとも説明する。10月の発表から数える期限ではない。Anza自身の文書は現在のDevnet配備と監査進行中の状態を示し、v1およびメインネット配備より前に監査と修正が必要で、インターフェースも変わり得るとする。Vectorのコードとプログラムアドレスの公開だけでは、監査済みのメインネット展開を立証できない。本稿は公開設計の解説であり、ネットワークの移行完了を報告するものではない。[1][4]
現在のnonceが保つもの
通常の取引は最近のブロックハッシュを参照し、受理される時間が限られる。durable nonce取引では、System Programのnonceアカウントに保存した値を代わりに使う。署名者がオフラインで取引を承認し、別の人が後から送信でき、通常のブロックハッシュの期限に縛られない。保存値はリプレイ防止も担う。nonceが次の値に進むと、古い値に署名した取引をそのまま再利用することはできない。[3]
ここで失敗には二つの意味がある。現在の文書によると、既に使われたnonceなど、検証段階で拒否された取引は手数料も状態変更もなく破棄される。一方、検証を通過してから命令の実行に失敗した場合は、nonceは進み、手数料も徴収される。アプリの処理が失敗しても、以前の署名済み取引は使えなくなる。拒否された試行はすべてnonceを消費する、と説明するとこの区別を失う。[3]
承認と運搬手段の寿命を分ける
Programmatic Signerは処理を三層に分ける。実行メッセージにはアプリの命令が入る。承認メッセージはその処理を実行器とnonceアカウントに結び付け、必要な権限者がその正確なバイト列に署名する。リレー取引は承認と署名をネットワークに運び、通常の最近のブロックハッシュと手数料負担者を使う。プログラムがオフライン署名を検査し、自分で管理するnonceを進め、承認済みの命令を呼び出す。バリデーターが受け取るのは通常の取引だ。[4][5]
署名済みの承認を配送封筒の中身と考えると分かりやすい。封筒が期限切れなら、リレイヤーは新しいリレー取引を作り、その外側の取引に再署名できる。中の承認に署名し直す必要はない。ただし、この比喩には明確な限界がある。リレイヤーは承認済みの命令を編集したり、承認メッセージ内のアカウントを差し替えたりできない。Anzaの文書では、実行メッセージのblockhash欄には期待するnonceが入り、外側のリレー取引の同じ欄には最近のブロックハッシュが入る。同名の欄でも役割は違う。[5]
行動するアカウントと署名の境界も変わる
プログラムはオフラインの権限者に代わり、プログラム派生アドレス（PDA）を通じて行動し、プログラム間呼び出し（CPI）でアプリを呼ぶ。従来の鍵ペアのアカウントと派生アカウントは、交換可能な同一の主体ではない。トップレベルの呼び出ししか認めないプログラムは、この経路を拒否し得る。外側の取引署名者だけを見るインデクサーにはリレイヤーが見え、実際に行動したPDAは内部命令に現れる場合がある。オフライン承認への対応には、有効期限の欄を一つ置き換える以上の互換性確認が必要になる。[1][4]
署名で何を固定するかも候補ごとに違う。Programmatic Signerは署名済み承認の内部変更を禁じる一方、リレイヤーがSubmitの前後に別の命令を加えることを認める。Vectorはpassthroughの内容を含め、すべてのトップレベル命令を署名対象のダイジェストに結び付ける。署名後にリレイヤーがそれらを追加、削除、並べ替えすることはできない。両者はプログラム管理のリプレイ防止とCPIを使うが、承認の周囲に加えられる処理の境界は異なる。どちらの説明も、特定のアプリが既に対応済みである証拠ではない。[1][5][6]
期限切れ、取り消し、再試行は別の出来事
公開された両設計には、承認の有効期限が組み込まれていない。したがってリレー取引の期限切れは、承認の取り消しではない。対応するnonceを進めれば、以前の値に結び付いた承認は無効になる。業務上の締め切りが必要なら、署名対象に含まれる命令で期限を検査しなければならない。承認ツールに日付を表示するだけでは足りず、実行されるルールがその日付を確認する必要がある。[1][5][6]
また、実行に失敗して取引がロールバックされ、nonceが変わらなければ、両設計では同じ承認で再試行できる。これは現在のdurable nonceの実行失敗時の挙動と異なる。ただし、いつか成功することや、ネットワークへの試行が無料であることは約束しない。通常の取引手数料は適用される。計画を読む際に役立つ問いは、何を承認したか、どのアカウントが行動するか、何が承認を無効にするか、受け手のアプリがその呼び出し経路を認めるかだ。Foundationは通常の取引は予定される廃止の影響を受けず、移行対象はdurable nonceを使うフローだと説明している。[1][3][6][7]
続けて読みたいストーリー
同じテーマを、別の事例や背景から考えてみましょう。
