---
title: "ブロックの提案"
description: "プルーフ・オブ・ステークのイーサリアムにおいて、ブロックがどのように提案されるかの解説。"
lang: ja
---

ブロックはブロックチェーンの基本単位です。ブロックはノード間で受け渡され、合意され、各ノードのデータベースに追加される個別の情報単位です。このページでは、ブロックがどのように生成されるかを説明します。

## 前提条件 {#prerequisites}

ブロックの提案は、プルーフ・オブ・ステーク (PoS) プロトコルの一部です。このページを理解するために、[プルーフ・オブ・ステーク](/developers/docs/consensus-mechanisms/pos/)と[ブロックのアーキテクチャ](/developers/docs/blocks/)について読むことをお勧めします。

## 誰がブロックを生成するのか？ {#who-produces-blocks}

バリデータアカウントがブロックを提案します。バリデータアカウントは、実行クライアントおよびコンセンサスクライアントの一部としてバリデータソフトウェアを実行し、デポジット・コントラクトに少なくとも32 ETHをデポジットしたノードオペレーターによって管理されます。ただし、各バリデータがブロックを提案する責任を負うのは時々です。[イーサリアム](/)は、スロットとエポックで時間を測定します。各スロットは12秒で、32スロット（6.4分）で1エポックを構成します。すべてのスロットは、イーサリアムに新しいブロックを追加する機会となります。

### ランダムな選択 {#random-selection}

各スロットでブロックを提案するために、単一のバリデータが疑似ランダムに選ばれます。各ノードが真にランダムな数値を生成した場合、コンセンサスに至ることができないため、ブロックチェーンには真のランダム性というものは存在しません。代わりに、バリデータの選択プロセスを予測不可能にすることを目的としています。イーサリアムにおけるランダム性は、ブロック・プロポーザーからのハッシュと、ブロックごとに更新されるシードを混合するRANDAOと呼ばれるアルゴリズムを使用して実現されます。この値は、バリデータの全体セットから特定のバリデータを選択するために使用されます。特定の種類のシード操作から保護する方法として、バリデータの選択は2エポック前に固定されます。

バリデータは各スロットでRANDAOに追加しますが、グローバルなRANDAO値は1エポックに1回だけ更新されます。次のブロック・プロポーザーのインデックスを計算するために、RANDAO値はスロット番号と混合され、各スロットで一意の値が生成されます。個々のバリデータが選択される確率は、単純に`1/N`（`N` = アクティブなバリデータの総数）ではありません。代わりに、各バリデータの有効ETH残高によって重み付けされます。最大有効残高は32 ETHです（つまり、`balance < 32 ETH`は`balance == 32 ETH`よりも低い重みになりますが、`balance > 32 ETH`は`balance == 32 ETH`よりも高い重みにはなりません）。

各スロットで選択されるブロック・プロポーザーは1つだけです。通常の条件下では、単一のブロック生成者が専用のスロットで単一のブロックを作成してリリースします。同じスロットに対して2つのブロックを作成することは、スラッシングの対象となる違反行為であり、多くの場合「エキボケーション」として知られています。

## ブロックはどのように作成されるのか？ {#how-is-a-block-created}

ブロック・プロポーザーは、ローカルで実行されているフォーク選択アルゴリズムのビューに従って、チェーンの最新のヘッドの上に構築される署名済みのビーコン・ブロックをブロードキャストすることが期待されます。フォーク選択アルゴリズムは、前のスロットから残っているキューに入れられたアテステーションを適用し、その履歴の中でアテステーションの累積された重みが最も大きいブロックを見つけます。そのブロックが、プロポーザーによって作成される新しいブロックの親になります。

ブロック・プロポーザーは、自身のローカルデータベースとチェーンのビューからデータを収集してブロックを作成します。ブロックの内容は以下のスニペットに示されています。

```rust
class BeaconBlockBody(Container):
    randao_reveal: BLSSignature
    eth1_data: Eth1Data
    graffiti: Bytes32
    proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
    attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
    attestations: List[Attestation, MAX_ATTESTATIONS]
    deposits: List[Deposit, MAX_DEPOSITS]
    voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
    sync_aggregate: SyncAggregate
    execution_payload: ExecutionPayload
```

`randao_reveal`フィールドは、ブロック・プロポーザーが現在のエポック番号に署名することによって作成する検証可能なランダム値を取ります。`eth1_data`は、デポジットのマークル・トライのルートや、新しいデポジットの検証を可能にするデポジットの総数を含む、ブロック・プロポーザーのデポジット・コントラクトのビューに対する投票です。`graffiti`は、ブロックにメッセージを追加するために使用できるオプションのフィールドです。`proposer_slashings`と`attester_slashings`は、プロポーザーのチェーンのビューに従って、特定のバリデータがスラッシングの対象となる違反を犯したという証明を含むフィールドです。`deposits`は、ブロック・プロポーザーが認識している新しいバリデータのデポジットのリストであり、`voluntary_exits`は、ブロック・プロポーザーがコンセンサス・レイヤーのゴシップネットワークで聞いた、エグジットを希望するバリデータのリストです。`sync_aggregate`は、どのバリデータが以前にシンク・コミッティ（ライト・クライアントのデータを提供するバリデータのサブセット）に割り当てられ、データの署名に参加したかを示すベクトルです。

`execution_payload`は、トランザクションに関する情報を実行クライアントとコンセンサス・レイヤークライアント間で受け渡すことを可能にします。`execution_payload`は、ビーコン・ブロック内にネストされる実行データのブロックです。`execution_payload`内のフィールドは、オマー（ommers）が存在せず、`difficulty`の代わりに`prev_randao`が存在することを除いて、イーサリアムのイエロー・ペーパーで概説されているブロック構造を反映しています。実行クライアントは、自身のゴシップネットワークで聞いたトランザクションのローカルプールにアクセスできます。これらのトランザクションはローカルで実行され、ポストステート（post-state）と呼ばれる更新されたステート・トライを生成します。トランザクションは`transactions`と呼ばれるリストとして`execution_payload`に含まれ、ポストステートは`state-root`フィールドで提供されます。

これらのデータはすべてビーコン・ブロックに収集され、署名され、ブロック・プロポーザーのピアにブロードキャストされ、ピアはそれをさらに自身のピアに伝播させます。

[ブロックの構造](/developers/docs/blocks)についてさらに読む。

## ブロックはどうなるのか？ {#what-happens-to-blocks}

ブロックはブロック・プロポーザーのローカルデータベースに追加され、コンセンサス・レイヤーのゴシップネットワークを介してピアにブロードキャストされます。バリデータがブロックを受信すると、ブロックが正しい親を持っているか、正しいスロットに対応しているか、プロポーザーのインデックスが期待されるものであるか、RANDAOの公開が有効であるか、プロポーザーがスラッシングされていないかなど、内部のデータを検証します。`execution_payload`はバンドル解除され、バリデータの実行クライアントはリスト内のトランザクションを再実行して、提案された状態の変更を確認します。ブロックがこれらすべてのチェックに合格したと仮定すると、各バリデータはブロックを自身の正規のチェーンに追加します。その後、次のスロットでプロセスが再び開始されます。

## ブロック報酬 {#block-rewards}

ブロック・プロポーザーは、その作業に対する支払いを受け取ります。アクティブなバリデータの数とその有効残高の関数として計算される`base_reward`があります。その後、ブロック・プロポーザーは、ブロックに含まれる有効なアテステーションごとに`base_reward`の一部を受け取ります。ブロックをアテステーションするバリデータが多いほど、ブロック・プロポーザーの報酬は大きくなります。また、スラッシングされるべきバリデータを報告した場合の報酬もあり、スラッシングされたバリデータごとに`1/512 * effective balance`に等しくなります。

[報酬とペナルティの詳細](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)

## 参考文献 {#further-reading}

- [ブロックの概要](/developers/docs/blocks/)
- [プルーフ・オブ・ステークの概要](/developers/docs/consensus-mechanisms/pos/)
- [イーサリアムのコンセンサス仕様](https://github.com/ethereum/consensus-specs)
- [Gasperの概要](/developers/docs/consensus-mechanisms/pos/gasper/)
- [イーサリアムのアップグレード](https://eth2book.info/)