メインコンテンツへスキップ

ブロック

最終編集者: , Invalid DateTime

ブロックとは、チェーンの 1 つ前のハッシュとトランザクションのバッチのことです。 ハッシュはブロックデータから暗号的に生成されるため、チェーンのブロックはお互いに繋がっています。 前のブロックのハッシュを用いるため、どれかのブロックが改ざんされるとデータの整合性が取れなくなるため、ブロックチェーンを実行しているすべての人が改ざんに気づくことになります。

前提知識

この記事は初心者向けに記載していますが、 より理解を深めるために、まずアカウント、トランザクションそしてイーサリアムの導入を読むことをお勧めします。

ブロックを使用する背景

ブロックはすべてのイーサリアムネットワークへの参加者が同期された状態を維持し、トランザクションの正確な履歴に同意できるように、複数のトランザクションをブロックにバッチとして格納します。 これは、何十件(もしくは数百) ものトランザクションが一度にコミット、合意、同期されることを意味します。

状態の変更を起こすブロックのトランザクション図 (opens in a new tab) イーサリアム EVM(opens in a new tab)からの図解

コミットの間隔をあけ、すべてのネットワーク参加者がコンセンサスに至るまでの十分な時間を確保しています。たとえトランザクション要求が毎秒数十回発生したとしても、ブロックはイーサリアム上で 12 秒に 1 回生成され、コミットされます。

ブロックの仕組み

トランザクション履歴を保持するため、ブロックは厳密に順序付けられ、作成されたすべての新規ブロックに親ブロックへの参照 (ハッシュ) が含まれます。 同様に、ブロック内のトランザクションも厳密に順序付けられています。 まれな例外を除き、 常時ネットワーク上のすべての参加者は、正確な数のブロックとその履歴に合意しており、現在のトランザクションリクエストを次のブロックにバッチ処理しています。

バリデータがブロックをまとめると、そのブロックは残りの他のネットワークに伝播されます。すべてのノードはこのブロックをブロックチェーンの最後尾に追加し、次のブロックを生成するために新しいバリデータが選ばれます。 このブロック生成とコミットメント/コンセンサスプロセスは、現在イーサリアム「プルーフ・オブ・ステーク (PoS) 」プロトコルによって定義されています。

プルーフ・オブ・ステーク(PoS)プロトコル

プルーフ・オブ・ステークとは、以下のことを意味します。

  • 検証を行うノードは、不正行為をしない担保として、デポジットコントラクトに 32 ETH のステーキングが必要。 明らかに不誠実な行為を行うと、担保のステーキングの一部またはすべてが失うことになるため、ネットワークの保護を目的としている。
  • すべてのスロット(12 秒間隔)において、ランダムに 1 つのバリデータがブロックの提案者として選出される。 選ばれたバリデータが、トランザクションを 1 つにまとめ、実行し新たな「状態」を決定し、 この情報をブロックに格納し、他のバリデータに渡す。
  • 新しいブロックに関する情報を受け取った他のバリデータは、トランザクションを再実行し、グローバル状態への変更提案について同意することを確認する。 ブロックが有効であった場合、それを自分のデータベースに追加する。
  • バリデータが同一スロットで 2 つの競合するブロックの情報を受け取った場合は、フォーク・チョイス・アルゴリズムを使用して、最も多額の ETH ステーキングにより支持されている方を選択する。

プルーフ・オブ・ステーク(PoS)の詳細

ブロックが保持するパラメータ

ブロックにはたくさんの情報が含まれており、 大まかには、以下のようなフィールドがあります。

1slot: ブロックが所属するスロット
2proposer_index: ブロックを提案しているバリデータのID
3parent_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 倍)までは、ネットワークの需要に応じてブロックサイズが増減します。 ブロックの全トランザクションで消費されたガスの総量は、ブロックのガスリミット以下でなければなりません。 これはブロックが勝手に大きくなりすぎないようにする点で重要です。 もしブロックサイズが非常に大きくなると、パフォーマンスの低いフルノードは、スペースと速度の要件により、ネットワークに追いつけなくなってしまいます。 ブロックが大きいほど、次のスロットに間に合うように処理するために必要な計算能力が高くなります。 これは中央集権的な力につながってしまうため、ブロックサイズに上限を設けています。

参考文献

役に立つコミュニティリソースをご存知の場合は、 このページを編集して追加してください。

トップに戻る ↑

この記事は役に立ちましたか?