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

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

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

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

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

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

報酬とペナルティ

報酬

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

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))により全体の発行額も増えますが、バリデータ1名あたりのベース報酬は(1/sqrt(N))により少なくなります。これらの要因は、ステーキングを行うノードのAPRに影響を及ぼします。この仕様の根拠については、ヴィタリックの説明(opens in a new tab)をご覧ください。

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

11. ソース投票：バリデータが、適切なソース・チェックポイントに対して、適時に投票したかどうか。2. ターゲット投票：バリデータが、適切なターゲット・チェックポイントに対して、適時に投票したかどうか。
23. ヘッド投票：バリデータが、適切な先頭ブロックに対して適時に投票したかどうか。
34. 同期委員会の報酬：バリデータが、同期委員会に参加したかどうか。
45. 提案者の報酬：バリデータが、適切なスロットにブロックを提案したかどうか。

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

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分の1(上限は1ETH)がただちにバーンされ、さらに36日間の削除期間が開始されます。この削除期間にわたり、バリデータのステークは徐々に減少します。この期間の中間点(18日目)には追加のペナルティが科されますが、その額は、当該のスラッシング・イベントが発生する前の36日間においてスラッシングの対象となったすべてのバリデータがステークしたイーサの合計に基づいて決定されます。つまり、スラッシング対象のバリデータが多いほど、このスラッシングの額が大きくなります。最悪の場合、スラッシングは対象のバリデータにおける有効な残高が全額没収されます(つまり、スラッシング対象のバリデータが多数である場合、彼らはステークをすべて失う可能性があります)。一方、1件のスラッシングイベントのみが発生した場合、バリデータのステークのうちごく一部しかバーンされません。スラッシング対象のバリデータ数に応じて決定される中間地点におけるペナルティは、「コリレーション・ペナルティ」と呼ばれます。

インアクティブ・リーク

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

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

参考文献

ソース

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