RoninのKarstアップグレードとは？日本時間10月8日1時の変更点と対応

RoninのKarstアップグレードは、2026年10月8日1時00分01秒（日本時間）に有効化される予定です。結論からいえば、ゲームやウォレットを使う一般利用者は原則として操作不要です。一方、DApp開発者はガス上限や暗号処理の再テスト、ノード運用者はop-rethへの移行などが必要です。

この記事は2026年10月7日18時（日本時間）時点の公式情報で検証しています。この時点では有効化のおよそ7時間前なので、稼働済みとはせず「予定」として整理します。一般利用者は「一般利用者は原則対応不要」まで読めば要点をつかめます。開発者はガス・暗号処理・Saigon、ノード運用者はop-reth以降を重点的に確認してください。Karstの前提を知りたい人は、レイヤー2の仕組みも参照できます。

Karstアップグレードは日本時間10月8日1時に有効化予定

Ronin Networkの公式告知が示す有効化予定は、2026年10月7日16時00分01秒（UTC）です。日本標準時はUTCより9時間進んでいるため、日本時間では翌10月8日1時00分01秒になります。日付をまたぐ点に注意してください。アップグレードは、ネットワークが共有するルールを決められた時刻から切り替える作業です。スマートフォンアプリの更新のように各利用者が同じボタンを押すものではありません。対応が必要なのは主に、ルール変更の影響を受けるアプリを開発する人と、ネットワークを追従するノードを運用する人です。

検証時点では有効化前、完了情報と混同しない

公式は停止なしで移行する計画を案内していますが、将来の結果を保証する表現ではありません。「正常に完了した」という評価は、有効化後の公式情報と実際のチェーン状態を確認して初めて可能です。利用者は非公式投稿を根拠に操作せず、開発者と運用者はブロック進行、RPC応答、同期高、主要機能を確認してください。

Karstとは何か：Fusakaの実行層改善をRoninへ導入

Roninが導入するのはFusaka由来の実行層改善

Karstは、Roninが利用するOP Stackの更新と関係し、EthereumのFusakaで扱われる改善のうち実行層に関わる変更をRoninへ取り込むものです。実行層とは、取引やスマートコントラクトを実際に計算し、その結果がルールに合うか検証する部分を指します。初心者は「Ethereumの更新が、そのままRoninにも入る」と考えがちですが、両者はネットワーク構成も役割も同一ではありません。Ronin公式告知に明記された変更を基準に読む必要があります。

Karstでは、単一取引のガス上限、暗号処理用precompileの料金や入力制限、新しいopcode、ノードソフトウェア、コアコントラクト更新方式などが重要です。OP Stackでは、ロールアップノードがL1の情報からL2チェーンを導出し、実行エンジンと連携します。したがって、アップグレードではスマートコントラクトだけでなく、op-nodeと実行クライアントの互換性も問題になります。利用者の画面から見えにくい部分ですが、運用者には欠かせない区別です。

PeerDASなどEthereum固有機能は明示範囲外

Ethereum版Fusakaには、実行層以外の変更も含まれます。たとえばPeerDASは、Ethereumノードがblobデータの可用性を標本から検証するための仕組みです。しかし、Ronin公式告知がKarstの変更としてPeerDASまで導入すると明記しているわけではありません。同様に、Ethereum側のblob料金変更や既定ブロックガス上限に関する情報を見つけても、それをRoninへ自動的に当てはめるべきではありません。「Fusakaに含まれる」と「KarstでRoninに採用される」は別の主張です。本記事ではRonin公式告知と、そこから参照できるEIPやOP Stack仕様の範囲を分けて扱います。

一般利用者は原則対応不要：資産移行や秘密鍵入力は求められない

ウォレットやトークンの手動移行は不要

Ronin公式の案内では、一般利用者は原則として何もする必要がありません。ウォレット内のRONやゲーム資産を別アドレスへ送り直す、トークンを交換する、秘密鍵やシードフレーズを入力して「アップグレードする」といった作業は求められていません。この点はセキュリティ上とても重要です。ネットワーク更新の時期には、「移行しないと資産が失われる」「新ウォレットへ接続が必要」などと不安をあおる偽サイトが現れる可能性があります。秘密鍵やシードフレーズはウォレットを支配する情報であり、運営を名乗る相手にも渡してはいけません。署名を求められた場合も、内容や接続先を確認できなければ承認しないでください。

有効化前後は公式案内とRPCの状態を確認

一般利用者ができる現実的な対応は、必要な操作を急がず、利用しているゲームやウォレットの公式案内を見ることです。有効化前後に一時的な接続不良があっても、すぐに資産消失と判断する必要はありません。アプリ側、RPC側、表示側のどこで問題が起きているかは画面だけでは分からないためです。開発者や高度な利用者は、公式RPCの応答やエクスプローラー上のブロック進行も確認できます。ただし、検索広告やSNSの短縮URLからではなく、公式ドキュメントに掲載されたネットワーク情報を起点にしてください。RoninメインネットとSaigonテストネットではチェーンIDや接続先が異なるため、環境の取り違えにも注意します。

開発者への主要変更：1取引のガス上限は16,777,216

ブロック全体ではなく単一取引にかかる上限

KarstではEIP-7825に基づき、通常の1取引が使えるガスに16,777,216、つまり2の24乗の上限が設けられます。ガスはスマートコントラクトの計算量を測る単位です。基礎から確認したい場合はガス代の解説を先に読むと、この上限と手数料価格の違いを理解しやすくなります。この上限は手数料の価格を固定するものではなく、1件の取引がネットワークへ極端に大きな計算負荷を持ち込むことを抑えるための制約です。重要なのは、単一取引の上限とブロック全体のガス上限を混同しないことです。ブロックには複数の取引が含まれます。1取引が上限内でも、ブロック全体には別の制約があります。また、ガス価格とガス使用量も別概念です。今回の数値だけを見て「手数料が必ずこの金額になる」「処理能力が一律に下がる」とは判断できません。

巨大batch・multicall・コントラクト配置を再検証

影響を受けやすいのは、多数の処理を1取引に詰め込むbatchやmulticall、大きなコントラクトの配置、複雑な初期化処理です。従来は成功した取引でも、必要ガスが新上限を超えれば同じ形では実行できません。通常の送金や軽いコントラクト呼び出しだけを見て「問題なし」と判断せず、最も重い経路を試す必要があります。開発者はフロントエンドのガス推定にも注目してください。推定値が上限を超える場合、単にgasLimitの入力値を大きくしても解決しません。処理の分割、データ量の削減、コントラクト設計の見直しが必要です。bytecode解析やデプロイスクリプトも、本番と同じ条件に近づけて確認します。

分割には副作用があります。1取引なら全処理が成功するか全体が巻き戻る「原子性」を保てますが、複数取引へ分けると途中だけ成功する可能性があります。順番の入れ替わり、二重実行、再試行、途中状態を想定した設計が欠かせません。

Ethereum由来のdeposit transactionは告知上の例外

Roninの告知では、Ethereumからのdeposit transactionはこの取引ガス上限の例外として説明されています。EIP-7825にも、通常のユーザー取引とプロトコル内部の特定取引を区別する考え方があります。ただし「deposit」という語を、一般的な取引所への入金やアプリ内の預け入れまで広げて解釈してはいけません。ここでの例外はプロトコル上の取引種別に関するものです。アプリが独自にdepositと名付けた関数が自動的に例外になるわけではありません。ブリッジや入出金機能を開発する場合は、実際に生成される取引種別と経路を確認し、通常取引側の処理も上限内かテストしてください。

暗号処理とopcodeの変更：P256VERIFY・ModExp・CLZを確認

項目	変更点	影響対象	対応
P256VERIFY	6,900ガス、既存L2実装比で約2倍	Passkey・WebAuthn	署名検証を実測
ModExp	料金改定、各入力1024バイトまで	RSA・一部のZK処理	料金と境界値を試験
bn256Pairing	最大300組	ZK・BLS関連	ペア数の上限前後を試験
CLZ	opcode 0x1eを追加	算術・圧縮・ビット処理	利用環境の対応を確認

P256VERIFYのコスト変更と端末署名への影響

P256VERIFYは、P-256（secp256r1）曲線の署名を検証するprecompileです。precompileとは、よく使われる重い処理をEVM内で効率よく利用できるよう、特定のアドレスに用意された機能です。P-256はWebAuthnやPasskeyなど、端末の認証機能と組み合わせる場面があります。KarstではP256VERIFYのコストが既存のL2実装と比べて約2倍になるとRoninが案内しています。EIP-7951はP256VERIFYの安全検査、入出力と6,900ガスの料金を規定します。Passkeyを使うウォレットやアカウント抽象化の仕組みは、署名検証そのものだけでなく、前後の処理を含めた実ガスを測り直す必要があります。

ModExpの値上げと各入力1024バイト上限

ModExpは剰余付きの累乗計算を行うprecompileで、RSAや一部のゼロ知識証明など、大きな整数を扱う暗号処理で使われます。EIP-7883では、実際の計算負荷に対して割安だった料金式を改め、最低料金を200ガスから500ガスへ変更し、一般的な計算コストも概ね3倍になる仕様が示されています。さらにEIP-7823は、base、exponent、modulusの各入力を最大1024バイトに制限します。上限を超える入力は失敗するため、「料金が上がるだけ」と考えるのは不十分です。RSA、ZK関連処理、特殊な証明検証などを利用するアプリは、実際の入力サイズを記録し、境界値の直前と直後を試す必要があります。

処理を別方式へ置き換える場合は、ガス削減だけでなく暗号学的な安全性や互換性も再評価します。入力を単純に切り詰めることは解決策になりません。ライブラリが内部でModExpを使っているケースもあるため、直接呼び出していないプロジェクトでも依存関係を確認してください。

bn256Pairingの上限とCLZ opcodeの追加

Roninの告知では、bn256Pairingで扱える組数が最大300組になります。ペアリング演算はZKやBLS関連の検証で使われることがあり、入力数の多い検証処理は上限への到達を確認しなければなりません。普段のゲーム操作で利用者が意識する変更ではありませんが、証明を検証するコントラクトには直接関係します。一方、CLZは256ビット値の先頭にゼロがいくつ並ぶかを返す新しいopcodeで、番号は0x1eです。算術、圧縮、ビットマップ処理などを効率化できる可能性があります。ただし、新opcodeが追加されたからといって既存コードが自動で高速化されるわけではありません。コンパイラやライブラリの対応状況を確認し、利用する場合はKarst前後の環境差も考慮します。

開発者の事前確認：Saigonで失敗条件とガス見積もりを試す

batch・multicall・デプロイの成功条件を検証

RoninにはSaigonテストネットがあり、公式ドキュメントでチェーンID、RPC、エクスプローラーなどのネットワーク情報を確認できます。開発者は、Karstの条件が反映された環境で、実運用に近いデータ量と処理経路を使って試験します。接続先だけSaigonに変え、中身が極端に小さいテストでは上限問題を見逃します。batchとmulticallは、通常時、最大想定時、上限付近、上限超過のケースを用意します。コントラクト配置ではbytecode、コンストラクタ、初期化を合わせたガスを見ます。プロキシを使う場合も、実装コントラクトの配置とアップグレード呼び出しを別々に確認してください。

暗号処理の実ガスと入力サイズを測定

P256VERIFY、ModExp、bn256Pairingを使う処理は、推測ではなく計測します。入力ごとのガス使用量、全取引のガス使用量、入力バイト数、ペア数、成功・失敗理由を残すと、Karst後の回帰テストにも使えます。WebAuthnやPasskeyでは、端末側で署名できたことと、チェーン上で検証取引が成功したことを分けて確認します。境界値テストでは、1024バイト以下だけでなく1024バイトを超えるModExp入力、300組付近のペアリング、単一取引ガス上限の前後を対象にします。失敗が想定どおり検知され、ユーザーへ分かる形で表示されるかも重要です。RPCやライブラリが返すエラーを握りつぶすと、利用者には処理中のままに見えることがあります。

分割実行時の順序と原子性も確認

大きな処理を複数取引へ分ける設計では、順序と原子性が変わります。第1取引の後に第2取引が失敗した場合、最初の状態だけが残る可能性があります。別の利用者の取引が間に入り、想定した価格や在庫、権限状態が変わることもあります。対策として、途中状態を明示する、同じ処理を再送しても壊れないようにする、期限やnonceを確認する、キャンセルや復旧の経路を用意するといった検討が必要です。ただし最適な方法はアプリの設計によって異なります。単に「分割すればよい」とせず、資産移動や権限変更を伴う経路を重点的にレビューしてください。

ノード運用者はop-reth v2.2.3への移行が必須

op-gethからop-rethへ切り替える

一般利用者と異なり、ノード運用者には明確な更新作業があります。Ronin公式告知ではop-gethのサポート終了と、op-reth v2.2.3への移行が案内されています。未更新の実行クライアントは新しいルールを正しく処理できず、チェーンへの追従が止まる可能性があります。移行はバイナリ名を置き換えるだけの作業ではありません。データディレクトリ、起動引数、認証、Engine API接続、監視、バックアップ、ディスク容量などを構成単位で確認します。管理サービスやコンテナイメージを使っている場合は、タグが期待するバージョンを指しているか、実行中プロセスのバージョン表示まで検証してください。

新しいgenesisとoverride時刻を一致させる

Karst対応では、新しいgenesisとKarst overrideも必要です。overrideは、クライアントにアップグレードの有効化条件を与える設定です。時刻、単位、タイムゾーンを取り違えると、正しいバイナリを入れていても異なるタイミングでルールを切り替える恐れがあります。設定ファイルは公式配布元から取得し、既存ファイルとの差分を確認します。本番へ反映する前に、設定のパス、読み込みログ、コンテナへのマウント、環境変数による上書きまで点検してください。ファイルを更新しても、古いボリュームや起動引数を参照していれば実行時には反映されません。

有効化前には現在の同期状態とピア接続を記録し、有効化後はブロック高、チェーンID、フォーク設定、エラー率を比較します。復旧手順や連絡経路も事前に共有しておくと、異常時に場当たり的な設定変更を避けられます。

op-nodeと実行クライアントの互換性を確認

op-nodeとop-rethは同じものではありません。op-nodeはL1データなどからL2の正しいチェーンを導出するロールアップノードで、op-rethは取引を実行して状態を保持する実行クライアントです。両者はEngine APIを通じて連携するため、一方だけが新しいルールへ対応しても十分ではありません。運用者は推奨される組み合わせ、認証用JWT、APIポート、ネットワーク到達性を確認します。起動していることと正常に追従していることも別です。ログに接続エラーがないか、ヘッドが進んでいるか、他の信頼できるRPCやエクスプローラーと同じチェーンを見ているかを監視してください。

L2 Contract Managerでコアコントラクトを更新

コアコントラクト更新を単一ブロックで実行する設計

KarstではL2 Contract Manager（L2CM）が導入され、Roninのコアコントラクトを単一ブロックで更新できる設計になります。複数の中核要素を別々の時点で更新すると、一時的にバージョンが混在する可能性があります。単一ブロックでの更新は、その移行境界を明確にするための仕組みと理解できます。ただし、「単一ブロックだから無条件に安全」という意味ではありません。対象コントラクト、実装、初期化、権限、設定値が意図どおりかを確認する必要があります。Optimismのop-contracts v7.0.0の変更履歴にはKarst対応、L2CM実装、EIP-7825のガス上限検証などが含まれています。

SystemConfig・predeploy・eth_configの確認観点

OP StackのSystemConfigは、L1上の設定変更をロールアップ設定へ反映するために使われます。predeployは、L2上の決められたアドレスにあらかじめ配置される主要コントラクトです。コアコントラクト更新の確認では、コードだけでなく、設定値と固定アドレスの構成も対象になります。EIP-7910のeth_configは、ノードの現在、次、直前のフォーク設定を取得するJSON-RPCメソッドです。対応環境ではchainId、forkId、有効化時刻などの整合確認に利用できます。ただし、RPCが返した値を保存するだけでは監視になりません。期待値を定義し、差異が出た場合に通知できるようにします。

監視では、設定値、ブロック進行、実行エラー、アプリの重要トランザクションを組み合わせます。ひとつの指標だけが正常でも、利用者経路全体が正常とは限りません。アップグレード直後は特に、読み取りと書き込み、通常取引と重い取引を分けて観察してください。

有効化前後の最終チェック：誰が・何を・いつ確認するか

有効化前後の確認では、まず自分の立場を決めると情報を整理しやすくなります。ゲームを遊ぶ、ウォレットで残高を見る、通常の送受信をするだけなら一般利用者です。コントラクト、フロントエンド、バックエンド、署名やガス推定を実装しているなら開発者です。RPCやアーカイブ、バリデーションに関わるサーバーを管理しているならノード運用者に当たります。複数の立場を兼ねる組織では、担当別にチェック項目を分け、誰が結果を確認するかまで決めておきましょう。

一般利用者（有効化前後）は、手動の資産移行をせず、不審な署名要求を拒否します。秘密鍵やシードフレーズを求める誘導への基本対策はネットワーク更新の考え方と併せ、必ず公式案内を起点に確認してください。

開発者は、Saigonで巨大batch、multicall、デプロイ、ガス推定を確認します。P256VERIFY、ModExp、bn256Pairingを使う処理は、料金、入力サイズ、失敗条件を実測します。処理を分割する場合は順序、原子性、再試行、途中状態を設計し直してください。

ノード運用者は、op-reth v2.2.3、新しいgenesis、Karst override、互換性のあるop-node構成を確認します。op-gethのまま運用せず、有効化前後の同期高、設定、ログ、RPC応答を比較します。異常時の復旧手順も有効化前に準備します。

開発チームはテスト結果に、実行したネットワーク、クライアント版、時刻、取引ハッシュ、入力条件、推定ガスと実使用ガス、成功または失敗の理由を残します。同じ「失敗」でも、取引ガス上限、ModExpの入力上限、ペアリング組数、RPCタイムアウトでは修正方法が異なるからです。代表的な正常系だけでなく、上限の直前、上限と同値、上限超過の境界条件を並べると、仕様どおりの挙動か判断しやすくなります。

運用チームは有効化前の基準値を保存し、有効化後の値と比較します。確認対象は、同期中のブロック高、直近ブロックの時刻、ピア数、op-nodeとop-rethの接続、RPCのエラー、ディスクとメモリ、主要な読み書き要求です。ひとつのRPCだけで判断せず、公式エクスプローラーなど別の観測点と照合します。差が出たときは、直ちに不明な設定を追加するのではなく、バージョン、genesis、override、接続先という既知の必須条件から順に確認します。

一般利用者向けの案内を出すサービス運営者は、「操作不要」「秘密鍵やシードフレーズを入力しない」「障害時の公式確認先」という三点を明確にすると、詐欺対策にもなります。アップグレードが完了したと告知する場合は、予定時刻を過ぎただけでなく、自社サービスの入出力や主要機能を確認したうえで表現を選びます。公式が予定した停止なしの移行と、個別サービスで一時的な不具合が起きないことは同じではありません。

Karstは一般利用者に新しい操作を迫る更新ではありませんが、開発者と運用者には具体的な確認事項があります。自分の立場に関係する項目だけを切り分け、公式情報を基準に行動することが重要です。SNS上の未確認情報だけで設定や資産を動かさず、公式告知、公式ドキュメント、実際のチェーン状態という順で確かめましょう。確認結果を時刻とともに記録すれば、問題の切り分けにも役立ちます。有効化後の成否や実際の影響は、予定時刻を過ぎてから公式発表とネットワーク状態で確認してください。