SIMD-0232: Custom Commission Collector Account#232
Conversation
jstarry
changed the title
jstarry
force-pushed
the
block-fee-collection
branch
5 times, most recently
from
de734ee to
436083d
Compare
|
how does this work with SIMD-0123? would a % of the PDA funds get sent to stakers? what if the PDA subtracts the lamports half way through the epoch? |
|
@topointon-jump and I were thinking of this as an alternative approach to solving SIMD-0123 by first allowing collection into a custom address and then later providing a cranking mechanism in another SIMD to distribute the funds. But I think we've agreed to go with SIMD-0123 for now since the cranking mechanism design needs to be thought out and would probably be a sizable change on its own. |
|
how does 123 preclude this simd? |
|
oh i think i'd prefer that the changes not be combined. this is desirable even without 123 |
jstarry
force-pushed
the
block-fee-collection
branch
from
436083d to
32607e1
Compare
jstarry
changed the title
buffalojoec
left a comment
buffalojoec
left a comment
There was a problem hiding this comment.
Note that this proposal is listed as an alternative in SIMD-123, with drawbacks highlighted, but the roadmap shared in Discord reflects SIMD-232 as incrementally leading up to SIMD-123.
| The designated commission collector must either be equal to the vote account's | ||
| address OR satisfy the following constraints: | ||
|
|
||
| 1. Must be a system program owned account |
There was a problem hiding this comment.
The motivation explicitly states that validators cannot use program-derived addresses, thus on-chain programs, for revenue distribution. This constraint preserves that limitation.
There was a problem hiding this comment.
No it definitely removes the limitation despite not allowing non system owned accounts. Onchain programs will be able to create system owned pda's for the collector accounts.
There was a problem hiding this comment.
What's the rationale for the System program ownership?
There was a problem hiding this comment.
Trying to minimize the surface area of possible account state changes the runtime can do outside of the SVM. By limiting to system program ownership, we implicitly make it impossible to do things like collect your commission into the system program account or some other unexpected place.
There was a problem hiding this comment.
im a little confused here. by allowing system program, won't you give up programmatic control of the fees?
There was a problem hiding this comment.
Onchain programs will be able to create system owned pda's for the collector accounts.
There was a problem hiding this comment.
Ok, this works for me. The only thing that's left off the table is some PDA that must carry data, which would be owned by the user program still. I think that's ok, since programs can work around that limitation programmatically before providing a PDA signature.
It's also more performant to ensure the owner is System, rather than go through some handful of constraints like reserved account keys or multiple disallowed owners.
Yeah thanks for calling it out, I need to clean up SIMD-123 with the latest updates to the rollout plan. |
| The designated commission collector must either be equal to the vote account's | ||
| address OR satisfy the following constraints: | ||
|
|
||
| 1. Must be a system program owned account |
There was a problem hiding this comment.
Ok, this works for me. The only thing that's left off the table is some PDA that must carry data, which would be owned by the user program still. I think that's ok, since programs can work around that limitation programmatically before providing a PDA signature.
It's also more performant to ensure the owner is System, rather than go through some handful of constraints like reserved account keys or multiple disallowed owners.
| For a given epoch `E`, the earned inflation rewards for each vote account are | ||
| calculated at the beginning of the next epoch `E + 1`. This proposal doesn't | ||
| change the commission calculation but it does define new rules for how the | ||
| calculated commission rewards are collected into an account. Rather than | ||
| collecting the inflation rewards commission into the vote accounts by default, | ||
| the protocol must fetch the inflation rewards commission collector address from | ||
| the vote account state at the beginning of epoch `E + 1`. This is the same | ||
| vote account state used to get the commission rate and latest vote credits | ||
| for inflation rewards calculation. |
There was a problem hiding this comment.
Sorry to raise this now, but could we avoid having to cache the commission collector account across epochs? Cross-pasting from a discussion in #consensus:
Data that needs to be persisted for business logic operations such as paying rewards out, should be persisted on-chain and not solely in a cache that each client has to re-create on re-start. If a particular client wants to add a cache then they obviously are able to, but falling back to on-chain data should always be an option.
Two questions:
- Do we need to use older versions of this field? Can't we just use the current commission collector account in the vote state at the point of the rewards payout slot? Is there a good reason not to do this?
- If we do need to use the collector account from previous epochs, could we store this data on-chain, possibly in a PDA keyed by epoch? This would make implementing this much easier.
Thank-you so much, and again sorry for not raising this before.
There was a problem hiding this comment.
Do we need to use older versions of this field? Can't we just use the current commission collector account in the vote state at the point of the rewards payout slot? Is there a good reason not to do this?
Part of the design of this SIMD was done with the idea that some validators will implement their own reward distribution mechanisms using these collector accounts. I feel it's best to not allow rugging those custom reward mechanisms by enforcing a few epoch's delay before applying new collector accounts. This is similar to the idea of avoiding commission rugs by delaying commission rate updates.
If we do need to use the collector account from previous epochs, could we store this data on-chain, possibly in a PDA keyed by epoch? This would make implementing this much easier.
As discussed in #consensus in Discord, we should definitely move to storing this data onchain but it's a reasonably large effort so I think it's best to tackle that later and not delay shipping SIMD-0123.
There was a problem hiding this comment.
Agreed in the discord chat, shipping SIMD-0123 is the priority - approved this SIMD. Having a long-term plan to move this data on-chain is awesome though.
8 participants
No description provided.