MultiversXは、ネットワークの仮想マシン層におけるトランザクションのアトミック性の問題を悪用しようとする攻撃を受け、無効な変更がオンチェーンに記録されたとして、メインネットの運用を停止しました。チームはブロック生成を停止し、パッチをシャドウフォークでのテストに回し、選択的リカバリーを評価中であると述べています。確認された損失額はまだ公表されていません。

MultiversXが確認したこと

• 問題はトランザクションのアトミック性に関係していた。
• 無効な変更がオンチェーンに記録された。
• メインネットの運用が停止された。
• パッチがシャドウフォークでのテストに入った。
• 選択的リカバリーが評価されていた。

依然として不明な点

• ユーザーが資金を永久に失ったかどうか。
• 影響を受けたアカウントやコントラクト。
• 攻撃者がどのように障害を引き起こしたか。
• どのリカバリー手法が採用されるか。
• すべてのサービスがいつ再開されるか。

停止は問題を凍結したものであり、解消したものではない

インシデント更新の中でMultiversXは、攻撃者がメインネットの仮想マシン層におけるアトミック性の問題を悪用しようとしたと述べました。開発者は、発生したステート変更を追跡しパッチを準備する間、ネットワーク運用を停止しました。確認された損失額は公表されていません。

ブロック生成を停止することで、すでに不正になっている可能性のあるレコードの上に新たなトランザクションが積み重なるのを防ぎ。また、エンジニアがどの残高やコントラクトのエントリーが影響を受けたかを特定する間、同じ手法による再攻撃も阻止します。

この停止は、ネットワークがすでに受け入れた変更を取り消すものではありません。MultiversXがリカバリー計画を採用するまで、それらのレコードはウォレット、アプリケーション、ブリッジが使用する出発点であり続けます。

9月20日に確認したところ、MultiversXのステータスページはシステムを「部分的に低下」と分類していました。公開API、xPortal、Explorer、Wallet、Bridge、xExchange、xLaunchpadでパフォーマンスの低下が表示され、ゲートウェイとインデックスは稼働中と表示されていました。

これらのラベルは個別のサービスを示すものであり、通常のトランザクション処理が再開したことを確認するものではありません。インターフェースを復旧させても、根底にある会計問題は解決しません。その理由を理解するには、まずトランザクションのアトミック性から説明する必要があります。

アトミック性とは、ブロックチェーン版の「全か無か」

スマートコントラクトのトランザクションには、複数の関連する操作が含まれることがあります。ある残高が減り、別の残高が増え、流動性プールが更新されるといった具合です。アトミックな実行では、それらの変更のいずれかが恒久的なものになる前に、シーケンス全体が成功しなければなりません。

期待される結果: すべての必須ステップが成功し、すべての変更がまとめてコミットされます。いずれかのステップが失敗した場合、トランザクションの変更は一切コミットされるべきではありません。

アトミック性の失敗: ある操作が失敗したのに、それ以前のステート変更が残る場合です。ネットワークは、単独では存在すべきでない部分的な結果を記録してしまう可能性があります。

これはアトミック性の簡略化した例であり、MultiversXインシデントの再現ではありません。壊れたトランザクションは、アカウント残高、トークンの供給量、コントラのレコードを意図された結果と矛盾した状態にする可能性があります。MultiversXはどの種類のデータが改変されたかを公表していないため、攻撃者がトークンを作成した、特定のコントラクトから資金を引き出した、既知の金額を盗んだと断定する十分な証拠はありません。

ファイナリティは合意を証明するものであり、バグのない実行を証明するものではない

ブロックチェーンのファイナリティとは、バリデーターがどのブロックと結果のステートが正規チェーンに属するかで合意したことを意味します。そのステートを計算するために使用されたソフトウェアに欠陥がなかったことを証明するものではありません。

バリデーターは同じプロトコルルールを実行し、結果を比較します。そのルールにすべてのノードで同じ欠陥が含まれている場合、バリデーターはプロトコルが決して許可する意図のなかった結果について一貫して合意することがあり得ます。コンセンサスはネットワークが受け入れたステートがどれかを確定できますが、ソフトウェアのバグがそのステートの生成に関与していなかったことを保証することはできません。

修正済みソフトウェアをインストールすれば、同じ実行パスが再び機能するのを防げますが、すでに記録された変更をどう扱うかは決まりません。MultiversXは影響を受けたエントリーを特定し、無関係なアクティビティが変更されていないことをバリデーターが検証できる再現可能な方法を提供しなければなりません。

シャドウフォークはメインネット再開前のリハーサルを提供する

MultiversXはシャドウフォーク環境でのテスト用にパッチを準備しました。シャドウフォークは関連するメインネットの履歴とステートを隔離された環境にコピーし、エンジニアが実際の残高を実験に使うことなく、実際のネットワーク条件を再現できるようにします。

チームはパッチを適用し、影響を受けたシーケンスを再生し、バリデーターがメインネットにインストールする前に提案されたリカバリーをテストできます。そのプロセスで以下を確認する必要があります。

• ノードが同じ修復済みステートを計算するか。
• 影響を受けていない残高が変更されずに残るか。
• アプリケーションが修正されたレコードを正しく読み取れるか。
• ブリッジや取引所がデータを整合させられるか。
• バリデーターが競合するチェーンを生成せずに再開できるか。

これらのテストに合格しても、すべてのサービスが自動的に再開されるわけではありません。展開には、バリデーター、取引所、ブリッジ、ユーザーとアプリケーションをMultiversXにつなぐインフラ事業者の調整が依然として必要です。

選択的修復ならチェーン全体の巻き戻しを回避できる

MultiversXは、最終確定されたトランザクション履歴と正規のユーザーレコードを保持しつつ、インシデントに関連する変更のみを対象とする選択的リカバリーを評価していると述べました。ジェクトはその修正がどのように実装されるかをまだ説明していません。

選択的ステート修正。 インシデントに関連する残高、コントラクトストレージ、その他のレコードのみが修復され、無関係なトランザクションは最終確定済み履歴に残ることができます。主な難題は、修正にすべての無効な変更が含まれ、それ以外が含まれないことを証明することです。

広範なチェーンロールバック。 ネットワークはより早いブロックに戻り、そこから再構築します。その時点以降に完了したトランザクションは、インシデントと無関係であっても消える可能性があります。主な難題は、正規の送金やアプリケーションのアクティビティを再実行または整合させなければならない可能性があることです。

より広範なロールバックのコストは、Tectonicの悪用事案の後にはっきりと見えました。Cronosのバリデーターは約2時間分に相当するほぼ11,000ブロックを削除しました。このロールバックはCronosに記録されていたインシデント関連の借入の大半を取り消しましたが、その期間に完了した無関係なトランザクションも取り消しました。2つのインシデントの原因は異なりますが、Cronosの例が重要なのは、共有台帳を巻き戻す付随コストを示しているからです。

MultiversXはより限定的な修復を検討していると述べていますが、影響を受けたレコードをどのように分離するかはまだ示していません。選択的修復では、必ずしも元のブロックが削除されるわけではありません。調整されたプロトコル変更によって、再開後にアプリケーションとバリデーターが認識するステートを確立する間、トランザクション履歴は表示されたままになる可能性があります。この手法は、MultiversXがリカバリー設計を公表するまで適切に評価できません。

停止中にMultiversXユーザーがすべきこと

一般の保有者にとって最も簡単な指示は待機することです。MultiversXは、トークンの移行、リカバリーサイトへのウォレット接続、修正トランザクションの承認をユーザーに求めていません。

• トランザクションを送信または再ブロードキャストしない。
• 取引所を通じてEGLDやESDTを入出金しない。
• それらの資産をクロスチェーンブリッジで移動しない。
• 停止付近で送信したもののトランザクションハッシュは保管しておく。
• リカバリーリンク、移行、一方的なサポートメッセージは無視する。
• MultiversXと該当プラットの双方が再開を確認するのを待つ。

ネットワーク修復はバリデーターとインフラ運営者によって採用されるものであり、ユーザーがシードフレーズを明かしたり、資産を新しいアドレスに送金したりする必要はありません。

ブロック生成が再開した後、ウォレットやエクスプローラーも再同期に時間を要する可能性があります。インターフェースで残高が古い、または直近のトランザクションが表示されないこと自体は、根底の資産が変わったことを示すものではありません。

再開は検証可能でなければならない

ブロック生成を再開すれば可用性は回復しますが、それだけではファイナリティの問題に答えられません。MultiversXは、どのアカウントやコントラクトが影響を受けたか、修復済みステートがどのように計算されたか、バリデーターがどのように独自に同じ結果に到達したかを依然として公表する必要があります。

その記録がインシデント関連の変更のみが修正されたことを示していれば、選択的リカバリーは広範なロールバックよりも多くの正規のアクティビティを保持できる可能性があります。そうでなければ、一部の確定済み変更が改変され他が保持された理由をユーザーが検証できないまま、ネットワークが再開する恐れがあります。

この記事は情報提供のみを目的としており、金融または投資助言を構成するものではありません。ネットワークの状況とリカバリー手順は、MultiversXのさらなる更新により変更される可能性があります。