ブロック

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

前提知識

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

ブロックを使用する背景

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

イーサリアムEVM(opens in a new tab)からの図解

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

ブロックの仕組み

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

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

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

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

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

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

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

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

ブロックのbodyには独自のフィールドがいくつかあります。

attestationsフィールドには、ブロック内のすべてのアテステーションのリストが含まれます。 アテステーションは、複数のデータを含むそれぞれの独自のデータ型があり、 それぞれのアテステーションには以下が含まれています。

attestationのdataフィールドには、以下が含まれます。

execution_payloadのトランザクションを実行すると、グローバル状態が更新されます。 すべてのクライアントは「新しい状態」が「新しいブロック」のstate_rootフィールドの状態と一致することを確認するために、execution_payloadのトランザクションを再実行します。 このようにして、クライアントは「新しいブロック」が有効であり、ブロックチェーンに追加しても安全であることを判断します。 execution payload自体は、いくつかのフィールドを持つオブジェクトです。 実行データに関する重要な要約情報を含むexecution_payload_headerもあります。 これらのデータ構造は、以下のように構成されています。

execution_payload_headerには、以下のフィールドが含まれます。

execution_payload自体には、以下のものが含まれます(注:トランザクションのルートハッシュの代わりに実際のトランザクションリストと引き出し情報を含んでいることを除けば、ヘッダーと同じ)。

withdrawalsリストには、次のように構造化されたwithdrawalsオブジェクトが含まれています。

ブロックタイム

ブロックタイムとは、ブロックの生成間隔のことです。 イーサリアムでは、12秒単位で時間を分割し、その単位を「スロット」と呼びます。 各スロットでは、1人のバリデータが選ばれ、ブロックを提案します。 すべてのバリデータがオンラインで完全に稼働している場合、すべてのスロットにブロックが1つ生成され、ブロックタイムは12秒となります。 しかし、バリデータがブロックを提案するタイミングでオフラインになっていることがあり、その場合、スロットが空になることがあります。

この実装は、ブロックタイムが不規則であり、プロトコルがターゲットとして定めるマイニングの難易度によって調整されるプルーフ・オブ・ワークを基としたシステムとは異なります。 イーサリアムの平均ブロックタイム(opens in a new tab)は、12秒という新しいブロックタイムで安定しており、これは、プルーフ・オブ・ワークからプルーフ・オブ・ステークへの移行が明確に示される最も良い例です。

ブロックサイズ

最後に重要なのは、ブロックのサイズには制限があるということです。 各ブロックの目標サイズは1,500万ガスですが、ネットワークの需要に合わせて、ブロックの上限である3,000万ガス(目標ブロックサイズの2倍)まで増減します。 ブロックのガスリミットは、前のブロックのガスリミットから1/1024の割合で上下に調整することができます。 したがって、バリデータはコンセンサスによってブロックのガスリミットを変更することができます。 ブロックの全トランザクションで消費されたガスの総量は、ブロックのガスリミットを超えてはいけません。 ブロックが勝手に大きくなりすぎるのを防ぐという点で、この制限は重要です。 ブロックサイズが大きすぎると、スペースと速度の要件により、パフォーマンスの低いフルノードはネットワークに追いつけなくなり、 次のスロットに間に合うように処理するために必要な計算能力も高くなります。 これが中央集権的な力につながってしまうことから、ブロックサイズに上限を設けています。

参考文献

役に立ったコミュニティリソースがあれば、 ぜひこのページに追加してください。

関連トピック

• トランザクション
• ガス
• プルーフ・オブ・ステーク