イーサリアムのPoS「ザ・マージ」への移行はアプリケーション層にどのような影響を与えるでしょうか?
ソース：
ソース：イーサリアム公式ブログ
イーサリアム ネットワークのプルーフ オブ ステーク (マージ) への移行が差し迫っています。現在、開発ネットワークが構築され、仕様が最終決定され、コミュニティへの支援の準備が本格的に始まっています。 Merge は、エンドユーザー、スマート コントラクトと dapps の運用方法への影響を最小限に抑えて移行するように設計されています。そうは言っても、途中で強調する価値のある小さな変更がいくつかあります。変更点を詳しく説明する前に、The Merge の全体的なアーキテクチャについての洞察を提供するリンクをいくつか示します。
ロードマップの進化
統合されたクライアントのアーキテクチャ
この記事の残りの部分は、読者が上記のことをよく理解していることを前提としています。もう少し詳しく知りたい方は、The Merge の完全な仕様を以下でご覧いただけます。
コンセンサス層
コンセンサス層
エンジンAPI
1
ブロック構造
イーサリアムの合併後、Proof of Work (PoW) はネットワーク上に存在しなくなります。代わりに、以前の PoW 部分は、ビーコン チェーン上に作成されるブロックの不可欠な部分になります。ビーコン チェーンは、以前の PoW コンセンサス レイヤーに代わる、イーサリアムの新しい PoS コンセンサス レイヤーと考えることができます。 Beacon Chain ブロックには、現在の PoW チェーン上のブロックと同等のマージされた ExecutionPayload が含まれます。以下の図は、この関係を示しています。
エンド ユーザーとアプリケーション開発者にとって、これらの ExecutionPayload は Ethereum と対話する場所です。この層のトランザクションは、引き続き実行層クライアント (Besu、Erigon、Geth、Nethermind など) によって処理されます。幸いなことに、実行層の安定性により、The Merge では最小限の重大な変更のみが導入されます。
2
鉱区とオマー鉱区
合併後、以前に PoW ブロック ヘッダーに含まれていたいくつかのフィールドは、PoS に関連しないため使用されなくなりました。ツールやインフラストラクチャへの中断を最小限に抑えるために、これらのフィールドはデータ構造から完全に削除されるのではなく、0 またはそれらのデータ構造と同等の値に設定されます。ブロック フィールドへの完全な変更は EIP-3675 で確認できます。
PoS は PoW のようにオマー (別名アンクル ブロック) を自然に生成しないため、各アンクル ブロック (オマー) 内のこれらのリストは空になり、このリストのハッシュ (オマーズハッシュ) は RLP エンコードされたハッシュ リストの空のハッシュになります。また、PoW には難易度と nonce も含まれるため、以降は 0 に設定され、バイト サイズの値が与えられます。
マイニングに関連する別のフィールド mixHash は 0 に設定されませんが、ビーコン チェーンの RANDAO 値が含まれます。これについては以下で詳しく説明します。
3
ブロックハッシュと難易度オペコードの変更
マージ後も、BLOCKHASH オペコードは引き続き機能しますが、このオペコードが提供する擬似ランダム性は、PoW ハッシュ手順によって偽造されなくなったため、はるかに弱くなります。
関連して、DIFFICULTY オペコード (0x44) が更新され、名前が RANDOM に変更されます。マージされると、ビーコン チェーンによって提供されるランダム ビーコンの出力が返されます。したがって、BLOCKHASH と比較すると、このオペコードはアプリケーション開発者が使用する強力なランダム性のソースになりますが、それでも偏りはあります。
RANDOM によって公開された値は ExecutionPayload に保存されます。ExecutionPayload には、PoW 計算に関連する値 mixHash が保存されます。ペイロードの mixHash フィールドの名前もランダムに変更されます。
以下は、マージの前後で DIFFICULTY および RANDOM オペコードがどのように機能するかを示しています。
マージ前に、0x44 オペコードがブロック ヘッダーの難易度フィールドを返すことがわかります。マージ後、RANDOM という名前に変更されたオペコードは、以前は mixHash を含んでいたブロック ヘッダー フィールドを指し、ビーコン チェーンの状態からのランダムな値を格納するようになりました。
EIP-4399 で正式化されたこの変更により、オンチェーン アプリケーションにマージが発生したかどうかを評価する方法も提供されます。この EIP の概要によると、次のようになります。
さらに、この EIP によって提案された変更により、スマート コントラクトは PoS へのアップグレードが行われたかどうかを判断できるようになります。これは、DIFFICULTY オペコードの戻り値を分析することで実行できます。値が 2**64 より大きい場合、トランザクションが PoS ブロックで実行されていることを意味します。
4
ブロックタイム
この合併はイーサリアムの平均ブロック時間に影響を与えるだろう。現在、PoW では平均約 13 秒ごとにブロックが生成されており、実際のブロック間隔時間には大きな差があります。プルーフ・オブ・ステークでは、バリデーターがオフラインになったり、時間内にブロックをコミットしなかったりしてスロットが失われない限り、ブロック間隔はちょうど 12 秒になります。実際にはスロットでもこれが起こります<1%。
これは、ネットワーク上の平均ブロック時間が約 1 秒短縮されることになります。計算において特定の平均ブロック時間を想定するスマート コントラクトでは、これを考慮する必要があります。
5
セーフヘッドとファイナルブロック
PoW では、ブロックの再編成はいつでも可能です。アプリケーションは通常、新しいセーフヘッドで数ブロックがマイニングされるのを待ってから、そのブロックが正規チェーンから削除される可能性が低い、または「確認済み」であると判断します。マージ後は、最終的で安全なヘッド ブロックという概念が得られます。これらのブロックは、「確認済み」PoW ブロックよりも確実に使用できますが、正しく使用するには理解の変更が必要です。
ファイナライズされたブロックとは、バリデーターの 2/3 以上によって正規として受け入れられたブロックです。競合するブロックを作成するには、攻撃者はステーキングされた ETH の合計の少なくとも 1/3 を燃やす必要があります。これは、この記事の執筆時点で 100 億ドル以上 (または 250 万以上) の ETH を意味します。
安全なヘッドは、通常のネットワーク条件下で正規チェーンに含めたいブロックです。ネットワーク遅延が 4 秒未満で、ほとんどのバリデーターが誠実で、フォーク選択ルールに対する攻撃がないと仮定すると、安全なヘッドが孤立ブロックになることはありません。さまざまな状況で安全なヘッドがどのように計算されるかについて詳しく説明したプレゼンテーションは、ここから入手できます。さらに、安全ヘッドの仮定と保証は、今後の論文で正式に定義され、分析される予定です。
マージ後、実行層 API (JSON RPC など) は、最新のブロックを要求されたときにデフォルトでセーフヘッドを返すようになります。通常のネットワーク条件では、チェーンの安全な先頭と実際の先頭は同等になります (安全な先頭と末尾は数秒間のみ)。セーフヘッドは現在のPoW最新ブロックに比べて再編成されにくいです。 PoW チェーンの実際の先端を公開するために、安全でないフラグが JSON RPC に追加されます。
ファイナライズされたブロックは、新しいファイナライズされたフラグを介して JSON RPC 経由でも公開されます。これらは、PoW 証明のより強力な代替手段として機能します。以下の表はこれをまとめたものです。
次のステップ
6
次のステップ
この記事は Yuan Universe の Tao からのものであり、許可を得て転載しています。
この記事は Yuan Universe の Tao からのものであり、許可を得て転載しています。
