Shardeum v1.1.0とは？Cosmos EVM v0.6.3移行の影響と対応

SHMの移行やMetaMaskの更新は原則不要です。ただし、Shardeum v1.1.0の停止前後は送金、dApp、ブリッジ操作を待ち、利用先が再開を案内してから操作してください。

アップグレードはブロック高7,927,860で実施予定です。公式案内の目安は日本時間2026年10月13日15時前後ですが、この記事の最終確認時刻である12時時点では未完了です。実施条件は時計ではなくブロック高であり、完了と各サービスの再開も別々に確認します。

以下では、まず利用者が取るべき行動を示し、その後に停止型更新の理由、Cosmos EVM v0.6.3の変更、事業者・ノード運用者の手順を解説します。価格予測ではなく、公開資料で確認できる技術面と運用面が対象です。

一般利用者とSHM保有者が最初にすること

一般利用者の基本方針は、事前に不要な操作を増やさず、停止前後に重要な送信を避け、公式情報を確認することです。アップグレードを装った偽サイトが「資産移行」「ウォレット同期」「再認証」を求めても、シードフレーズや秘密鍵を入力してはいけません。

ウォレット利用者の事前更新は不要

Shardeumの公式案内は、通常利用者に事前のソフト更新操作は不要としています。SHMを別トークンへ交換したり、残高を新しいアドレスへ移したりする手続きも示されていません。自己管理ウォレットの利用者は、公式ウォレットや利用中のアプリから更新通知が出た場合に、その配布元を確認して対応します。

「アップグレード前に必ず送金しないと失う」といった非公式メッセージは、今回の資料に根拠がありません。安全な送金の基本は暗号資産を安全に送金する方法でも確認できます。焦って送るより、ネットワークが安定してから少額テストを行うほうが確認しやすくなります。保管方法を見直す場合はウォレットの選び方も確認できます。

停止中は送信やdApp操作を控える

ネットワーク停止中は、新しいブロックに取引を取り込めません。ウォレット画面で送信操作ができても、取引が保留になる、RPCがエラーを返す、dApp側が結果を確定できない可能性があります。ブリッジでは送信元と送信先の確認が別々に必要になるため、停止時間をまたぐ操作は特に避けるのが無難です。

すでに送信して保留になった場合、同じ取引を何度も作り直す前に、トランザクションハッシュ、送信元のnonce、エクスプローラー表示を確認してください。焦って別の送金を重ねると、復旧後の処理順を把握しにくくなります。利用するウォレットやdAppのサポート案内を優先します。再送時に気になる手数料はガス代の仕組みで確認できます。

ウォレット表示とサービス復旧は同時とは限らない

ブロック生成が再開しても、ウォレットのRPC、インデクサー、ブリッジ、取引所の入出金システムが同時に復旧するとは限りません。残高表示はキャッシュやインデックス更新の遅れを受けることがあります。画面上の表示が一時的に古くても、直ちに資産消失を意味するわけではありません。

過去のShardeum EVMメインネット移行でも、取引所サービスは確認後に段階的に再開されました。過去の事例は今回の時間を保証しませんが、「チェーン再開」と「各社の入出金再開」が別判断であることを理解する手掛かりになります。

Shardeum v1.1.0アップグレードの要点

今回の更新は、Shardeumのオンチェーンガバナンスで承認されたメインネット更新です。中心となる変更は、Shardeum EVMの実装を上流のCosmos EVM v0.6.3へ合わせることです。更新の境界は日時ではなくブロック高で指定され、ネットワークはいったん停止したうえで、対応版へ切り替えたバリデータが十分に復帰してからブロック生成を再開します。

Proposal #1で承認された更新内容

公式発表によると、Proposal #1は参加投票力の100%の賛成で可決され、賛成投票力は759,659,283.2 SHMでした。ここでいうガバナンス提案は、単なる意向調査ではなく、どの更新計画をどの高さで実施するかをネットワーク参加者が承認する手続きです。結果は公式のガバナンスダッシュボードでも確認できます。

承認されたからといって、更新作業がすでに終わったわけではありません。承認は実施条件を確定する段階であり、その後に指定高への到達、旧ソフトの停止、新ソフトでの起動、状態移行、十分な投票力の復帰という工程があります。ニュースを読むときは「可決」「開始」「完了」「各サービス再開」を分けて捉える必要があります。

実施はブロック高7927860、時刻は目安

実施点はブロック高7,927,860です。公式案内は日本時間10月13日15時前後を見込んでいますが、ブロックは常に一定間隔で生成されるとは限りません。したがって、15時という時計の時刻よりも、チェーンが対象高へ到達したかが実際の切り替え条件になります。

利用者は予定時刻の直前だけを避ければよい、と考えないほうが安全です。前後の余裕を取り、公式エクスプローラーでブロックの進行を確認し、利用する取引所やdAppが再開を明示するまで重要な操作を待つと、送信後に長く保留される状況を避けやすくなります。

所要時間は1〜2時間見込み、完了前の断定に注意

公式の見込みは1〜2時間です。ただし、これは保証された終了時刻ではありません。対応バリデータが戻り、合意形成に必要な投票力がそろい、新しいブロックが継続して生成されるまで、取引やdAppは一時的に利用できなくなります。検証中に追加対応が必要になれば、停止が見込みを超えることもあり得ます。

本記事の予定公開時刻は12時で、目安の15時より前です。このため「アップグレードに成功した」「すべて復旧した」とは記載しません。読者も、時刻を過ぎたことだけで完了と判断せず、後半で紹介する複数の確認先を組み合わせてください。

MetaMaskやdAppへの互換性影響

互換性の話では、Cosmosネイティブ取引とEthereum形式の取引を分けることが重要です。v1.1.0にはCosmosネイティブの動的手数料拡張に関する型URL変更がありますが、公式リリースはEthereum形式の取引や主要なJSON-RPCツールを変更対象から切り分けています。

型URL変更の対象となるCosmosネイティブ取引

Cosmos SDKでは、メッセージや拡張情報の型を識別するために型URLが使われます。今回、動的手数料拡張の型URLが変わるため、Cosmosネイティブ形式で取引を構築し、その拡張を直接扱うクライアントは新しい定義に合わせる必要があります。古い型名を固定的に組み込んだ署名・送信処理は、事前の互換性試験が必要です。

これは主にウォレット開発者、取引所の入出金基盤、SDKを使う事業者が確認する項目です。一般利用者が型URLを手入力する場面は通常ありませんが、利用するサービスが旧実装のままだと送信を受け付けない可能性があるため、サービス側の更新案内を待ちます。

Ethereum形式取引と主要JSON-RPCツールは対象外

MetaMaskのようなEthereumウォレットは、通常、Ethereum形式の署名済み取引をJSON-RPC経由で送ります。公式リリースでは、今回の型URL変更はこの経路を対象としていません。そのため「Cosmosネイティブの型URLが変わる」ことを根拠に「MetaMaskが非対応になる」と一律に結論付けるのは不正確です。ネットワーク追加などの基本はMetaMaskの設定方法も参照してください。

もっとも、停止中は接続先RPCが応答しない、最新ブロックが進まない、残高表示が一時的に更新されないといった運用上の影響はあり得ます。プロトコル上の取引形式が対象外であることと、サービスが停止時間なく使えることは別です。dApp側もRPCの復旧とチェーンID、最新高、送信結果を確認する必要があります。

移行名とリリース番号を混同しない

今回の配布ソフトのリリース番号はv1.1.0ですが、チェーン上の更新計画名は「v0.4.0-to-v0.6.3」です。前者は取得・検証するShardeumソフトウェアの版、後者は指定高で実行する移行ハンドラを識別する名前です。

名前が二つあるのは誤記ではありません。運用者はバイナリがv1.1.0であることに加え、そのバイナリが計画名に対応する処理を持つことを確認します。利用者は両者を覚える必要はありませんが、異なる表記を見て別のアップグレードだと誤解しないようにしましょう。

なぜ停止型アップグレードと状態移行が必要なのか

ブロックチェーンのノードは、同じ取引を同じ規則で計算し、同じ結果へ到達することで一つの台帳を維持します。互換性を壊す変更を各運用者が好きな時刻に適用すると、同じ入力から異なる状態を作るおそれがあります。そこで今回のようなstate-breaking版では、共通の高さを境界として停止し、足並みをそろえて再開します。

state-breaking版は旧状態との互換性が変わる

「state」は、口座残高、コントラクトの保存値、モジュールが管理する情報など、チェーンが現在までに蓄積した状態を指します。「state-breaking」は、それらを扱う規則や形式に互換性を壊す変更が含まれることを示します。これは過去の履歴を削除するという意味でも、利用者のSHMが自動的に失われるという意味でもありません。

重要なのは、旧版と新版が同じ状態を異なる方法で処理しないようにすることです。Cosmos EVM v0.6.3のリリースはstate-breakingであることを示し、協調した更新を求めています。旧バイナリのままでは新規則を理解できず、指定高で停止する可能性があります。

指定高で全ノードを止めるx/upgradeの役割

Cosmos SDKのx/upgradeは、更新計画の名前と実施高をチェーン上で共有し、対応していないノードを境界で止めるための仕組みです。対応版はその名前に結び付いた更新処理を持ち、指定高で必要な移行を行ってから処理を続けます。全ノードを遠隔操作する仕組みではなく、各運用者が正しいソフトを準備することが前提です。

停止は障害ではなく、互換性のない状態で誤って進み続けることを防ぐ安全装置として機能します。古いノードだけが止まる場合も、新版の起動が早すぎて想定外の挙動になる場合もあるため、運用者は公式手順にある起動タイミングを守る必要があります。

バイナリ更新と保存済み状態の移行は別の工程

バイナリ更新は、実行するプログラムをv1.1.0へ置き換える作業です。一方の状態移行は、すでにディスク上にあるチェーン状態を新版の規則で利用できる形へ変換する処理です。新しい実行ファイルを置いただけでは、保存形式やモジュール版の差が自動的に解消されるとは限りません。

Cosmos SDKのIn-Place Store Migrationsは、既存ストアをその場で移行し、モジュールごとの版を管理する考え方を説明しています。運用者にとっては、実行ファイルの検証、データのバックアップ、更新ハンドラの実行、再起動後の同期確認を別々の工程として扱うことが大切です。

Cosmos EVM v0.6.3移行で変わること

Shardeum v1.1.0は、上流のCosmos EVM v0.6.3へ実装を再同期します。Cosmos EVMは、Cosmos SDK上でEthereum Virtual MachineとEthereum向けの開発・利用体験を提供するための実装です。今回の更新は単一の機能追加ではなく、v0.4系からv0.6.3までの変更系列をShardeum側へ取り込む位置付けです。

Shardeum実装をCosmos EVM v0.6.3へ再同期

再同期とは、Shardeum固有の実装を保ちながら、基盤として利用する上流プロジェクトの変更へ追随させることです。上流と長く離れたままでは、修正の取り込みや互換性の維持が難しくなります。v1.1.0はCosmos EVM v0.6.0、v0.6.1、v0.6.2、v0.6.3に積み重なった変更を含むため、差分の範囲が広くなっています。

ただし、上流版の全項目が一般利用者の操作を直接変えるわけではありません。低層の状態処理、内部呼び出し、モジュール口座の防御などは、主にノードが正しく同じ結果を計算するための変更です。利用者は、ウォレットの資産を別の場所へ移すより、利用サービスの停止と再開の案内を確認することが中心になります。

v0.6.xで積み重なったStateDB関連修正

公開されたリリースと比較差分では、StateDBに関係する複数の修正を確認できます。v0.6.3の差分には、Commitの原子性を改善し、処理が失敗した場合に一部だけ書き込まれた状態を残しにくくする修正が含まれます。原子性とは、複数の変更を「全部成功」または「全部失敗」として扱う性質です。

v0.6.1にはlocked balanceのスナップショットなどの修正があり、v0.6.2も重要なセキュリティ修正を含むstate-breaking版として案内されています。これらは台帳処理の堅牢性に関係しますが、公開資料にない具体的な攻撃や過去の被害を推測してはいけません。「セキュリティ修正がある」という事実と、「何が悪用されたか」という未確認情報を分ける必要があります。

v1.0.2の先行セキュリティ修正との関係

Shardeum v1.0.2は、Cosmos EVM側の重大な修正とShardeum側の防御を先行して取り込んだセキュリティ版でした。v1.1.0は、その先行対応を捨てるのではなく、正式な上流v0.6.3系列へ再同期したうえで引き継ぐ位置付けです。

版番号が上がる理由を「新機能が増えたから」だけで理解すると、状態移行の重要性を見落とします。今回の中心は、上流の修正系列と整合し、将来の保守をしやすくすることです。変更の確認には公式リリースだけでなく、Shardeum EVMのCHANGELOGも補助資料になります。

ここからは事業者・ノード運用者向けです。一般利用者は「復旧確認」まで読み進めれば、操作再開の判断材料を確認できます。

取引所・dApp・インフラ事業者への影響

サービス提供者は、利用者より広い範囲を確認します。ノードの対応版、入出金キュー、インデクサー、RPC、監視、カスタマーサポートを同じタイムラインで管理しなければなりません。公式推奨時刻は全社共通の確定停止時刻ではなく、各社が自分のシステム状況に応じて判断します。

入出金停止の推奨時刻と各取引所の判断

Shardeumは取引所に対し、10月13日02:00 UTCごろ、すなわち日本時間11時ごろからSHMの入出金を停止することを推奨しています。これは安全余裕を持たせるための公式推奨であり、すべての取引所が同じ分に停止すると確定した情報ではありません。

利用者は、自分が口座を持つ取引所の告知で停止対象を確認します。「取引」と「入金」と「出金」は別機能で、現物売買は続けながらオンチェーン入出金だけ止める場合もあります。公式ブログの予定だけを見て、個別取引所の機能状態を推測しないでください。

取引・入出金の再開には時間差があり得る

取引所は、チェーンがブロックを再開しただけで直ちに入出金を開くとは限りません。十分な確認数、ノード同期、入金検知、出金署名、残高照合をテストしてから再開するためです。ある取引所が再開しても、別の取引所が同時に再開する保証はありません。

事業者は停止前に未処理の入出金を把握し、復旧後に二重計上や取りこぼしがないか照合します。利用者向け告知には、停止対象、開始時刻、再開条件、保留取引の扱いを分けて示すと誤解を減らせます。予定を確定時刻として案内しないことも重要です。

dAppとRPCは更新後に同期・応答を再確認

dApp運営者は、接続RPCがv1.1.0に対応し、最新高まで同期し、Ethereum JSON-RPCへ正しい応答を返すことを確認します。単にHTTP応答が返るだけでは不十分で、ブロック番号、チェーンID、残高照会、読み取り呼び出し、取引シミュレーション、送信、レシート取得まで段階的に試します。

複数RPCへフェイルオーバーする構成では、一部だけ旧版や同期遅れのノードが混ざると、呼び出しごとに結果が揺れる可能性があります。ロードバランサーへ戻す前に各バックエンドを個別に検査し、インデクサーやイベント購読も停止高から欠落なく追いついたかを確認します。

バリデータとノード運用者の更新手順

以下は公開資料を理解するための順序です。実作業では、必ずShardeumの公式ノード文書とv1.1.0リリースに記載されたコマンド、ファイル名、ハッシュをその場で照合してください。第三者の記事から秘密鍵を伴うコマンドをコピーしないことが重要です。

v1.1.0を取得し成果物ハッシュを検証

最初に、公式GitHubリリースまたは公式が指定するレジストリからv1.1.0を取得します。ダウンロード元のドメイン、タグ、対象アーキテクチャを確認し、リリース記載のSHA-256またはDocker digestと手元の成果物を照合します。ファイル名が同じでも内容が正しいとは限らないためです。

コンテナ利用時も、可変タグだけに依存せずdigestで内容を固定すると、どのイメージを起動したか追跡しやすくなります。検証結果、取得時刻、実行予定のパスを運用記録に残し、ロールバック判断に必要な旧版情報も保存します。

バックアップを取り指定高まで待機

設定ファイル、バリデータ運用に必要な重要ファイル、データディレクトリなど、公式文書が指定する対象を退避します。バックアップは作成しただけでなく、保存先、権限、復元可能性を確認します。秘密鍵は安全な既存手順の範囲で扱い、チャットや共有ストレージへ平文で移してはいけません。

v1.1.0は事前に取得できますが、公式文書は指定高より前に起動しないよう明示しています。旧版で対象高まで追従し、想定された停止を確認してから切り替えます。早期起動は互換性のない規則を先に適用する危険があり、準備完了と起動可能を混同しないでください。

指定高到達後に起動して同期状態を確認

指定高への到達後、公式手順に従って旧プロセスを確実に停止し、検証済みのv1.1.0で起動します。ログで移行処理の開始と終了、致命的エラーの有無、ピア接続、最新高を確認します。バリデータは署名状態や投票参加も監視し、二重起動を避けます。

プロセスが起動中であることと、チェーンへ正常に参加していることは同じではありません。ローカルの高さがネットワーク最新高へ追いついているか、catching_up相当の状態、RPC応答、ブロックの連続取得を確認します。異常時は場当たり的にデータを削除せず、ログとバックアップを保持して公式サポート経路へ報告します。

アップグレード完了とサービス復旧の確認方法

復旧は一つの緑色表示だけで判断しません。公式の完了告知、オンチェーンのブロック進行、個別ノードの同期、RPCの機能、利用サービスの再開案内は、それぞれ別の状態を表します。自分が利用者か運用者かに応じて必要な層まで確認します。

公式告知とガバナンス情報を確認

まずShardeum公式ブログや公式コミュニケーションで、アップグレード開始・完了・既知の問題に関する案内を確認します。Proposal #1の可決結果はガバナンスダッシュボードで検証できますが、投票結果は実施後の稼働状況を示すものではありません。

SNSの短い投稿だけでなく、リンク先が公式ドメインか、投稿時刻が最新かを確認します。予定告知が検索結果の上位に残り、完了告知より目立つこともあります。障害や延長の案内が追加されていないか、時系列で読みます。

エクスプローラーでブロック生成再開を確認

公式エクスプローラーでは、最新ブロック高が7,927,860を超え、その後も増えているかを確認できます。一つ新しいブロックが表示されたことは重要な兆候ですが、継続して生成されているか、時刻が更新されているかも見ます。単発の表示だけで安定稼働を断定しません。

エクスプローラー自体もRPCやインデクサーに依存するサービスです。表示が遅れていてもチェーンが止まっているとは限らず、反対に画面が開くことだけで最新データとは限りません。運用者は公式エンドポイントと自ノードの高さも突き合わせます。

RPC・ノード同期・取引所案内を個別に確認

ウォレット利用者は、利用中のRPCで残高と最新高が更新されるかを見ます。dApp事業者は読み取り・送信・レシート取得を、ノード運用者は同期とピアを、取引所利用者は各社の入出金再開告知を確認します。ある層が復旧しても、別の層に遅れが残ることがあります。

送金を再開する場合は、宛先ネットワークとアドレスを再確認し、利用サービスが明示的に再開した後に少額で試す方法があります。ただし、少額テストも損失を完全に防ぐものではありません。SHMを保有するか売買するかは、アップグレードの成否だけで決められるものではなく、価格変動や各自の状況を含めた判断が必要です。

まとめ：立場ごとに更新状況を確認する

Shardeum v1.1.0は、ブロック高7,927,860でネットワークを止め、Cosmos EVM v0.6.3へ移行する協調型アップグレードです。日本時間10月13日15時前後は目安であり、予定公開時刻の12時時点では未完了です。通常利用者に事前更新は不要ですが、停止前後の送信、dApp、ブリッジ操作は控え、利用先の再開を待ちましょう。

運用者はv1.1.0のハッシュやdigestを検証し、バックアップを取り、指定高より前に新版を起動しないことが重要です。完了後は、公式告知だけでなく、ブロックの継続生成、RPC応答、ノード同期、取引所の個別案内を分けて確認します。アップグレードは技術・運用上の更新であり、それだけを根拠にSHMの価格や投資成果を予測することはできません。

検証・編集体制：クリプトラボ編集部がShardeum公式ブログ、公式GitHubリリース、公式運用ドキュメント、ガバナンス画面、公式エクスプローラーを2026年10月13日12:00 JSTに照合し、技術資料に基づいて編集・技術確認しました。誤りが判明した場合は訂正し、実施後はステータス、本文、FAQを更新します。

最終行動：一般利用者は利用先の再開を待ち、取引所利用者は各社告知、事業者は同期と送信試験、バリデータは移行ログと署名参加を確認してください。最新情報はShardeum公式案内を優先します。