🦾

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

2024/06/01に公開

ブロックチェーン

Ethereum

Bitcoin

tech

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

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

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

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

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

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

3まではThe Mege以前と変わらないため割愛。

ブロック提案者と投票者の選択(4)

提案者となるバリデータの選択

各EpochのSlot0の時点で、次のEpochの提案者が選択される。各Slotに対し1バリデータずつ割り当てる（32Slotなので32バリデータ）。
多くのバリデータをもつノードほど、提案の権利を得る確率が高くなる。

バリデータの投票先の割り当て

投票者も提案者と同様、各EpochのSlot0の時点で、次のEpochの投票者が決まる。すべてのアクティブなバリデータ（提案者含む）が1Epochに必ず1回ずつ投票するように割り当てる（ランダムでStake量は関係ない）。
多くのバリデータをもつノードほど、1Epochで投票できる回数が増える。

Committee

各Slotに割り当てられた投票者バリデータは、committeeという単位にグループ分けされる（ランダム）。投票の集約（後述）をcommittee単位で並列化して行うため。

さらに各committeeに対し、集約担当者がランダムに選ばれる。これらの値はプロトコルで決まっている。

MAX_COMMITTEES_PER_SLOT: 64
TARGET_COMMITTEE_SIZE: 128
MAX_VALIDATORS_PER_COMMITTEE: 2048
TARGET_AGGREGATORS_PER_COMMITTEE: 16

分散型ネットワークで確率的な選択をする方法

それぞれのノードが同じ入力に対し、同じ出力を返す必要があるため、乱数を利用できない（EVMでも乱数は扱えない）。ネットワーク外から与えられた乱数は信用できない。

そのため、RANDAOという仕組みで擬似乱数を仕様している。各ブロックに含まれるrandao_revealという値（ブロック提案者の署名から生成）を使い、epochごとに変わる擬似乱数を生成する。これをシードとして、各ノードのConsensus Clientで確率的な選択をする。

ブロックへの投票（attestation）(5)

投票者となったバリデータは、正統なブロックチェーンを決めるために投票（attestation）を行う。投票は割り当てられたslot内で行うことが望ましいが、有効期限内なら可能。

現在どのブロックが先頭か？
現在どのepoch（完成したもの）が先頭か？
を宣言する。多くの場合、割り当てられたslotのブロックが投票先となり、その投票の集約が次slotのブロックに格納される。

Field	Description
aggregation_bits	署名したバリデータを効率的に把握するためのバイナリ列
signature	Validator Signing Keyの秘密鍵をもちいたBLS署名
data	-
- slot	割り当てられたslot番号
- committee_index	そのslotにおける何番目のcommitteeに所属しているか
- beacon_block_roor	先端だと思うブロックのヘッダーハッシュ
- source	最新のjustified（後述）されたと思うブロックヘッダーのハッシュとslot
- target	現在のepochで最初にあると思うブロックヘッダーのハッシュとslot

投票はネットワークにブロードキャストされ（トランザクションではない）、各ノードが検証し有効なものがMempoolにためられる。無効な投票をしたバリデータは罰則としてstakeしているETHの一部を失う（スパム対策）。

Mempoolにたまった投票は、集約担当者が集約する（検証の効率化）。集約はcommittee単位で並列して行い、data領域の内容が一致するものがまとめられる。集約された投票は再びネットワークにブロードキャストされ（トランザクションではない）、各ノードが検証し有効なものがMempoolにためられる。

これらの、ブロックの提案・投票・投票の集約の3つの作業が、1slotをさらに3分割（4秒ごと）した時間軸で行われる。ブロックには、1つ前のslotの投票が格納されることになる。

ブロックの作成(6,7)

The Mergeにより、Execution LayerのブロックをConsensus Layerが内包する形になった。

Execution Payload

Execution LayerについてのThe Merge以前との差分のみ記載（大まかにはUncleブロックに関する部分がWithdrawalsになった）。

Field	Description	Remarks
fee_receipient	Gasを受け取るEOAアドレス	ブロック提案バリデータが指定
prev_randao	前ブロックのRANDAO	Difficultyと入れ替わり
withdrawals_root	withdrawalsのルート	-
withdrawals	引き出し情報リスト	16個

BeaconBlockBody(Consensus Layer)

Field	Description	Remarks
randao_reveal	次epochのRANDAOをつくるパーツ	-
eth1_data	約17時間前のexecution layerの情報	投票を通じてepochごとに更新
graffiti	任意データ領域	-
proposer_slashings	提案者の不正の証拠をいれる領域	最大16個
attester_slashings	投票者の不正の証拠をいれる領域	最大2個
attestations	集約された投票	最大128個
deposits	新規バリデータの情報	最大16個
voluntary_exits	退出バリデータの情報	最大16個
sync_aggregate	集約された投票（ライトクライアント用）	割愛
bits_to_execution_changes	withdrawal_credentialsを0x01に変更	最大16個

BeaconBlockHeader(Consensus Layer)

Field	Description	Remarks
slot	ブロックに対応するslot	-
proposer_index	提案者のValidator Signing Keyの公開鍵	-
body_root	BeaconBlockBodyのマークルパトリシアツリーのroot	-
parent_root	親ブロックのブロックヘッダーのハッシュ	-
state_root	Consensus Layerのstateツリーのroot	後述

ブロック生成手順

Execution Clientがこれまでどおりトランザクションを詰める（withdrawalsについてはConsensus Clientから渡ってきている）
Consensus ClientがConsensus Layer側の内容を詰める（Rootはまだ）
提案者ノードは、Execution Clientでトランザクション、Consensus Clientでメッセージなどを実行する。それぞれのstateデータを更新し、rootをブロックに入れる。

Epochのはじめに行われる処理

ブロックの提案・投票を行うバリデータの選択
RANDAOの再設定
justified, finalizedブロックの更新（後述）
各バリデータの報酬と罰則の計算（後述）

コンセンサスと報酬(11)

PoSでもブロックチェーンは分岐する可能性がある。The Merge後も「最も重いチェーン」を正統とするが、Gasperプロトコル（LMD GHOST + Casper FFG）（以前はGHOSTプロトコル）を採用している。

LMD GHOST: epoch内でブロックチェーンが分岐した場合の重いチェーン
Casper FFG: epoch内を跨いでブロックチェーンが分岐した場合の重いチェーン
（GHOST: 子ブロックの数で重さを決定）

checkpoint, justified, finalized

各epochの最初のブロックをcheckpointという。投票のsource, targetはこのcheckpointを宣言の対象とする。このとき、全stake量の2/3以上（投票は票数ではなく、stake量で判定）の投票を得たtargetをjustifiedとみなす。

あらたにjustifiedブロックが生まれた場合、その前にjustifiedされたブロック以前の全ブロックはfinalizedとみなす（基本的に覆らない、覆すには全stakeの1/3以上がpenaltyとして失われる必要がある, economic finality）。

チェーンの分岐や空のslotが続くなどの事態がなければ、checkpointは大体1.5epoch（9.6分後）にfinalizedする。

LMD GHOST

epoch内で分岐した場合、各分岐の先端から遡って最も多くの投票（beacon_block_root）を集めたチェーンを「最も重い」と判定。投票は各バリデータのstake量で重みづけされ（32ETH上限）、投票数は直近のjustifiedブロックからカウントする。

Casper FFG

epochを跨いで分岐した場合、一番先にcheckpointがjustifiedになったチェーンを「最も重い」とする（投票におけるsource, targetを利用）。票の割れなどで4epochでfinalizedしない場合、投票していない or 少数派に投票しているバリデータのstakeを徐々に没収する（inactivity leak）ことで事後finalizedする。

報酬

ブロック提案者と投票者の両方にETHが報酬として新規発行される（マイニング廃止に伴い、以前の報酬体系はgasを除き廃止）。報酬と罰則は、epochごとに計算・反映される。

報酬額（罰則）の基準となるバリデータごとのbase reward = stake量(上限32ETH) / sqrt(総stake量)。自身のstakeが減ったり、総stakeが増えるとbase rewardは減る。

base rewardを64として、各行為に重みづけして報酬量が決まる（26: Casper FFGで期限内に正しいtargetへ投票, 14: LMD-GHOSTにおいて期限内に正しいbeacon_block_rootに投票 etc）

投票の有効期限は、1slot: beacon_block_root, 5slot: target, 32slot: source

また、提案者や不正行為の証拠データをつめたバリデータには追加報酬がある。

罰則

サボった場合、不正な内容を提出した場合のいずれも、以下のような罰則となる。また、明確に悪意のある行為をした場合、強制排除（slashing）され、stakeしたETHを一部失う。

Role	Penalty
提案者	報酬機会を逃すだけ（罰則なし）
投票者	stakeしているETHが減る（項目などにより変動）

Layer2(Rollup)

Ethereumのスケーラビリティの課題に対し、Rollupというアプローチがある。ブロックチェーンの外（オフチェーン, これがLayer2）でトランザクションの検証や実行をして、結果だけをEthereumブロックチェーンに戻す。

しかし、Layer2で実行したトランザクションの情報はEthreumブロックチェーンに別途記録する必要がある（検証可能な状態にするため = Data Availablity）。

これまではトランザクションのdata領域を無理やり使っていたが、Ethereumの最新のアップデート（Dencun）では専用領域（blob）が追加された（Ethereum事態がLayer2を意識している）。これらのアップデートによるスケーリングの構造をダンクシャーディングという。

第8回（Ethereum）ここまで