The MergeによるEthereumのPoSへの移行

Ethereum 2.0のロードマップがだいぶ変わっていたので、久しぶりに調べてみた↓

Ethereum 2.0とその変遷

2018年に発表されたEthereum 2.0のロードマップは、シャーディングによりEthereumのスループットを向上させるのが目的で、3つのフェーズで構成されていた。

最初のフェーズ0では、PoSベースのBeacon chainを導入する。
続くフェーズ1では、データシャードを追加する。
最後のフェーズ2では、各シャードでコントラクトの実行ができるように、各シャードにVMを追加する。

全フェーズのデプロイには数年間かかるという、長期に渡るロードマップだった。しかし、Ethereumのスケーリングの問題はそれを待つほど余裕がなく、ソリューションのより早い展開が求められていた。

そこで既存のPoWチェーンの改善をするStateless Ethereumなどの研究も始まる。また、Beacon chain自体は割と早く展開できるということもあり、既存のEVMチェーンをEthereum 2.0のシャード0として立ち上げようというEarly Mergeと呼ばれるプランも検討されるようになる。

The Merge

さまざまな検討がされる中、Vitalikから短期的なスケーリングソリューションとしてロールアップに集中しようという提案が行われる。つまり、シャーディングによるスケーリングよりも、すぐにスケーリング効果が見込めるレイヤー2ソリューションであるロールアップに計画をシフトするということ。

その結果、2020年、既存のEVMチェーンをEthereum 2.0のシャード0にするのではなく、Beacon chainと直接統合しようという提案が行われる。つまり、ブロックの承認はBeacon chainを使ってPoSベースで行われるが、そのブロックに含まれるトランザクションの実行は既存のEhereumクライアントを使って実行できるようにするというもの。元々のロードマップでは、フェーズ2まで待たなければVMを利用したコントラクトを実行できなかったが、この方法であれば、PoSベースのEVMチェーンが早く実現できる。これがThe Mergeと呼ばれる新しいPoS移行の計画。

シャードによるVMの実行（もともとのフェーズ2）には、まだ時間がかかるし、未解決の課題もあることから、延期やキャンセルも可能という位置づけみたい。

次にこのThe Mergeでどんな変更が入るのか見ていこう。

Eth1クライアントの変更

既存のEth1クライアントには、TERMINAL TOTAL DIFFICULTYという閾値が設定される。PoWのチェーンでブロックの総難易度がこの閾値を超えるブロックが作られると、そのブロックがPoWの最後のブロックとなる。それ以降のブロックは、Beacon chain上のバリデーターにより作成/認証され、Eth1クライアントはPoWブロックのゴシップを完全に停止する（NewBlockHashesやNewBlockといったP2Pメッセージが処理されなくなる）。

その後、Eth1クライアントはブロックの有効性などは検証しないが、トランザクションのゴシップやEVMによる実行、ステートの管理はPoSに切り替わってもそのまま実行される。このためマージ後、Eth1クライアントは実行エンジンとして動作し、実行レイヤーとして分類される。

Beacon chainの変更

現在のBeacon chainのブロックにはトランザクションデータは含まれていないため、空ブロックを作っているようなものだが、PoW→PoSに切り替わると実行エンジンと通信して、ExecutionPayloadsというデータの生成/検証を依頼するようになる。これには、親のハッシュ、ステートルート、Base fee、実行するトランザクションのリストなどが含まれる。Eth1クライアントから見ると、これが切り替え後のブロックに相当する。Beaconノードは、生成したExecutionPayloadsを含むブロックを作成、承認し、P2Pネットワークの他のノードにゴシップし、共有する。

Beacon chainはEthereumのコンセンサスレイヤーとして動作するが、基本的に実行レイヤーと連携して動作する。これによりBeach chainに実行機能が備わる。

Engine API

実行レイヤーとコンセンサスレイヤーはそれぞれ異なるP2Pネットワークで稼働する。The Merge後に完全に検証可能なノードを構成するためには、Beacon chainのオペレーターは新たに実行エンジンのノードを起動する必要がある。また、実行エンジンの方も最新のチェーンの情報を得るためにBeaconノードと連携する必要がある。このため、Beaconノードと実行エンジンの通信用に新たに以下の３つのメソッドを提供するEngine APIが提供される。これらのAPIは基本的にBeaconノードが実行エンジンに対して呼び出すものになる。

engine_executePayload：実行エンジンに対して、ExecutionPayloadが正しいか検証を依頼する。他のBeaconノードから受け取ったブロックの検証の際に使うものと思われる。
engine_forkchoiceUpdated：Beaconノードが実行エンジンに対して、ネットワークの最新のブロックを通知するためのAPI。このメソッドでは実行エンジンがExecutionPayloadを生成するのに必要となる情報（timestamp、random、feeReceipent）が渡され、実行エンジンでは、その情報を元に後続のExecutionPayloadを構築する。
engine_getPayload：実行エンジンに対して、engine_forkchoiceUpdatedで更新したチェーンの後続の新たなブロック用ExecutionPayloadを要求する。

ブロックヘッダーのフィールドとopcodeの変更

↑でできるだけ影響を最小限にPoSへの移行をするものの、一部変更が発生する。

ブロックはBeacon chain側のコンポーネントになり、これまでのEth1の実行レイヤーとやりとりする。ExecutionPayloadsは、引き続きEth1クライアントにとってみればブロックで、その一部のフィールドはPoSへの切り替えで意味合いが変わってくる。

ブロックヘッダーの変更

具体的には、ブロックヘッダーのフィールドの内、PoWに関連するフィールドは、PoSになると不要になる。ただ、フィールドが削除される訳ではなく、既存のツールへの影響を最小限にするため、以下のように変更される。

PoSになるとOmmerは発生しなくなるので、Ommerは常に空になり、その結果ommerHashは空のKecchak256ハッシュ値、つまり固定値になる。
PoWが行われなくなるため、
- difficultyは常に0
- nonceも常に0
mixHashもPoW関連のフィールドだが、0をセットするのではなく、Beacon chainのRANDAOの値が含まれるようになり、フィールド名もrandomに変更される。

opcodeの変更

ブロックのdifficultyを取得するDIFFICULTY(0x44) opcodeは、RANDOMという名前に変更され、元々ブロックヘッダーのmixHashが格納されていた箇所のデータ、つまりPoSに切り替わった後はBeacon chainのRANDAO値を返すようになる。

また、PoSに切り替わってもBLOCKHASH opcodeは使用できるが、PoWが機能しなくなるので、このopcodeが提供していたランダム性はかなり弱くなる。そのため、ランダム性が必要な場合は、↑のRANDOM opcodeの方が適している。

マージ前後の構造の変更を図示したのが↓

ファイナライズ

PoWでは常にreorgの可能性を考慮する必要がああったが、PoSでは正常に動作する限りreorgは発生しない。PoSになると2/3以上のバリデーターによって正規なブロックとして認められたブロックはFinalized Blockとして扱われる。このブロックを覆すためには、攻撃者は最低1/3のステークをバーンする必要がある。

また、Finalized Blockになる前に、チェーンに含まれると予想されるブロックをSafe Head blockと呼ぶ。2/3のバリデーターによる認証はないものの、大多数のバリデーターが正直に行動し、fork-choiceルールへの攻撃がない場合、このブロックがオーファンブロックになることはない。

アプリケーションへの影響

EVMで実行されるコントラクトは引き続き、実行レイヤーのクライアント（gethやNethermind、Besuなど）で処理されるので、大きく仕組みが変わることはなく、コントラクトで影響するのは、

BLOCKHASH opcodeが提供していたランダム性は弱まるので、ランダム性が必要な場合は、RANDOM（旧DIFFICULTY）opcodeへの切り替えが推奨される。
現在約13秒前後のブロックタイムが、PoSに切り替わると12秒となるので、特定の平均ブロックタイムを利用するコントラクトでは、意図しないずれが発生する可能性がある。

あたり。

以上が、今後のEthereum 2.0へのロードマップ。方向性としては現実的な計画になってきた感じがする。

今月予定されているArrow Glacierのネットワーク・アップグレードで、difficulty bombが2022年6月まで延期されるようになるので、The Mergeが発生するのは順調に行けば、2022年の6月までの間に実行されるっぽい。