명세
읽기 편의를 위한 AI 번역이며 부정확하거나 오래되었을 수 있습니다. 거버넌스·투표·분쟁 시에는 영어 원문만이 유일한 정식 본문입니다. 정확한 표현은 GitHub 원본을 참고하세요.
GitHub 영어 원문 ↗## 초록
이 MIP는 우선 순위 수수료를 검증자의 수익 주소에만 적립하는 대신, 위임자에게 자동으로 분배합니다.
## 동기
현재 우선 순위 수수료는 검증자의 수익 주소에 직접 적립됩니다. 원칙적으로 검증자는 스테이킹 계약에서 `externalReward`를 호출하여 이러한 수수료를 위임자에게 전달할 수 있지만, 이는 운영적으로 번거롭습니다. 각 검증자가 수익 잔액을 정리하고, 전달 거래에 대한 가스를 관리하며, `dust_threshold` 최소값을 처리하기 위해 추가 인프라를 운영해야 합니다. 실제로 대부분의 검증자는 오늘날 이를 수행하지 않으므로 우선 순위 수수료는 위임자에게 흐르지 않고 수익자에게 축적됩니다.
모든 스테이커에 대한 일관된 보상을 보장하기 위해, 이 제안은 프로토콜 수준에서 우선 순위 수수료를 위임자에게 자동으로 분배하는 메커니즘을 도입합니다.
## 명세
### 개요
자동화된 우선 순위 수수료 분배는 두 가지 구성 요소로 이루어져 있습니다:
1. 우선 순위 수수료를 수집하는 새로운 계정, 즉 `distribution account`로 불리는 계정. 분배 계정의 주소는 `0xfee5fee5fee5fee5fee5fee5fee5fee5fee5fee5`입니다.
2. 해당 검증자 풀에서 `distribution account`에 축적된 우선 순위 수수료로 `external_rewards`를 호출하는 블록 종료 실행 로직.
`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))
# block_leader에 대한 syscall_reward에서 사용되는 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`의 잔액에 직접 적립되지 않습니다.
우선 순위 수수료가 이제 검증자의 풀 내 모든 위임자에게 분배되므로, 제3자 위임 계약에 영향을 미칠 수 있습니다. 사용자가 외부 계약을 우회하고 검증자 풀에 직접 스테이킹할 경우 이러한 계약은 우선 순위 수수료의 지분이 희석됩니다.
이 업데이트에 적합하도록 `external_rewards`는 호출 시 수수료를 제거하도록 수정됩니다.
## 보안 고려 사항
주요 고려 사항은 보상 누적기의 정밀도입니다.
`external_rewards`는 누적기 내에서 특정 소수점 정확성을 보장하기 위해 정의된 최소 입력 금액인 `dust_threshold`를 요구합니다. 비영(非零) 우선 순위 수수료에 대한 최소 임계값은 이 `external_rewards` 최소 잔액 요구 사항과 일치해야 하며, 이 임계값 이하의 수수료는 분배되지 않습니다.
고려해야 할 엣지 케이스:
1. 우선 순위 수수료가 0인 블록은 분배가 발생하지 않습니다.
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.