プルーフ・オブ・ステークにおける報酬とペナルティ

イーサリアムでは、ネイティブの暗号通貨であるイーサ(ETH)を使用することでセキュリティを維持しています。 ブロックの検証やチェーンのヘッドの特定に参加したいノードオペレーターは、イーサリアムのデポジットコントラクトにイーサを入金します。 ノードの運用者は、ピアツーピアネットワークで受信した新規ブロックの正当性を確認するためのバリデータ・ソフトウェアを実行し、チェーンの先頭を特定するためのフォーク選択アルゴリズムを適用することで、報酬を得ることができます。

バリデータは、主に、1) 新規ブロックを確認し、それが正当なブロックでることを「証明」(アテステーション)すること、および2) バリデータの全体プールから選出された場合に、新規ブロックを提案すること、という2つの役割を担います。 バリデータがこれらのタスクの実行を要求された場合に実行できない場合、イーサの支払いを受け取る機会を逃すことになります。 バリデータはさらに、署名の集約作業や同期委員会に参加することが求められる場合もあります。

また、同一のスロットに複数のブロックを提案したり、同一のスロットに対する複数のブロックにアテステーションを提供するなど、故意に実行することがとても困難であり、悪意を持つことを示すアクションも存在しています。 これらの行為は「スラッシング」の対象であり、当該のバリデータは、最終的に36日間をかけてネットワークから削除されるまでの期間において、最大1ETHのイーサがバーンされます。 スラッシングの対象となったバリデータのイーサは、退出期間にわたり徐々に保有量が削減されますが、18日目には「コリレーション・ペナルティ」が科されます。これは、より多くのバリデータが同時期にスラッシングの対象となった場合に、より高額のペナルティが科されるものです。 このように合意メカニズムでは、誠実なユーザーに報酬を付与し、悪意のあるユーザーを罰するというインセンティブ体制を採用しています。

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

詳細については、以下をご覧ください。

報酬とペナルティ

報酬

バリデータは、ブロックが提案された場合と同期委員会に参加する際に、多数派のバリデータと同じ投票を行うことでで報酬を受け取ります。 各エポックの報酬額は、base_rewardから計算されます。 ベース報酬は、その他の報酬を算定する際の基準値です。 base_rewardは、最適な条件下でバリデータがエポックごとに受け取る平均報酬を表します。 ベース報酬額は、当該バリデータにおける有効な残高と、アクティブなバリデータ数を掛け合わせて算出します。具体的な数式は、以下の通りです:

1base_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) として) 大きくなりますが、バリデータあたりの base_reward は (1/sqrt(N) として) 小さくなります。 これらの要因は、ステーキングを行うノードのAPRに影響を及ぼします。 この理論的根拠については、ヴィタリックのメモ (opens in a new tab)をお読みください。

次に合計報酬を計算しますが、これは、それぞれが異なる重みを持つ5つの構成要素を合計して算出します。この重みは、合計報酬を算出するにあたり、各構成要素がどれだけ重要であるかを決定する値です。 5つの構成要素は、以下の通りです:

11. ソース投票：バリデータが正しいソースチェックポイントに対して適時に投票した
22. ターゲット投票：バリデータが正しいターゲットチェックポイントに対して適時に投票した
33. ヘッド投票：バリデータが正しいヘッドブロックに対して適時に投票した
44. 同期委員会報酬：バリデータが同期委員会に参加した
55. 提案者報酬：バリデータが正しいスロットでブロックを提案した

これらの構成要素に対する重み付けは以下のようになっています:

1TIMELY_SOURCE_WEIGHT	uint64(14)
2TIMELY_TARGET_WEIGHT	uint64(26)
3TIMELY_HEAD_WEIGHT	uint64(14)
4SYNC_REWARD_WEIGHT	uint64(2)
5PROPOSER_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アップグレードで調整されました。これについては、ダニー・ライアンとヴィタリックが議論しているこちらのPeep an EIPビデオ (opens in a new tab)をご覧ください。

スラッシング

スラッシングとは、バリデータをネットワークから強制的に退場させ、このバリデータがステークしたイーサを没収するより厳格な処罰です。 バリデータは、ブロックの不正な提案/アテステーションをもたらす以下の3つの場合にスラッシングの対象となります:

• 同一スロットに、2つの異なるブロックを提案、署名した場合
• あるブロックを「取り囲む」ブロックに対してアテステーションを提供した場合(事実上、履歴を変更した場合)
• 同一ブロックの2つの候補にアテステーションを提供することで、「二重投票」を行った場合

バリデータによるこのような行為が発見された場合、このバリデータはスラッシングの対象となります。 具体的には、対象となる32 ETHのバリデータから0.0078125 ETHが即時にバーンされ(アクティブバランスに応じて線形的に増加）、同時に36日の削除期間が開始されます。 この削除期間にわたり、バリデータのステークは徐々に減少します。 この期間の中間点(18日目)には追加のペナルティが科されますが、その額は、当該のスラッシング・イベントが発生する前の36日間においてスラッシングの対象となったすべてのバリデータがステークしたイーサの合計に基づいて決定されます。 つまり、スラッシング対象のバリデータが多いほど、このスラッシングの額が大きくなります。 最大スラッシュ額は、スラッシングされたすべてのバリデータの有効残高の全額です（つまり、多くのバリデータがスラッシングされた場合、彼らはステークの全額を失う可能性があります）。 一方、1件のスラッシングイベントのみが発生した場合、バリデータのステークのうちごく一部しかバーンされません。 スラッシング対象のバリデータ数に応じて決定される中間地点におけるペナルティは、「コリレーション・ペナルティ」と呼ばれます。

無活動リーク

コンセンサスレイヤーにおいて、4エポック連続でファイナライズが実行されない状態になると、「インアクティブ・リーク」と呼ばれる緊急プロトコルが実行されます。 インアクティブ・リークの究極的な目的は、チェーンがファイナリティを回復できる状況に戻すことです。 上述したように、ファイナリティを実現するには、ステークされたイーサの合計の3分の2が、ソースおよびターゲットのチェックポイントについて同意する必要があります。 バリデータ全体の3分の1以上のバリデータがオフラインになったり、適切なアテステーションを送信しない場合、3分の2のスーパーマジョリティによるチェックポイントのファイナライズが不可能になります。 インアクティブ・リークでは、インアクティブなバリデータに帰属するステークを最終的にはステーク合計の3分の1未満になるまで徐々に減少させることで、残りのアクティブなバリデータがチェーンをファイナライズできるようにします。 インアクティブなバリデータの数がどんなに大規模であろうと、最終的には残りのアクティブなバリデータがステーク合計の3分の2以上を支配できるようになります。 このメカニズムによるステークの喪失は、インアクティブなバリデータに対してできる限り早くアクティブな状態に復帰しなければならないという強力なインセンティブとして機能します。 Madallaテストネットにおいてインアクティブ・リークが発動した事例では、アクティブなバリデータの割合が全体の66%未満でしたが、ブロックチェーンの現在の先頭ブロックについてコンセンサスに達することができました。 インアクティブ・リークを実行した結果、ファイナリティを取り戻すことができたのです！

合意メカニズムにおける報酬、ペナルティ、スラッシングは、個々のバリデータにおける適切な行為を促すように設計されています。 しかし、これらの設計上の選択により、複数のクライアントにわたりバリデータを平等に配分することを強く奨励するシステムとなっており、単独のクライアントによる支配を断固として拒否することができるはずです。

参考リンク

• イーサリアムのアップグレード：インセンティブレイヤー (opens in a new tab)
• イーサリアムのハイブリッドCasperプロトコルにおけるインセンティブ (opens in a new tab)
• ヴィタリックの注釈付き仕様 (opens in a new tab)
• Eth2のスラッシングを防ぐヒント (opens in a new tab)
• EIP-7251におけるスラッシングペナルティの分析 (opens in a new tab)

出典

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