-
Notifications
You must be signed in to change notification settings - Fork 594
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Feat(stateless-validation): Rewards for stateless validators (#11121)
The goal of this PR is to give rewards to stateless validators (validators which do not produce blocks or chunks but do validate chunks by producing endorsements). This means updating `EpochInfoAggregator` to track the expected number of endorsements for each validator as well as how many were actually produced. For the MVP we are not actually tracking endorsements directly, instead we assume that if a chunk was included in a block then all stateless validators for that shard should be rewarded (because there must have been a sufficient number of endorsements for the block producer to include the chunk). However, this logic will need to be iterated on in future versions of the stateless validation protocol. Additionally, the reward calculator required updating to use the new endorsement stats as part of the uptime calculation which forms the basis of the rewards. Both of those changes are relatively minor. The technical snag in all of this is that the `EpochInfoAggregator` and other structures related to validator stats are persisted in the node state via borsh serialization. ~To avoid a large database migration, I have made this update backwards compatible with the old format without the endorsement stats. The logic for this is in `core/primitives/src/types/chunk_validator_stats.rs`. The legacy variant is distinguished from the new one in the serialization by serializing the one's compliment of the `u64` values for the new variant. During deserialization we check if the first `u64` is larger than 2^32 - 1 or not. If it is larger then we assume the value is actually a one's compliment and proceed with the new variant deserialization, and otherwise we do the legacy deserialization.~ ~This means that the serialized values can be interpreted improperly if 2^32 (4.29 billion) or more chunks are produced by a single validator during one epoch. I do not expect this to be an issue, but it is a limitation worth documenting.~ @Longarithm told me that the DB migration is actually fine here because it's not that much data. So the DB migration of the `EpochValidatorInfo` column is also implemented.
- Loading branch information
Showing
12 changed files
with
615 additions
and
106 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.