[Ethereum 2.0] Execution / Consensus layer 間の通信 (Shanghai Updade 時点)
この記事は株式会社 Ginco のテックブログとして書いています。
はじめに
前提：Blockchain Nodeとは
Blockchain は P2P Network を活用し、その中で行われる取引や処理のログを蓄積する巨大なステートマシンです。このとき、 P2P Network に参加しデータを取得 / 共有するエンティティを総称して「Blockchain Node（以下、Node）」と呼びます。
今回の記事では、時価総額 No.2 の Blockchain であり、 No.1 の利用シェアを誇る Ethereum Network における Node の仕組み（特に 2 種類の Node が内部的にどう通信しているか）を概観します。
The Merge 以降の Ethereum Network
The Merge 以降の Ethereum Network は、 Execution Layer と Consensus Layer という 2 つの Layer で構成されています。ここでいう Layer とは、 Node が共通のプロトコルを実行することによって形成する P2P Network のことで、実態上はそれぞれの Node 群を意味します。
Ethereum Network が 2 つの Layer で構成される以上、 Ethereum Network の Node を運用する際には、 2 種類の Node を合わせて運用しなくてはなりません。以降では、 Execution Layer と Consensus Layer の Node がそれぞれどういったもので、互いにどのように通信しているかを紹介します。また、それに関連して、 Shanghai Upgrade で導入された EIP-4895 の内容にも触れたいと思います。
Execution Layer vs Consensus Layer
まずは、Execution Layer、 Consensus Layer とはどのようなものか説明します。
Execution Layer
Execution Layer は、Block の Validation と実行、生成、実行結果の保持などを行う Layer です。代表的な Node の実装としては、go-ethereum などがあり、Network の状態は Etherscan などの Explorer で確認できます。
Consensus Layer
Consensus Layer は、Proof of Stake Consensus の実行、 Validator の管理などを行う Layer です。代表的な Node の実装としては、prysm などがあり、Network の状態は Beaconscan などの Explorer で確認できます。
Layer 間の通信について
Engine API
Execution Node には、Engine API と呼ばれる API 群が実装されており、Consensus Layer から Execution Layer への Request は、主にこれを用いて行われています。下記が主要なものとなります。
NewPayload()
Payload の Validation と、実行を行います。また、実行は行うが、 先頭の Block を進めることはしないようになっています。(先頭の Block を進める処理は ForkChoiceUpdated() に実装されています) この点については、一般的な Database の Transaction などで、Commit 以前の処理 (処理の Validation と実行は行うが、反映は行わない) を思い浮かべてもらうとイメージしやすいと思います。
Payload は、Blockhash, Transaction などの、基本的な Block 情報を表現しています。またそれに加え、EIP-4895 で withdrawals Field が追加されています。withdrawals は、Validator の Staked Eth を引き出すための Field になります。 Payload のデータ構造はこちらで確認することができます。
ForkChoiceUpdated()
下記の機能を持っており、 Usecase に依存した振る舞いをします。
-
NewPayload()の処理を受けて、先頭の Block を進めます。 - Payload 生成の Request を受けて、 Payload の生成と保存を行います。
GetPayload()
ForkChoiceUpdated() で生成した Payload の内容を返します。
Engine API の認証
前項では、Execution Layer / Consensus Layer 間で、 Engine API を用いて通信が行われていることについて説明しましたが、ここでは認証について触れようと思います。
Engine API は、 Layer 間の通信に利用するものであり、また、インターネット上に公開すると盗聴や Replay Attack の危険があるため、認証を行った方がベターです。そのため、 Engine API には JWT を用いた認証の仕組みがあります。
処理の流れ
ここでは、実際の Usecase での Layer 間の処理の流れについて説明します。
Block の実行
Network から伝搬されてきた Block の Transaction を実行し、 Node のデータを最新に保ちます。
- [Consensus Node] Network から Block を検知します。
- [Execution Node]
NewPayload()を実行し、Block の Validation と実行を行います。 - [Execution Node]
ForkChoiceUpdated()を実行し、先頭の Block を進めます。
Block の提案
Validator Node が Network から Request を受け、Block の提案を行います。
- [Consensus Node] Network から Block 提案の Request を受けます。
- [Execution Node]
ForkChoiceUpdated()を実行し、Payload の生成と保存を行います。 - [Execution Node]
GetPayload()を実行し、 2 で生成した Payload を返します。 - [Consensus Node] Payload を受け取ります。
- [Consensus Node] Block を Network に提案します。
最後に
この記事では、 Execution / Consensus Layer 間の通信について説明し、EIP-4895 の内容についても触れました。
個人的には、 Node の Setup などに関する情報は比較的多いものの、各 Node がどういった役割でどう通信しあっているかなどの情報はあまりないので、調べてみて理解が深まったかなと思っています。
株式会社 Ginco ではブロックチェーンを学びたい方、ウォレットについて詳しくなりたい方を募集していますので下記リンクから是非ご応募ください。
Discussion