【東京大学ブロックチェーン公開講座第6週】イーサリアム②
本記事は、2024年東京大学ブロックチェーン公開講座の6つ目のレポートです。
【東京大学ブロックチェーン公開講座第1週】ブロックチェーン概論
【東京大学ブロックチェーン公開講座第2週】ビットコイン①
【東京大学ブロックチェーン公開講座第3週】ビットコイン②
【東京大学ブロックチェーン公開講座第4週】ビットコイン③
【東京大学ブロックチェーン公開講座第5週】イーサリアム①
【東京大学ブロックチェーン公開講座第6週】イーサリアム②（本記事）
なお、本記事は講座の要約ではなく、講座のポイントを抽出しつつ、筆者の理解や考察を添えてアウトプットしたものとなります。講座内容との差異や筆者の主張（オレンジ背景）が含まれます。
イーサリアムもビットコインと同様、初期のものと現行のものでバージョンアップが入っており、それなりに違いがあるそうです。本記事の内容は初期のイーサリアムについてです。
トランザクションのライフサイクル
- EOAは、トランザクションを各ノードに伝搬する
- 各ノードは、受け取ったトランザクションを独立に検証する
- 各ノードは、問題ないトランザクションをプールし、隣接ノードに伝搬する
- マイナーノードは、プールから任意のトランザクションをブロックに詰める
- マイナーノードは、各トランザクションを実行する
- マイナーノードがブロックを既存のチェーンにつなぐ
- マイナーノードはPoWでブロックを完成させる
- マイナーノードは完成したブロックを隣接ノードに伝搬する
- 各ノードは、受け取ったブロックを独立に検証する
- 各ノードは、問題ないブロックを自身のチェーンに反映する
- Ethereumは最も「重い」チェーンを正しいものとみなす
基本的にはBitcoinと同様。違いのある部分を中心に以下解説。
Ethereumネットワークのノード
BitcoinはSPV（軽量）ノードとフルノードの2種類だが、Ethereumでは3種類。
| Type | Data | Validation | Can be miner? |
|---|---|---|---|
| light node | ブロックヘッダ | ブロック（ヘッダのみ） | なれない |
| full node | すべてのブロックヘッダ、直近128ブロックのstate | トランザクション、ブロック | なれる |
| archive node | すべてのブロックヘッダ、すべてのstate | トランザクション、ブロック | なれる |
また、ネットワーク参加時に接続するノードも異なる。
| Protocal | Network Type | Description |
|---|---|---|
| Bitcoin | Unstructured P2P network | 接続するノードは自由に選べる |
| Ethereum | Structured P2P network | IDが近いノードが複数選択される（所与） |
トランザクションの検証
基本的にBitcoinと同様、違いとして以下の項目を検証する。
- トランザクションがRLPフォーマットに沿っていること
- gasLimitがintrinsic gas（後述）以上か
- nonceがEOAのnonceより大きいか
Intrinsic gas
トランザクションの実行において最低限必要なgasの量で、以下3つの合計値。
- トランザクションの実行には21000gasが必要（predefined gas）
- Inputに対して最低68gasが必要で、送るデータが1byte増えるごとに4gas追加（storage fee）
- Contract Creationの場合、32000gas追加
EthereumのMempool
基本的にBitcoinと同様、EthereumのMempoolは2階層に分かれている（BitcoinはTransaction PoolとOrphan transaction pool）。
| Type | Description |
|---|---|
| Pending pool | 処理待ちのトランザクションプール |
| Queued pool | Pending poolのトランザクションの順序を揃えるために噛ませておく。nonceをみて順番になるよう制御 |
ブロックのデータ構造
The mergeにより大きく変化したが、今も残っている構造として以下の特徴がある。
- トランザクションのリストはマークル・パトリシアツリー
- State Root, Receipts Rootを含んでいる
- Block gasLimitによって上限が決まっている
Bitcoinと違う要素は以下。
| Name | Description | Remarks |
|---|---|---|
| sha3Uncles | Uncleブロックのブロックヘッダリストをハッシュ化 | 後述 |
| extraData | 任意のデータ（32bytesまで） | - |
| gasLimit | ブロック全体のgasLimit | 後述 |
| gasUsed | ブロックに格納されたトランザクションのgasUsedの合計 | - |
| logsBloom | ブロックに格納されたトランザクションの実行ログ | - |
| miner | マイナーのアドレス | - |
| minHash | nonceとあわせてPoWの証明となる256bitのハッシュ | - |
| number | ブロック番号（genesisが0） | - |
| totalDifficulty | このブロック以前のブロックのdifficultyの総和 | 頻繁に分岐が発生するため |
| StateRoot | トランザクション実行後のネットワークのすべてのアカウント状態をマークルパトリシアツリーで要約したルートのハッシュ値(Keccak-256) | Rootのみ |
| ReceiptsRoot | このブロックのトランザクションのレシートをマークルパトリシアツリーで要約したルートのハッシュ値(Keccak-256) | Rootのみ |
State Root, Receipt Root
StateとReceiptの履歴はフルノード（直近128ブロック）とアーカイブノードが保持しており、ブロックに含まれるのはRootのみ。
スマートコントラクトにおけるStateの整理は以下のとおり。
| Name | Example | Store | Blockchain |
|---|---|---|---|
| stateデータ | Aliceのアドレス、残高 | フルノード・アーカイブノード | ブロックヘッダー（集約したStateRoot） |
| stateデータ（storage data） | コントラクト実行回数（コントラクト自体のstate） | フルノード・アーカイブノード | ブロックヘッダー（集約したStorageRootを集約したStateRoot） |
| 返り値 | 成功・失敗etc | なし | ContractCreationのdataに含まれたプログラムにより定義 |
これらを踏まえて、ノードごとに保持するデータを整理すると以下。
| Type | Data | State data |
|---|---|---|
| light node | ブロックヘッダ | transaction root, state root, receipts root |
| full node | すべてのブロックヘッダ、直近128ブロックのstate | transaction root, state root, receipts root, transaction data, state data(latest 128), receipts dataa(latest 128) |
| archive node | すべてのブロックヘッダ、すべてのstate | transaction root, state root, receipts root, transaction data, state data, receipts dataa |
ブロックのgasLimit
Bitcoinと違い、ブロックサイズの上限が設定されていない。代わりにブロックにgasLimitがあり、ブロックに格納されたトランザクションのgasLimitの合計値がこの値を超えてはいけない。
ブロックのgasLimitはマイナーノードが決定する。最大で30,000,000Gweiまで増やすことができるが、ターゲット値は15,000,000Gwei。この値を利用して、次のブロックのbaseFeePerGasが決定される（ネットワークが空いていれば安く、混んでいれば高くなる）。
Uncle block
メインチェーンから分岐したブロックのこと。任意のUncle blockのブロックヘッダを2つまで格納できる。
Ethereumのブロックは15秒ごとに生成され、生成タイミングが短いため分岐が頻繁に発生する。その対策として、Uncle blockを考慮した合意形成（GHOST protocol）を採用しており、Uncle blockにもマイニング報酬が与えられる。
トランザクションの実行
マイナーノードは、トランザクションに対して以下を実行。
- 状態ツリーにあるトランザクション作成者EOAのnonceを1増やす
- 実行に必要であろうether（gasLimit * feePerGas + value）をEOAから徴収
- inputの処理をEVMで実行
- 実行結果のレシートを発行
- 処理にかかったgasのうち、priority fee部分を自身のアドレスに送金（余ったらEOAに返金）
また、ブロックに対して以下を実行。
- 状態ツリーとレシートツリーを作成
- ブロックヘッダーにState Root, Receipts Rootを書き込む
- ブロックヘッダーにgasUsedを書き込む
EhtereumのProof of Work
現在はProof of Stakeに移行済みだが、初期はPoWを採用していた。Bitcoinのマイナーの寡占化をうけ、それを防ぐ形のPoWの実装だった（詳細割愛）。
Ethereumではブロック間隔が15秒に設定されている（ワールドコンピューターというビジョン）。また、難易度調整も1ブロックごとに行われる（詳細割愛）。
コンセンサス
Ethereumは最も長いチェーン（Nakamoto consensus）ではなく、最も重いチェーンを正しいチェーンとするGHOST（Greedy Heaviest Observed Subtree）プロトコル。重い=子孫ブロック（サブツリー）の数で判定。ブロック間隔が短く、頻繁に分岐が発生することによる配慮。
サブツリー数は、現在のメインチェーンの先端から7つ遡ったブロックから数え、同じ重さで分岐した場合はdifficultyの合計が大きい方を採用する。
マイニング報酬
Ethereumでは、ブロック作成に成功すると2ETHを新規発行。Bitcoinと異なり半減期がなく、総発行量も決まっていない。また、Uncle blockにもマイニング報酬が与えられる。
ガバナンスとEIP
Ethereumの仕様変更はBitcoinと同様、EIP（Ethereum Improvement Proposal）に基づいて議論される。新しい仕様の適用はノードが選択できるため、合意が取れない場合ブロックチェーンが分岐する（Ethereum Clasicなどの事例あり）。
仕様変更に関するCoreのほかに、開発者向けのERC（Ethrerum Request for Comments）がある。代表的なものでEIP20（Fungible Token）・EIP721（Non-Fungible Token）、EIP1155（条件を満たすとユニークになるSemi-Fungible Token）など。仕様変更ではなく、利便性のための標準化の呼びかけという位置づけ。
スケーラビリティの問題
分散的な合意形成には時間がかかるため、トランザクションが増加すると捌ききれない、という課題がある。
| Protocol | TPS（Transactions per Seconds） |
|---|---|
| Bitcoin | 5 |
| Ethereum | 10-20 |
| VISA | 1500-2000 |
スケーラビリティの向上のため、2022年9月に大規模なアップデート（The Merge）を実行し、PoWからPoS（Proof of Stake）へ移行した（マイニングが廃止された）。また、シャーディングの導入なども予定されている。
さらに、スマートコントラクトの実行をEthreumから切り出して別で実行し、結果だけを戻すLayer2の提案もされている。また、分散性を妥協することで対処するブロックチェーン（Binance Smart Chain, Solana）も登場している。
第6回ここまで
来週から、The mergeの内容に入っていくようです。
Discussion