BTC
ETH
HTX
SOL
BNB
View Market
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

イーサリアム難易度爆弾の爆発と解体

以太坊爱好者
特邀专栏作者
この記事は約5284文字で、全文を読むには約8分かかります
爆弾はどうやって爆発したのですか?正しい爆弾解除姿勢とは何ですか?
AI要約
爆弾はどうやって爆発したのですか?正しい爆弾解除姿勢とは何ですか?

編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfa​​ns)編集者注: この記事は以下から引用しました

イーサリアム愛好家 (ID: ethfa​​ns)

イーサリアム愛好家 (ID: ethfa​​ns)

、著者:トーマス・ジェイ・ラッシュ、翻訳・校正:Zeng Mi & A Jian、許可を得てOdailyより転載。

イーサリアムの時限爆弾が爆発するたびに、常に 2 つの問題が私たちの前に現れます。最初の質問 (そしておそらくより重要な質問) は、「いつブロックの生産が遅くなるか、それは耐えられないことです。」 2 番目の質問は、「今度は、爆弾をどのくらい遅らせるべきですか?」 です。

この短いエッセイで、私は 2 番目の質問に対する自明の理にかなった単純な答えを提案します。難易度ボムはどのくらい遅らせる必要がありますか?私の提案は、「ハード フォークをブロックの高さ N で実行する必要があるとすると、ディフィシティ ボムを N ブロック (セキュリティを強化するにはそれ以下) ブロックだけ遅らせることです。」です。

この記事では難易度をどのように計算するかについては説明しません(知りたい場合は以前の記事を参照してください)。下の図は前回の記事にも登場しましたが、難易度の計算式をまとめたものです。

(画像内のテキスト: 現在の難易度値 dc は、前の難易度値 dp と 2 つの部分を加算することによって取得されます。最初の部分は、現在のブロックと前のブロックの間の時間間隔に基づいて難易度レベルを調整します。s = tsc とします。 - ts、s < 10 の場合、上記の式の係数 max(x) は 1 と評価されます (割り算法を想定) この場合、ブロックの作成が早すぎると難易度が上がり、ブロックの作成速度が遅くなります。 10<= s < 20 の場合、係数 max(x) は 0 になるため、s が目標時間の 14 秒に近づくと、難易度は調整されなくなります。また、s>=20 の場合、次の値は係数 max(x) は次のようになります。係数は -99 まで徐々に減少します。これにより、難易度が低下し、ブロック生成の速度が向上します。方程式の 2 番目の部分は、前のブロックのブロック番号に基づいています。 100,000 を指数で割る、周期的なステップ関数としての 100,000 ブロック。2 番目の部分は、私たちがよくディフィシティ ボムと呼ぶものです。2 番目の部分がなければ、ディフィシティ ボムについて語ることは不可能です。)

式の最初の部分を、私は「調整」(またはパート A)と呼びます。この部分は、現在のブロックの難易度を調整することで、前のブロックのブロック生成時間のずれを補正します。この調整により、最後のブロックの生成にかかった時間に応じて、難易度が低くなったり高くなったりします。上の画像の最初の括弧は、この部分を強調表示しています。仕組みを理解してください。部分 A の実際の効果は設計目標とまったく同じであり、その機能は、ネットワーク動作に対するハッシュ レート変動の影響を平滑化することです (訳者注: ハッシュ レートは計算能力の単位であるため、ハッシュ レートを指す場合にも使用されます)。計算能力)。以下のグラフから、計算式の A 部分が期待どおりに機能していることがはっきりとわかります。

パート A がハッシュ レートの影響を排除するように設計どおりに動作するからといって、時限爆弾を遅らせる方法を考えるときに実際の計算能力の大きさを考慮する必要はないと思います。つまり、計算能力が低すぎるとディフィシティ ボムが爆発する際のブロック生成時間が長くなりませんし、計算能力が高すぎるとディフィシティ ボムの影響が緩和されません。上記の分析を踏まえると、式の A 部分はブロック時間の遅延とは何の関係もないというのが私の結論です。そして、式の 2 番目の部分 (爆弾を引き起こす B 部分) がすべての問題を引き起こす犯人です。

以下の分析により、これら 2 つの部分を別々に扱うことが十分に可能であることがわかります。これらの分析により、パート A はブロックの生成に影響を及ぼさない一方、パート B (爆弾) がブロック時間を延長させることが容易にわかります。さらに、フォークごとにエポックを 0 にリセットするだけで爆弾を解除することがいかに簡単であるかがわかります。

副題

データを生成してフォーマットする

上記のコードを実行すると、次の非常に単純なデータ ファイルを .csv 形式で生成できます。

上記のデータと EtherScan から取得した毎日のハッシュ レート リストを組み合わせると、イーサリアムの難易度の計算を理解するには十分以上です。 RStudio と「R」と呼ばれるデータ プログラミング言語を使用して、以下のグラフを作成しました。 「R」言語に詳しくない場合は、非常に優れたプログラミング言語であるため、チェックしてみることを強くお勧めします。

まずはイーサリアムのハッシュレートを見てみましょう。

日次平均ハッシュレート

最初のグラフは、EtherScan からのデータを使用して、イーサリアム メインネットの 1 日あたりの平均ハッシュ レートを示しています。データがどのように収集/作成されたかわからないので、その信憑性を保証することはできませんが、私はそれが正しいと仮定しています。このリンクをクリックすると、関連データが表示されます。

考察: 上のグラフから、イーサリアムのハッシュレートがイーサの価格に応じて変化することは明らかです。このグラフはイーサリアムの価格変動を思い出させます。 2017 年の夏にハッシュ レートが急騰し、2018 年の第 1 四半期にピークに達しました (通貨の価格とまったく同じです)。 2016 年 10 月のハッシュ レートの変動は、当時の悪名高い DDos 攻撃によるもので、上の図の 2 本の灰色の縦線は、ビザンチン ハード フォーク (2017 年 10 月) とコンスタンティノープル ハード フォーク (2019 年 1 月) の 2 つのハード フォークを表しています。 。当面はこの画像をここで分析しますが、次にブロックチェーンの難易度データについて説明するときにも言及します。

副題

生の難易度データ

難易度データに基づく最初のグラフは、Parity の RPC 呼び出し get_Block によって返されたデータを示しています。まず、いくつかの標準的な統計を以下に示します。

最初のグラフは非常に直感的です。

考察: 上図のデータはブロック 8,920,000 で生成されました。 「R」言語ではこれほど多くのデータ レコードを処理するのは簡単ですが、データ マイニングの反復的な性質を考慮すると、100 件ごとに 1 件のレコードをサンプリングし、結果として約 9,000 件のレコードが得られ、上記の内容が図に示されています。前回の記事と同様に、上の画像の灰色の縦線もハード フォークを表しています。

赤い線の高さ (y(x) = ブロック.x の難易度) は、指定されたブロックの難易度の値を表します。各分岐点で難易度爆弾を解体した場合の効果が簡単にわかります。前回の記事のハッシュ レートのグラフに戻ると、2016 年秋の DDos 攻撃では、難易度とハッシュ レートの関係がわかります。

難易度ボムが解体されていないと仮定すると、実際には難易度がアクティブになった高さから赤い線を上に伸ばします。両方のハード フォークに対して同じことを行うと、これがハッシュ レートの変化のグラフと驚くほど一致していることがわかります。 。言い換えれば、ハッシュレートと難易度は密接に関係しており、これは非常に理にかなっています。それが難易度公式のパート A がそのように設計されているからです。さまざまなハッシュレートの難易度値を直接調整するために存在します。

難易度ボムの解体によってマイナーの行動が変わることはありません。彼らの採掘リグは、困難爆弾が機能しなくなる前でも後でも、同様に正常に動作し続けました。唯一の変化は、ブロックを生成する平均時間が短くなったことです。

考察: 上のグラフを縦線で 100,000 ブロックのグループに分割します。目を開いて注意深く見てみると、難易度ジャンプを表す曲線が、作成した垂直線 (分割線) と正確に一致しています。これらの仕切りの間では、難易度は上昇し続けますが、仕切りでのジャンプほど速くはありません。難易度の爆発的な増加は、2017 年にハッシュ レートが急上昇したという事実と一致しています。

おそらく、連続する「爆発」にも気づいたかもしれません。爆弾が爆発するたびに、難易度の値が前回の 2 倍増加します。これらのジャンプの周期性は、現時点で何が起こっているかを理解するために特に重要であることがわかりました。

この記事の残りの図では、難易度の式の最初の部分 (つまり、パート A または「調整」) と 2 番目の部分 (つまり、パート B または「爆発」) を分離することが目標です。したがって、将来の難易度ボムに対処する方法をよりよく理解するのに役立ちます。

副題

ブロックごとに難易度が変わる

次のグラフでは、連続する各ブロック間の難易度の変化を確認します。計算式はy(x) = ブロックxの難易度値 - ブロックxの難易度-1

あなたにとって、このグラフはディフィシティ ボムを初めて視覚的に表現したものかもしれません。明らかに、各爆発は前の爆発の 2 倍の難易度になります。

しかし私の意見では、この状況はまだ十分に明確ではありません。たとえば、なぜ同じパターンがコンスタンティノープル中に明確に再現されなかったのでしょうか?実際、ハッシュレートが大幅に向上したためです。計算のこの部分ではブロック時間を 14 秒に維持できますが、システムの変動はより激しくなります。これは、コンスタンティノープル分岐点に近づいたときに、より激しい変動によって影が隠れたため、ディフィシティ ボムを識別できなかった理由も説明します。

では、もっとはっきりと見えるようにするための他の対策はあるのでしょうか?確かに!この方法は実際に存在しており、次の図で明らかにします。

副題

難易度の相対的な変化

記事のこのセクションの最後のグラフは、ブロックの合計難易度に対する難易度の変化の割合を示しています。計算式は

前のグラフは、難易度の生の変化を示しています。このグラフは、正規化された難易度の変化を示しています。これにより、ハッシュ レートの増加の影響が除去され、難易度計算式の 2 つの異なる部分 (パート A とパート B) がより明確にわかります。

ディスカッション: 前回の記事で、ディフィシティ ボムについて議論する際に、コンピューティング パワーを心配するのは逆効果であると述べた理由が理解できたはずです。このグラフから、時限爆弾が「頭を上げる」まで、ブロックの生成はハッシュレートの増加(または減少)の影響を受けないことがはっきりとわかります。式のパート A は、ブロック生成の速度と出力を安定した状態に保ちます。 (平均化および正規化されたデータからの) 難易度は、時限爆弾が爆発するまではほとんど影響を受けません。

ここで注目すべきさらに 2 つの興味深い点があります: (1) 上の画像から、ビザンチウムとコンスタンティノープルの間の距離よりもはるか上にあるにもかかわらず、爆弾がチャートの右端で「上を向いて」始めていることもわかります。 (2) グラフの下部の縞模様は、式の A 部分の 10 で割る式の部分によるものです; (3) Ha が高くなるほど、ヒッチ レートが「ヘッド アップ」を遅らせるように見えます。 」とレーン・レッティグ氏がコンスタンティノープル分岐点の前に述べたように、これについては上記の記事でも書きました。

この写真についてはまだ共有したいことがたくさんあるので、いつか戻ってきて続きを書くことになるかもしれません。しかし、将来的には爆弾を解除するためのより良い方法が欲しいと思っています。

副題

爆弾を解除するより良い方法

まず最初に、時限爆弾を心配しながら計算能力の変動を心配するのは逆効果であることをもう一度強調したいと思います。計算式のパート A では、計算能力の増加 (または減少) の影響がすでに除外されています。これはまさにパート A の内容です。ほぼ完全に平坦な難易度の増加 (当時のブロックの高さに比べて) は、パート A がほぼ完璧に機能することを証明しています。どうやら、ハッシュ レートはブロック時間に影響を与えないようですが、これはすでにわかっています。難易度調整はそのために設計されています。

爆弾は、上記の式の末尾に追加の値を追加することで定義されます。

(翻訳者注: Floor(x) は切り捨ての関数です。つまり、x 以下の最大の整数をとります。たとえば、floor(3.14) = 3)

上の式は底が 2 のべき乗関数です。 p = フロア(現在のブロック番号/100,000) とすると、上記の式を 2p に書き換えることができます。 (式の最後の -2 が食べられているのではないかと疑問に思うかもしれません。いいえ、計算値を小さくする機能があるため、当面は無視します。) 最後に、長いステップ関数が得られます。

ただし、コア開発者が爆弾を 2 回リセットしていることに注意してください。そう、文字通り「リセット」、爆弾の計算のサイクル開始をリセットします。これは、Go コードを使用して計算に使用される疑似ブロックを作成することで実現されます。これまでのところ、偽のブロックには過去に爆弾をリセットする効果があったようです。以下の修正された図は、この期間に実際に何が起こったかを示しています。

次の表にリセット後の情報を示します。何かおかしな点はありましたか?

ビザンチン フォーク後の疑似ブロック番号は 1,370,000 で、この値を 100,000 で割ると、周期 13 が得られます。つまり、ハッシュレート調整後、各ブロックの難易度はさらに 213 増加します。コンスタンティノープルのハードフォークが発生すると、偽のブロック数は 2,280,000 にリセットされました。これは、期間が 22 になったことを意味し、各ブロックの難易度がさらに 222 増加したことを意味します。だからこそ時限爆弾が予想よりも早く爆発したのだと思います。前回リセットしたときに十分に遡っていないためです。

今回時限爆弾をリセットするための推奨値は、69,000 ブロックをロールバックしてエポックを 0 にすることです。これが正しいリセット量です。

時限爆弾をリセットする必要があるときはいつでも、それを正しい値にリセットする非常にシンプルで簡単な方法があります。このようにして、ディフィシティボムに関連する問題のほとんどは解消されます。難易度ボムをリセットするときのブロック数をフォークの FORK_BLOCK_NUMBER (フォーク ブロック番号) と同じに戻すだけです (またはわずかに調整します)。こうすることで偽のブロック番号が0に近くなり、エポックも0になります。

結論は

ブロック生成速度の低下は主に時限爆弾の存在によるものであるため、上記のように「ヘッドアップ」効果は完全に予測可能になります。部分 B の計算は擬似ブロック番号に完全に依存します。コンスタンティノープル分岐点でこれを実行していれば (以下の表を参照)、時限爆弾はそれほど早く爆発しなかったでしょう。

副題

結論は

开发者
ETH
Odaily公式コミュニティへの参加を歓迎します
購読グループ:
https://t.me/Odaily_News
チャットグループ:
https://t.me/Odaily_GoldenApe
公式アカウント:
https://twitter.com/OdailyChina