11 月 16 日の午前 2 時 16 分、BCH はブロック 556767 でハード フォークを発生しました。フォーク戦争は終結し、BCH ABC と BCH SV の 2 つの陣営に分かれました。

このハードフォークでは、BCH ABC も BCH SV も「リプレイ保護」を実装していません。つまり、理論的には、このフォークの後、リプレイ攻撃により合意が崩壊し、いずれかの当事者の計算能力がゼロになる可能性があります。

「リプレイアタック」とは何ですか？

従来のコンピュータ用語では、リプレイ攻撃 (リプレイ攻撃またはリプレイ攻撃とも呼ばれる) とは、攻撃者がシステムを欺くという目的を達成するために、宛先ホストが受信したデータ パケットを送信することを指します。リプレイ攻撃はあらゆるネットワーク通信プロセスで発生する可能性があり、コンピューターの世界でハッカーが使用する一般的な攻撃方法の 1 つです。主に認証プロセスで使用されます。

ブロックチェーンの分野では、リプレイ攻撃（リプレイ攻撃）は通常、ブロックチェーンがハードフォークされたときに発生し、「あるチェーン上のトランザクションが別のチェーンでは合法であることが多い」ことを指します。

ブロックチェーンにおける「リプレイ攻撃」とは何かを簡単に説明できる例があります。

幼い A は、支払いを効果的に識別できないビール醸造所 (ここでは、どの支払いであるかを判断することは不可能です) からビールを購入しますが、Alipay で成功した支払いの支払い情報を販売員に見せると、販売員は彼にビールを渡します。その後、Xiao A さんが最後の支払い情報を別のセールスマンに見せると、セールスマンは彼にビールをもう 1 杯与えました。 Little A が支払い情報を繰り返し提示する限り、ビールを騙し続けることができますが、ビール醸造所にとっては、これはリプレイ攻撃であり、数え切れないほどのビールが失われます。

この BCH ハード フォークに関する限り、BCH は 1 つのチェーンから 2 つのチェーンに変更されています。両方のチェーンがサポートされ、動作し続けると、フォークされたもう一方のチェーンは資産 BSV を生成します。つまり、BCH ABC と BCH SV の両方が存在します。 。リプレイ保護がないため、フォーク後に放置して自然に成長させると、この時点で次のことが起こります。 SV チェーンで取引すると、アドレス、アルゴリズム、トランザクション形式が同じであるため、次のような結果が得られます。 ABC チェーンが再ブロードキャストすると、ABC チェーンによって有効であると認識され、同じトランザクション操作を実行できるようになります。攻撃者がこの脆弱性を利用し、取引所で継続的に入出金 (BCH SV) を行うと、追加の BCH ABC を取得できます。

これは、リプレイ保護のない BCH ユーザー資産がリスクにさらされていることを意味し、さらに深刻なことに、コンセンサスが崩壊し、コンピューティング能力がゼロになる可能性があります。

「リプレイ攻撃」の起源：イーサリアムのハードフォーク

2016年7月20日の夜、イーサリアムはブロック192万でハードフォークし、その結果ETHチェーンとETHクラシックチェーンと呼ばれる2つのチェーンが誕生し、上記のトークンはETHとETCと呼ばれました。

これら 2 つのチェーンのアドレスと秘密鍵アルゴリズムは同じであり、トランザクション形式もまったく同じであるため、一方のチェーンでのトランザクションは、もう一方のチェーンでは完全に合法である可能性があります。したがって、チェーンの 1 つでトランザクションを開始し、それを別のチェーンで再ブロードキャストすると、それが確認される可能性もあります。

事前に計画がないため、多くの人がこの抜け穴を利用して取引所で ETH を継続的に入出金し、追加の ETC を取得します。 「リプレイ攻撃」はブロックチェーンの世界で再定義されました。

リプレイ攻撃の影響を受けて、イーサリアムの現在の問題がユーザーに存在します。 ETH と ETC はどちらも十分な経済ボリュームを持っているため、ユーザーが自分の操作がリプレイされる可能性を解決できない場合、一方の資産を売却してもう一方の資産を保持したいか、自分で分離する必要があるか、またはそれしかできないためです。それは取引所の支援によってのみ実現できます。

対応：取引前に別居

BCHはリプレイプロテクションなしでフォークされているためリプレイは避けられず、損失を避けるためには取引所や利用者がBCH ABC/BCH SVを確認して分離する必要があります。

BCH の 2 つのアップグレード バージョン、bitcoin abc 0.18.2 と bitcoin sv 0.1 を振り返ってみましょう。

Abc0.18.2 プロトコル バージョンの主な変更点は、2 つのオペコード OPcode、OP_CHECKDATASIG (CDS) と OP_CHECKDATASIGVERIFY (DSV) を追加し、ブロック内のトランザクションの順序付けルールをトポロジカル ソート (TTOR) から正規ソート (CTOR) に変更することです。

SV0.1 プロトコル バージョンの主な変更点は、初期の 4 つのビットコイン オペコード OPCode、OP_MUL、OP_LSHIFT、OP_RSHIFT、OP_INVERT を復元し、各スクリプトの 201 オペコードの制限を削除し、ブロック サイズの上限を 128 MB に増加することです。

どちらのバージョンも操作コードが更新されているため、すでにBCHを保有しているユーザーは、取引操作には新しいOPコードを使用する方が安全です。口座操作前に分離する必要があります。

最も簡単で効果的な分割方法は、分割ポイントから100ブロック後のマイニングプールからコインベーストランザクションの少量のUTXOを購入し、それをBCHウォレットに送信し、その後、すべての残高を新しいアドレスに一度に転送することです。これをチェーン上で 1 回行うだけで、チェーンを完全に分離できます。

2 つの資産を分離した後は、新しい OPCode を使用できるようになり、BCH チェーン上の新しい OPCode が再生されることによる安全上の問題は発生しません。

ここで、SECBIT Lab は、ABC/BSV をサポートする BCH 保有者と取引所に対し、リプレイによる損失を避けるために、ユーザーの BSV を分離する前にトランザクションで新しい OPCode を慎重に使用するよう注意を促します。