プルーフ・オブ・ステークの報酬とペナルティ

イーサリアムは、ネイティブの暗号資産であるイーサ(ETH)を使用して保護されています。ブロックの検証やチェーンの先頭(head)の特定に参加したいノードオペレーターは、イーサリアム上のデポジット・コントラクトにイーサを預け入れます。その後、ピア・ツー・ピアネットワーク経由で受信した新しいブロックの有効性をチェックし、フォーク選択アルゴリズムを適用してチェーンの先頭を特定するバリデータソフトウェアを実行することで、イーサで報酬が支払われます。

バリデータには主に2つの役割があります。1) 新しいブロックをチェックし、有効であれば「アテステーション」を行うこと、2) バリデータプール全体からランダムに選ばれた際に新しいブロックを提案することです。バリデータが要求された際にこれらのタスクのいずれかを実行できなかった場合、イーサの支払いを逃すことになります。また、バリデータは署名の集約やシンク・コミッティへの参加を任されることもあります。

また、同じスロットに対して複数のブロックを提案したり、同じスロットに対して複数のブロックにアテステーションを行ったりするなど、誤って行うことは非常に難しく、悪意のあるインテントを示すアクションもいくつか存在します。これらは「スラッシング対象」となる行為であり、バリデータがネットワークから削除される(これには36日かかります)前に、一定量(最大1 ETH)のイーサがバーン(焼却)される結果となります。スラッシングされたバリデータのイーサはエグジット期間中に徐々に失われていきますが、18日目には「相関ペナルティ(correlation penalty)」を受けます。これは、同時期にスラッシングされたバリデータが多いほど大きくなります。したがって、コンセンサス・メカニズムのインセンティブ構造は、誠実な行動には報酬を支払い、悪意のあるアクターには罰を与えるようになっています。

すべての報酬とペナルティは、エポックごとに1回適用されます。

詳細については以下をお読みください...

報酬とペナルティ

報酬

バリデータは、他の大多数のバリデータと一致する投票を行った場合、ブロックを提案した場合、およびシンク・コミッティに参加した場合に報酬を受け取ります。各エポックにおける報酬の価値は、base_rewardから計算されます。これは、他の報酬を計算するための基本単位です。base_rewardは、最適な条件下でバリデータが1エポックあたりに受け取る平均報酬を表します。これは、バリデータのエフェクティブ・バランスとアクティブなバリデータの総数から次のように計算されます。

base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance))))

ここで、base_reward_factorは64、base_rewards_per_epochは4、sum(active balance)はすべてのアクティブなバリデータにステークされたイーサの総量です。

これは、基本報酬がバリデータのエフェクティブ・バランスに比例し、ネットワーク上のバリデータ数に反比例することを意味します。バリデータが多いほど、全体の発行量は大きくなりますが(sqrt(N)に比例するため)、バリデータ1人あたりのbase_rewardは小さくなります(1/sqrt(N)に比例するため)。これらの要因は、ステーキングノードのAPRに影響を与えます。この根拠については、ヴィタリックのノート (opens in a new tab)をお読みください。

その後、合計報酬は5つのコンポーネントの合計として計算されます。各コンポーネントには、合計報酬にどれだけ追加されるかを決定する重み付けがあります。コンポーネントは以下の通りです。

1. source vote: バリデータが正しいソースチェックポイントに対してタイムリーな投票を行った
2. target vote: バリデータが正しいターゲットチェックポイントに対してタイムリーな投票を行った
3. head vote: バリデータが正しい先頭ブロックに対してタイムリーな投票を行った
4. sync committee reward: バリデータがシンク・コミッティに参加した
5. proposer reward: バリデータが正しいスロットでブロックを提案した

各コンポーネントの重み付けは以下の通りです。

TIMELY_SOURCE_WEIGHT	uint64(14)
TIMELY_TARGET_WEIGHT	uint64(26)
TIMELY_HEAD_WEIGHT	uint64(14)
SYNC_REWARD_WEIGHT	uint64(2)
PROPOSER_WEIGHT	uint64(8)

これらの重みの合計は64になります。報酬は、該当する重みの合計を64で割ったものとして計算されます。タイムリーなソース、ターゲット、および先頭への投票を行い、ブロックを提案し、シンク・コミッティに参加したバリデータは、64/64 * base_reward == base_rewardを受け取ることができます。ただし、バリデータは通常ブロック・プロポーザーではないため、最大報酬は64-8 /64 * base_reward == 7/8 * base_rewardとなります。ブロック・プロポーザーでもなく、シンク・コミッティにも参加していないバリデータは、64-8-2 / 64 * base_reward == 6.75/8 * base_rewardを受け取ることができます。

迅速なアテステーションを促すために、追加の報酬が付与されます。これがinclusion_delay_rewardです。これは、base_rewardに1/delayを掛けた値に等しくなります。ここで、delayはブロック提案とアテステーションを隔てるスロット数です。例えば、アテステーションがブロック提案から1スロット以内に提出された場合、アテステーションを行った者はbase_reward * 1/1 == base_rewardを受け取ります。アテステーションが次のスロットに到着した場合、アテステーションを行った者はbase_reward * 1/2を受け取り、以降も同様に計算されます。

ブロック・プロポーザーは、ブロックに含まれる有効なアテステーションごとに8 / 64 * base_rewardを受け取るため、報酬の実際の価値はアテステーションを行うバリデータの数に比例して増加します。また、ブロック・プロポーザーは、提案したブロックに他のバリデータの不正行為の証拠を含めることで、報酬を増やすこともできます。これらの報酬は、バリデータの誠実さを促す「アメ」となります。スラッシングを含めたブロック・プロポーザーは、slashed_validators_effective_balance / 512の報酬を受け取ります。

ペナルティ

ここまでは完全に正しく振る舞うバリデータについて考えてきましたが、タイムリーな先頭、ソース、ターゲットへの投票を行わない、あるいは投票が遅いバリデータについてはどうでしょうか？

ターゲットおよびソースへの投票を逃した場合のペナルティは、アテステーションを行った者が提出していれば受け取っていたはずの報酬と同額です。つまり、報酬が残高に追加される代わりに、同等の価値が残高から差し引かれます。先頭への投票を逃した場合のペナルティはありません(すなわち、先頭への投票は報酬が与えられるのみで、ペナルティが科されることはありません)。inclusion_delayに関連するペナルティもありません。単に報酬がバリデータの残高に追加されないだけです。また、ブロックの提案に失敗した場合のペナルティもありません。

報酬とペナルティの詳細については、コンセンサス仕様 (opens in a new tab)をお読みください。報酬とペナルティはBellatrixアップグレードで調整されました。ダニー・ライアン(Danny Ryan)とヴィタリック(Vitalik)がこれについて議論しているPeep an EIPの動画 (opens in a new tab)をご覧ください。

スラッシング

スラッシングはより厳しい措置であり、バリデータがネットワークから強制的に削除され、それに伴いステークしたイーサを失う結果となります。バリデータがスラッシングされるケースは3つあり、いずれもブロックの不正な提案またはアテステーションに該当します。

同じスロットに対して2つの異なるブロックを提案し、署名した場合
別のブロックを「囲む(surrounds)」ブロックにアテステーションを行った場合(事実上の履歴の改ざん)
同じブロックの2つの候補にアテステーションを行う「二重投票(double voting)」をした場合

これらのアクションが検出されると、バリデータはスラッシングされます。これは、32 ETHのバリデータの場合、0.0078125 ETHが即座にバーンされ(アクティブな残高に比例してスケーリングされます)、その後36日間の削除期間が始まることを意味します。この削除期間中、バリデータのステークは徐々に失われていきます。中間点(18日目)には追加のペナルティが適用され、その規模はスラッシングイベント前の36日間にスラッシングされたすべてのバリデータの合計ステークイーサ量に比例します。つまり、スラッシングされるバリデータが多いほど、スラッシングの規模は大きくなります。最大のスラッシングは、スラッシングされたすべてのバリデータの完全なエフェクティブ・バランスです(すなわち、多数のバリデータがスラッシングされている場合、ステーク全体を失う可能性があります)。一方、単独で孤立したスラッシングイベントでは、バリデータのステークのほんの一部がバーンされるだけです。スラッシングされたバリデータの数に比例するこの中間点のペナルティは、「相関ペナルティ(correlation penalty)」と呼ばれます。

インアクティビティ・リーク

コンセンサス・レイヤーがファイナリティに達することなく4エポック以上経過した場合、「インアクティビティ・リーク」と呼ばれる緊急プロトコルがアクティブになります。インアクティビティ・リークの最終的な目的は、チェーンがファイナリティを回復するために必要な条件を作り出すことです。上記で説明したように、ファイナリティには、ステークされたイーサ総量の3分の2の多数派がソースおよびターゲットのチェックポイントに合意する必要があります。全バリデータの3分の1以上を占めるバリデータがオフラインになったり、正しいアテステーションを提出できなかったりした場合、3分の2のスーパーマジョリティがチェックポイントをファイナライズすることは不可能です。インアクティビティ・リークは、非アクティブなバリデータに属するステークを徐々に失わせ、彼らがコントロールするステークが全体の3分の1未満になるまで減らすことで、残りのアクティブなバリデータがチェーンをファイナライズできるようにします。非アクティブなバリデータのプールがどれほど大きくても、残りのアクティブなバリデータは最終的にステークの3分の2超をコントロールすることになります。ステークの喪失は、非アクティブなバリデータができるだけ早く再アクティブ化するための強力なインセンティブとなります！インアクティビティ・リークのシナリオは、アクティブなバリデータの66%未満しかブロックチェーンの現在の先頭についてコンセンサスを得られなかった際に、Medallaテストネットで発生しました。インアクティビティ・リークがアクティブになり、最終的にファイナリティが回復しました！

コンセンサス・メカニズムの報酬、ペナルティ、およびスラッシングの設計は、個々のバリデータが正しく振る舞うことを促します。しかし、これらの設計上の選択から、複数のクライアント間でバリデータを均等に分散させることを強く推奨し、単一クライアントの支配を強く抑制するシステムが生まれます。

参考文献

ソース

https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/ (opens in a new tab)