[EIP4895] ビーコンチェーンからEVMへのバリデーター出金サポートの提案を理解しよう！

はじめに

初めまして。
CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。

代表的なゲームはクリプトスペルズというブロックチェーンゲームです。

今回は、ビーコンチェーン上でのバリデーター出金をEVMに「プッシュ」するためのシステムレベルの「操作」を導入する提案をしているEIP4895についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

他にも様々なEIPについてまとめています。

概要

ブロックチェーン技術には「ビーコンチェーン」と「EVM（イーサリアム仮想マシン）」という二つの重要な要素があります。
ビーコンチェーンは、イーサリアム2.0において、プルーフ・オブ・ステーク（PoS）のコンセンサスメカニズムを管理するためのチェーンです。
一方、EVMはイーサリアム上でスマートコントラクトを実行するための環境です。

提案されている「システムレベルの操作」については、ビーコンチェーンからEVMへと「プッシュ」される検証者（バリデーター）の出金をサポートするものです。
ここでいう「検証者」とは、イーサリアムのネットワークセキュリティを担保し、新しいトランザクションを検証してブロックに追加する役割を果たすユーザーやノードのことを指します。

具体的には、以下のようなプロセスを想定しています。

1. 検証者の出金

   • ビーコンチェーン上で検証者がある条件を満たした場合（例えば、一定期間ネットワークを安定してサポートした後）、彼らは自分の賭け金（ステーク）と報酬を引き出すことができます。

2. システムレベルの操作

   • この操作は、ビーコンチェーンからEVMに対して、特定の受取人（出金を受ける検証者）への残高の無条件の増加を命じるものです。
   • つまり、この操作により、検証者は自分の賭け金と報酬を直接、自分のイーサリアムアドレスに受け取ることができるようになります。

3. 「プッシュ」される出金

   • ここでの「プッシュ」とは、出金がビーコンチェーンから能動的にEVMに送られることを意味します。
   • これにより、検証者は自ら出金のリクエストを送る必要がなく、プロセスが自動化され、より効率的になります。

このシステムは、検証者がより簡単に、かつ迅速に報酬を受け取れるようにするためのものです。
また、ビーコンチェーンとEVM間の相互運用性を強化し、イーサリアムネットワーク全体の効率性とユーザビリティを向上させることを目的としています。

ビーコンチェーン

ビーコンチェーンは、イーサリアムネットワークのアップグレードであるイーサリアム2.0の中核をなす新しいブロックチェーンです。
その主な目的は、イーサリアムのコンセンサスメカニズムを従来のプルーフ・オブ・ワーク（PoW）からプルーフ・オブ・ステーク（PoS）へと移行させることです。

プルーフ・オブ・ワーク（PoW）とプルーフ・オブ・ステーク（PoS）の違い

プルーフ・オブ・ワーク（PoW）

マイナーが複雑な数学的問題を解くことで新しいブロックを生成し、ネットワークに貢献するコンセンサスメカニズム。このプロセスは多大な計算能力とエネルギーを要します。

プルーフ・オブ・ステーク（PoS）

バリデーターが自らの持つ仮想通貨の量（ステーク）を担保として新しいブロックの生成に参加するコンセンサスメカニズム。PoWに比べてエネルギー効率が良い。

ビーコンチェーンの役割

コンセンサス層

ビーコンチェーンは、イーサリアムネットワークのコンセンサスを管理する役割を果たします。
バリデーターは、新しいブロックを提案し、他のブロックの有効性を確認することでネットワークのセキュリティと正確性を保証します。

スケーラビリティの向上

ビーコンチェーンは将来的にシャーディングと組み合わせられることで、トランザクションの処理能力とネットワークのスケーラビリティが大幅に向上する予定です。

エネルギー消費の削減

PoSメカニズムはPoWに比べてはるかに少ないエネルギーを消費するため、イーサリアムの環境への影響が大きく減少します。

ビーコンチェーンの特徴

バリデーターによる運営

ネットワーク参加者は、ETHをステークすることでバリデーターとなり、ネットワークの運営に参加します。
バリデーターは、正しく行動することで報酬を得る一方で、不正行為や怠慢があるとステークが没収されるリスクがあります。

分散型とセキュリティ

PoSメカニズムにより、より分散化されたネットワークと高いセキュリティが実現されます。
これにより、中央集権的なコントロールを避け、ネットワークの健全性を保ちます。

ビーコンチェーンの導入により、イーサリアムはより持続可能でスケーラブルなブロックチェーンへと進化を遂げています。

動機

このEIP（Ethereum Improvement Proposal、イーサリアム改善提案）は、ビーコンチェーン上で検証者（バリデーター）が行う出金をイーサリアム仮想マシン（EVM）へと取り込む方法に関するものです。
ここでいう「プッシュ」ベースのアーキテクチャとは、出金がビーコンチェーン（コンセンサス層）から削除されるとすぐにEVM（実行層）で処理されるべきであるという設計のことです。
これは、出金を行う際にEVM側から積極的に引き出す「プル」ベースのアプローチとは異なります。

この提案では、出金を「オペレーション」という新しいタイプのオブジェクトとして実行ペイロード内に表現します。
これにより、出金機能が通常のユーザーレベルのトランザクションから分離されます。
この方法は、新しいトランザクションタイプを導入する以前のアプローチよりも手間がかかりますが、システムレベルの操作を通常のトランザクションから明確に分けることができます。
この分離は、システムレベルの懸念事項をユーザーデータと混合することによって生じる相互作用効果を減少させることで、テストを単純化し（セキュリティを促進することにつながります）。

さらに、このアプローチはコアプロトコルに関しては「プル」ベースの代替案よりも複雑ですが、重要な機能をプロトコル自体により緊密に統合するという利点があります。

このEIPはビーコンチェーンでの出金をEVMへスムーズに移行させるための新しい仕組みを提案しています。
この仕組みは、より効率的な処理を可能にし、検証者が自分の報酬をより迅速に受け取れるようにすることを目指しています。
同時に、このシステムレベルの操作を通常のユーザートランザクションから分けることで、全体のシステムの安全性と整合性を高めることができます。

仕様

ある特定の変更がイーサリアムの実行クライアントに導入されるタイミングを指定しています。
ここでの重要な要素は「FORK_TIMESTAMP」という定数です。
これは、変更が適用されるべき特定の実行タイムスタンプ（UNIXタイムスタンプ形式での日時）を示しています。

表によると、FORK_TIMESTAMPの値は1681338455です。
これは、特定の時点を表しており、このタイムスタンプが達成された時点から、実行クライアントは新しいペイロードの検証と処理に関する拡張を導入しなければなりません。
つまり、このタイムスタンプが指す瞬間から、新しいルールやプロセスが実行層で有効になるということです。

具体的な拡張内容については記載がありませんが、通常、このような仕様では新しいトランザクションタイプの導入、検証ルールの変更、セキュリティ強化などが含まれることがあります。

constants	value	units
FORK_TIMESTAMP	1681338455

この表は、FORK_TIMESTAMPという定数に1681338455という値が割り当てられていることを示しています。
units列は空ですが、これは通常、値が時間（UNIXタイムスタンプ）を表しているため、特定の単位が不要であることを意味します。

システムレベルの運営：引き出し

イーサリアムにおける新しいタイプのペイロードレベルオブジェクト、「出金（withdrawal）」の定義について説明しています。
このオブジェクトは、コンセンサス層で検証された出金を記述するために使用されます。
出金オブジェクトは、ユーザーレベルのトランザクションと文法的には似ていますが、異なるドメインに存在します。

出金にはコンセンサス層からの重要な情報が含まれています。

インデックス

0から始まる単調増加するインデックスで、uint64値として表されて各出金を一意に識別するために出金ごとに1ずつ増加します。

バリデーターインデックス

出金が対応するコンセンサス層のバリデーターのインデックスで、uint64値として表されます。

受取人アドレス

出金されたイーサの受取人のアドレスで、20バイトの値として表されます。

出金額

0ではないイーサの量で、Gwei（10億wei）単位のuint64値として与えられます。

注各出金のインデックスは、出金の全シーケンスにわたってグローバルなカウンターです。

出金オブジェクトは、スキーマ [index, validator_index, address, amount] に従ってRLP（Recursive Length Prefix）リストとしてシリアライズされます。

このシステムは、イーサリアムのネットワークでバリデーターとして機能するユーザーが自分の報酬を受け取る時に使用する新しい方法を提供します。
これにより、コンセンサス層で検証された出金が、効率的かつ透明に実行層に記録されることを可能にします。

実行ペイロードの新フィールド：引き出し

イーサリアムの実行ペイロードに「出金（withdrawals）」という新しいフィールドを追加する仕様です。
この新しいフィールドは、「出金データ」を含むRLP（Recursive Length Prefix）リストで構成されます。
RLPは、イーサリアムでデータをシリアライズするための標準的な方法です。

各出金データは、以下の4つの要素からなるリストとして表されます。

• index
  • 出金の一意な識別子として機能する、0から始まる単調増加のインデックス（uint64型）。
• validator_index
  • 出金に対応するコンセンサス層の検証者（バリデーター）のインデックス（uint64型）。
• address
  • 出金されたイーサーの受取人のアドレス（20バイトの値）。
• amount
  • 出金されるイーサーの量で、Gwei（10億Wei）単位の非ゼロのuint64値。

例えば、2つの出金データがある場合、それぞれwithdrawal_0、withdrawal_1としてリスト化され、これらがwithdrawalsフィールドにまとめられます。
このwithdrawalsフィールドは、実行ペイロードの既存のフィールドの後にエンコードされ、実行ペイロードの本体の一部とみなされます。

実行ペイロードはRLPでシリアライズされ、execution_payload_rlpはヘッダー、トランザクション、空リスト（EIP3675によってommersの値が固定定数に設定されるため）、そしてwithdrawalsを含むリストとして表されます。
execution_payload_body_rlpは、トランザクション、空リスト、そしてwithdrawalsを含むRLPリストとして表されます。

この仕様により、出金情報が実行ペイロードに直接含まれるようになり、イーサリアムの実行層で出金をより効率的かつ透明に処理できるようになります。

実行ペイロードヘッダーの新フィールド：引き出しルート

実行ペイロードヘッダーに「withdrawals root」という新しいフィールドが追加されることについて説明します。
このフィールドは、実行ペイロード内の出金にコミットするために導入されます。

このコミットメントは、既存の実行ペイロードヘッダー内のトランザクションルートと同様に構築されます。
具体的には、出金リストのインデックスをキーとして使用し、各出金をMerkle-Patriciaトライに挿入することで作成されます。

compute_trie_root_from_indexed_dataという関数は、与えられたデータ（この場合は出金）からトライのルートを計算します。
データの各アイテムはインデックスで列挙され、それらがトライに挿入されます。
このトライのルートは、出金リスト全体にコミットする32バイトの値としてwithdrawals_rootに設定されます。

実行ペイロードヘッダーは、この新しいwithdrawals_rootフィールドを含むように拡張されます。
これにより、与えられた実行ペイロード内の出金リスト全体に対するコミットメントが確保されます。

RLP（Recursive Length Prefix）でエンコードされる実行ペイロードヘッダーは、parent_hash、coinbase、state_root、txs_root（トランザクションルート）、receipts_root、logs_bloom、number（ブロック番号）、gas_limit、gas_used、timestamp（タイムスタンプ）、extradata、prev_randao、base_fee_per_gas、そして新しいwithdrawals_rootを含むリストとして表されます。

ここでのcompute_trie_root_from_indexed_data関数やwithdrawals_rootフィールドの導入は、実行ペイロードの整合性と検証可能性を高め、イーサリアムネットワーク上での出金処理の透明性と信頼性を向上させることを目的としています。
EIP3675およびEIP4399に関連するフィールド名や定数値については、それらのEIPを参照してください。

EIP4399については以下の記事を参考にしてください。

実行ペイロードの有効性

実行ペイロードの有効性に関する説明は、実行ペイロードが適切にフォーマットされていると仮定した上で、実行クライアントが追加のペイロード検証を実施する必要があることを指しています。
この追加の検証は、ペイロード内の出金リストに基づいて予想されるwithdrawals_rootの値が、実際の実行ペイロードヘッダーのwithdrawals_rootと一致することを確認することを目的としています。

実行ペイロードの有効性に関する説明は、イーサリアムの実行環境（実行層）でトランザクションやその他のデータ（出金情報など）が処理される際の検証プロセスを指しています。
ここでの「実行ペイロード」とは、ブロックに含まれるトランザクションや出金などのデータセットのことです。

「適切にフォーマットされている」とは、実行ペイロードがイーサリアムのプロトコルや規約に沿った形式であることを意味します。
例えば、トランザクションデータが正しい形式である、出金情報が正しく記載されているなどが含まれます。

実行クライアントが「追加のペイロード検証」を実施する必要があるという部分は、単にデータが正しい形式であるだけでなく、その内容も正確であることを確認するプロセスを指しています。
たとえば、出金がビーコンチェーンで承認されたものであるか、トランザクションが有効な署名を持っているかなど、具体的な内容の検証が含まれます。

この検証プロセスを通じて、不正なトランザクションやデータがネットワークに含まれるのを防ぎ、イーサリアムシステムのセキュリティと正確性を保つことが目的です。
実行クライアントによるこの追加検証は、ネットワークの健全性を維持し、ユーザーの資産を保護するために不可欠なステップとなります。

具体的には、execution_payload_header.withdrawals_rootというフィールドに格納されている値が、compute_trie_root_from_indexed_data(execution_payload.withdrawals)関数によって計算される値と一致することを確認する必要があります。
この関数は、与えられた出金データのリストからトライのルートを計算します。
このトライのルートは、出金データの全体構造を要約したもので、特定の出金データのリストに特有の値です。

この検証プロセスにより、実行ペイロードに含まれる出金情報の整合性と正確性が保証されます。
出金データのリストがペイロードに正しく含まれていて、それがwithdrawals_rootに正しく反映されていることを確認することで、データの改ざんや不整合を防ぎ、システムの信頼性を高めることができます。

状態遷移

実行ペイロード内の出金処理に関するこの説明では、実行ペイロードに含まれる出金が、ユーザーレベルのトランザクションが適用された後に処理されることを指しています。
つまり、まず通常のトランザクションが実行され、その後で出金が処理されるという順序です。

実行ペイロードのwithdrawalsリスト内の各出金について、実装は指定されたアドレスの残高を、指定された金額で増加させます。
ここで重要な点は、出金の金額がGwei単位で与えられているということです。イーサリアムのアカウント残高は通常、Wei単位で管理されているため、GweiからWeiへの変換が必要になります（1 Gweiは10億 Weiに相当します）。

この残高の変更は無条件であり、失敗することはありません。つまり、この操作は必ず成功し、特定のアドレスの残高を増加させることが保証されています。また、この操作には関連するガスコストがないため、出金処理によって追加のトランザクション料金が発生することはありません。

このプロセスにより、ビーコンチェーンでの検証者活動に対する報酬として、検証者が出金を行うことができるようになります。そして、この報酬はイーサリアムの実行状態における検証者のアカウント残高に直接反映されます。このシステムは、検証者が彼らの報酬を迅速かつ確実に受け取ることを可能にし、イーサリアムネットワークのセキュリティと運用のインセンティブを強化します。

補足

新しいトランザクションタイプではない理由

「出金操作」は、既存のEVMトランザクションのタイプとは異なる特別な意味を持っています。
これらの操作はシステム全体によって開始され、典型的なトランザクションのようにエンドユーザーから発生するものではありません。
完全に新しいオブジェクトタイプを導入することで、出金処理を一般的なEVM実行から隔離し、テストやセキュリティレビューを単純化します。

出金タイプにガスコストがない理由

実行層に到達できる出金の最大数は、コンセンサス層によって制限されています。
この制限は、実行層の運用コストが広いコンテキストでのペイロード実行において無視できるほど小さいことを保証するために選ばれています。
この制限は、計算コスト（状態内のいくつかの残高更新のみ）とストレージ/ネットワーキングコストの両方に適用されます。
追加のペイロードフットプリントは小さく保たれ、現在のパラメーターでは追加のオーバーヘッドを現在の平均ペイロードサイズの約1％に抑えています。

なぜ残高更新のみで、一般的なEVM実行が含まれないのか？

より一般的な処理を導入すると、失敗のリスクが生じ、ビーコンチェーン上での会計を複雑にします。
このEIPは、最小限の（複雑さの）コストでほとんどの利益を提供する出金のためのルートを提案しています。

このEIPは出金を単純かつ効率的に処理することを目的としており、新しいオブジェクトタイプを導入することで、一般的なトランザクション処理から明確に分離し、システムの安全性と信頼性を高めることを意図しています。
また、ガスコストを免除することで、このプロセスをさらに簡素化し、利用者にとっての負担を減らしています。

セキュリティ

コンセンサス層における出金トランザクションの検証は、適切な量のETHが実行層に戻されることを保証するために非常に重要です。
これは、ビーコンチェーン（コンセンサス層）で承認された出金が、イーサリアムの実行環境（実行層）に正しく反映されることを意味します。
このプロセスは、現在のEVM（イーサリアム仮想マシン）には存在しない新しいメカニズムであり、コンセンサス層から実行層へのETHの移動を伴います。

このようなメカニズムがEVMには現在存在しないため、非常に高いセキュリティ検討が必要とされます。
これは、システムに新しい種類のトランザクションや操作を導入する際には、不正な出金や不正確なトランザクションが実行層に影響を与えないように、厳格な検証プロセスが必要であることを意味します。
そのため、コンセンサス層での検証は、ETHの移動が正しく、安全に行われることを確認するための重要なステップとなります。

このプロセスの安全性を確保するためには、コンセンサス層と実行層の間で情報が正確に伝達され、ETHの出金が承認された条件に基づいてのみ行われるようにする必要があります。
また、この種の操作がシステムに導入されることで生じる可能性のある新たな攻撃ベクトルに対する保護措置も慎重に検討されるべきです。

引用

Alex Stokes (@ralexstokes), Danny Ryan (@djrtwo), "EIP-4895: Beacon chain push withdrawals as operations," Ethereum Improvement Proposals, no. 4895, March 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4895.

最後に

今回は「ビーコンチェーン上でのバリデーター出金をEVMに「プッシュ」するためのシステムレベルの「操作」を導入する提案をしているEIP4895」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

Twitter @cardene777

他の媒体でも情報発信しているのでぜひ他も見ていってください！