イーサリアムの合併タイムノードが近づいているので、今日は合併後にイーサリアムが直面する規制上の問題とアプリケーション層の問題について説明します。
2022年8月16日、イーサリアムの共同創設者ヴィタリック・ブテリン（V神）はTwitterでのディスカッションに参加し、「バリデーターが特定のプロトコル（Lido、Coinbaseなど）を通過した場合、イーサリアムコミュニティはどう反応するだろうか」と述べた。は、この審査をイーサリアムへの攻撃とみなし、より広範な合意（社会的合意）を通じてこれらのバリデーターの約束された権利と利益を破壊することを選択すると述べた。
この議論のきっかけは、最近、米国財務省外国資産管理局（OFAC）が、Tornado Cash 関連のイーサリアムアドレスを制裁対象のリストに追加したことです。ただし、現在の制裁はすべて集中レベルであり、分散化を伴うスマートコントラクトの部分に技術的制裁を課すことはできません。
これは、米国がトルネードキャッシュを完全に制裁したいのであれば、基礎となるイーサリアムチェーンを管理する必要があることを示しています。次に、米国政府がイーサリアムを規制した場合、政府は何に直面するのかという疑問が生じます。
米国政府がイーサリアムを規制したい場合、最大の可能性は、大規模なPoSプレッジサービスプロバイダーに対し、イーサリアムにおけるプロトコルレベルのトランザクションレビューの実施を義務付けることだ。簡単に言えば、
簡単に言えば、これは、認可されたアドレスによって送信されたすべてのリクエストを監視し、認可されたアドレスのトランザクションを含むすべてのブロックを拒否することであり、ブロックが 66% 以上の株式検証投票を通過できなかった場合、ブロックのすべてのトランザクション リクエストはロールバックされます。これは、認可されたアドレスがいかなる操作も実行できなくなり、バリデーターがいかなるペナルティも受けないことを意味します。
現在までにイーサリアムネットワーク全体で約束されたETHの量は約1,300万ETHで、Lidoを通じて約束されたETHの量は約30.9%、Coinbaseが約14.7%、Krakenが約8.5%を占めています。
画像の説明
Dune Analytics の図
上記の起こり得る状況に対応して、イーサリアムコミュニティは、OFACが検証ノードを通じてイーサリアムを規制する場合にどうするかを議論するためにTwitter上で投票を開始しました。 V 神は、上記の状況をイーサリアムへの攻撃として扱い、より広範な合意を通じてこれらのノードの約束された権利と利益を破壊することを支持しています。
次に、アプリケーション層について説明します。
前回の記事で触れましたが、計画によれば、イーサリアムのマージは「被害を最小限に抑える」という原則に基づいて実行されるため、元々実行されていたアプリケーションクライアントは何の意味もなくPoSに切り替えることができます。そうは言っても、「最小限の混乱」にもかかわらず、途中で注目に値する小さな変更がいくつかあります。ここではアプリケーション開発の観点から合併後に注意すべき点を中心に紹介します。
合併後、現在の Eth1 および Eth2 クライアントは、イーサリアムの実行層およびコンセンサス層 (またはエンジン) になります。これは、Eth1 またはビーコン チェーン クライアントのノード オペレーターが、完全に検証されたノードを取得するためにスタックの「残りの半分」を実行する必要があることを意味します。文章
画像の説明
マージされたクライアント アーキテクチャ (画像提供: Danny Ryan)
ブロック構造
マージが発生すると、ビーコン ノードは現在の PoW チェーンを監視し、TERMINAL_TOTAL_DIFFICULTY と呼ばれる事前定義された合計難易度しきい値に達するまで待機します。つまり、PoW チェーンが合計難易度 >= TERMINAL_TOTAL_DIFFICULTY のブロックを生成すると、それはチェーン上の最後の PoW ブロックとみなされます。
その後、PoW ブロックに含まれるデータはビーコン チェーン ブロックのデータ コンポーネントとなり、ビーコン チェーンは以前の PoW コンセンサス レイヤーに代わるイーサリアムの新しい PoS コンセンサス レイヤーとみなすことができます。
同時に、コンセンサス検証を実行するとき、ビーコン ノードはその実行エンジン (アップグレード前の Ethereum クライアント) と通信し、ExecutionPayload の生成または検証を依頼します。 ExecutionPayloads には、親ハッシュ、状態ルート、基本料金、実行するトランザクションのリストなどの情報が含まれています。
これらのデータが生成または検証されると、ビーコン ノードはそれらを p2p ネットワーク上の他のノードと共有します。
画像の説明
画像提供：ダニー・ライアン
実行エンジン
合併後、実行エンジンは主に状態管理、ブロック作成、検証機能を担当し、コンセンサスに関連する操作は含まれなくなりました。このため、実行エンジンが一部変更されており、主に以下の 3 点の変更内容が EIP-3675 に記載されています。
まず、ブロックのいくつかのデータフィールドが変更されます。元のブロック内のいくつかの PoW 関連フィールド、特にマイニング (難易度、mixHash、nonce)、アンクル ブロック報酬 (ommers、ommersHash) に関連するフィールドを 0 (またはそれらのデータ構造と同等) に設定します。さらに、extraData の長さもメインネットでは 32 バイトに制限されます。
次に、マージされたビーコン チェーンのみがブロックを生成できるため、実行エンジンはブロックの処理を停止し、ブロック報酬を受け取りません。ただし、トランザクション手数料は引き続き処理されます。つまり、実行エンジンが ExecutionPayload を作成するとき、すべてのトランザクションの開始者が少なくとも現在の BaseFeePerGas 料金を支払い、残りのトランザクション料金を FeeReceipient に送信できることを確認する必要があります。 FeeReceipient はビーコン チェーン バリデーター アドレスではなく、アップグレード前のイーサリアム アドレスを参照することに注意してください。
最後に、PoS が PoW に置き換わると、実行エンジンはブロックのブロードキャストを担当しなくなりますが、トランザクションは引き続き p2p ネットワーク経由でブロードキャストされます。具体的なプロセスとしては、まずユーザーがローカル RPC リクエストを通じてトランザクションをコンセンサス クライアントに送信し、トランザクションはビーコン ブロックにパッケージ化されます。その後、コンセンサス クライアントは、p2p ネットワーク内でビーコン ブロックをブロードキャストします。
画像の説明
画像提供：ダニー・ライアン
ブロックハッシュと難易度オペコードの変更
合併後も、BLOCKHASH オペコードは引き続き使用できますが、プルーフ オブ ワークを通じて対応するハッシュ値を生成しなくなるため、このオペコードによって提供される擬似ランダム性は大幅に弱まります。
同時に、DIFFICULTY オペコード (0x44) の名前が RANDOM に変更され、ビーコン チェーンによって提供されるランダムな値が返されます。したがって、この値は、アプリケーション開発者が使用できるランダム性のより優れたソースとして BLOCKHASH に置き換わります (ただし、バイアスはまだ存在します)。
RANDOM 値は、Proof-of-Work 計算に関連する元の mixHash の代わりに ExecutionPayload に保存されます。この値は、アップグレード後に名前がランダムに変更されました。
画像の説明
画像提供：ダニー・ライアン
マージする前に、0x44 オペコードがブロック ヘッダーの難易度フィールドを返すことがわかります。マージ後、乱数の生成を担当する RANDOM オペコードは、名前がrandomに変更された元の mixHash フィールドを指します。
ブロックタイム
この合併はイーサリアムの平均ブロック時間に影響を与えるだろう。現在、PoW では平均 13 秒ごとにブロックが生成されますが、実際のブロック間隔時間はネットワークの混雑により大幅に変動します。ただし、PoS では、検証者がオフラインであるか、時間内にブロックを送信できず、特定のスロットを逃すなどの極端な状況が発生しない限り、ブロック間隔は 12 秒に固定されます。
参考文献:
参考文献:
《元のリンク》
