Reorg（チェーン再編成）

暗号資産におけるReorgとは？

Reorg（チェーン再編成）とは、ブロックチェーンノードが現在のチェーン履歴の一部を、別の有効なチェーン分岐に置き換えることです。

簡単に言えば、ブロックチェーンが一時的にある経路をたどった後、ネットワークがより適切なもの、または正規のチェーンと認めた別の経路に切り替わる現象です。

Reorgによって、アクティブチェーンに最近追加されたブロックが1つ以上取り除かれ、別のブロックに置き換えられる場合があります。

取り除かれたブロック内のトランザクションは、メンプールに戻る、再び保留中になる、後のブロックに含まれる、または新しいチェーンで競合するトランザクションが承認された場合に無効になることがあります。

Reorgは、Proof of Workのチェーン、Proof of Stakeのチェーン、Layer 2システム、ブリッジ、ウォレット、決済処理業者、取引プラットフォームなど、トランザクションを最終確定済みとして扱ってよい時点を判断する必要があるシステムでよく取り上げられます。

EthereumのProof of Stakeの攻撃と防御に関するドキュメントでは、Reorgをブロックの順序が入れ替わることであり、正規チェーンへのブロックの追加や削除を伴う可能性もあると定義しています。

Bitcoinの開発者向けドキュメントでは、承認数はトランザクションを削除または変更するために必要なブロック数を示すと説明されています。これは、ユーザーが決済を最終確定済みとして扱う前に待つ実務上の理由です。

Reorgは必ずしも攻撃ではありませんが、重要なトランザクションを取り消す、二重支払いを可能にする、アプリケーションを妨害する、クロスチェーンシステムに影響を与える場合には危険になり得ます。

Reorgの簡単な定義

Reorgとは、ブロックチェーンがどの最近のブロックをメインチェーンの一部と見なすかを変更することです。

以前のブロックは、ネットワークで使われる用語に応じて、古いブロック、孤立ブロック、または非正規ブロックになります。

新しいブロックは、ノード、ウォレット、エクスプローラー、アプリケーションが従うべき、受け入れられた履歴になります。

複数のバリデーターやマイナーが同じ高さで競合するブロックを一時的に生成すると、Reorgが起きることがあります。

ネットワーク遅延によって、一部のノードは先にあるブロックを受信し、別のノードは別のブロックを先に受信した場合にも起こり得ます。

より深刻な場合には、攻撃者や大規模なバリデーターグループが、利益獲得や検閲を目的としてブロックを置き換えようとするためにReorgが発生することがあります。

ユーザーにとって重要なのは、承認済みに見えたトランザクションが、未承認になったり置き換えられたりする可能性があることです。

そのため、暗号資産システムでは承認数、ファイナリティのルール、リスクに応じた待機期間を設けています。

Reorgが重要な理由

ブロックチェーンは所有権や決済の判断に使われるため、Reorgは重要です。

決済、スワップ、ブリッジへの入金、ミント、出金、強制決済などを早すぎる段階で承認すると、その後のReorgによって損失や混乱が生じる可能性があります。

承認が少ない段階で商品を発送した加盟店は、決済がReorgによって消えた場合にリスクを負う可能性があります。

送信元チェーンのトランザクションが最終確定する前に資産をリリースするブリッジでは、そのトランザクションが削除された場合、裏付けのない資産が重複して生じる可能性があります。

十分なファイナリティが得られる前にブロックに反応するDeFiプロトコルは、古い状態を処理してしまう可能性があります。

トランザクションを早すぎる段階で完了と表示するウォレットは、ユーザーに誤解を与える可能性があります。

Circleのファイナリティとブロック承認に関するドキュメントでは、より速いアテステーションにはReorgのリスクが伴う可能性がある一方、標準的なフローでは、チェーン再編成によってトランザクションが取り消される可能性が低い、強固なファイナリティが得られるまで待つと説明されています。

そのため、特に高額送金やクロスチェーンアプリケーションでは、Reorgへの理解がブロックチェーンの安全性の基本となります。

Reorgの仕組み

Reorgは、2つ以上の有効なチェーン分岐が同時に存在するときに始まります。

ブロックチェーンは分散型システムであり、すべてのノードが新しいブロックをまったく同じタイミングで受け取るわけではないため、自然に起こることがあります。

あるノード群はBlock Aを先に受信する場合があります。

別のノード群はBlock Bを先に受信する場合があります。

どちらのブロックも有効である可能性がありますが、正規の経路になれる分岐は1つだけです。

ネットワークのコンセンサスルールによって、どちらの分岐が選ばれるかが決まります。

別の有効な分岐がネットワークのフォーク選択ルールに基づいてより強くなったとノードが判断すると、その分岐に切り替わります。

この切り替えがチェーン再編成です。

Reorgとフォークの違い

フォークとは、複数の有効な分岐が存在するブロックチェーン履歴の分岐です。

Reorgとは、ある分岐から別の分岐に切り替えるプロセスです。

すべてのフォークが大規模なReorgになるわけではありません。

ネットワークが一方の分岐を選び、もう一方を放棄すると、多くの短期的なフォークはすぐに解消されます。

ハードフォークは異なります。プロトコルのルールを変更し、コミュニティが双方を支持し続ける場合、恒久的なチェーン分岐を生み出す可能性があります。

通常のReorgは、一時的なものであり、同じコンセンサスルールのもとで起こることが一般的です。

恒久的な分岐では、2つのネットワークがそれぞれ稼働し続けます。

Reorgは、1つのネットワークのコンセンサスプロセス内でアクティブチェーンの経路を修正するものです。

Reorgとファイナリティの違い

ファイナリティとは、ネットワークのルール上、トランザクションの取り消しが非常に困難、または不可能と見なされる時点です。

Reorgを防ぐ、または経済的に現実的でないものにするのがファイナリティです。

EthereumのProof of Stakeのドキュメントでは、トランザクションが、取り消すために大量のETHをバーンする必要があるブロックに含まれたとき、ファイナリティが得られると説明しています。

同じドキュメントでは、Ethereumの最終確定済みブロックを取り消すには、攻撃者がステーキングされたETH総量の少なくとも3分の1を失う必要があると説明されています。

Bitcoinでは、ブロックが追加されるたびに過去の履歴の置き換えが困難になるため、確率的なファイナリティが採用されています。

Solanaでは、processed、confirmed、finalizedなどのコミットメントレベルを使い、クライアントがトランザクションの確実性を理解できるようにしています。

実務上の教訓は、トランザクションがブロックに含まれた後も、強固なファイナリティが得られているとは限らないことです。

アプリケーションは、金額、速度、リスクに応じて必要なファイナリティの水準を決める必要があります。

Reorgと孤立ブロックの違い

孤立ブロックまたは古いブロックとは、有効であったものの、正規チェーンに残らなかったブロックです。

古い分岐がアクティブチェーンではなくなるため、Reorgによって古いブロックが発生することがあります。

これらの用語は、ブロックチェーンコミュニティによって多少異なる意味で使われます。

一般的な暗号資産用語では、競合する分岐に置き換えられたブロックを「孤立した」と表現することがよくあります。

重要なのは、そのブロックに含まれていたトランザクションを再処理する必要がある場合や、承認済みの履歴から消える場合があることです。

Reorgが検出されると、ウォレットやブロックチェーンエクスプローラーがトランザクションの状態を更新する場合があります。

ブロックを一度見ただけで、恒久的なものとして扱うべきではありません。

取り消し不能なオフチェーン操作を行う前に、承認数とファイナリティの状態を追跡する必要があります。

Reorgと二重支払いの違い

二重支払いとは、同じ資金を競合する2つの方法で支出しようとすることです。

ある相手への支払いトランザクションが削除され、新しいチェーンで別の相手に支払う競合トランザクションが承認されると、Reorgによって二重支払いが可能になる場合があります。

Bitcoinの決済処理に関するドキュメントでは、悪意ある支払者が受取人への支払いトランザクションと、同じインプットを自分に戻す別のトランザクションを作成できるものの、ブロックチェーンに含められるのはどちらか一方だけだと説明しています。

同じドキュメントでは、トランザクションがブロックに含まれた後に置き換えるには、ブロックチェーンの履歴を変更する必要があり、承認数が増えるほど困難になると説明しています。

Reorgは常に二重支払いを意味するわけではありませんが、二重支払い攻撃では、最初のトランザクションが承認された後に成功させるため、Reorgが必要になることがよくあります。

そのため、高額決済では通常、少額決済より多くの承認が求められます。

トランザクションの下に後続のブロックが積み重なるほど、置き換えにかかるコストは高くなります。

したがって、承認数のポリシーはReorgを利用した二重支払いに対する防御策です。

Reorgが発生する主な原因

よくある原因の1つ目は、ネットワーク遅延です。

有効なブロックがすべてのノードに届くまで時間がかかると、別のブロック生成者が最初のブロックを認識する前に競合するブロックを生成する場合があります。

2つ目の原因は、ブロックの同時生成です。

2人のマイナーまたはバリデーターがほぼ同時に有効なブロックを生成することがあります。

3つ目の原因は、バリデーターやマイナーの行動です。

ブロック生成者がブロックを保留、遅延、または戦略的に公開し、Reorgのリスクを高める場合があります。

4つ目の原因は、ソフトウェアやクライアントの不具合です。

異なるクライアントが状態を誤って解釈すると、正しいチェーンについて一時的に意見が分かれる場合があります。

5つ目の原因は、悪意ある攻撃です。

攻撃者が二重支払い、トランザクションの検閲、価値の抽出を目的として、ブロックの再編成を試みる場合があります。

短いReorg

短いReorgでは、通常、最近のブロックが1つまたは少数置き換えられます。

最近のブロックは安全性を裏付ける要素が少ないため、深いReorgよりも短いReorgの方が一般的です。

通常のネットワーク環境でも自然に発生することがあります。

多くのユーザーにとって、1ブロックのReorgは、トランザクションの状態が一時的に承認済みから保留中に変わり、その後再び承認済みになるだけの場合があります。

高速処理を必要とするアプリケーションでは、短いReorgでも重要な問題になる可能性があります。

取引アプリ、ブリッジ、オラクル、強制決済ボット、決済処理業者は、ごく最近のブロックに反応する場合があります。

そうしたブロックが置き換えられると、アプリケーションは内部状態をロールバックまたは修復する必要が生じる場合があります。

そのため、インフラはReorgが起きないと想定するのではなく、発生に対応できるよう設計する必要があります。

深いReorg

深いReorgでは、多数のブロックが置き換えられます。

ユーザーがすでに信頼できると考えていたトランザクションが削除される可能性があるため、深いReorgははるかに深刻です。

深いReorgは、重大なネットワーク問題、攻撃、コンセンサスの不具合、バリデーターの障害、極端なネットワーク分断を示している可能性があります。

Proof of Workのシステムでは、元のトランザクションの上により多くのProof of Workが積み重なるほど、深いReorgのコストは高くなります。

経済的なファイナリティを備えるProof of Stakeのシステムでは、最終確定済みブロックに影響する深いReorgに、スラッシング対象となる行為や非常に高い経済的コストが必要となる場合があります。

Ethereumのシングルスロット・ファイナリティのロードマップでは、現在のファイナリティの遅延によって短いReorgが発生する余地があり、ファイナリティが速くなればこのリスクを抑えられる可能性があると説明されています。

成熟したネットワークで深いReorgが起こることはまれですが、影響が深刻になり得るため重要です。

多額の価値を扱うシステムは、発生確率は低くても影響の大きいReorgのシナリオに備える必要があります。

Proof of WorkネットワークにおけるReorg

Proof of Workネットワークでは、通常、ノードは累積作業量が最も多い有効なチェーンに従います。

2つの有効な分岐が現れると、マイナーは最善と考える分岐の上にブロックを追加し続けます。

累積作業量が増えた分岐が正規チェーンになります。

敗れた分岐に従っていたノードは、勝った分岐に再編成されます。

Bitcoinの動作モードに関するドキュメントでは、フルノードはブロックをダウンロードして検証することでブロックチェーンを確認し、フルノードを欺くには、現在の正規チェーンより難易度の高い代替ブロックチェーン履歴が必要だと説明されています。

Proof of Workによる決済では、承認数が中心的な役割を果たします。

新しいブロックが追加されるたびに、攻撃者が乗り越えなければならない作業量が増えます。

ブロックの深さが増えるほど、Reorgのリスクは低下します。

Proof of StakeネットワークにおけるReorg

Proof of StakeネットワークでのReorgの挙動は、バリデーターの投票、フォーク選択ルール、ファイナリティの仕組み、ペナルティ、スラッシング条件によって異なります。

EthereumはLMD-GHOSTと呼ばれるフォーク選択ルールと、チェックポイント投票に基づくファイナリティシステムを使用しています。

Ethereumのドキュメントでは、バリデーターはチェーンのヘッドと見なすブロックにアテステーションを行い、コンセンサスクライアントはアテステーションの重みが最も大きいフォークを優先すると説明されています。

そのため、ファイナリティに達する前に短期的な意見の不一致が発生する可能性があります。

一度ファイナリティに達すると、攻撃者がステークを失う可能性があるため、最終確定済みブロックを取り消すには経済的に大きなコストがかかります。

そのため、Proof of StakeのReorg分析では、アテステーションの重み、ファイナリティの状態、バリデーターの参加状況、ネットワーク遅延、スラッシングのリスクに注目します。

Proof of StakeのReorgは、ブロック数だけで判断されるものではありません。

置き換えられたブロックが最終確定済み、正当化済み、承認済み、または提案されたばかりのものかどうかも考慮する必要があります。

Reorgと承認数

承認とは、トランザクションがブロックに含まれ、その上に後続のブロックが追加されている可能性があることを意味します。

多くのチェーンでは、1承認はトランザクションが最新の承認済みブロックに含まれている状態を指します。

2承認は、そのブロックの上にさらに1つのブロックが追加された状態です。

通常、承認数が多いほどReorgのリスクは低くなります。

Bitcoinの開発者向けドキュメントでは、高額なトランザクションで6承認が一般的に使われる一方、その数はある程度慣習的であり、リスクに応じて決められると説明されています。

少額決済であれば、より少ない承認数で許容できる場合があります。

高額な入金、ブリッジ、取り消し不能なオフチェーンでの商品引き渡しでは、より多くの承認が必要となる場合があります。

適切な承認ポリシーは、ネットワークのセキュリティ、トランザクションの価値、攻撃のインセンティブ、ユーザーのリスク許容度によって異なります。

Reorgと最終確定済みブロック

最終確定済みブロックとは、ネットワークが削除を非常に困難なものとして扱うブロックです。

ファイナリティは、単にブロックに含まれることよりも強い確定状態です。

Ethereumでは、ブロックの取り消しには攻撃者に対する深刻な経済的ペナルティが必要となる状態を指します。

Solanaのコミットメント状態に関するドキュメントでは、対象ブロックの上に31以上の承認済みブロックが追加された状態をfinalizedと説明しています。

ブリッジや決済システムでは、送信元チェーンのルールとアプリケーションのリスクポリシーによってファイナリティが定義される場合があります。

最終確定済みのトランザクションは、処理されたばかり、または最近ブロックに含まれたばかりのトランザクションより、通常ははるかに安全です。

ただし、ファイナリティのモデルはブロックチェーンごとに異なります。

開発者は、各ネットワークのコンセンサス設計を理解せずに、すべてのネットワークに同じ待機ルールを適用するべきではありません。

Reorgとウォレット

ウォレットは、Reorgに適切に対応できるよう設計する必要があります。

ウォレットは最初にトランザクションを保留中と表示する場合があります。

その後、1つ以上の承認を表示することがあります。

Reorgによってトランザクションを含むブロックが削除された場合、ウォレットは何も変わっていないように見せるのではなく、状態を更新する必要があります。

トランザクションが引き続き有効で、再度含まれるのを待っている場合は、保留中に戻る可能性があります。

新しいチェーンで競合するトランザクションが承認された場合は、失敗する可能性があります。

高額なトランザクションを早すぎる段階で最終確定済みと表示することは避けるべきです。

明確な状態ラベルにより、ユーザーはブロードキャスト済み、ブロックに含まれた状態、承認済み、最終確定済みの違いを理解できます。

Reorgとブロックチェーンエクスプローラー

ブロックチェーンエクスプローラーは、現在の正規チェーンを追跡し、ユーザーにトランザクションの状態を表示します。

Reorgが起きると、エクスプローラーはメインチェーンの表示からブロックを削除し、置き換え後のブロックを表示する場合があります。

ネットワークやエクスプローラーの設計に応じて、トランザクションのページは承認済みから削除、保留中、失敗、または置き換え済みに変わる場合があります。

Reorgの進行が速い場合、各エクスプローラーがネットワークデータを受け取るタイミングが異なるため、一時的に異なる表示になることがあります。

異常なネットワーク状況では、重要な承認状態を単一のエクスプローラーだけに頼らないでください。

開発者は、決済ロジックにエクスプローラーのページをスクレイピングして使うのではなく、信頼できるノードのインフラとファイナリティを考慮したインデックス作成を利用する必要があります。

インデクサーは、Reorg後に影響を受けた状態をロールバックできるだけの履歴を保存する必要があります。

エクスプローラーは状況を確認するための便利なツールですが、正規チェーンとファイナリティのルールを決めるのはノードです。

Reorgと取引所

取引プラットフォームやカストディサービスは通常、入金を反映する前に所定の承認数を待ちます。

目的は、ユーザーに残高を反映した後、Reorgによって入金が消える可能性を抑えることです。

ハッシュパワーが低い、ステークの安全性が低い、最近不安定な状況があった、または攻撃のインセンティブが高いネットワークでは、リスク管理チームがより多くの承認を求める場合があります。

決定論的なファイナリティがより速いネットワークでは、必要な承認数を少なくする場合があります。

異常なReorgが発生している間、入金や出金を一時停止することもあります。

ユーザーは入金の待機時間を単なる遅延と考えることがありますが、これはリスク管理策でもあります。

入金を早く反映しすぎた後にReorgで削除されると、プラットフォームが損失を被る可能性があります。

そのため、承認ポリシーはオペレーショナルリスク管理の一部です。

Reorgとブリッジ

ブリッジは複数のチェーンをつなぐため、Reorgの影響を特に受けやすいシステムです。

ブリッジは、一方のチェーンで資産をロックまたはバーンし、別のチェーンで関連資産をリリースまたはミントする場合があります。

送信元チェーンのトランザクションが、送信先チェーンでの操作の後にReorgによって削除されると、ブリッジは有効な送信元イベントなしに価値をリリースしてしまう可能性があります。

これにより、担保不足の資産や会計上の不一致が生じる可能性があります。

ブリッジシステムは、承認を待つ、ファイナリティを待つ、不正証明または有効性証明を使う、処理済みメッセージを追跡する、リスク上限を設定するなどの方法でリスクを抑えます。

Circleのファイナリティに関するガイダンスによると、クロスチェーン送金システムでは、高速な処理と標準的な処理で待機時間を変える場合があります。高速なフローには、異なるReorgの想定があるためです。

より高速なブリッジでは、速度と引き換えにReorgやファイナリティのリスクが高くなる可能性があることを理解してください。

高額送金では、より強固なファイナリティを待つ方が一般的に安全です。

ReorgとLayer 2ネットワーク

Layer 2ネットワークは、データの可用性、ファイナリティ、不正証明、有効性証明、出金の安全性について、決済レイヤーに依存することがよくあります。

Layer 2のインターフェースでは最終確定したように見えるトランザクションでも、関連するバッチが決済レイヤーで最終確定する前の可能性があります。

Circleのファイナリティに関するドキュメントでは、一部のLayer 2システムは、バッチがEthereumに投稿された時点と、関連するEthereumブロックが最終確定した時点に依存すると説明されています。

そのため、2つのレイヤーでファイナリティを理解する必要があります。

Layer 2内での承認と、決済レイヤーでのファイナリティが存在する場合があります。

一般的な少額トランザクションでは、Layer 2内の承認だけで十分な場合があります。

クロスチェーン送金、高額入金、プロトコルの会計処理では、決済レイヤーでのファイナリティが必要になる場合があります。

すべてのLayer 2の承認でReorgのリスクが同じだと想定しないでください。

ReorgとMEV

MEV（最大抽出可能価値）とは、ブロック生成者やトランザクションの順序を決める主体が、トランザクションを追加、除外、並べ替えることで獲得できる価値です。

ブロックの置き換えによって、利益につながるトランザクションの順序付けの機会を得られる場合、ReorgがMEVと結び付くことがあります。

Ethereumの攻撃と防御に関するドキュメントでは、悪意あるReorgによってフロントランニングやバックランニングの取引から価値を抽出できると説明されています。

十分な価値を得られる場合、ブロックの置き換えを試みるインセンティブが生じるため、短期的なReorgは大きな懸念事項です。

より深いブロックの置き換えにかかるコストを高めることで、ファイナリティはこのリスクを抑えます。

アプリケーションは、ファイナリティを待つ、適切な場合にプライベートなトランザクション経路を使う、より安全なオークション方式を設計する、異常なチェーンの動きを監視するなどの方法でリスクを軽減できます。

MEVに関連するReorgのリスクは、高額なDeFi取引、強制決済、アービトラージ、オラクルの更新、ブリッジのイベントで特に重要です。

Reorgのリスクは技術的な偶発事象だけではなく、経済的な動機によって生じる場合もあることを理解してください。

Reorgとオラクル

オラクルは、オフチェーンまたはクロスチェーンのデータをスマートコントラクトに取り込みます。

オラクルが読み取ったブロックが後にReorgで削除されると、そのデータは正規チェーンの履歴と一致しなくなる可能性があります。

たとえば、削除されたブロックにしか存在しない価格、残高、入金、イベントをオラクルが報告する可能性があります。

適切なオラクルシステムでは、重要なデータを公開する前に、承認数とファイナリティを考慮します。

Reorgによって深刻な損失が生じる可能性がある場合、プロトコルはごく最近のイベントに依存することを避ける必要があります。

クロスチェーンオラクルでは、送信元チェーンのReorgリスクが送信先チェーンのコントラクトに影響する可能性があります。

オラクルは、設計におけるファイナリティの前提を明確にする必要があります。

オラクルを使用するスマートコントラクトは、オラクルのデータが即時、承認済み、最終確定済みのいずれなのかを理解する必要があります。

Reorgとインデクサー

インデクサーはブロックチェーンデータを読み取り、アプリ、ダッシュボード、ウォレット、分析ツール、API向けの検索可能なデータベースに変換します。

インデックス化したデータのロールバックが必要になるため、Reorgはインデクサーにとって大きな課題です。

記録したイベントを含むブロックが後に古くなった場合、インデクサーはそのイベントを削除または修正する必要があります。

Reorgへの対応に失敗すると、残高、トランザクション履歴、NFTの所有者、強制決済データ、ブリッジの状態が誤って表示される可能性があります。

インデクサーは、ブロックハッシュ、親ブロックのハッシュ、ブロック番号、ファイナリティの状態、ロールバックの深さを追跡する必要があります。

新しいブロックをすぐに恒久的なものとして扱うべきではありません。

高額な取引を扱うアプリケーションでは、ファイナリティを考慮したAPIを提供する必要があります。

Reorgに対応できるインデクサーは、本格的な暗号資産アプリケーションに欠かせないインフラです。

Reorgとスマートコントラクト

スマートコントラクトは、正規チェーンの状態に従って実行されます。

スマートコントラクトの呼び出しを含むブロックがReorgで削除されると、その呼び出しは正規の履歴に含まれなくなります。

トランザクションが後に再び含まれる場合もありますが、置き換え後のチェーンでは状態が変化しており、実行結果も変わる可能性があります。

状態が急速に変化するDeFiでは、これは重要な点です。

スワップ、強制決済、オラクルの更新、ミント、請求などは、実行時点の正確な状態に依存する場合があります。

十分な承認を得る前にトランザクションの結果が最終確定したと想定するオフチェーンシステムを構築するべきではありません。

スマートコントラクトは、削除されたブロックの履歴が正規チェーンに含まれていない限り、その履歴を「記憶」しません。

スマートコントラクトを取り巻くオフチェーンサービスもReorgに対応できる必要があります。

Reorgと決済処理

決済処理業者は、暗号資産の決済を受け入れてよいと判断する時点を決める必要があります。

承認ゼロで決済を受け入れると速く処理できますが、リスクがあります。

1承認で受け入れるとリスクは低下しますが、なくなるわけではありません。

承認数を増やして待つと、Reorgと二重支払いのリスクを抑えられますが、ユーザーの待ち時間が長くなります。

適切なポリシーは、決済額と不正利用による損失の大きさによって異なります。

少額のデジタル商品では、高額な物理商品の発送より多くのリスクを許容できる場合があります。

高額決済では、通常、より強固な承認またはファイナリティを待つ必要があります。

決済システムは、承認ポリシーをユーザーや加盟店に明示する必要があります。

Reorgとトランザクションの状態

Reorgの前後でトランザクションの状態が複数回変わることがあります。

ブロードキャスト済みで未承認の場合があります。

ブロックに含まれる場合があります。

承認数が増える場合があります。

Reorgの間に正規チェーンから削除される場合があります。

有効なままであれば、保留中に戻る場合があります。

置き換え後のブロックで再び承認される場合があります。

競合するトランザクションが承認されると、恒久的に置き換えられる場合があります。

Reorgとガス代

Reorg中のガス代の扱いは、ブロックチェーンの設計と、最終的に正規チェーンに残ったトランザクションの状態によって異なります。

トランザクションが古いブロックに含まれたものの、最終的な正規チェーンには含まれなかった場合、ユーザーにとって重要なのは、承認されたチェーン上で最終的に実行されたかどうかです。

後に正規ブロックで実行された場合、ユーザーはそのチェーンのルールに従って手数料を支払います。

正規の履歴でトランザクションが実行されなかった場合、最終チェーン上ではその実行が決済されなかったことになります。

ただし、Reorgの間、ウォレットやエクスプローラーに手数料が分かりにくく表示される場合があります。

開発者は一時的なブロックの観測結果ではなく、正規チェーン上のトランザクションレシートを追跡する必要があります。

最終的な手数料や実行状態を判断する前に、ユーザーは承認を待つ必要があります。

ネットワークに負荷がかかっていると、Reorgと手数料の変動によってトランザクション追跡が一貫しないように感じられる場合があります。

Reorgとリスク管理

Reorgのリスク管理は、必要な承認数を決めることから始まります。

トランザクションの価値が高いほど、受取側が求めるファイナリティも高くする必要があります。

2つ目の手段は、ネットワークごとのポリシーです。

チェーンごとに、ブロック生成時間、ファイナリティシステム、バリデーターセット、攻撃コストが異なります。

3つ目の手段は監視です。

サービスは、異常なReorgの深さ、スロットの欠落、バリデーターの障害、フォーク選択の不安定さ、エクスプローラー間の不一致を検出する必要があります。

4つ目の手段は決済の延期です。

企業は、オンチェーントランザクションが十分に安全になる前に、取り消し不能なオフチェーン処理を行わないようにする必要があります。

Reorgと51%攻撃

51%攻撃とは、攻撃者がチェーンの正規履歴に影響を与えられるほどのマイニングパワーまたはステークの影響力を持つ状況です。

Proof of Workのシステムでは、十分なハッシュパワーを持つ攻撃者が、代替チェーンを構築して公開し、最近のブロックを置き換えようとする場合があります。

Proof of Stakeのシステムでは、攻撃者がフォーク選択に影響を与えたり、ファイナリティを遅らせたり、ペナルティの対象となるより深刻な攻撃を試みたりする可能性があります。

Ethereumのドキュメントでは、Proof of Stakeの攻撃者がReorg、ファイナリティの二重化、またはファイナリティの遅延を狙う可能性があると説明されています。

Reorg攻撃は、二重支払いやトランザクションの検閲に利用されることがあります。

攻撃にかかるコストや実行可能性は、ネットワークのセキュリティモデルによって異なります。

一般に、成熟したネットワークは、マイニングやステーキングのセキュリティが弱い小規模ネットワークより攻撃が困難です。

セキュリティが低いネットワークを利用する場合、ユーザーは承認数により慎重になる必要があります。

Reorgとネットワーク分断

ネットワーク分断とは、ネットワークの一部が他の部分と正常に通信できなくなることです。

分断中は、異なるノード群が別々のチェーン分岐を構築する可能性があります。

通信が回復すると、ネットワークは一方の分岐を正規チェーンとして選び、もう一方からReorgする場合があります。

ネットワーク分断は、インターネットの経路障害、クライアントの問題、サービス妨害攻撃、インフラの停止などによって発生することがあります。

Reorgの深さは、分断が続いた時間や、コンセンサスルールが競合する分岐をどのように処理するかによって異なります。

アプリケーションは、個々のトランザクションの状態だけでなく、ネットワーク全体の健全性を監視する必要があります。

あるノードからは正常に見えるチェーンでも、ネットワークの別の部分では異なる状態が見えている場合があります。

複数の信頼できるノードを使うことで、チェーンの表示の不一致を検出しやすくなります。

Reorgとクライアントの不具合

ノード間で有効なブロックについて意見が分かれると、クライアントの不具合によってReorgに似た混乱が起きる場合があります。

あるクライアントが受け入れたブロックを別のクライアントが拒否すると、問題が解決するまでネットワークが分裂する可能性があります。

そのため、クライアントの多様性、テスト、監査、アップグレードの調整が重要です。

不具合によるチェーン分岐は、コンセンサス自体に影響する可能性があるため、通常の1ブロックのReorgより危険な場合があります。

異常な動きが発生した場合、アプリケーションは公式クライアントの告知を監視する必要があります。

ノード運用者はソフトウェアを最新の状態に保つとともに、大規模リリースの前にアップグレード手順を理解する必要があります。

クライアントの多様性は、1つのソフトウェアの不具合がネットワーク全体に損害を与える可能性を抑えます。

したがって、Reorgのリスクはマイナーやバリデーターの行動だけでなく、ソフトウェアの品質にも関係します。

Reorgとロールバック

ロールバックとは、より広い意味で、状態を以前の時点に戻すことです。

Reorgとは、別のチェーン分岐への切り替えによって生じる、ブロックチェーン固有のロールバックです。

Reorg後、アプリケーションは内部状態をロールバックする必要がある場合があります。

たとえば、入金トランザクションがReorgで削除された場合、会計システムは入金の反映を取り消す必要が生じることがあります。

ゲームでは、ミントのトランザクションが消えた場合、アイテムを削除する必要があるかもしれません。

送信先チェーンで資産をリリースした後にロールバックするより、ブリッジはより長く待つ必要がある場合があります。

Reorgに対応したアプリケーション設計では、ロールバックを許容できる場面と、待つ方が安全な場面を決めることがよくあります。

ロールバックを許容できないシステムは、処理を行う前に強固なファイナリティを待つ必要があります。

Reorgとユーザーの安全

トランザクションを最終確定済みとして扱う前に承認を待つことで、ユーザーはReorgのリスクを軽減できます。

高額決済では、承認されたばかりのトランザクションだけを根拠に、商品を発送したり、サービスを提供したり、取り消し不能な判断を下したりすることは避けてください。

チェーンによって一般的な承認数が異なることを理解してください。

フォーク、障害、攻撃、ブリッジのイベント、異常なネットワーク状況では、特に注意が必要です。

承認状態を明確に表示するウォレットやサービスを利用してください。

短いReorgの後、最近承認されたトランザクションが保留中に戻っても、慌てる必要はありません。

多くの場合、トランザクションは再びブロックに含まれる可能性があります。

トランザクションが競合したり消えたりした場合は、可能であれば信頼できるエクスプローラー、ウォレットのサポートページ、または自分のノードで確認してください。

Reorgと開発者の安全対策

開発者はReorgが起きる可能性を前提とする必要があります。

取り消しを許容できる用途でない限り、新しいブロックを1つ確認しただけで重要なイベントを処理するべきではありません。

ブロック番号だけでなく、ブロックハッシュと親ブロックのハッシュを保存してください。

以前に処理したブロックが正規でなくなったことを検出できるようにする必要があります。

インデックス化したイベントのロールバック処理を実装してください。

チェーンごと、金額ごとに承認数のしきい値を定めてください。

ファイナリティとブロックへの包含を区別してください。

Reorgをシミュレーションできる開発ネットワークでシステムをテストしてください。

Reorgを理解するメリット

第一のメリットは、決済の受け入れがより安全になることです。

第二のメリットは、ブリッジの設計が改善されることです。

第三のメリットは、ウォレットでトランザクション状態をより正確に表示できることです。

第四のメリットは、インデクサーやアプリケーションの信頼性向上です。

第五のメリットは、取引所の入出金に関するリスク管理の改善です。

第六のメリットは、承認とファイナリティをより明確に理解できることです。

第七のメリットは、二重支払いの試みに対する保護の強化です。

Reorgについて理解すると、ブロックチェーンの決済は一瞬で完了するものではなく、プロセスであることが分かります。

Reorg対策の限界

承認によってReorgのリスクは低下しますが、考えられるすべての攻撃を防げるわけではありません。

ファイナリティによってReorgのリスクはさらに低下しますが、ファイナリティのモデルはネットワークによって異なります。

セキュリティが弱い小規模ネットワークでは、深いReorgのリスクが残る場合があります。

送信元チェーンのファイナリティを誤って理解していれば、ブリッジが失敗する可能性があります。

状態表示が不適切なウォレットは、依然としてユーザーに誤解を与える可能性があります。

チェーン自体が安定していても、スマートコントラクトに別の不具合があれば問題が起きる可能性があります。

Reorg対策は安全性を支える要素の1つであり、完全なセキュリティシステムではありません。

ユーザーと開発者は、カストディのセキュリティ、スマートコントラクトのレビュー、オラクルの安全性、運用管理と組み合わせる必要があります。

Reorgに関するよくある誤解

よくある誤解の1つは、トランザクションがブロックに表示された時点で最終確定するというものです。

実際には、最近ブロックに含まれたトランザクションは、短いReorgの影響を受ける可能性があります。

すべてのReorgが攻撃だというのも誤解です。

ネットワーク遅延や有効なブロックの競合によって、短いReorgが自然に起きることもあります。

すべてのチェーンで同じ承認数が必要だというのも誤解です。

必要な承認数は、チェーンのセキュリティモデル、ファイナリティのルール、送金額、リスク許容度によって異なります。

ファイナリティがどこでも同じ意味だというのも誤解です。

ネットワークごとにファイナリティのモデルが異なるため、利用するチェーン固有の仕組みを確認する必要があります。

Reorgに関する危険信号

承認ポリシーなしで高額入金を反映するサービスは危険信号です。

送信元チェーンのファイナリティが明確になる前に資産をリリースするブリッジも危険信号です。

ブロードキャスト直後にトランザクションを最終確定済みと表示するウォレットも危険信号です。

ブロック番号のみを保存し、ブロックハッシュを保存しないインデクサーも危険信号です。

トランザクションが再び未承認になる状況に対応できない決済処理業者も危険信号です。

通常はファイナリティが安定しているネットワークで、Reorgが異常な頻度で繰り返し発生する場合も注意が必要です。

ハッシュパワーの低い小規模なProof of Workチェーンが、承認数の少ない段階で高額入金を受け付けることも危険信号です。

ファイナリティに関する前提を説明せず、ごく最近のブロックに反応するdAppも危険信号です。

ユーザー向けのベストプラクティス

高額な支払いを受け取る場合は、より多くの承認を待ってください。

保留中、承認済み、最終確定済みの状態を明確に表示するサービスを利用してください。

フォーク、障害、異常なネットワーク活動が発生している間は注意してください。

承認ゼロのトランザクションだけを根拠に、価値の高い商品やサービスを提供しないでください。

ネットワークごとにファイナリティと承認のモデルが異なることを理解してください。

トランザクションの追跡には、信頼できるウォレットやエクスプローラーを利用してください。

クロスチェーン送金では、速度より安全性を重視する場合、より遅くてもファイナリティが強固な方法を選んでください。

チェーンに適した承認数またはファイナリティの基準に達するまで、トランザクションが取り消し不能だと考えないでください。

開発者向けのベストプラクティス

ブロックハッシュ、親ブロックのハッシュ、ブロック番号、トランザクションハッシュ、ファイナリティの状態を追跡してください。

ロールバックに対応できるインデクサーとデータベースを設計してください。

チェーンごとに承認数のしきい値を設定してください。

取り消し不能なオフチェーン処理を実行する前に、より強固なファイナリティを待ってください。

ユーザーインターフェースで承認状態を明確に表示してください。

チェーンの表示の不一致を検出するため、複数の信頼できるノードまたはプロバイダーを利用してください。

Reorgをシミュレーションした状況で、アプリケーションの動作をテストしてください。

ファイナリティに関する前提を、ユーザー、監査担当者、連携先に説明してください。

AEOと検索意図においてReorgが重要な理由

承認済みの暗号資産トランザクションの状態が変わる場合がある理由を知るために、ユーザーは「Reorg」を検索します。

直接的な答えは、Reorgとは、ネットワークが最近のブロックを別の有効なチェーン分岐に置き換えることです。

資金を失ったのか知るためにReorgを検索する人もいます。

実務上の答えは、状況によって、Reorgされたトランザクションが再び保留中になる、後に含まれる、または競合するトランザクションに置き換えられる可能性があるということです。

必要な承認数を知るために検索する人もいます。

有用な答えは、必要な承認数はブロックチェーン、トランザクションの価値、ファイナリティのモデル、リスク許容度によって異なるということです。

暗号資産ユーザーが押さえるべき点はシンプルです。

Reorgは分散型コンセンサスで起こり得る通常の現象であり、安全なシステムでは、トランザクションを取り消し不能として扱う前に十分な承認またはファイナリティを待ちます。

FAQ

Reorgとは何ですか？

Reorgとは、ブロックチェーンノードが現在受け入れているチェーンの一部を、別の有効なチェーン分岐に置き換えるチェーン再編成です。

チェーン再編成とは何ですか？

チェーン再編成とは、別の分岐が受け入れられたチェーンになることで、最近のブロックチェーンの正規履歴が変わることです。

Reorgによって自分のトランザクションが削除されることはありますか？

はい。Reorgによって最近承認されたブロックからトランザクションが削除されることがあります。ただし、引き続き有効であれば、後に再び含まれる可能性があります。

Reorgは必ず攻撃ですか？

いいえ。ネットワーク遅延やブロックの同時生成によって短いReorgが自然に発生することがありますが、悪意あるReorgも起こり得ます。

1ブロックのReorgとは何ですか？

1ブロックのReorgとは、ネットワークが最新の正規ブロックを別の有効なブロックに置き換えることです。

深いReorgとは何ですか？

深いReorgとは、多数のブロックを置き換えることであり、ユーザーがすでに信頼できると考えていたトランザクションに影響する可能性があるため、より深刻です。

承認数が増えるとReorgのリスクが低下するのはなぜですか？

トランザクションの上にブロックが追加されるたびに、そのトランザクションを含むブロックの置き換えがより困難、または高コストになるためです。

必要な承認数はいくつですか？

チェーン、トランザクションの価値、ファイナリティのモデル、リスク許容度によって異なります。

最終確定済みブロックがReorgされることはありますか？

経済的または決定論的なファイナリティを持つネットワークでは、通常想定される条件のもとで最終確定済みブロックを再編成するには、非常に高いコストがかかるか、実質的に不可能となるよう設計されています。

Reorgはブリッジにどのような影響を与えますか？

Reorgで後に削除される送信元チェーンのトランザクションに基づいてブリッジが処理を行うと、裏付けを失ったり、誤って資産をリリースしたりする可能性があります。

Reorgはウォレットにどのような影響を与えますか？

トランザクションを含むブロックがReorgで削除されると、ウォレットは状態を承認済みから保留中または削除済みに変更する場合があります。

開発者はどのようにReorgに対応しますか？

ブロックハッシュを追跡し、承認を待ち、ロールバックに対応し、チェーン固有のファイナリティルールを利用して対応します。

Reorgに関する最大のミスは何ですか？

最も大きなミスは、新たにブロックに含まれたトランザクションが、適切な承認数またはファイナリティの水準に達する前に、取り消し不能だと扱うことです。

まとめ

Reorg（チェーン再編成）とは、最近受け入れられたブロックが別の有効なチェーン分岐に置き換えられるブロックチェーン上の現象です。

分散型ネットワークが新しいブロックについて合意するまでに時間がかかるため、Reorgは自然に発生することがあります。

また、攻撃、バリデーターの行動、ネットワーク分断、ソフトウェアの不具合、MEVのような経済的インセンティブによって起きることもあります。

実際には、承認済みに見えたトランザクションが保留中になったり、削除されたり、置き換えられたりする可能性があります。

そのため、暗号資産の決済では承認とファイナリティが重要です。

Bitcoin系のシステムは主に承認数の増加に依存し、Ethereum系のProof of Stakeシステムはフォーク選択と経済的ファイナリティを組み合わせています。

ウォレット、ブリッジ、決済処理業者、インデクサー、取引所、DeFiプロトコルはすべて、Reorgに対応できる設計を必要とします。

実用上の要点はシンプルです。Reorgは分散型コンセンサスの一部であるため、暗号資産のトランザクションを取り消し不能として扱う前に、ユーザーも開発者も十分な承認またはファイナリティを待つ必要があります。