本文主要是介绍POS 之 奖励机制，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
为什么需要有奖惩机制
如果没有奖励，就不会有节点参与POS，运营节点有成本，而奖励正是让运营者获利的方式
如果没有惩罚，网络上会充斥着很多无效节点，会扰乱甚至破坏网络
所有奖励和惩罚在每个
Epoch实施一次
奖励
什么行为才能获取奖励
- 当验证者作出与大多数其他验证者一致的投票时
- 当验证者提议区块时
- 当验证者参与同步委员会时
奖励的数额
base_reward
b a s e _ r e w a r d = e f f e c t i v e _ b a l a n c e ∗ ( b a s e _ r e w a r d _ f a c t o r / ( b a s e _ r e w a r d s _ p e r _ e p o c h ∗ s u m ( a c t i v e _ b a l a n c e ) ) ) base\_reward = effective\_balance * (base\_reward\_factor / (base\_rewards\_per\_epoch * \sqrt{sum(active\_balance)})) base_reward=effective_balance∗(base_reward_factor/(base_rewards_per_epoch∗sum(active_balance)))
base_reward: 代表在每个 Epoch 的最佳条件下每个验证者的平均奖励，根据验证者有效余额以及活跃的验证者的总数计算的base_reward_factor: 64base_reward_per_epoch: 4sum(active_balance): 所有活跃验证者质押以太币的总数
这意味着：
- 基础奖励与验证者有效余额成正比，与验证者数量成反比
- 验证者越多，ETH的增发量就越大，但每个验证者的
base_reward就越小
base_reward_factor的构成：
| Item | 描述 | 权重 | |
|---|---|---|---|
| 🍠 | 来源投票 | 验证者给正确的来源检查点进行了及时投票 | 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 - 8) / 64 * base_reward = \frac{7}{8} * base_reward $
inclusion_delay_reward
这里其实是一个激励，激励节点更快的投票。
i n c l u s i o n _ d e l a y _ r e w a r d = b a s e _ r e w a r d ∗ 1 d e l a y inclusion\_delay\_reward = base\_reward * \frac{1}{delay} inclusion_delay_reward=base_reward∗delay1
delay是区块提议和完成认证之间的slot数
如果用户在区块提议的一个 slot内提交认证，那么认证者将获得 b a s e _ r e w a r d 1 1 = = b a s e _ r e w a r d base\_reward \frac{1}{1} == base\_reward base_reward11==base_reward
如果认证在下一个时隙到达，认证者将收到 b a s e r e w a r d 1 2 base_reward \frac{1}{2} basereward21 的奖励，以此类推。
区块提议者奖励
包含在区块中的每一个有效认证都能让区块提议者获得 $ \frac{8}{64} * base_reward$，所以奖励的实际值与证明验证者的数量成比例。 通过在所提议区块中包含其他验证者的不良行为证据，区块提议者也能增加奖励。 这些奖励是鼓励验证者诚实的
胡萝卜。
这篇关于POS 之 奖励机制的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
