RPIP-73 Saturn-compatible treegen (v11) #344
Conversation
|
|
||
| The following changes will be made to the smart contracts: | ||
|
|
||
| 1) The megapool delegate will, at the time of distribution, calculate the operator share of the rewards adjusted for operator commission (`node_operator_commission_share + node_operator_commission_share_council_adder`) and send it to the operator's primary withdrawal address, as usual. The remainder shall be sent to the Smoothing Pool, and a global counter called `protocolShare` shall be incremented by the amount. |
There was a problem hiding this comment.
Keep in mind that with Saturn 2, there could be a new component (for example to burn). Does it make sense to route that through smoothing pool as well?
|
|
||
| 2) When iterating the nodes that are members of the smoothing pool, each minipool will receive attestation scores in the same manner as v8/v9/v10. | ||
|
|
||
| 3) When iterating the nodes that are members of the smoothing pool, each megapool will receive attestation scores based on the fixed commission defined in RPIP-46 and RPIP-72. The node's score will be incremented to reflect `node_operator_commission_share + node_operator_commission_share_council_adder`, and a global counter will track the scores assigned to `protocolShare`, in the same way that `reth_share` is tracked. Scores will be scaled linearly to normalize for balances higher than 32 eth, such that the scores for a megapool with 64 total eth balance shall be twice the score for a minipool. |
There was a problem hiding this comment.
Scores will be scaled linearly to normalize for balances higher than 32 eth, such that the scores for a megapool with 64 total eth balance shall be twice the score for a minipool.
I'm confused. If a megapool has 2 validators (64 ETH), they will be getting twice the attestations, right? Why do we need to scale scores?
|
|
||
| 3) When iterating the nodes that are members of the smoothing pool, each megapool will receive attestation scores based on the fixed commission defined in RPIP-46 and RPIP-72. The node's score will be incremented to reflect `node_operator_commission_share + node_operator_commission_share_council_adder`, and a global counter will track the scores assigned to `protocolShare`, in the same way that `reth_share` is tracked. Scores will be scaled linearly to normalize for balances higher than 32 eth, such that the scores for a megapool with 64 total eth balance shall be twice the score for a minipool. | ||
|
|
||
| 4) The final scores will be used to determine how much of the non-protocol-share ETH (`balance - protocolShare`) goes to rETH, to node operators, and to UARS. |
There was a problem hiding this comment.
As used in RPIP-46, UARS is the concept of having all these different dynamic shares, including no_share, voter_share, pdao_share, ...
I think you may use UARS to refer to the new share that may come with Saturn 2? If not, I'm not sure what you are saying here and in 5).
2 participants
No description provided.