V GodはETH2.0ビーコンチェーンの最初のハードフォーク提案HF1をリリースし、より公平なノードペナルティメカニズムを導入しました
編集者注: この記事は以下から引用しましたバビット情報（ID：bitcoin8btc）、カイル著、許可を得て掲載。
編集者注: この記事は以下から引用しました
バビット情報（ID：bitcoin8btc）
バビット情報（ID：bitcoin8btc）
、カイル著、許可を得て掲載。
「イーサリアムの創設者である V 神は、イーサリアム ビーコン チェーン (仮称「HF1」) の最初のハード フォークのアップグレード提案を Twitter で紹介しました。V 神は、HF1 は軽量クライアント サポートを追加し、仕様を簡素化し、効率を向上させ、ドキュメントによると、ハードフォークにより、開発者は最近リリースされたビーコンチェーンにいくつかの重要なアップグレードを行うことができ、変更に対するより深い有用なテストを行う方法にもなります。最小限のリソース要件があり、モバイル デバイス上で実行できるものです。これにより、「最小信頼ウォレット」は、By が提供する外部サービスに依存するのではなく、ブロックチェーン自体を検証できるようになります。
HF1 は、イーサリアム ビーコン チェーンの最初のハード フォーク アップグレードの暫定コード名です (このハード フォークの長期的な命名案については、こちらを参照してください)。 HF1 の主な目標は次のとおりです。
ライトクライアントのサポートを追加する
ビーコン チェーンのいくつかの脆弱性を修正します。これらの脆弱性は、ビーコン チェーンの生成が開始されたときに修正するには遅すぎて発見されました。
ビーコン チェーンのハード フォーク アップグレード メカニズムは、マイナー変更アップグレードの環境でテストされるため、後でより大きな変更を加えることができます。
HF1 で提案されているコンセンサスの変更には次のものが含まれます。https://github.com/ethereum/eth2.0-specs/pull/2130
同期委員会
ランダムに描画された「同期委員会」をビーコン チェーンに追加します。この目的は、軽量クライアントが非常に少ないオーバーヘッド (1 日あたり最低約 20 キロバイト、単一ブロックの検証に約 500 バイト) でチェーン ヘッドを決定できるようにすることです。これにより、ライトクライアントはモバイルデバイスや組み込みブラウザなどのユースケースで実際にビーコンチェーンを使用できるようになり、より信頼を最小限に抑えたウォレットエコシステムへの道が開かれます。
各期間 (約 27 時間) で、1,024 人の検証者が同期委員会のメンバーとしてランダムに選択されます。同期委員会の検証ノードは、現在の責任者を証明する署名を発行します。これらの署名は、ライト クライアントがこのヘッドを見つけるのに役立つ LightClientUpdate オブジェクトの一部としてブロードキャストされ、報酬のビーコン チェーンに含まれます。https://github.com/ethereum/eth2.0-specs/pull/2176
さらなるコンテンツ:
簿記改革（Tier1）
証明者の報酬の計算を置き換えました。 PendingAttestation オブジェクトを保存して最後に処理する代わりに、各バリデーターの状態を保存するビットフィールドを追加して、参加者に関するデータをリアルタイムに蓄積できるようにしました。ビットフィールドは、同じ委員会のバリデーターからのレコードが一緒に表示されるようにするために、「シャッフル順序」でソートされます。この変更の目的は、クライアントの実装を簡素化し、マークル ツリーの更新を安価にすることです。
具体的な参考資料:
簿記改革（第2段階）https://github.com/ethereum/eth2.0-specs/issues/2098
バリデータ セットに変更を加えますが、ペナルティ ブックキーピングはすべてのエポックではなく、64 エポックごとにのみ行われます。この目的は、「ギャップ期間の移行」を処理する複雑さを大幅に軽減することです。たとえば、2 つの連続するブロックが 1,000 個のスロットで隔てられ、その間にギャップ期間しかない、参加率が非常に低いチェーンがあります。このようなチェーンを処理するには、現在クライアントは、エポックごとに各バリデーターの残高を再計算することで、非アクティブなバリデーターにペナルティを課す必要がありますが、新しい提案では、それを 64 エポックごとに行うだけで済みます。
さらに、非アクティブペナルティの仕組みに 2 つの変更を加えました。https://github.com/ethereum/eth2.0-specs/pull/2192
https://github.com/ethereum/eth2.0-specs/pull/2194
非アクティブペナルティは、バリデータごとに二次関数になります。つまり、完全にオフラインだったバリデーターが残高の約 10% を失う非アクティブペナルティがある場合、この期間中 90% の時間オンラインだったバリデーターは残高の約 0.1% しか失うことはありません (比較〜 1%)。これは、ネットワーク接続の問題によりオフラインになっている誠実なノードではなく、本当に不正な動作をしているノードにペナルティを集中させることを目的としています。
INACTIVITY_PENALTY_QUOTIENT: reduced from 2**26 (= 67,108,864) to 3 * 2**24 (= 50,331,648)
PROPORTIONAL_SLASHING_MULTIPLIER: increased from 1 to 2
MIN_SLASHING_PENALTY_QUOTIENT: reduced from 2**7 (= 128) to 2**6 (= 64)
さらに詳しい議論はここでご覧いただけます:
バリデーターの非アクティブなペナルティは、決定後に停止されるのではなく、徐々に遅くなります。これにより、最終状態に達すると、オフライン ノードは一定期間バランスを失い続けることが保証され、バリデーターのオンライン時間の割合が、そのしきい値をわずかに上回るのではなく、2/3 より大幅に高くなります。
具体的な参考資料:
祝うべきことの 1 つは、バリデーターのペナルティを弱めることで、私たちが（完全ではないにせよ）わずかに危機から抜け出すことができるかもしれないということです。定数を変更します。
HF1 と (ほぼ) 同時に展開されたフォーク選択の変更https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf
(ブロック、スロット) ペア (ペア) フォークの選択
現在、最新のスロットでブロックが公開されていない場合、そのスロット中に証明者が LMD GHOST 証明の目的でサポートしているチェーン内の最新のブロックとみなされます。たとえば、次の図では、BLANK のプルーフは A のプルーフとしてカウントされます。https://github.com/ethereum/eth2.0-specs/pull/2197
ただし、これにより 34% の攻撃への扉が開きます。 m 個のバリデーターが各スロットに割り当てられ、悪意のある攻撃者が 0.34*m を制御すると仮定します。攻撃者は、スロット n+1 のブロック B を公開する権利もあります。攻撃は次のように進行します。攻撃者は B もその証拠も公開しません。すべての正直な認証者は、スロット n にはブロック A があったが、スロット n+1 には何も見えなかったという主張に投票します。このカウントは現在、A への投票とみなされます。スロット n + 2 では、誠実な提案者は A の上にブロック C を構築します。このとき、悪意のある提案者は B とその B の証明をスロット n + 1 と n + 2 にアナウンスします。上のフォークには 0.68*m のバッキングが付いていますが、上のフォークには 0.66*m のバッキングしかないため、下のフォークが勝ちます。
この攻撃については、この文書のセクション 3.1 で詳しく説明されています。
提案された解決策は、ブロックのツリーではなく (ブロック、スロット) ペアのツリー上で動作するようにフォーク選択の動作方法を変更することです。したがって、上のグラフでは、スロット n+1 の正直な投票は (BLANK,n+1) の投票としてカウントされるため、上のフォークをサポートするものとして正しくカウントされるため、上のフォークが取得するサポートは 1.32*m になります。したがって、攻撃を破ります。
