Cronos v1.8:空の保留中取引一覧をどう読むか
Cronosのアップグレード予定高度がエクスプローラーに記録された。任意で有効にするアプリ側mempoolは、保留中の取引が見える場所と空の応答の意味を変える。

AI生成の概念イラスト。技術者が空の区画から、隣の封筒が入った区画へ視線を向ける。保留中取引を見る経路の違いを表し、実際の障害やCronosの画面を再現したものではない。
要点
- Chainstackは10月22日08:00 UTCにアップグレード保守の完了を記録した。Cronos Explorerでは予定ブロック101,485,000の時刻が07:52:24 UTCと表示され、次のブロックとの接続も確認できる。
- アプリケーション側mempoolは任意の設定。有効にすると一部の従来の保留中取引照会が空になり、txpoolメソッドがアプリ側のプールを読む。
- プールの管理、並列実行、実験的なネットワーク機能は別々の変更だ。予定高度の通過だけでは、全ノードの設定や実測性能は分からない。
出来事のタイムライン
リリースにはPre-releaseの表示があり、ただちにバイナリを交換しないよう案内された。
Cronosは10月22日を予定日とし、任意のmempool、並列実行、実験的なlibp2pを区別した。
ブロック101,485,000の時刻は07:52:24 UTC。Chainstackの保守完了記録は08:00 UTCであり、二つは意味の異なる記録だ。
予定高度の通過と、記録が示す範囲
CronosはEVM v1.8のメインネット更新を2026年10月22日に予定していた。今は日付以外の記録も確認できる。Chainstackの保守告知は高度101,485,000を指定し、08:00 UTCに完了を記録した。Cronos Explorerはこのブロックの時刻を07:52:24 UTCと表示し、次の101,485,001の親ハッシュはそのブロックを指している。エクスプローラーの履歴では、告知された高度を通過している。[1][3][4][5]
ただし、それぞれの観測には限界がある。ブロック時刻はチェーンの記録であり、08:00は事業者の保守記録だ。ネットワーク全体の正確な有効化時刻を測った値ではない。CoinYQはバリデーターの実行ソフトウェアのバージョンを独立に確認していない。リリース一覧にはv1.8.0が依然としてPre-releaseと表示される。この表示や保守完了の印だけで、全運用者がどのオプションを有効にしたかは分からない。[3][4][5][6]
一つのノードの待合室を見る二つの窓
取引フィードを見る人が見落としやすい変更は、任意で選ぶ待機プールにある。mempoolはブロックへの取り込みを待つ取引を保持する場所だ。従来のCronosでは合意層のCometBFTが管理していたが、v1.8では運用者がその役割をアプリケーションに移せる。移行ガイドはこれを任意の変更とし、既存の設定もそのまま動くと説明している。[2]
選択によって、プールを見る窓が変わる。ガイドによると、appモードではCometBFTの/unconfirmed_txsと/num_unconfirmed_txsに保留中の項目が現れず、eth_newPendingTransactionFilterとpendingフィルターも結果を返さない。代わりにtxpool_contentとtxpool_statusがアプリ側のプールを読む。floodモードではCometBFTの照会が機能する一方、これらのtxpoolメソッドは空のアプリ側プールを見る。一つのインターフェースの空の応答だけでは、そのノードに待機中の取引がないとは判断できない。[2]
ブロックの前の仕事を移し、中の仕事を分ける
なぜプールを移すのか。Cronosの発表は、取引の受付とブロックの構成で処理を共有し、検証の重複を減らすと説明する。ブロック処理後の再検証も、合意処理と同じ経路で競合する代わりにバックグラウンドで実行できる。次のブロックの前に仕事をどう配置するかという変更であって、送信した取引がすでに取り込まれたり確定したりした証拠ではない。[1][2]
Block-STMが扱うのは別の段階だ。ブロック内の取引を並列実行し、競合を検出すると影響を受ける取引を再実行する。移行ガイドは利用を推奨するが、記載されたblock-executorの既定値はsequentialだ。ソフトウェアのバージョン、プールの選択、実行モードは別々の情報になる。アプリ側プールを有効にする際には適合する容量設定も必要で、プールを無効にする値max-txs = -1はappモードと併用できない。[1][2]
アップグレードだけでは決まらないこと
他の更新項目も条件を読む必要がある。10月14日の発表ではlibp2pを実験的な対応とし、当時はメインネットで未有効化と説明していた。v1.8にコードがあることだけでは、その後の有効化を確認できない。移行ガイドも、取引当たり16,777,216のガス上限には別途ガバナンス変更が必要であり、更新高度で自動適用されないとしている。本稿では、この二項目の後続変更は確認していない。[1][2]
ダッシュボードを作る人や待機中の取引を調べる人にとって、実務上の問いは、そのエンドポイントがどのプールを公開しているかだ。ガイドは、従来の照会を必要とする利用者のためにfloodを維持するか、txpool名前空間を有効にして利用側をそのメソッドへ移すよう案内する。予定高度を通過した今、この違いを理解する意義がある。空の一覧は静かなネットワークの証拠にはならず、実際の実行時間や照会の遅延を測る代わりにもならない。[2][3][4]
続けて読みたいストーリー
同じテーマを、別の事例や背景から考えてみましょう。
出典・参考文献
- [1]出典 1: Cronos Labs — Cronos EVM Mainnet v1.8 UpgradeCronos Labs · 2026-10-14確認 2026-10-22
- [2]出典 2: Cronos v1.8.0 — migration guide, pending-transaction views and defaultsCronos確認 2026-10-22
- [3]出典 3: Chainstack — Cronos Mainnet Upgrade maintenance recordChainstack確認 2026-10-22
- [4]出典 4: Cronos Explorer — block 101,485,000Cronos Explorer確認 2026-10-22
- [5]出典 5: Cronos Explorer — block 101,485,001 and parent hashCronos Explorer確認 2026-10-22
- [6]出典 6: Cronos — v1.8.0 release notesCronos · 2026-09-24確認 2026-10-22


