Ethereum PoW と PoS の統合はアプリケーション層にどのような影響を与えますか?

Ethereum ネットワークの Proof of Stake (The Merge) への移行が近づいています。開発ネットワークが確立され、仕様が完成し、コミュニティへのアウトリーチの準備が本格的に始まっています。マージは、エンドユーザー、スマート コントラクト、および dapp の動作方法への影響を最小限に抑えて移行するように設計されています。そうは言っても、注目に値する小さな変更点がいくつかあります。変更点について詳しく説明する前に、The Merge の全体的なアーキテクチャについての洞察を提供するリンクをいくつか紹介します。

• ロードマップの進化

• 統合クライアントアーキテクチャ

この記事の残りの部分では、読者が上記の内容を理解していることを前提とします。さらに詳しく知りたい人のために、The Merge の完全な仕様を以下でご覧ください。

• 実行レイヤー

• コンセンサスレイヤー

• エンジンAPI

ブロック構造

Ethereum の合併後、ネットワーク上で Proof of Work (PoW) は存在しなくなります。代わりに、以前の PoW 部分は、ビーコン チェーンで作成されるブロックの不可欠な部分になります。ビーコン チェーンは、以前の PoW コンセンサス レイヤーに代わる、Ethereum の新しい PoS コンセンサス レイヤーと考えることができます。ビーコン チェーン ブロックには、現在の PoW チェーン上のブロックと同等のものを統合した ExecutionPayloads が含まれます。次の図はこの関係を示しています。

エンドユーザーとアプリケーション開発者にとって、これらの ExecutionPayloads は Ethereum とのやり取りが発生する場所です。このレイヤー上のトランザクションは、引き続き実行レイヤー クライアント (Besu、Erigon、Geth、Nethermind など) によって処理されます。幸いなことに、実行レイヤーの安定性により、マージによってもたらされた重大な変更は最小限に抑えられました。

鉱業とオマーブロックフィールド

合併後、以前は PoW ブロック ヘッダーに含まれていたいくつかのフィールドは、PoS とは関係がないため使用されなくなりました。ツールとインフラストラクチャの中断を最小限に抑えるために、これらのフィールドはデータ構造から完全に削除されるのではなく、0 またはそれに相当するデータ構造に設定されます。ブロック フィールドへの完全な変更については、EIP-3675 ​​を参照してください。

PoS は PoW のように自然に ommers (別名 uncle ブロック) を生成しないため、各 uncle ブロック (ommers) 内のこれらのリストは空になり、このリストのハッシュ (ommersHash) は RLP でエンコードされたハッシュの空のリストになります。同様に、PoW には難易度と nonce も含まれるため、今後は 0 に設定され、バイト サイズの値が与えられます。

別のマイニング関連フィールドである mixHash は 0 に設定されませんが、ビーコン チェーンの RANDAO 値が含まれます。これについては以下で詳しく説明します。

BLOCKHASH & 難易度オペコードの変更

合併後も BLOCKHASH オペコードは引き続き機能しますが、PoW ハッシュ プロセスを介して偽造できなくなるため、このオペコードによって提供される疑似ランダム性は大幅に弱くなります。

関連して、DIFFICULTY オペコード (0x44) が更新され、RANDOM に名前が変更されます。マージされると、ビーコン チェーンによって提供されるランダム性ビーコンの出力が返されます。したがって、BLOCKHASH と比較すると、このオペコードは、偏りはあるものの、アプリケーション開発者が使用するランダム性のより強力なソースになります。

RANDOM によって公開された値は、PoW 計算に関連する値 mixHash が格納される ExecutionPayload に格納されます。 Payload の mixHash フィールドの名前も random に変更されます。

以下は、マージ前とマージ後の DIFFICULTY および RANDOM オペコードの動作を示した図です。

マージ前に、0x44 オペコードがブロック ヘッダーの難易度フィールドを返すことを確認しました。マージ後、RANDOM に名前が変更されたオペコードは、以前は mixHash が含まれていたブロック ヘッダー フィールドを指し、ビーコン チェーンの状態からのランダムな値を格納するようになりました。

EIP-4399 で正式化されたこの変更により、オンチェーン アプリケーションがマージが発生したかどうかを評価する方法も提供されます。この EIP の紹介によると:

さらに、この EIP によって提案された変更により、スマート コントラクトは PoS へのアップグレードが行われたかどうかを判断できるようになります。これは、DIFFICULTY オペコードの戻り値を分析することによって実行できます。値が 2**64 より大きい場合、トランザクションが PoS ブロック内で実行されていることを意味します。

ブロックタイム

この合併はイーサリアムの平均ブロック時間に影響を与えるでしょう。現在、PoW では平均 13 秒ごとにブロックが生成され、実際のブロック間隔時間は大きく異なります。プルーフ・オブ・ステークでは、バリデータがオフラインになったり、時間内にブロックを送信しなかったりしてタイムスロットが失われない限り、ブロック間隔は正確に 12 秒になります。実際には、これはスロットの 1% 未満で発生します。

これは、ネットワーク上の平均ブロック時間が約 1 秒短縮されたことを意味します。計算において特定の平均ブロック時間を想定するスマート コントラクトでは、これを考慮する必要があります。

セーフヘッドとファイナルブロック

PoW では、ブロックの再編成は常に可能です。アプリケーションは通常、ブロックが正規チェーンから削除される可能性が低い、または「確認済み」であると判断する前に、新しいヘッド ブロック (安全なヘッド) でいくつかのブロックがマイニングされるのを待機します。合併後、最終的で安全なヘッダー ブロックの概念が生まれます。これらのブロックは、「確認済み」PoW ブロックよりも信頼性が高く使用できますが、正しく使用するには理解の変更が必要です。

確定したブロックとは、バリデーターの 2/3 以上によって正規のブロックとして受け入れられたブロックです。競合するブロックを作成するには、攻撃者はステークされた ETH の合計の少なくとも 1/3 を破壊する必要があります。これは、この記事の執筆時点では 100 億ドル (または 250 万ドル超) 以上の ETH を意味します。

安全なヘッド ブロックとは、通常のネットワーク条件下で正規チェーンに含めるブロックです。ネットワーク遅延が 4 秒未満で、バリデーターの大多数が正直であり、フォーク選択ルールに対する攻撃がないと仮定すると、安全なヘッドが孤立ブロックになることはありません。さまざまな状況で安全な水頭を計算する方法を詳しく説明したプレゼンテーションは、こちらでご覧いただけます。さらに、安全な頭部の仮定と保証は、今後の論文で正式に定義され、分析される予定です。

マージ後、実行層 API (JSON RPC など) は、最新のブロックを要求するときにデフォルトでセーフ ヘッドを返します。通常のネットワーク状況では、安全な先頭とチェーンの実際の先端は同等になります (安全な先頭と末尾は数秒しか異なりません)。現在のPoW最新ブロックと比較すると、セーフヘッドが再編成される可能性は低くなります。 PoW チェーンの実際の先端を公開するために、JSON RPC に unsafe フラグが追加されます。

ファイナライズされたブロックは、新しいファイナライズ フラグを介して JSON RPC 経由でも公開されます。これらは、PoW 証明のより強力な代替手段として機能する可能性があります。これをまとめたものが次の表です。

ブロック型コンセンサス メカニズム JSON RPC 再編成の条件 headPoWlatest 発生する可能性がありますが、注意して使用する必要があります headPoSunsafe 発生する可能性がありますが、注意して使用する必要があります safe headPoSlatest 発生する可能性がありますが、実現するには大きなネットワーク遅延またはネットワークへの攻撃が必要です。ハッシュレートの大部分は、深さ > # 確認を持つ競合チェーンをマイニングするために必要となるため、confirmedPoWN/A が発生する可能性は低いです。競合チェーンを完了するにはバリデータの 2/3 以上が必要であり、少なくとも 1/3 を削減する必要があるため、finalizedPoSfinalized が発生する可能性は極めて低くなります。

次のステップ

この投稿が、アプリケーション開発者が待望の PoS 移行に備える一助となることを願っています。今後数週間で、より広範なコミュニティによるテスト用にテストネットが利用可能になります。また、インフラストラクチャ、ツール、およびアプリケーションの開発者が質問したり、The Merge に関する最新の技術アップデートを聞いたりできる The Merge コミュニティ コールも近々開催されます。

--------------------------------------------------------------------------------------------------------

「Safe Head」セクションの核となるコンテンツを提供してくれた Mikhail Kalinin 氏と、この記事の草稿をレビューしてくれた Danny Ryan 氏と Matt Garnett 氏に感謝します。

出典: イーサリアム公式ブログ

(https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/)

著者: Tim Beiko、イーサリアム開発者、イーサリアム財団のコミュニティマネージャー