ブロック
ブロックとは、チェーンの 1 つ前のハッシュとトランザクションのバッチのことです。 ハッシュはブロックデータから暗号的に生成されるため、チェーンのブロックはお互いに繋がっています。 前のブロックのハッシュを用いるため、どれかのブロックが改ざんされるとデータの整合性が取れなくなるため、ブロックチェーンを実行しているすべての人が改ざんに気づくことになります。
前提知識
この記事は初心者向けに記載していますが、 より理解を深めるために、まずアカウント、トランザクションそしてイーサリアムの導入を読むことをお勧めします。
ブロックを使用する背景
ブロックはすべてのイーサリアムネットワークへの参加者が同期された状態を維持し、トランザクションの正確な履歴に同意できるように、複数のトランザクションをブロックにバッチとして格納します。 これは、何十件(もしくは数百) ものトランザクションが一度にコミット、合意、同期されることを意味します。
(opens in a new tab)
イーサリアム EVM(opens in a new tab)からの図解
コミットの間隔をあけ、すべてのネットワーク参加者がコンセンサスに至るまでの十分な時間を確保しています。たとえトランザクション要求が毎秒数十回発生したとしても、ブロックはイーサリアム上で 12 秒に 1 回生成され、コミットされます。
ブロックの仕組み
トランザクション履歴を保持するため、ブロックは厳密に順序付けられ、作成されたすべての新規ブロックに親ブロックへの参照 (ハッシュ) が含まれます。 同様に、ブロック内のトランザクションも厳密に順序付けられています。 まれな例外を除き、 常時ネットワーク上のすべての参加者は、正確な数のブロックとその履歴に合意しており、現在のトランザクションリクエストを次のブロックにバッチ処理しています。
バリデータがブロックをまとめると、そのブロックは残りの他のネットワークに伝播されます。すべてのノードはこのブロックをブロックチェーンの最後尾に追加し、次のブロックを生成するために新しいバリデータが選ばれます。 このブロック生成とコミットメント/コンセンサスプロセスは、現在イーサリアム「プルーフ・オブ・ステーク (PoS) 」プロトコルによって定義されています。
プルーフ・オブ・ステーク(PoS)プロトコル
プルーフ・オブ・ステークとは、以下のことを意味します。
- 検証を行うノードは、不正行為をしない担保として、デポジットコントラクトに 32 ETH のステーキングが必要。 明らかに不誠実な行為を行うと、担保のステーキングの一部またはすべてが失うことになるため、ネットワークの保護を目的としている。
- すべてのスロット(12 秒間隔)において、ランダムに 1 つのバリデータがブロックの提案者として選出される。 選ばれたバリデータが、トランザクションを 1 つにまとめ、実行し新たな「状態」を決定し、 この情報をブロックに格納し、他のバリデータに渡す。
- 新しいブロックに関する情報を受け取った他のバリデータは、トランザクションを再実行し、グローバル状態への変更提案について同意することを確認する。 ブロックが有効であった場合、それを自分のデータベースに追加する。
- バリデータが同一スロットで 2 つの競合するブロックの情報を受け取った場合は、フォーク・チョイス・アルゴリズムを使用して、最も多額の ETH ステーキングにより支持されている方を選択する。
ブロックが保持するパラメータ
ブロックにはたくさんの情報が含まれており、 大まかには、以下のようなフィールドがあります。
1slot: ブロックが所属するスロット2proposer_index: ブロックを提案しているバリデータのID3parent_root: 前のブロックのハッシュ4state_root: 状態オブジェクトのルートハッシュ5body: 複数のフィールドを含むオブジェクト、定義は以下に記載。6
ブロックのbodyには独自のフィールドがいくつかあります。
1randao_reveal: 次のブロックの提案者を選択するのに使用される値2eth1_data: デポジットコントラクトに関する情報3graffiti: ブロックにタグをつけるのに使用される任意の値4proposer_slashings: スラッシング対象のバリデータリスト5attester_slashings: スラッシング対象のバリデータリスト6attestations: 現在のブロックに同意するアテステーションのリスト7deposits: デポジットコントラクトへの新規デポジットのリスト8voluntary_exits: ネットワークに存在するバリデータリスト9sync_aggregate: ライトクライアントを提供するのに使用されるバリデータのサブセット10execution_payload: 実行クライアントから渡されたトランザクション11すべて表示
attestationsフィールドには、ブロック内のすべてのアテステーションのリストが含まれます。 アテステーションは、複数のデータを含むそれぞれの独自のデータ型があり、 それぞれのアテステーションには以下が含まれています。
1aggregation_bits: 当該アテステーションに参加したバリデータリスト2data: 複数のサブフィールドを持つコンテナ3signature: アテステーションを行った全バリデータの署名を集約したもの4
attestationのdataフィールドには、以下が含まれます。
1slot: アテステーションが関連するスロット2index: 証明しているバリデータのインデックス3beacon_block_root: このオブジェクトを含むビーコンブロックのルートハッシュ4source: 直近の正当性が確認されたチェックポイント5target: 最新のエポックバウンダリブロック6
execution_payloadのトランザクションを実行すると、グローバル状態が更新されます。 すべてのクライアントは「新しい状態」が「新しいブロック」のstate_rootフィールドの状態と一致することを確認するために、execution_payloadのトランザクションを再実行します。 このようにして、クライアントは「新しいブロック」が有効であり、ブロックチェーンに追加しても安全であることを判断します。 execution payload自体は、いくつかのフィールドを持つオブジェクトです。 実行データに関する重要な要約情報を含むexecution_payload_headerもあります。 これらのデータ構造は、以下のように構成されています。
execution_payload_headerには、以下のフィールドが含まれます。
1parent_hash: 親ブロックのハッシュ2fee_recipient: トランザクションフィーの支払い先のアカウントアドレス3state_root: 当該ブロック変更後のグローバル状態のルートハッシュ4receipts_root: トランザクションレシートトライのハッシュ5logs_bloom: イベントログを含むデータ構造6prev_randao: バリデータのランダムな選択で使用する値7block_number: 現在のブロック番号8gas_limit: 当該ブロックの最大許容ガス量9gas_used: 当該ブロックでの実際のガス使用量10timestamp: ブロックタイム11extra_data: 任意の追加データ(Rawバイト)12base_fee_per_gas: ベースフィー値13block_hash: 実行ブロックのハッシュ14transactions_root: ペイロードに含まれるトランザクションのルートハッシュ15すべて表示
execution_payload自体には、以下のものが含まれます (トランザクションのルートハッシュの代わりに実際のトランザクションのリストを含んでいることを除けば、ヘッダーと同じ)。
1parent_hash: 親ブロックのハッシュ2fee_recipient: トランザクションフィーの支払い先のアカウントアドレス3state_root: 当該ブロック変更後のグローバル状態のルートハッシュ4receipts_root: トランザクションレシートトライのハッシュ5logs_bloom: イベントログを含むデータ構造6prev_randao: バリデータのランダムな選択で使用する値7block_number: 現在のブロック番号8gas_limit: 当該ブロックの最大許容ガス量9gas_used: 当該ブロックでの実際のガス使用量10timestamp: ブロックタイム11extra_data: 任意の追加データ(Rawバイト)12base_fee_per_gas: ベースフィー値13block_hash: 実行ブロックのハッシュ14transactions_root: ペイロードに含まれるトランザクションのルートハッシュ15すべて表示
ブロックタイム
ブロックタイムとは、ブロックを区切る時間を指します。 イーサリアムでは、時間は「スロット」と呼ばれる 12 秒単位で分割されています。 各スロットで、単一のバリデータがブロックを提案するために選ばれます。 すべてのバリデータがオンラインで完全に稼働中と仮定すると、すべてのスロットにブロックが 1 つ存在し、ブロックタイムは 12 秒です。 しかし、ブロックを提案するように求められたときにバリデータがオフラインであることがあり、スロットが空になってしまうことがあります。 この点がブロックタイムが確率的であり、マイニングの難易度によって調整されるプルーフ・オブ・ワークを基としたシステムとは異なります。
ブロックサイズ
最後に重要なのは、ブロック自体のサイズが制限されていることです。 各ブロックの目標サイズは 1,500 万ガスですが、ブロックの上限である 3,000 万ガス(目標ブロックサイズの 2 倍)までは、ネットワークの需要に応じてブロックサイズが増減します。 ブロックの全トランザクションで消費されたガスの総量は、ブロックのガスリミット以下でなければなりません。 これはブロックが勝手に大きくなりすぎないようにする点で重要です。 もしブロックサイズが非常に大きくなると、パフォーマンスの低いフルノードは、スペースと速度の要件により、ネットワークに追いつけなくなってしまいます。 ブロックが大きいほど、次のスロットに間に合うように処理するために必要な計算能力が高くなります。 これは中央集権的な力につながってしまうため、ブロックサイズに上限を設けています。
参考文献
役に立つコミュニティリソースをご存知の場合は、 このページを編集 して追加してください。