【東京大学ブロックチェーン公開講座第7週】イーサリアム③

本記事は、2024年東京大学ブロックチェーン公開講座の7つ目のレポートです。

【東京大学ブロックチェーン公開講座第1週】ブロックチェーン概論
【東京大学ブロックチェーン公開講座第2週】ビットコイン①
【東京大学ブロックチェーン公開講座第3週】ビットコイン②
【東京大学ブロックチェーン公開講座第4週】ビットコイン③
【東京大学ブロックチェーン公開講座第5週】イーサリアム①
【東京大学ブロックチェーン公開講座第6週】イーサリアム②
【東京大学ブロックチェーン公開講座第7週】イーサリアム③（本記事）

なお、本記事は講座の要約ではなく、講座のポイントを抽出しつつ、筆者の理解や考察を添えてアウトプットしたものとなります。講座内容との差異や筆者の主張（オレンジ背景）が含まれます。

本記事の内容は、2022年9月の大規模バージョンアップ（The Merge）後のイーサリアムについてです。

The Merge

2022年9月に行われた互換性のない大規模な仕様変更で、Proof of WorkからProof of Stakeへ変わった（マイニングの廃止）。仕様としては、大きく以下3点が変化した。

• Execution LayerとConsunsus Layerの分離
• バリデータの導入
• SlotとEpochの導入

Execution Layer, Consensus Layer

トランザクションの実行・検証を担う層（Execution Layer）と正しい状態遷移の記録について合意形成をとる層（Consensus Layer）に分離した（ネットワークが2つ存在）。

これに伴い、クライアントソフトウェアもExecution ClientとConsensus Clientの2種類になった。両者は相互依存関係にあり、フルノードを立てる場合は両方が必要。2つのLayerは、それぞれで異なるStateデータ（のマークル・パトリシアツリー）を保持している。

いままでの構成から、合意形成にまつわる部分を分離して同期的に動く別チェーンにした、と考えればよさそう。。。？

バリデータ

ブロックの提案と正当性の合意形成をするための投票者。マイナーノードの役割を、バリデータを管理するノードが引き継いだイメージ。

EOAはDeposit Contractという専用のコントラクトに32ETHを預けること（Staking、PoSの由来）でバリデータになることができる。1つのEOAが複数のバリデータをもつこともでき、2024年4月現在でアクティブなバリデータは1000000つほど。

レイヤーとデータの分類は以下。

Type	Node（Client）が管理するデータ	ブロックチェーンが管理するデータ
Consensus Layer	バリデータごとの残高、ステータスなど	バリデータに関するメッセージ（トランザクションのようなもの）
Execution Layer	アカウントごとの残高、ステータスなど	トランザクション

Slot, Epoch

Slot=12秒, Epoch=32Slot(6.4mins)とし、SlotとEpochを基準単位としてブロックの提案や合意形成、報酬などの管理をしている。これまでのEthereumでは15秒ごとにブロックが生成される（ブロックインターバル）仕様だった。

トランザクションのライフサイクル

Execution Layer, Consensus Layer でそれぞれ記載。

1. EOAは、トランザクションを各ノードに伝搬する
2. 各ノードは、受け取ったトランザクションを検証する
3. 各ノードは、問題ないトランザクションをプールし、隣接ノードに伝搬する
4. バリデータは、確率的にブロックの提案者と投票者に選ばれる
5. 投票者は、正当と考えるチェーンの先端のブロックを宣言する
6. （両レイヤー）提案者は、任意のトランザクションおよび集約した宣言をブロックに格納する
7. 提案者は、ブロック内のトランザクションを実行する
8. 提案者は、ブロックを既存のいずれかのチェーンにつなぐ
9. 提案者は、完成したブロックを各ノードに伝搬する
10. （両レイヤー）各ノードは、受け取ったブロックを検証する
11. 各ノードは、問題がないブロックを自身のチェーンに反映する
12. バリデータたちは、最も重いチェーンを「正しい」状態遷移の記録とする

各要素が保持するデータ

以下の項目については以前と同様のため、割愛。

• EOA
• CA
• Message Callトランザクション
• Message Callのレシート
• Contract Creationトランザクション
• Contract Creationのレシート
• 手数料（gas）

バリデータ

バリデータは、アカウント用の鍵とは別のValidator Signing KeyとWithdrawal Keyの2種類（それぞれ秘密鍵と公開鍵をもつ）で構成される。セキュリティ上のリスク軽減および、署名の集約に適したBLS署名を用いるため。

Type	秘密鍵	公開鍵
Validator Signing Key	ブロックの提案・投票	署名の検証
Withdrawal Key	StakeしたETHの引き出し	署名の検証

バリデータを運用する鍵がアカウントの鍵と別立てになっているため、自身でノードを立てるほか、Stakingの委任や共有バリデータ（Staking Pool）といった運用ができる。

バリデータの新規登録

Execution Layer

1. EOAの所有者が、秘密鍵・公開鍵のペアを2つ作成する（ローカル）
2. input（Deposit data）として以下を含む32ETHのトランザクションを発行する
3. Deposit contractはトランザクションを確認（署名の検証はしていない）し、Deposit Eventを発行する（イベントはトランザクションレシートのlogs領域に記録される）

Type	Description
pubkey	Validator Signing Keyの公開鍵
withdrawal_credentials	Withdrawal Keyの公開鍵ハッシュ
signature	Validator Signing Keyの秘密鍵によるBLS署名
deposit_data_root	上記3つのマークルルート

Consensus Layer

Deposit contractへのトランザクションがブロックに格納され、Deposit EventがExecution Clientのstateデータに反映されたあとにConsensus Layerでバリデータの登録が行われる。ただし、Consensus Layerのバリデータ登録情報は約17時間前のExecution Layerを参照している（将来的に解消見込み）。

4. Execution Clientから時間差でDeposit Eventの生成通知をうけとる
5. ブロック提案者（のバリデータを管理する）Consensus Clientは、手元のDepositツリーを用いてDeposit dataを検証する（BLS署名の検証を含む）
6. ブロック提案者Consensus Clientは、問題がなければ手元のstateデータにDeposit dataを反映（バリデータリストに追加）（このときバリデータインデックスを付与）
7. ブロック提案者Consensus Clientは、Deposit dataを新規ブロックのConsensus Layer領域（1ブロック最大16個）に詰め、Consensusネットワークに伝搬する
8. 受け取ったCosensus Clientはブロックの検証を行い、手元のstateデータにDeposit dataを反映
9. 次のEpochで該当のバリデータはpendingステータスになり、ある程度の時間が経過するとactiveになる（現在8バリデータ/epoch）

Consensus Layerでの検証が失敗（ex.BLS署名が不正）した場合、ブロックチェーン本体であるExecution Layerはすでに相当なブロックが確定済みになっていると思いますが、どのように整合を保つのでしょうか。

さすがに17時間分のブロックを覆すわけにはいかないと思いますが（ファイナリティの問題）、Depositトランザクションは通常のトランザクションと別で管理されていて、後からでも巻き戻しが可能な形になっていたりするんでしょうか（それはそれでセキュリティ的なリスクになりそう）。

バリデータが保持するデータ

Type	Role	Description
pubkey	Validator Signing Keyの公開鍵	Deposit dataから継承
withdrawal_credentials	引き出し先情報	Deposit dataから継承
effective_balance	stakeしているETHの量（Gwei）	Deposit dataから継承
slashed	強制退出されたかどうか	後述
activation_eligibility_epoch	pendingになったepoch	後述
activation_epoch	activeになったepoch	後述
exit_epoch	退出したepoch	初期値null
withdrawable_epoch	引き出し可能になったepoch	初期値null

バリデータの退出

Consensus Layer

activateから2^8epoch（約27時間、バリデータ数の急激な変動を避けるための仕様）経過すれば、自発的に退出可能。退出はConsensus Layerで完結する。

1. バリデータ（Validator Signing Keyの秘密鍵の管理主体）はConsensus LayerでVoluntaryExitメッセージ（以下参照）をブロードキャスト（トランザクションではなく、EVMの実行も不要、gasも不要）
2. ブロック提案者のConsensus Clientは、VoluntaryExitメッセージを検証する
3. ブロック提案者のConsensus Clientは、VoluntaryExitメッセージを新規ブロックのConsensus Layer領域に含める（1ブロック最大16個）
4. 受け取ったConsensus Clientは、VoluntaryExitメッセージの検証とバリデータリストの更新を行う
5. 次のEpochで該当のバリデータはexitingステータスになり、ある程度の時間が経過するとactiveになる（現在15バリデータ/epoch）
6. さらに2^8epoch（約27時間）経過すると、withdrawableステータスになり、StakeしていたETHの引き出しが可能になる

Type	Description
signature	Validator Signing Keyの秘密鍵を用いたBLS署名
message
- epoch	退出手続きを行いたいEpoch
- validator_index	自身のバリデータインデックス

Depositの引き出し

引き出すにはwithdrawable_credentialsをExecution Layerのアドレスに更新する必要がある。

• 0x00: Withdrawable Keyの公開鍵ハッシュ（今までのwithdrawable_credentials）
• 0x01: 送金先のExecution Layerのアドレス（新しいwithdrawable_credentials）

この更新は、activeなバリデータが1度だけ行うことができ、Consensus Layerに変更希望のメッセージを流すことで実行する。完了すると、報酬や退出時のStake分32ETHが自動で定期的に送金されるようになる（流れは後述）。

Type	Description
signature	Validator Signing Keyの秘密鍵を用いたBLS署名
to_execution_address	送金先のExecution Layerのアドレス（EOA/CAどちらも可）
validator_index	自身のバリデータインデックス

1. ブロック提案者のConsensus Clientは、バリデータインデックスを順番に確認し、各バリデータの報酬データを集める
2. 16つ集まったらwithdrawalリストとしてまとめ、Execution clientに送信する
3. withdrawalリストをExecution Layerの専用領域（通常のトランザクションとは別）に格納して伝搬する
4. ほかのConsensus Clientは、伝搬されたブロックの検証時にwithdrawalリストも検証し、問題なければバリデータの残高を減らす
5. Execution Clientは、伝搬されたブロックのExecution Layerのトランザクションをすべて実行したあと、withdrawalリストに沿って残高を増やす（この処理はEVMの実行やgas不要）

3の処理主体は明言されていませんでしたが、Execution Clientだと思われます。

処理が二つのレイヤーを行ったり来たりしているので、その連携はどのようにやっているのか気になりました（バリデータ登録時のDeposit Eventに相当する何かがある？）。

---

第7週ここまで