规范
为方便阅读的 AI 翻译，可能不准确或已过时。在治理、投票和争议中，英文原文是唯一权威文本。准确表述请参阅 GitHub 原文。
GitHub 英文原文 ↗## 摘要
本提案自动将优先费用分配给委托人，而不是仅仅将其记入验证者的受益地址。
## 动机
目前，优先费用直接记入验证者的受益地址。原则上，验证者可以通过在质押合约上调用 `externalReward` 将这些费用转发给其委托人，但这样做在操作上非常繁琐——这要求每个验证者运行额外的基础设施来清理受益余额，管理转发交易的 gas，并处理 `dust_threshold` 最小值。实际上，大多数验证者今天并没有这样做，因此优先费用积累到受益人，而不是流向委托人。
为了确保所有质押者的一致补偿，而不依赖于每个验证者的工具，本提案引入了一种机制，在协议层面上自动将优先费用分配给委托人。
## 规范
### 概述
自动优先费用分配有两个组成部分：
1. 一个新的账户，用于捕获优先费用，称为 `distribution account`。分配账户的地址将是 `0xfee5fee5fee5fee5fee5fee5fee5fee5fee5fee5`。
2. 结束区块执行逻辑，调用相应验证者池上的 `external_rewards`，并使用在 `distribution account` 中累积的优先费用。
`beneficiary` 仍然可以由区块提议者设置，并且在执行上下文中，`block.coinbase` 继续指向受益地址。
### 执行流程
在区块执行期间应用以下更改：
1. 受益人仍由区块提议者设置，并且在执行上下文中仍由 `block.coinbase` 表示。
2. 对于每个交易，优先费用记入分配账户，而不是受益余额。
3. 在区块执行结束时，系统在分配账户上调用 `syscall_distribute`。此函数通过 `external_rewards` 将全部累积余额转发到质押合约。
分配账户具有以下逻辑：
```python
class distribution_account:
# 此函数只能通过执行调用；没有交易可以调用它。
def syscall_distribute(address block_leader):
priority_fees = get_balance(address(this))
# 与 syscall_reward 对 block_leader 使用的 val_id 相同的值。
val_id = staking_contract.val_id(block_leader)
# 低于阈值的费用将被 external_rewards 过滤（见 dust_threshold）。
staking_contract.external_rewards(val_id){msg.value = priority_fees}
```
## 理由
优先费用是验证者收入的一部分，委托人应当获得这一分配的份额，以回报他们帮助保护网络。
此设计确保：
1. 优先费用在质押奖励中原生包含。
2. 消除对链外或外部分配逻辑的任何依赖。
## 向后兼容性
此更改修改了优先费用的流动：它们将不再作为直接信用出现在 `block.coinbase` 的余额中。
由于优先费用现在分配给验证者池中的所有委托人，第三方委托合约可能会受到影响。如果用户绕过外部合约并直接与验证者池质押，这些合约将经历优先费用份额的稀释。
为了适应此更新，`external_rewards` 将被修改，以便在调用时去除佣金费用。
## 安全考虑
主要考虑是奖励累加器的精度。
`external_rewards` 需要一个最小输入金额，定义为 `dust_threshold`，以保证累加器内的某种小数精度。非零优先费用的最小阈值必须与此 `external_rewards` 的最小余额要求对齐，低于此阈值的任何费用将不会被分配。
需要考虑的边缘情况：
1. 零优先费用的区块导致无操作分配。
2. 小额费用必须与 `dust_threshold` 进行验证；低于阈值的费用将被销毁。
## 版权
版权及相关权利通过 [CC0](../LICENSE.md) 放弃。论坛讨论
-
MIP 11 - Automatic Priority Fee Distribution This proposal introduces a protocol-level mechanism to automatically distribute priority fees to delegators. Currently, priority fees are credited directly to a validator’s beneficiary address; this proposal redirects those fees into the validator’s staking pool at the end of every block. We are seeking input on the following: - Third-Party Impact: How this change affects custom “Liquid Staking” or delegation wrappers that may currently rely on manual fee-sharing or direct block.coinbase monitoring. - Proposer Incentives: Does moving priority fees entirely to the pool affect proposer behavior or MEV strategies in a way that requires additional mitigation?
-
jhb10c: This proposal introduces a protocol-level mechanism to automatically distribute priority fees to delegators. Currently, priority fees are credited directly to a validator’s beneficiary address; this proposal redirects those fees into the validator’s staking pool at the end of every block. We are seeking input on the following: - Third-Party Impact: How this change affects custom “Liquid Staking” or delegation wrappers that may currently rely on manual fee-sharing or direct block.coinbase monitoring. - Proposer Incentives: Does moving priority fees entirely to the pool affect proposer behavior or MEV strategies in a way that requires additional mitigation? Regarding the redirection of priority fees: These fees have traditionally served as a primary buffer for validators to offset the high operational and hardware costs required to maintain 10k TPS. If these fees are moved...
-
To note, I am not sure of the actual cost to run a validator versus the inflation rate. So I will leave this particular question to another more knowledgeable. But to your point, a rational validators would re-adjust the commission with respect to the operational costs. However under the current regime, validators rarely claim priority fees. As such these rewards are idle. By observation, it seems that inflationary rewards are sufficient.