Cronos EVM v1.8は、ブロック101,485,000でメインネットへの適用を完了しました。今回の更新では、任意設定のアプリ側メンプール、Block-STMを使う並列EVM、Osaka対応、基盤ソフトウェアの更新などが導入されています。ただし、「更新が完了した」ことと、「すべてのノードやdAppが設定変更なしで同じ挙動を続けられる」ことは別です。
この記事では、ノード運用者、RPC事業者、dApp・スマートコントラクト開発者に向けて、v1.8で何が変わったのかを整理します。読み終えると、アプリ側メンプールを採用するか、どのRPCを再試験するか、ガス見積もりや廃止機能をどこまで点検するかを判断できます。技術更新はCROの価格上昇や投資収益を保証するものではありません。
最初に見る変更点と優先度
| 変更点 | 主な対象者 | 対応 | 最初の確認 |
|---|---|---|---|
| v1.8本体・依存版 | ノード運用者・RPC事業者 | 全員必須 | 稼働版とブロック101,485,000以降への追従 |
| Ethereum API・ガス検査 | dApp・ウォレット・RPC事業者 | 全員必須 | 利用RPCと実取引の回帰試験 |
| アプリ側メンプール | 採用するノード運用者 | 性能改善を採用する場合のみ | 従来構成との差分と戻し方 |
| Block-STM | 運用者・高負荷dApp | 性能評価する場合のみ | 競合率と更新前の基準値 |
| ICA・IBC・トークンマッピング・ReplayBlock | 該当機能の利用者のみ | 該当者は必須 | コード内の利用有無と制限・廃止条件 |
最優先の3項目：稼働版と同期、実利用RPCとガスの回帰試験、廃止・制限機能への依存有無を先に確認します。該当しない機能の章は読み飛ばせます。
Cronos EVM v1.8はメインネットへの適用を完了
適用実績は、アップグレード高101,485,000、PublicNodeが示す2026年10月22日07:52 UTC（日本時間16:52）の通過、Chainstackの同日08:00 UTCの保守完了で照合できます。Crypto.com KoreaのCRO入出金案内も完了表示へ更新されました。これはチェーンと周辺保守の完了を示しますが、個別の取引所、ウォレット、ブリッジ、独自RPCの正常稼働まで一括して保証するものではありません。利用サービスの状態は別に確認してください。
ブロック101,485,000での適用を確認
ブロック高はチェーン上のブロックの通し番号で、今回は101,485,000を境に新ルールへ切り替わりました。公式リリースの計画名、対象高を越えた外部RPC、利用中エンドポイントの応答を照合できれば、予定情報ではなく実績として判断できます。
RPC保守とCRO入出金停止も完了
周辺事業者の完了記録は補助材料です。単一画面だけで全サービスを正常とみなさず、入出金の再開時は利用先の最新表示、ネットワーク名、アドレスを確認します。
v1.8の主要変更と基盤アップデート
v1.8は一つの高速化機能だけを追加した版ではありません。取引をブロックへ入れる前段、EVMで実行する段階、Ethereum互換API、Cosmos系の基盤、データベース、IBCやブリッジ関連の検査まで複数の層が変わっています。そのため、「ノードが起動したから確認終了」ではなく、自分のシステムが触れる層ごとに試験を分けるのが要点です。
アプリ側メンプール、並列EVM、Osakaを導入
まなぶ「クリプ先生、メンプールとEVMは同じ場所の仕組みなんですか？」
クリプ「別の段階だよ。メンプールは実行前の取引を待たせて選ぶ場所、EVMは選ばれた取引を実行する仕組み、と分けると理解しやすいんだ。」
アプリ側メンプールは、未確定取引の保持やブロック提案用の選択をアプリケーション側で扱う機能です。並列EVMは、選ばれた取引を実行するとき、互いに競合しない処理を並行させる仕組みです。Osaka対応はEVMのルールと実装側の更新に関係します。名前が一緒に並んでいても、設定、性能測定、互換性試験の対象は異なります。
公式記事は40件を超える修正と運用上の変更を案内しています。また、libp2pに関する説明もありますが、メインネットではまだ有効化されないと明記されています。「リリースにコードが含まれること」と「今回のメインネットで有効になること」を混同しないようにしてください。
Cosmos SDK・IBC-Go・CometBFTなどを更新
公式リリースと実装PRによると、基盤はCosmos SDK 0.54.3、IBC-Go 11、CometBFT 0.39へ更新されました。ストレージではRocksDB 10.9.1と調整プロファイルが含まれます。Cronos EVMはEthereum形式の取引やスマートコントラクトを扱いますが、合意形成やチェーン間通信などにはCosmos系の構成要素も使います。
依存関係の更新は、直接利用していないように見えても、設定ファイル、起動引数、データベース性能、監視指標、IBC連携へ影響する可能性があります。運用者はv1.7系の設定を機械的に複製するのではなく、v1.8のリリースノートと差分を照合します。独自ビルドを使う場合は、公式成果物と同じ依存版になっているかも記録しておくと、障害時の切り分けがしやすくなります。
アプリ側メンプールは任意設定、取引受付経路が変わる
アプリ側メンプールはv1.8の中心機能の一つですが、公式説明では任意設定です。すべてのノードが直ちに有効化しなければならない機能ではありません。採用判断では、新機能という理由だけで切り替えず、現在の取引量、優先順位付け、監視体制、ロールバック手順を基準にします。
従来構成を維持したまま運用できる
任意設定であるため、従来構成を保ったままv1.8へ更新する選択肢があります。これは「何も確認しなくてよい」という意味ではありません。バイナリや依存関係は更新されるため、従来経路を選ぶ場合も、設定の解釈、取引受付、ブロック提案、RPC応答が想定どおりかを試験します。
段階導入するなら、まずステージングや限定ノードでアプリ側メンプールを有効にし、従来構成と同じ取引セットを流して比較します。見るべき項目は、受入件数、拒否理由、待機時間、ブロックへの採用順、メモリ使用量、再検査時間です。値の目標を根拠なく置くのではなく、切り替え前の自環境を基準値として保存します。
取引保持・提案選択・直接挿入をアプリ側で担う
まなぶ「取引を直接入れられるなら、必ず早くブロックに入るんですか？」
クリプ「必ずではないよ。入口が変わっても、検証や提案時の選択、混雑、手数料などがあるから、採用結果は実測して確かめるんだ。」
PR #2091では、アプリが取引を保持し、提案へ含める取引を選ぶ新しい経路が実装されました。PR #2119では、CometBFTの従来経路だけでなく、アプリ側メンプールへ直接投入する経路が追加されています。受付経路が増えると、送信成功の判定、重複取引の扱い、優先順位、観測位置も変わり得ます。
RPC事業者やリレイヤーは、「RPCが200番台を返した」「トランザクションハッシュを得た」と「メンプールに保持された」「ブロックへ採用された」を分けて監視してください。dApp側も送信直後を確定扱いせず、レシートやブロック確認まで状態を進める設計が必要です。
再検査、署名検証、nonceキャッシュを監視する
ブロック確定後、メンプールに残る取引は現在の状態でも有効か再検査されます。PR #2118は、この再検査を合意処理のクリティカルパス外で非同期に実行できる設計を示します。待ち時間の短縮が期待される一方、監視画面では再検査中、保持中、排除済みを区別できるようにしておく必要があります。
PR #2120ではEVM署名の事前検証をロックなしで行う変更が入り、PR #2177では取引排除時にante nonceキャッシュを消去し、キャッシュ容量へ独立した上限を設けています。nonceは、同じアカウントから出す取引の順番を示す番号で、主にノード・ウォレット・dApp運用者に関係します。キャッシュと実状態がずれると、正しい取引が拒否されたように見えたり、古い取引が長く残ったりするため、排除件数とnonce関連エラーを合わせて観測します。
Block-STMによる並列EVMの効果と限界
並列EVMは、すべての取引を無条件に同時実行する機能ではありません。Block-STMは取引を投機的に並列実行し、同じ状態へ読み書きするなど競合が見つかった処理を再実行します。最終結果は決定論的でなければならず、各ノードが速度優先で異なる結果を採用する仕組みではありません。
非競合取引を並列処理し競合分だけ再実行
たとえば、互いに関係のないアカウント間の送金や、状態を共有しないコントラクト呼び出しは並列化しやすい一方、同じDEXプール、同じカウンター、同じ残高へ集中する取引は競合しやすくなります。後者では再実行が増え、並列化の効果が小さくなることがあります。したがって、CPUコア数だけから性能を見積もることはできません。
運用時はブロック処理時間だけでなく、競合率、再実行回数、CPU使用率、メモリ、ブロックごとの取引構成を記録します。dApp開発者は、並列化を理由にコントラクトの状態設計を直ちに変える必要があるとは限りませんが、共有状態へ書き込みが集中する処理では負荷試験を行う価値があります。
20％高速化・最大66％増はシミュレーション値
公式記事には約20％の高速化と、特定条件で最大66％の処理量増という説明があります。ただし、これはシミュレーションの結果であり、実メインネット、すべてのノード構成、すべての取引構成で得られる保証値ではありません。最大値だけを容量計画やSLAへそのまま採用しないでください。
比較するときは、アップグレード前後で同じハードウェア、同じデータベース設定、近い取引構成、同じ計測区間を使います。平均値だけでは一時的な遅延を見落とすため、遅い側の分布、タイムアウト、再試行、ブロック追従の遅れも確認します。公表値は検証仮説を立てる材料であり、自環境の測定を置き換えるものではありません。
Osaka対応とEthereum API互換性の確認点
v1.8ではEVM実装とEthereum形式APIも更新されます。Ethereumとの互換性は、同じウォレットや開発ツールを利用しやすくする重要な性質ですが、「互換」という言葉だけで全メソッド、返値、エラー、タイミングが完全一致すると考えるのは危険です。
go-ethereum 1.16.9でOsakaを有効化
PR #2081は、go-ethereum 1.16.9への更新とOsakaの有効化を記録しています。ノード運用者は使用バイナリの版を確認し、独自パッチがある場合はEVM設定との差分を洗い出します。スマートコントラクト開発者は、コンパイラの出力だけで判断せず、デプロイ、call、estimateGas、ログ、リバート時の返値まで一連の試験を行います。
API互換性90％超でも完全互換ではない
まなぶ「互換性が90％を超えるなら、いつものEthereumツールをそのまま使って大丈夫ですか？」
クリプ「多くは使えても、君のdAppが残りの差分に触れるかもしれないよ。実際に呼ぶメソッドと返値をステージングで確かめよう。」
公式説明では、Ethereum APIは80を超えるメソッドをカバーし、互換性は90％超とされています。この数字は対応範囲の広さを示しますが、100％ではありません。dAppが使うメソッドが対応一覧に含まれているか、パラメータと返値の型が想定どおりか、エラーコードやタイムアウト時の挙動が同じかを確認します。
特に、ライブラリが内部で自動呼び出しするRPCは見落としやすい点です。画面に表示する残高取得だけでなく、チェーンID、nonce、ガス見積もり、ログ取得、レシート、過去ブロック照会、デバッグ系メソッドを棚卸しします。複数RPCを切り替える構成なら、事業者ごとに有効なメソッドや制限が異なる可能性も試験します。
ガス見積もりと取引成立条件への影響
ユーザーが直接気づきやすいのは、同じ操作でもガス見積もりや拒否条件が変わる場面です。v1.8にはcalldataに対する最低データガスの強制と、EIP-1559費用を賄う残高検査の適用範囲拡大が含まれます。この二つは関連しますが、別の変更として試験します。
calldataの多い取引は最低データガスを再計算
calldataは、コントラクト呼び出しへ渡す入力データです。PR #2041では、EVM内でcalldataに対する最低データガスを強制する変更が示されています。入力が多いバッチ処理、長い配列、複雑なルーター呼び出し、複数操作をまとめる取引では、従来の見積もりとの差が出る可能性があります。
dAppは固定のgas limitを前提にせず、v1.8接続先でestimateGasを取り直し、実送信でも成功するか確認します。見積もりへ任意の大きな上乗せをするだけでは、ユーザー表示の質や失敗原因の把握が悪化します。入力サイズごとの見積もり、実使用量、失敗理由を記録し、上限を設ける機能では最大ケースも試します。ガス代の基礎はEthereumのガス代の仕組みも参照してください。
EIP-1559費用の残高検査が実行経路全体に拡大
EIP-1559は基本手数料と優先手数料を使うEthereum由来の料金方式で、ウォレット・dApp利用者に関係します。PR #2068は、その費用を賄える残高の検査を、取引をブロック候補へ入れる前に点検するCheckTx以外の実行経路にも適用する修正です。以前に特定経路で受付された取引が、別の実行段階で残高不足になるような不一致を減らす狙いがあります。送信者は、送金額だけでなく最大手数料を含む必要残高を満たす必要があります。
ウォレットやdAppは、送信前の残高表示とノード側の拒否理由を一致させられるか確認します。連続取引では、先行取引が残高やnonceを変え、後続取引の成立条件が変わります。メンプール内に複数取引があるケース、置換取引、手数料条件を変えた再送も試験対象です。ユーザーには「残高不足」だけでなく、送付額と想定最大費用のどちらが不足したかを説明できると混乱を減らせます。
廃止・制限機能とセキュリティ修正を点検
v1.8では、古い機能を呼び続けると明確に失敗する変更や、許可された相手だけに制限する変更があります。アップグレード後もノードが稼働しているだけでは、個別のブリッジや管理処理が使えるとは限りません。利用機能をコード検索し、テストネットまたは安全な検証環境で呼び出し結果を確認します。
ICAとMsgTurnBridgeは利用不可、CRO-to-IBCは許可制
ICA（Interchain Accounts）は別チェーン上のアカウントをIBC経由で操作する機能で、IBC連携事業者が主な対象です。公式説明ではICAが利用不可となり、MsgTurnBridgeもサポート終了後は無処理の成功ではなく明示的に拒否されます。成功応答だけを見て後続処理へ進んでいたシステムは、エラー処理を確認してください。SendCroToIbcは許可済みコントラクトに限定されるため、該当フックを使うコントラクトは許可リストに含まれるかを運営側の情報で照合します。
許可制は、一般ユーザーが任意の送付先を登録すれば回避できるという意味ではありません。運用主体が管理する条件です。未登録時の再試行を無限に続けないこと、資産を別経路へ迂回させる前に公式仕様を確認すること、旧メッセージ型を呼ぶコードを停止することが重要です。
トークンマッピングの検証と再マップ挙動を変更
トークンマッピングは、異なる表現の資産をどのコントラクトへ対応付けるかに関わります。PR #1997では、検証済みマッピング提案の対象アドレスにコントラクトコードが存在することを要求します。CRC21はCronos上の資産対応付けに用いる規格で、トークン管理者が主な対象です。PR #2030では、CRC21の登録先としてゼロアドレスやEthereumのプリコンパイル範囲を拒否します。誤った対象や危険な予約領域への登録を防ぐための検証強化です。
denomはCosmos系で資産の種類を識別する文字列で、トークン管理者やIBC連携事業者に関係します。PR #1998ではdenomを再マップするときの自動マッピングが廃止され、暗黙の対応付けを抑えています。管理ツールが「一つ変更すれば関連付けも自動更新される」と仮定している場合、表示とオンチェーン状態がずれる恐れがあります。提案前、実行後、インデクサー反映後の三段階で、denom、コントラクトアドレス、コード存在、旧対応の残存を照合します。
IBC応答修正とReplayBlock負荷制限を追加
PR #1987にはIBCコールバック応答の修正が含まれます。IBC連携サービスは、成功・失敗応答を正しく解釈し、再送や補償処理が二重に走らないことを回帰試験します。また、ReplayBlockは過去ブロックのメッセージ実行を再現するgRPC照会で、監査ツールやインデクサーの運用者が主な対象です。PR #2131はReplayBlock gRPC照会のメッセージ数と各メッセージのガス量に上限を設け、無制限な再生負荷を抑えます。
照会制限が加わると、大量データを一度に取得していた監査ツールやインデクサーは、分割取得や再開位置の保存が必要になる場合があります。上限到達を一般的なネットワーク障害として再試行し続けるのではなく、エラーを識別し、要求範囲を小さくします。IBCの基本を整理したい場合はクロスチェーン相互運用性の解説も確認してください。
ノード運用者とdApp開発者の確認チェックリスト
進め方は更新前→ステージング検証→本番後の3段階です。 全員必須の版・同期・RPC確認を先に終え、任意機能と該当者限定機能を後から判定します。すべてを一度に切り替えず、現行値の保存、限定環境での試験、本番反映、反映後監視の順で進めます。障害時に戻せる範囲と、チェーンのアップグレード後には戻せない範囲も事前に分けてください。
ノード運用者は設定移行と処理指標を監視
更新前：現行値と戻し方を保存します。検証：限定ノードで取引経路と性能を比較します。本番後：同期、処理時間、資源使用量を監視します。移行可の合格条件は、対象高以降へ追従し、通常・異常取引の扱いが想定どおりで、基準値から許容できない劣化がないことです。
- 稼働バイナリがv1.8系で、対象ブロック101,485,000以降へ追従しているか確認する。
- Cosmos SDK、IBC-Go、CometBFT、RocksDBを含む依存版と独自パッチを記録する。
- アプリ側メンプールを有効にするか決め、設定ファイルの差分をレビューする。
- 受付、排除、再検査、署名拒否、nonceエラー、提案採用までを別の指標で監視する。
- Block-STMの効果を、自環境の競合率、再実行、処理時間、CPU、メモリで測る。
- ReplayBlock照会の上限到達を識別し、監視やインデクサーの要求を分割する。
設定変更前には、秘密情報を除いた設定差分と起動ログを保存します。複数ノードを運用する場合は、同時に全台へ反映せず、役割と冗長性を保てる単位で進めます。異常を検知したら、チェーン全体、接続先ピア、自ノード、RPCフロント、データベースのどこで遅れているかを切り分けます。
同期の確認では、単に最新ブロック番号が増えているかだけでなく、基準にする外部RPCとの差、最新ブロック時刻、ピア数、合意参加状況を並べます。ブロック高が一時的に止まって見えるとき、チェーン全体の停止と自ノードだけの遅延では対応が異なります。二つ以上の独立した参照先と比較し、自ノードだけが遅いならピア接続、ディスク入出力、CPU、メモリ、エラーログの順に範囲を絞ります。
データベース更新後は、RocksDBの新しい版や調整プロファイルによって、読み書きの傾向が変わる可能性があります。平均レイテンシだけでなく、コンパクション中の遅延、ディスク使用量の増え方、再起動後に追従するまでの時間を観測します。スナップショットから復元する運用がある場合は、作成、転送、復元、整合性確認までを一度通し、緊急時に初めて手順を実行する状態を避けます。
アプリ側メンプールを比較するときは、正常な単発取引だけでは差が見えません。同一アカウントからnonceが連続する取引、署名が不正な取引、残高不足、同じnonceを使う置換候補、ブロック確定後も残る取引を混ぜます。それぞれが受付、保留、排除、再検査のどこへ進んだかを追えば、キャッシュの不整合や監視漏れを発見しやすくなります。テスト用鍵と資産だけを使い、本番利用者の取引を再現用に無断転用しないことも大切です。
dApp開発者はRPC・ガス・廃止機能を回帰試験
更新前：利用RPCと機能依存を棚卸しします。検証：実入力で成功・失敗ケースを再現します。本番後：エラー率、確定時間、再試行を追います。移行可の合格条件は、主要操作の返値と画面表示が一致し、ガス不足や廃止機能のエラーを誤って成功扱いしないことです。
- 実際に使用する全RPCメソッド、パラメータ、返値、エラー処理を一覧にする。
- calldataが小さい取引と大きい取引のestimateGasおよび実使用量を比較する。
- EIP-1559取引で残高不足、連続送信、置換、再送の各ケースを試す。
- ICA、MsgTurnBridge、SendCroToIbcに依存するコードと運用手順を検索する。
- トークンマッピング後のdenom、アドレス、コード存在、表示を照合する。
- 送信受付、メンプール保持、ブロック採用、レシート確定を別の状態として扱う。
回帰試験はフロント画面の操作だけでなく、バックエンド、ジョブ、監視、障害時の再送も対象です。SDKやライブラリが裏で呼ぶRPCをアクセスログから確認し、未対応メソッドや返値差を見逃さないようにします。スマートコントラクトの仕組み自体を復習したい場合はスマートコントラクトの基礎解説も役立ちます。
試験用の取引一覧には、読み取りだけのcall、通常送金、コントラクトへの書き込み、イベントを出す処理、意図的にリバートする処理を含めます。各ケースでトランザクションハッシュ、見積もりガス、使用ガス、ステータス、ログ、エラー内容を保存します。成功ケースだけを並べると、互換性差が表れやすい失敗応答を確認できません。ユーザーが操作を再試行したとき、二重実行されないかも合わせて検証します。
RPCの回帰試験では、最新状態だけでなく過去ブロックを指定する照会、広い範囲のログ検索、ページングを伴う取得も確認します。公開RPCには、v1.8の仕様とは別に事業者独自のレート制限や取得範囲制限があります。制限応答を未対応APIと取り違えないよう、HTTPステータス、JSON-RPCのエラーコード、メッセージ、応答時間を記録します。フェイルオーバー先でも同じ試験を行い、切り替えた瞬間に返値形式が変わらないかを調べます。
ガス試験では、calldataの長さだけを変えたケースを用意すると、最低データガスの影響を他の実行コストと分けて観察できます。配列要素数、文字列長、バッチ件数を段階的に増やし、estimateGasと実使用量の関係を記録します。同時に、残高が十分な場合、送付額だけなら足りるが最大費用込みでは足りない場合、先行取引後に不足する場合を分け、画面表示とノードの拒否理由が一致するかを見ます。
ブリッジやトークンマッピングを扱うサービスでは、資産名だけでなく、チェーンID、denom、コントラクトアドレス、送信元と送信先の対応を試験記録へ残します。同名トークンや古いマッピングを画面上の名称だけで区別するのは不十分です。MsgTurnBridgeのように明示的な拒否へ変わる機能は、エラーを握りつぶして成功表示しないことを確認し、廃止された操作を案内するヘルプや自動ジョブも同時に更新します。
本番反映後の監視期間には、技術指標と利用者影響を結び付けます。RPCエラー率だけでなく、送信画面の失敗率、確定までの時間、再試行回数、問い合わせ内容を見ます。ただし、アップグレード前後で利用量や取引構成が違えば単純比較はできません。計測区間と条件を残し、異常がv1.8の仕様、RPC事業者の制限、dAppの実装、利用者の残高のどれに由来するかを一件ずつ分類します。再現できた問題には、使用したRPC、ブロック高、取引ハッシュ、入力条件、期待結果、実結果を添えます。秘密鍵や個人情報は記録へ含めず、チーム内で同じ手順を再実行できる形に整えれば、修正後の確認にも使えます。
運用者と開発者にとって重要なのは、自分の経路で取引が受け付けられ、正しく実行され、想定どおり観測できることです。適用高と版、任意設定、RPC、ガス、廃止機能の確認記録を移行判断の根拠にしてください。類似の更新で対象者別の確認方法を見るなら、他チェーンのアップグレード事例も参考になります。
検証・編集体制：クリプトラボ編集部が、Cronos Labsの公式記事、公式GitHubリリースと実装PR、公開RPC、事業者ステータスを2026年10月26日12:00 JSTに照合しました。適用高と公開RPCの表示は公開環境で確認し、個別機能の挙動は公式資料に基づいて整理しています。独自ノードや各dAppでの実機検証を代替するものではありません。
