Closed insumity closed 3 months ago
[!WARNING]
Rate limit exceeded
@insumity has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 5 minutes and 40 seconds before requesting another review.
How to resolve this issue?
After the wait time has elapsed, a review can be triggered using the `@coderabbitai review` command as a PR comment. Alternatively, push new commits to this PR. We recommend that you space out your commits to avoid hitting the rate limit.How do rate limits work?
CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our [FAQ](https://coderabbit.ai/docs/faq) for further information.Commits
Files that changed from the base of the PR and between 395409128f29dee730d5d9103f0cf18067bb1b7b and d28aba5493be187c2654794f46f9f69184c1d76d.
This update introduces a new parameter, NumberOfEpochsToStartReceivingRewards
, which delays reward distribution to validators until they have been validating for a specified number of blocks. The integration also encompasses adjustments to documentation, tests, and migration scripts to incorporate this parameter and ensure the system correctly reflects validation duration in reward allocations.
Files | Change Summary |
---|---|
.changelog/unreleased/improvements/provider/... |
Added a summary for changes related to distributing rewards to long-term validating validators. |
.changelog/unreleased/state-breaking/provider/... |
Summarized state-breaking changes related to reward distribution based on validation duration. |
docs/docs/validators/withdraw_rewards.md |
Updated title and added warning about validator reward eligibility based on validation duration. |
proto/interchain_security/ccv/provider/v1/provider.proto |
Introduced new fields in Params and ConsumerValidator messages for reward eligibility and validator height. |
tests/integration/distribution.go |
Renamed and added functions to test reward allocation among validators with different heights. |
x/ccv/provider/keeper/distribution.go |
Added IsEligibleForConsumerRewards function and integrated it into reward allocation and total power computation. |
x/ccv/provider/keeper/distribution_test.go |
Added tests for IsEligibleForConsumerRewards and setting of BlocksPerEpoch parameter in total power computation. |
x/ccv/provider/keeper/relay_test.go |
Added a test to ensure consumer validator heights are maintained during packet queuing. |
x/ccv/provider/migrations/migrator.go |
Updated Migrate5to6 function to call new migration functions for parameters and minimum power. |
x/ccv/provider/migrations/v6/migration_test.go |
Added test to verify parameter migration related to epochs. |
x/ccv/provider/migrations/v6/migrations.go |
Added new function for migrating provider chain parameters. |
x/ccv/provider/types/params.go |
Added and validated new parameter NumberOfEpochsToStartReceivingRewards in Params struct along with default values and key constants. |
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Description
Closes: (partially) https://github.com/cosmos/interchain-security/issues/1926 and https://github.com/informalsystems/interchain-security/issues/27
Problem A validator might opt in to a consumer chain simply to retrieve rewards without validating the consumer chain for too long.
Solution We introduce a
height
field inConsumerValidator
s. Thisheight
corresponds to the block height of the provider chain when the consumer validator first became a consumer validator. The setheight
of aConsumerValidator
remains stable as long as the validator remains a consumer validator. Theheight
of aConsumerValidator
only resets if a validator stops being a consumer validator and later becomes again a consumer validator.We introduce a new param
NumberOfEpochsToStartReceivingRewards
and a validator can only start receiving rewards after being a consumer validator forNumberOfEpochsToStartReceivingRewards
epochs or afterNumberOfEpochsToStartReceivingRewards * BlocksPerEpoch
blocks.Note that at the beginning of a provider chain (e.g., when the block height of the provider is still small), no validator could have been a consumer validator for more than
NumberOfEpochsToStartReceivingRewards
epochs and hence in this case we distribute rewards to validators, even though they might have not been validating the consumer chain for more than a single epoch.Finally, note that in a consumer chain that just starts, no validator would receive rewards during the first
NumberOfEpochsToStartReceivingRewards
epochs. During this time, any rewards sent to the provider from the consumer chain through IBC transfers will be allocated to the community pool.Testing Two main things are being tested:
height
of a consumer validator is not being reset if the validator remains a consumer validator (unit testTestQueueVSCPacketsDoesNotResetConsumerValidatorsHeights
);TestAllocateTokensToConsumerValidatorsWithDifferentValidatorHeights
).Author Checklist
All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.
I have...
!
to the type prefix if the change is state-machine breakingCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.
I have...
!
the type prefix if the change is state-machine breakingSummary by CodeRabbit
New Features
NumberOfEpochsToStartReceivingRewards
, to configure reward eligibility.Documentation
Tests
Migration