SIMD-0180: Use Vote Account Address To Key Leader Schedule#180
Conversation
jstarry
changed the title
jstarry
force-pushed
the
leader-schedule-migration
branch
from
b14c2bf to
deccb77
Compare
| up by first finding the vote account for the designated vote pubkey for a | ||
| particular leader slot in bank epoch stakes. Bank epoch stakes are keyed by | ||
| leader schedule epoch and therefore the vote account state should be retrieved | ||
| by looking up the epoch stakes for the current epoch. Since only valid vote |
There was a problem hiding this comment.
Confirming my understanding that this shouldn't cause an issue at epoch boundary:
Since the leader schedule is generated an epoch before, if we receive a shred from epoch E + 1, we can still use the root bank from epoch E to perform the vote account -> node pubkey lookup.
There was a problem hiding this comment.
That's correct. We can only validate shreds for epoch E + 1 once we have a root bank in epoch E
t-nelson
left a comment
t-nelson
left a comment
There was a problem hiding this comment.
i find the repeated "migration" reminders and back references to current implementation break the flow of the text and make it difficult to follow
that we're migrating is implicit from the nature of the proposed changes
there are only a few places where i find the existing implementation references helpful
- retaining the random draw algo
- shred signer
- collector address
- rpc suggestions
throughout are instances of our trademark ambiguous use of "pubkey." i think most here should be "account address" with exception of the places where we are talking about cryptographic signing/verification.
there are also several usages of "should" throughout that suggest optionality of details that are in fact requirements. most should(lol) be "must" as per rfc2119
assuming i read everything correctly, the proposed protocol changes themselves are correct and well motivated
| @@ -0,0 +1,91 @@ | |||
| --- | |||
| simd: '0180' | |||
| title: Leader Schedule Migration | |||
There was a problem hiding this comment.
title isn't particularly explanatory
| title: Leader Schedule Migration | |
| title: Use Vote Account Address To Key Leader Schedule |
| vote pubkey. Then use the existing stake weighted randomized leader schedule | ||
| generation using vote pubkeys and their delegated stake rather than node id | ||
| pubkeys and the accumulated delegated stake across (potentially more than one) | ||
| vote accounts. As before, only valid and initialized vote accounts should be |
There was a problem hiding this comment.
do we include any of the old vote state versions as "valid"? are validity criteria documented somewhere that we can link out to?
There was a problem hiding this comment.
I added a section for this.. we don't explicitly check vote state version for the initialization check. We just check the size of the account and whether there are some non-zero bytes. Less than ideal for sure but out of scope for this SIMD.
jstarry
changed the title
jstarry
force-pushed
the
leader-schedule-migration
branch
from
deccb77 to
43508cd
Compare
|
@t-nelson thanks for the feedback, addressed your comments I think. Can you take another look? |
This comment was marked as spam.
This comment was marked as spam.
|
@jstarry Does this SIMD change anything at all? Before, identities are determined when the leader schedule was derived. |
|
I see now, this defines a clear slot -> vote account leader mapping, even if it barely touches the slot -> validator identity mapping. |
Yeah, exactly. And the validator identity should be looked up from the vote account state at the beginning of the previous epoch |
7 participants
No description provided.