POS 之 奖励机制

本文主要是介绍POS 之 奖励机制，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

为什么需要有奖惩机制

如果没有奖励，就不会有节点参与POS，运营节点有成本，而奖励正是让运营者获利的方式
如果没有惩罚，网络上会充斥着很多无效节点，会扰乱甚至破坏网络

所有奖励和惩罚在每个 Epoch 实施一次

奖励

什么行为才能获取奖励

1. 当验证者作出与大多数其他验证者一致的投票时
2. 当验证者提议区块时
3. 当验证者参与同步委员会时

奖励的数额

base_reward

$$base\_reward=effective\_balance\ast (base\_reward\_factor/(base\_rewards\_per\_epoch\ast \sqrt{sum(active\_balance)}))$$

• base_reward : 代表在每个 Epoch 的最佳条件下每个验证者的平均奖励，根据验证者有效余额以及活跃的验证者的总数计算的
• base_reward_factor : 64
• base_reward_per_epoch : 4
• sum(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

这里其实是一个激励，激励节点更快的投票。

$$inclusion\_delay\_reward=base\_reward\ast \frac{1}{delay}$$

• delay是区块提议和完成认证之间的 slot数

如果用户在区块提议的一个 slot内提交认证，那么认证者将获得 $$base\_reward\frac{1}{1}==base\_reward$$
如果认证在下一个时隙到达，认证者将收到 $$bas{e}_{r}eward\frac{1}{2}$$ 的奖励，以此类推。

区块提议者奖励

包含在区块中的每一个有效认证都能让区块提议者获得 $ \frac{8}{64} * base_reward$，所以奖励的实际值与证明验证者的数量成比例。 通过在所提议区块中包含其他验证者的不良行为证据，区块提议者也能增加奖励。 这些奖励是鼓励验证者诚实的 胡萝卜。

这篇关于POS 之 奖励机制的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---