-
Notifications
You must be signed in to change notification settings - Fork 108
Mf/generate pos leader schedules #538
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mf/generate pos leader schedules #538
Conversation
lib/pos_leader_schedule.go
Outdated
| } | ||
|
|
||
| // Retrieve top, active validators ordered by stake. | ||
| validatorEntries, err := bav.GetTopActiveValidatorsByStake(int(bav.Params.LeaderScheduleMaxNumValidators)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never use int. Always be clear about the size of the int by using int32 or int64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in: #540.
lib/pos_leader_schedule.go
Outdated
| } | ||
|
|
||
| // Retrieve top, active validators ordered by stake. | ||
| validatorEntries, err := bav.GetTopActiveValidatorsByStake(int(bav.Params.LeaderScheduleMaxNumValidators)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: Need to make sure that this function returns the top validators in a deterministic order. If it has any non-determinism in it, then nodes will have different leader schedules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the tests so that they run GenerateLeaderSchedule() 10x times for each CurrentRandomSeedHash. It generates the same LeaderSchedule each time. I then repeat that process with 7x different CurrentRandomSeedHashes, generating different LeaderSchedules each time. With those tests, I'm fairly confident in this algorithm's determinism.
lib/pos_leader_schedule.go
Outdated
| // Take RandomUint256 modulo TotalStakeAmountNanos. | ||
| // For each ValidatorEntry: | ||
| // Skip if ValidatorPKID has already been added to the leader schedule. | ||
| // If ValidatorEntry.TotalStakeAmountNanos >= RandomUint256: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment is incorrect. You're tracking the SUM of the TotalStakeAmountNanos.
| } | ||
|
|
||
| // Take RandomUint256 % TotalStakeAmountNanos. | ||
| randomUint256 := uint256.NewInt().Mod(currentRandomSeedHash.ToUint256(), totalStakeAmountNanos) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: Make sure Mod is efficient. I'm almos certain it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| } | ||
| } | ||
|
|
||
| return leaderSchedule, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems pretty clean. Good work!
No description provided.