イーサリアムの歴史において、おそらく最も重要なイベントである「ザ・マージ」は、2022年9月15日に行われました。これにより、ネットワークは から へと移行し、イーサリアムがコンセンサスをどのように達成するかが根本的に変更されました。しかし、なぜ「トランジション」ではなく「ザ・マージ」と呼ばれるのでしょうか？ プルーフ・オブ・ワーク プルーフ・オブ・ステーク ザ・マージ以前、イーサリアムはプルーフ・オブ・ワークというコンセンサス・メカニズムで稼働していました。これは、「マイナー」が複雑な暗号パズルを解くことでトランザクションを検証し、新しいブロックを作成する必要があるメカニズムです。PoWは素晴らしいですが、莫大な計算能力を必要とし、大量の電力消費と環境への懸念、検証時間の遅さによる低いトランザクションスループット、したがって機関投資家の採用における課題、少数の強力なマイニングエンティティに統合される可能性が高いため、中央集権化のリスクが高いなど、多くの制約があります。これらの理由、そしてその他の理由から、イーサリアム財団は、設立からわずか3年後に、PoWが直面していたほとんどの問題を解決するために設計された新しいコンセンサスであるプルーフ・オブ・ステークの構築を開始しました。 2020年12月1日、イーサリアムはPoSの最初のバージョンである「ビーコンチェーン」と呼ばれる新しいチェーンをローンチしました。ビーコンチェーンはユーザーのトランザクションを処理していませんでした。その唯一の目的は、Gasperと呼ばれる新しいメカニズムを使用してバリデーターを調整し、コンセンサスに到達することでした。トランザクションは引き続きメインのプルーフ・オブ・ワークチェーンで処理されていたため、イーサリアムのメインチェーンとビーコンチェーンの両方のチェーンが並行して実行されていました。約2年間、これらの2つのチェーンは独立して動作していました。そして2022年9月15日、元のチェーンはマイニングベースのコンセンサスを放棄し、ビーコンチェーンに直接接続されました。これにより、2つのチェーンが1つになりました。だからこそ、「トランジション」ではなく「ザ・マージ」と呼ばれるのです。 現在、イーサリアムは2層ブロックチェーンとして稼働しています。コンセンサス層（以前はビーコンチェーンでした）は、ブロック提案、アテステーション、ファイナリティを処理します。実行層（元のイーサリアムチェーン）は、トランザクション処理を処理します。これらはそれぞれEth2およびEth1と呼ばれているかもしれませんが、イーサリアム財団は、これは単一システムの2つのレイヤーではなく、2つの別個のネットワークを暗示するため、その命名法を非推奨としました。この記事では、コンセンサス層に焦点を当てます。具体的には、ビーコンチェーンがステートマシンとしてどのように機能するかを説明します。 ビーコンステートとは？ ステートマシントランジションがどのように機能するかを理解するには、まずチェーンのジェネシス時にステートが実際に何を含んでいるかを理解する必要があります。ビーコンチェーンのステートは、BeaconStateと呼ばれる単一のオブジェクトによって表されます。これは、コンセンサス層が機能するために必要なすべてを保持しています。これは「ゴッドオブジェクト」と呼ばれることもあります。仕様自体は、フィールドを目的別にグループ化しており、それらを説明する最も明確な方法です。 class BeaconState(Container): genesis_time: uint64 genesis_validators_root: Root slot: Slot fork: Fork latest_block_header: BeaconBlockHeader block_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] state_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] historical_roots: List[Root, HISTORICAL_ROOTS_LIMIT] eth1_data: Eth1Data eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH] eth1_deposit_index: uint64 validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] previous_justified_checkpoint: Checkpoint current_justified_checkpoint: Checkpoint finalized_checkpoint: Checkpoint バージョン管理： genesis_time: uint64 genesis_validators_root: Root slot: Slot fork: Fork 最初の4つの変数は、「どのチェーンにいて、そのチェーンのどこにいるのか？」という質問に答えます。これらのフィールドはチェーンのアイデンティティをアンカーし、すべてのノードがどのプロトコルルールに従うべきかを伝えます。ジェネシス・タイムは、チェーンの開始時に設定されるUnixタイムスタンプであり、決して変更されません。ビーコンチェーンのジェネシス・タイムスタンプは1606824023であり、これは正確には2020年12月1日12:00:23 UTCです。スマートコントラクトから「block.timestamp」をクエリしたことがあるなら、その値はこのフィールドから計算されます。 ジェネシス・バリデーター・ルートは、タイムスタンプと同様に、チェーンの開始時にも追加されました。これは基本的にドメイン・セパレーターとして機能します。ブロック提案やアテステーション中のバリデーターの署名と組み合わされて、イーサリアム・メインネットを他のチェーンと区別します。 スロットは単なるカウンターであり、チェーンが時間的にどこにあるかを示します。ブロックが生成されるかどうかにかかわらず、12秒ごとにインクリメントされます。Forkは3つのフィールドを含むオブジェクトであり、前のチェーンバージョン、現在のチェーンバージョン、およびエポックです。ビーコンチェーンで最初のアップグレードが2021年10月27日に行われたとき、バージョンはフェーズ0からアルタイルに切り替わりました。この記事の執筆時点での現在のバージョンはFuluで、前のバージョンはElectraです。バリデーター・ルートと同様に、バージョンハッシュは署名に追加され、異なるフォークバージョンを区別します。一方、エポックは32スロットのバンドルであり、12秒x32（約6.4分）です。ここでファイナリティチェック、スラッシングペナルティ、エグジットキュー、その他のコンセンサス固有のクールなものがすべて行われます。ここで、Gasperの最後の部分であるCasper FFGが動作します。 履歴 latest_block_header: BeaconBlockHeader block_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] state_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] historical_roots: List[Root, HISTORICAL_ROOTS_LIMIT] このセクションは、「このチェーンで何が起こったか？」という質問に答えます。これらの変数は、チェーンに過去のコンパクトなメモリを提供し、バリデーターがすべてを保存することなく以前のステートを参照および検証できるようにします。 最新ブロックヘッダーは、最後に処理されたブロックのヘッダーを格納します。これは重複ブロックを防ぐために使用されます。なぜなら、新しいブロックを処理する前に、チェーンはブロックの親ルートが最新ブロックヘッダーのルートと一致するかどうかを確認するからです。 ブロック・ルートとステート・ルートの両方のフィールドは、過去のブロック・ルートとステート・ルートをそれぞれ満杯になるまで格納するリストです。各スロットで、ルートはインデックス にある対応する配列に書き込まれます。これにより、チェーンは27時間以内の任意の最近のスロットの状態を検索できます。履歴ルートは、ブロック・ルートとステート・ルートの配列がいっぱいになったときに、それらのマージされたハッシュを付加します。リストは無制限ですが、ゆっくりと成長し、27時間ごとに1つのエントリしか追加されません。 slot%8192 Eth1 eth1_data: Eth1Data eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH] eth1_deposit_index: uint64 マージ前、Eth2（ビーコンチェーン）はEth1（PoWチェーン）で何が起こっているかを追跡する必要がありました。特に、新しいバリデーターが32 ETHをロックしたデポジットトランザクションです。なぜPoSのために意図された32 ETHがビーコンチェーンではなくPoWチェーンにロックされていたのか不思議に思うかもしれません。答えは単純で、ビーコンチェーン自体にはトークン転送やトランザクション処理能力がなく、ネイティブにトークンデポジットを処理できなかったからです。 Eth1データには3つのサブフィールドがあります。 （デポジットコントラクトのデポジットツリーのマーケル・ルート）、 （コントラクトへのデポジットの総数）、そして （参照されているeth1ブロックのハッシュ）です。 デポジット・ルート デポジット・カウント ブロック・ハッシュ ビーコンチェーンは、単一のバリデーターのEth1チェーンのビューを信頼することはできません。なぜなら、ネットワーク遅延のために異なるバリデーターが異なる状態を見る可能性があるからです。そのため、ブロック提案者が現在のEth1データのビューをブロックに含めることを許可する投票メカニズムを使用します。これらの投票は、投票期間中にこのリストに蓄積され、その期間中にいずれかの値が過半数の票を獲得すると、新しいEth1データになります。投票期間の終了時に、リストはクリアされ、投票は新たに開始されます。 Ethデポジット・インデックスは、デポジットコントラクトからのデポジットがこれまでにいくつ処理されたかを追跡します。チェーンが新しいブロックを処理するとき、このインデックスをEth1データのデポジット・カウント・フィールドと比較して、未処理のデポジットがあるかどうかを確認します。デポジット・カウントが高い場合、ブロックは最大デポジット（当時16）までの次のデポジットを含める必要があります。 レジストリ validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] この変数は、基本的にコンセンサスに参加している者とそのステーク量をリストとして格納します。バリデーター・フィールドに関する興味深い事実の1つは、バリデーターが撤退した後でも、そのエントリはリストに残るため、常に増加し、決して縮小しないということです。現在、2,210,484件のエントリがあり、アクティブなのは962,941件のみです。 バリデーター・フィールドには8つのサブフィールドがあります。 （バリデーターの公開鍵）、 （撤退時にステークが行く場所）、 （報酬とペナルティの計算に使用されるGweiに切り捨てられた残高。ヒステリシスとともにエポック境界で更新され、上下にちらつくのを防ぎます）、 （バリデーターがスラッシュされたかどうかを示すブールフラグ）、 （バリデーターがアクティブ化されたエポック）、 （アクティブ化されたエポック）、 （離脱したエポック）、そして最後に （残高を引き出せるエポック）です。 pubKey withdrawable credentials effective balance slashed activation eligibility epoch activation epoch exit epoch withdrawable epoch バリデーター・リストに有効残高フィールドがあり、ビーコンステートに直接残高フィールドがある理由を指摘すると、有効残高フィールドは実際の残高が更新された瞬間に更新されるわけではなく、バッファーがあるため行ったり来たりするのを防ぎます。ヒステリシスがない場合、報酬とペナルティのために各エポックで32 ETH周辺を変動するバリデーター（たとえば、31.99と32.01の間で変動する）は、有効残高が各エポックで31と32の間で切り替わることになります。これは、バリデーターオブジェクトを常に再マーク化し、各エポックでコミッティ計算におけるその重みを変更することを意味します。 ランダム性 randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] randao_mixesは65,536（約2の16乗）エントリの固定サイズのリストです。バリデーターがブロックを提案するたびに、「randao reveal」と呼ばれるものをリストに追加します。このrevealは基本的に、バリデーターによって署名された現在のエポック番号です。署名後、チェーンはそれを受け取り、現在のエポックの最後のミックスとXOR演算することで新しいミックスを生成します。エポック内のすべての提案者は、次のエポックの最終的な累積ミックスを取得するために同じことを行います。 randaoミックスは、次のエポックのコミッティとブロック提案者を決定するために使用されます。コミッティは、32スロットに分割されたすべての有効なバリデーターであり、「swap-or-not」シャッフルアルゴリズムによって決定されます。このアルゴリズムは、基本的にミックスでバリデーターインデックスをランダムにスワップするだけです。ブロック提案者の選択については、チェーンはrandaoミックスをハッシュしてシードを形成します。次に、そのシードから導出されたランダムなオフセットから開始して、すべての有効なバリデーターを反復処理します。各候補について、シードとバリデーターのインデックスのハッシュをバリデーターの有効残高で割ったものがしきい値を超えるかどうかを確認します。超える場合、バリデーターが提案者になります。超えない場合、次のバリデーターにスキップします。実際には、ほとんどの有効なバリデーターが32 ETHの残高を持っているため、すぐに1つ見つかります。 スラッシング slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] バリデーターは2つの理由でスラッシュされます。1つは、同じスロットに対して2つの異なるブロックを提案してフォークを作成しようとした場合、もう1つは、矛盾するアテステーションを行った場合です。スラッシング・フィールドは、エポックごとに1つの固定リスト（8192エントリ）です。スラッシュされたすべてのバリデーターの有効残高の合計が含まれています。このフィールドはペナルティ額の計算に使用されます。 アテステーション previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] すべての有効なバリデーターはエポックごとに1回アテステーションを行い、これらのアテステーションがフォーク選択ルール（LMD-GHOST）とファイナリティメカニズム（Casper FFG）を推進します。 アテステーションには6つのサブフィールドがあります。バリデーターがアテステーションを行っている 、バリデーターがチェーンのヘッドと見なしているブロックである （バリデーターによるLMD-GHOST投票と見なされ、フォーク選択を決定するために使用されます）、バリデーターが正当だと信じているエポック・チェックポイントである 、バリデーターがアテステーションを行っている現在のエポックである （これら2つはファイナリティで使用されるCasper FFG投票を形成します）。簡単に言うと、バリデーターはソースエポックがファイナライズされるべきであり、ターゲットエポックが正当化されるべきであるとアテステーションしています。 は、コミッティ内のどのバリデーターがアテステーションしたかを示します。バイトにビットとしてものを結合する方が安価であるため、集約ビットはメモリ効率のためにビットフィールドに格納されます。最後に、アテステーション・データに対するバリデーターの があります。 スロット ビーコンブロック・ルート ソース ターゲット 集約ビット 署名 ファイナリティ justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] previous_justified_checkpoint: Checkpoint current_justified_checkpoint: Checkpoint finalized_checkpoint: Checkpoint ファイナリティとは、ブロックとそのすべてのトランザクションが決して元に戻せないことを意味します。ビーコンチェーンでは、ファイナリティは絶対的です。エポックがファイナライズされると、それを元に戻す唯一の方法は、ステークされたETHの1/3がスラッシュされることですが、これには数十億ドルがかかります。 正当化ビットは長さ4のビットベクトルであり、基本的に最後の4つのエポックが正当化されたかどうかを追跡します。以前に正当化されたチェックポイントは、前のエポック時点での正当化されたチェックポイントです。現在の正当化チェックポイントは、最も最近に正当化されたチェックポイントであり、ファイナライズされたチェックポイントは、最も最近にファイナライズされたチェックポイントです。 エポックが、全アクティブステークの2/3がそのエポックをターゲットとして指す超多数リンクをアテステーションした場合に正当化されます。ファイナリティは、2つの正当化されたチェックポイントが連続して得られた場合に発生します。2番目のチェックポイントが正当化された瞬間、最初のチェックポイントはファイナライズにアップグレードされますが、さらにいくつかのニュアンスがあります。 ステートマシン ステートが何を含んでいるかを知ったので、それがどのように変化するかを見てみましょう。12秒ごとに新しいスロットが到着します。ブロックが提案されると、ステート遷移関数は現在のステートとそのブロックを受け取り、検証を実行し、更新して新しいステートを出力します。このプロセスは、仕様によってスロット処理、ブロック処理、エポック処理の3つのステージに分かれています。 スロット処理 スロット処理は、ブロックが生成されたかどうかにかかわらず、チェーンが次のスロットに進む必要があるたびに実行されます。 スロットがNからN+1に進むときに3つのことが起こります。まず、スロットNのステート・ルートは、そのスロットでの状態を記録するために更新されます。次に、最後に処理されたブロックのヘッダーを格納する最新ブロックヘッダーも更新されます。このフィールドが重複ブロックを防ぐために使用されることを思い出してください。また、その完了したヘッダーのルートがブロック・ルートに書き込まれます。最後に、スロット・カウンターが1つインクリメントされます。 提案者がスロットをスキップした場合、ステートに何が起こるのか不思議に思うかもしれません。すべてのステートは引き続き更新されます。たとえば、そのスロットのブロック・ルートは、新しいブロックが置き換えるために到着しなかったため、最新ブロックヘッダーのルートと同じになります。 スロットをインクリメントした後、チェーンはエポック境界を越えたかどうかを確認します（slot mod 32 == 0で簡単に確認できます）。もしそうなら、他のことが起こる前にエポック処理が開始されます。したがって、技術的には、32スロットごとにエポック処理がスロット処理と並行して実行されます。つまり、エポック処理はスロットが進んだ後、そのスロットのブロックが処理される前に実行されます。 最後に注意すべき点は、ステート・ルートとブロック・ルートの配列がいっぱいになった時点（slot mod 8192 == 0の位置）で、配列が円形のように新しいデータで上書きされ始める前に、チェーンは2つのフィールドをハッシュし、履歴ステートに付加することです。 ブロック処理 ブロック処理は、実際にあるスロットに対してブロックが提案されたときに実行されます。スロット処理がステートを正しいスロットに進めた後、ブロック処理は署名されたブロックを受け取り、その内容をステートに適用します。ブロックヘッダーの検証とブロック本体の処理の2つの主要な部分があります。 まず、チェーンは、ブロックヘッダーが現在のステート・スロットと一致するかどうか、ブロック提案者のインデックスが実際にrandaoによって選択されたバリデーターであるかどうかなど、いくつかのことを確認します。最後に、ブロックの親ルートが最新ブロックヘッダーのルートと一致するかどうかを確認します。検証に成功すると、ブロックヘッダーはステートの最新ブロックヘッダーとして格納されます。 次に、提案者はrandao revealを含める必要があります。これは前述のように、基本的にバリデーターによって署名された現在のエポック番号です。チェーンは、提案者の公開鍵に対して署名を検証します。この現在の方法が決定論的であることは容易にわかります。バリデーターの署名は同じエポック番号に対して常に同じになります。実際、このように行うことの目的は、誰でもバリデーターの公開鍵を使用して、バリデーターが実際に署名したエポック番号を確認できるようにすることです。提案者はrandao revealをスキップできません。ブロックを提案する場合、それを含める必要があります。プロセスをスキップする唯一の方法は、そもそもブロックを提案しないことです。 その後、提案者はEth1チェーンのデポジットコントラクト・ステートのビューをEth1データ投票として含めます。投票リスト内のEth1データ値が過半数に達すると、それはステートの新しいEth1データになります。 ブロック処理中、提案者スラッシング・フィールドには、バリデーターが同じスロットに対して2つの異なるブロックヘッダーに署名した証拠が含まれています。チェーンは両方の署名を検証し、有効な場合は、バリデーターのスラッシュ済みフラグをtrueに設定し、有効残高をスラッシング配列に追加することによってスラッシュします。また、アテスターについても、矛盾するアテステーションがあれば、チェーンはそれを検証し、署名を通じて不正なバリデーターを特定し、ブロック提案者スラッシングと同じ方法とプロセスでそれらのバリデーターをスラッシュします。 ブロック内の新しいアテステーションは検証され、アテステーションは、インクルージョン遅延と提案者インデックスという2つの新しいフィールドを追加することで保留中のアテステーションに変換され、現在のエポック・アテステーションまたは前のエポック・アテステーションのいずれかに付加されます。追加された後、それらはすぐにステートに影響を与えないため、あまり多くのことはありません。エポック処理がそれらを評価するまで、そこに座っています。 Eth1デポジットコントラクトからの新しいバリデーターのデポジットが処理されます。ブロックは、最大16のデポジットまでのすべての保留中のデポジットを含める必要があります。チェーンは、各デポジットのマーケル証明をデポジット・ルートに対して検証し、それが正しいことを確認します。デポジターの公開鍵が新しい場合、新しいバリデーターエントリと対応する残高が追加されます。 バリデーターは、署名された自主的なエグジットを送信することによって、離脱したいという意向を示すことができます。チェーンは、バリデーターが少なくとも256エポックアクティブであったこと、および現在のエポックが指定されたエグジットエポック以上であることを確認します。すべてがチェックアウトした場合、バリデーターのエグジットエポックと引き出し可能エポックが設定されます。 上記のすべてが処理された後、最後で重要なピースがあります。それは、他のノードによって計算されたステート・ルートがブロックに含まれているステート・ルートと比較されることです。一致しない場合、ブロック全体が拒否されます。 エポック処理 エポック処理は、エポック境界、つまり「slot mod 32 = 0」のステップごとにトリガーされます。スロット・カウンターが新しいエポックに切り替わるときに、スロット処理中に実行されます。これは最も複雑なステージであり、コンセンサスのクールなもののほとんどがここで発生します。 まず、正当化とファイナリティが開始されます。ここでCasper FFGが機能します。プロセスは複雑に聞こえるかもしれませんが、非常に簡単です。簡単に言うと、チェーンは前のエポックからのアテステーションを見て、正しいターゲットでアテステーションしたバリデーターの有効残高を数えます。その合計が全アクティブ残高の2/3以上であれば、ターゲットエポックは正当化され、2つの連続するエポックが正当化されると、前のエポックがファイナライズされます。簡単です！ ブロック処理ステージで指摘しなかった事実の1つは、各ステージでバリデーターが報酬を蓄積することです。アテステーションを含めた場合、スラッシング証拠を追加した場合、または通常の基本報酬を得た場合でも、報酬が得られます。これらの累積報酬は、エポック処理ステージで前のエポックにわたってチェーンによって評価され、残高がそれに応じて調整されます。 チェーンが4エポック以上ファイナライズされていない場合、「非アクティビティ・リーク」と呼ばれるものが開始されます。欠席アテステーションに対する通常のペナルティに加えて、非参加バリデーターは、最後にファイナライズされたエポックからの経過エポック数とともに二次関数的に増加する追加の非アクティビティペナルティを受けます。つまり、ブロックのファイナライズに時間がかかるほど、ペナルティは厳しくなります。これを行う目的が何であるか不思議に思うかもしれません。ブロックがしばらくファイナライズされていないということは、そのブロックに対する過半数の投票がないことを意味します。ファイナリティへの投票は、バリデーターの有効残高の重み（基本的にバリデーターがいくらETHを持っているか）で測定されるため、有効残高の減少は投票力を低下させます。したがって、イーサリアムはブロック・ファイナリティを強制する方法としてこれを使用します。非アクティビティ・リーク中は、正しいアテスターでさえ報酬を受け取らないことに注意してください。すべてがペナルティモードに移行し、再バランスをスピードアップします。 このステージで発生するもう1つの重要なイベントは、アクティベーション・エリーチビリティ・エポックに達したバリデーターのアクティベーションです。また、エグジット・エポックが到着したバリデーターは、バリデーターの有効セットから削除されます。 次に、有効残高は各スロットやエポックで更新されないことを思い出してください。ヒステリシスが適用されるためです。実際の残高が現在の有効残高の上限しきい値を十分に上回った場合のみ更新され、有効残高は1 ETH増加し、下限しきい値を下回った場合は1 ETH減少します。 最後に、現在のエポックのrandaoミックスが次のエポックのスロットにコピーされます。はっきりとわかるように、エポック処理はステートマシンの最も複雑な部分であり、計算的に不利であるため、常にチェーンクライアントを構築するエンジニアにとって多くの最適化作業につながります。 フェーズ0からFuluへ これまで説明してきたBeaconStateは、オリジナルのフェーズ0バージョンです。しかし、ビーコンチェーンは生きているシステムです。すべてのコンセンサス層フォークは、新しいフィールドを追加したり、古いフィールドを削除したり、既存のフィールドの動作を変更したりして、BeaconStateを変更してきました。 たとえば、Altairフォークでは、以前および現在のエポックのattestationリストは完全に削除され、以前および現在のエポックの に置き換えられました。以前のリストは完全なattestationオブジェクトを格納していましたが、新しいparticipationタイプはビット形式でのみ格納しています。現在、各バリデーターはエポックごとに3ビットを持ち、ソースが正しいか、ターゲットが正しいか、ヘッドが正しいかを示します。これにより、メモリサイズが大幅に削減されました。Bellatrix（マージ・フォーク）は、ビーコンステートにexecution payloadフィールドを導入しました。このフィールドは、コンセンサス層と実行層を接続するために使用されます。Eth1フィールドは維持されましたが、それらはもはや必要とされなかったため、その役割は縮小されました。 participation Capellaフォークはバリデーターの引き出し機能を導入し、ビーコンステートにnext withdrawal indexという新しいフィールドを追加して記録します。Historical rootsはhistorical summariesに置き換えられ、ブロック・ルートとステート・ルートをハッシュする代わりに構造体に格納します。一方、Denebフォークは、フォークが主にブロブに関連していたため、BeaconStateにほとんど影響を与えませんでした。ElectraとFuluでは、主な変更点は最大有効残高を32 ETHから2048 ETHに引き上げたことです。これにより、BeaconStateに新しいフィールドが導入されました。 各フォークは前のフォークの上に構築され、BeaconStateはフェーズ0の21フィールドからFuluの30以上のフィールドに成長しました。1つのことは一貫しています。フェーズ0からFuluまで、ステートは成長し、フォークはフィールドを追加し、フォークはフィールドを削除しますが、アーキテクチャは同じままです。 結論 ビーコンチェーンはしばしば複雑であると説明されます。はい、複雑であることは同意します。なぜなら、それは複雑だからです。しかし、その核心では、それは基本的に、ステートが存在し、入力が到着し、既存のステートが更新されて新しいステートを生成し、そして繰り返すというサイクルです！シンプルです！ビーコンチェーンを本当に驚くべきものにしているのは、単一のフィールドではなく、それらがすべて接続されて、今日のこの素晴らしい「tek」を提供する方法です！ 参考文献 Ethereum Consensus Specifications (Phase 0) Ethereum Annotated Specification by Ben Edgington eth2book.info Gasper: Combining GHOST and Casper (Original Paper) Casper the Friendly Finality Gadget (Original Paper) Lighthouse Client Implementation Ethereum Beacon Chain Explorer Ethereum Foundation Blog on the Merge Ethereum Annotated Spec by Vitalik Buterin
