ETCの格安51%アタックパズル

編集者注: この記事は以下から引用しましたゴールデンファイナンス、許可を得てOdailyによって転載されました。

編集者注: この記事は以下から引用しました

ゴールデンファイナンス

この攻撃は、独立したマイナー「0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e」によって開始されました。マイナーは 3594 個のブロックを静かに生成し、他のマイナーにブロードキャストしました。これらのブロックの数が多いため、ブロックの順序は他のマイナーが確立したチェーンよりも大きな重みを持ち、他のマイナーがこの一連のブロックを受け入れることになります。最終的に、攻撃者ブロックは元のブロックを置き換えることに成功し、ブロックの高さ 10904146 からブロック 10907740 まで再編成が発生しました。

、許可を得てOdailyによって転載されました。

ETCの公式Twitterは8月3日、ETCに対する51%攻撃に関するブロックチェーンデータ分析会社ビットクエリの調査報告書を発表した。

レポートによると、8月1日の0時30分から8月2日の11時30分までの間、ETCが51%の攻撃を受けました。

この攻撃は、独立したマイナー「0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e」によって開始されました。マイナーは 3594 個のブロックを静かに生成し、他のマイナーにブロードキャストしました。これらのブロックの数が多いため、ブロックの順序は他のマイナーが確立したチェーンよりも大きな重みを持ち、他のマイナーがこの一連のブロックを受け入れることになります。最終的に、攻撃者ブロックは元のブロックを置き換えることに成功し、ブロックの高さ 10904146 からブロック 10907740 まで再編成が発生しました。

チェーン上のデータは、マイナーが攻撃を開始するために意図的に外部からハッシュ パワーを購入したことを示しており、マイナーのアドレスがアクティブとして表示されるのは 7 月 29 日以来であり、3 日連続で 1 日あたり 30 ブロックが生成されています。最終的に、攻撃者は 12 時間にわたって ETC ネットワーク全体を欺くのに 17.5 BTC (約 17 万米ドル) を費やしただけで、攻撃の実行に成功しました。

さらに、ノードとマイナーによって実行されるすべてのソフトウェアが ETC ネットワーク内で同じように動作するわけではないため、ノードのバージョンとソフトウェアの多様性により、この攻撃はさらに深刻になります。

Geth と Hyperledger Besu の 2 つのクライアントに基づくノードは、攻撃者のブロックを受け入れ、最長のフォークされたチェーンを選択します。

Open Ethereum クライアントに基づくノードは、依然として古いチェーンを保持しています。これらすべてにより、一部のマイナーは古いチェーンに基づいて送金することになりますが、メインの ETC チェーン (フォーク チェーン) には反映されず、異なるクライアントに基づくノードは二重支出に直面する可能性があります。

関係機関の調査によると、具体的なプロセスは次のとおりです。

1. 悪意のあるマイナー (ETC アドレス: 0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e) が約 3000 ブロックをマイニングしました。

2. Multi-geth がイーサリアム クラシックのサポートを終了したため、2Miners プールはメンテナンスのために一時的にオフラインになりました。

3. 2Miners マイニング プールのメンテナンス期間中、2Miners マイニング プールは新しいブロックを生成しませんでした。 2Miners マイニング プールがメンテナンスを終了してオンラインになった後、約 3,000 ブロックが同時に 2Miners マイニング プールに挿入されました。

4. Ethereum Classic 上のどの Parity ノードも OpenEthereum ノードも Core-Geth ノードからの 3693 ブロックを処理できなかったため、チェーン フォークが発生しました。

Parity ノードまたは OpenEthereum ノード上のすべてのマイナーは引き続き元のメイン チェーンでマイニングを行っていますが、Core-Geth ノード上のマイナーは約 3000 ブロックに挿入された新しいチェーンでマイニングを行っています。

5. Proof of Work (POW) コンセンサスによると、新しいチェーンのワークロードは元のメイン チェーンを徐々に超え、元のメイン チェーンのパリティ ノード上の一部のマイナーは「より多くのワークロードを持つチェーンでマイニングすることを選択する」 「ガイドライン、マイニングのために新しいチェーンに転送します。

最後に、ブロック高さ 10904146 で、合計 3693 個のブロックが再編成によってブロックチェーンに追加されました。

2 つの組織の調査と情報公開を通じて、原因が 2 つあることは明らかです。1 つは最近のクライアント サポートの問題によるもので、もう 1 つは攻撃者がこれを利用しただけであるということです。

クライアントが異なれば、アクセスの役割も異なります。マイナーはネットワーク保守者であると同時にデータ生成者でもあります。つまり、クライアントが誤ったデータを提供すると、そのデータは他のノードによって同期され、これが攻撃の始まりとなります。

上記の攻撃者は、マイニングプールノードの再オンラインのタイミングを利用して、準備されたブロックデータをマイニングプールを正しい会計データと誤認させ、ブロードキャストを継続させました。そして、Parity、OpenEthereum、および Core-Geth クライアント マイナーの「不一致」により、異なるデータの同期に一貫性がなくなり、フォークが発生します。

この攻撃の原因はクライアントの混乱であり、この事件の原因は長い間醸成されてきました。

Jinse Finance の以前のレポートによると、2020 年 1 月 25 日、ETC Cooperative のエグゼクティブ ディレクターである Bob Summerwill 氏は、最近 ECIP-0001 提案のサポート延長を発表し、提案の一部の変更には Rust 開発者の Wei Tang 氏の削除が含まれています。

Bob Summerwill は、ECIP 編集者であり ECIP-1000 の著者である Wei Tang が権力を繰り返し乱用し、ETC エコシステムからソフトフォークするか離脱すると脅迫したと非難しました。

さらに、ECIP-1000 の編集者リストでは soc1c の代わりに soc1c の本名が使用されていたため、ETC コミュニティでは、コミュニティ内の別の ECIP 編集者である soc1c の人身調査を Wei Tang が行ったと非難する声があります。

この点、ウェイ・タン氏は自身のブログで事件の原因を説明し、関連提案の変更はETCの過度な集中化を避けるための配慮によるものであると回答した。しかし後期になると、論争は実際に彼自身に移った。同時に、魏唐は、いわゆる人肉の事実は存在しないと述べた。というのも、以前編集者リストを統合する際にsoc1cさん自身が同意しており、soc1cさんの本名はコミュニティ内で広く知られており、本名を使用することが多いからです。

この物議を醸した事件は ECBP-1076 提案に端を発していると報告されている。 Wei Tang はさらなる議論を求めたが、ECBP-1076 提案が ETC 会議で初めて提案され受け入れられたこと、そして ECIP 編集者が ECBP-1065 提案のステータスを次のように変更したと感じたため、soc1c によって拒否された。軽率にも「アクティブ」(soc1c が失効レビューを実行) した後、soc1c は ECIP プロセスから Wei Tang を削除するリクエストを送信しました。それ以来、Aztlan のハードフォーク中に ECIP-1061 と ECIP-1072 をめぐる紛争が発生しました (この紛争では「失効」操作も登場しました)。 Wei Tang 氏は、提案プロセスにおける soc1c の「取り消し」操作は実際には大きな中央集権化のリスクであると考えており、「取り消し」操作はプロセスに違反しており、標準とみなされるべきではないと主張して、新しいリクエストを作成しました。

Wei Tang氏とコミュニティはETCアズトランのハードフォーク延期についても異なる見解を持っており、アズトラン仕様の誤りがすでにモルドールとコッティのテストネットに取り返しのつかない損害を与えていると信じており、今は被害が広がらないことを祈るばかりだという。メインネットに。 Wei Tang氏は、「無責任なハードフォークはネットワークのセキュリティを破壊するだろうし、コードが法律であると毎日叫んでも無駄だ」と述べた。

Bob Summerwill 氏は、フォークの遅延はコミュニティが以前に選択したハード フォークのブロック番号を変更したのではなく、予測できないブロック時間要因によるものであると答えました。ブロック時間の予測における誤差はよくあります。コミュニティが不健全であるという非難に対して、ボブ・サマーウィルはETCコミュニティは非常に健全であると答えた。

対立を繰り返すが団結は確認できない。

6月14日、Wei Tang氏は、フェニックスのハードフォーク後、特に不変性の点でETCネットワークがイーサリアムの一貫性のロジックを破ったため、ETCのサポートを個人的に中止すると発表した。

1か月後、ETCの2大クライアントであるOpenEthereumとMultiGethはETCのサポートを停止すると発表した。また、これら 2 つのクライアントは依然として ETC ネットワーク上の総ノード数の 70% を共有しているため、これは ETC ユーザーが適切な措置を講じるよう公共サービスとして発表したものです。その後Wei Tangが公開した記事によると、大手クライアント2社がETCのサポートを中止した理由はWei TangがETCのサポートを中止した理由と同じだという。

これが攻撃の根源であり、ネットワークノードのクライアントが半分以上を占め、そのサービスが突然停止されると、その後の計算能力移行の過程でネットワークが危険になるはずです。

OpenEthereumとMultiGethがETCのサポートを停止すると発表したというニュースに関して、ETCアジアパシフィックコミュニティマネージャーのクリスチャン氏は、OpenEthereumの保守管理者であるGnosisがETCのサポートを停止する理由は開発に限られたエネルギーを注ぐためであると公式声明を発表したと述べた。イーサリアムメインネットの理由ではなく、魏唐氏が理由を述べた。

Phoenix 以降、MultiGeth の実際の開発者は Wei Tang 本人のみですが、いくつかの相違点により、Wei Tang は MultiGeth の ETC サポートを停止することを選択しました。

昨年以来、ETC は 3 回のハードフォーク アップグレードを完了し、ETC ネットワークは ETH と完全に一致しました。その中で、ETC Core チームは多大な貢献をしてくれました。今年の前半には早くも ETC コア チームは、より安全な Go 言語クライアント CoreGeth を開発しました。CoreGeth は Phoenix ハード フォークを完全にサポートしており、これまでのところ無傷で実行されています。 Gnosis への返信から、OpenEthereum と MultiGeth が終了した後も、CoreGeth は ETC Core によって維持される公式クライアントとして完全に信頼されており、ETC ネットワークにサービスを提供し続けていることもわかります。

すると Wei Tang は、OpenEthereum と MultiGeth が ETC を最も長い間サポートしている 2 つのクライアントであるという事実があると答えました。このうち、OpenEthereum は 4 年、MultiGeth は 2 年です。 ETC を 1 年以上サポートしているクライアントは他にありません。このうち、Hyperledger Besuは昨年9月からETCをサポートしており、CoreGethは今春MultiGethから分離してETCをサポートしており、OpenETCはETCのサポートを開始したばかりである。

Tang Wei 氏の見解では、ETC ネットワークが不変性の原則を放棄したことに加え、ETC のサポートを一時停止することも合理的かつ必要な対応です。なぜなら、過去 6 か月間、ETC コミュニティの非常に悪い側面を見てきたからです。

これはETCに対する最も激しいコメントです。クライアントの問題、コミュニティの不和、突然の攻撃に直面して。