Skip to content
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

docs(x/staking): update readme #22216

Merged
merged 1 commit into from
Oct 10, 2024
Merged

docs(x/staking): update readme #22216

merged 1 commit into from
Oct 10, 2024

Conversation

JulianToledano
Copy link
Contributor

@JulianToledano JulianToledano commented Oct 10, 2024

Description

Ref:
#21429


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...

  • included the correct type prefix in the PR title, you can find examples of the prefixes below:
  • confirmed ! in the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • reviewed "Files changed" and left comments if necessary
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • updated the relevant documentation or specification, including comments for documenting Go code
  • confirmed all CI checks have passed

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.

Please see Pull Request Reviewer section in the contributing guide for more information on how to review a pull request.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic, API design and naming, documentation is accurate, tests and test coverage

Summary by CodeRabbit

  • Documentation

    • Enhanced clarity and accessibility of the staking module documentation.
    • Updated descriptions for state management and data structures.
    • Added a new validation function for the PowerReduction parameter.
  • Bug Fixes

    • Improved validation checks to ensure parameters meet required conditions.

@JulianToledano JulianToledano added the backport/v0.52.x PR scheduled for inclusion in the v0.52's next stable release label Oct 10, 2024
Copy link
Contributor

coderabbitai bot commented Oct 10, 2024

📝 Walkthrough

Walkthrough

The pull request introduces significant updates to the x/staking module documentation and code. It simplifies the data structures for state variables, changing them from complex ProtocolBuffer representations to more straightforward numerical formats. Key variables like LastTotalPower, UnbondingID, and Params have been modified. Additionally, the indexing scheme for validators has been updated, and new functions for validation have been added in the params.go file. Overall, these changes aim to enhance clarity and maintainability of the staking module's documentation and functionality.

Changes

File Path Change Summary
x/staking/README.md Updated documentation on state management and data structures; simplified variable types and indexing schemes for LastTotalPower, UnbondingID, and Params; refined state transition sections for clarity.
x/staking/types/params.go Added ValidatePowerReduction function; updated comments for DefaultMaxValidators, DefaultMaxEntries, MustUnmarshalParams, UnmarshalParams, and Validate method to improve clarity and documentation.

Possibly related PRs

  • refactor: decouple comet from modules #21382: This PR discusses the removal of historical information querying functionality within the staking module, which relates to the changes in state management and data structures in the main PR.
  • chore(x/staking): revert proto breakage #21666: This PR reverts changes that caused breakage in the staking module, which is relevant to the updates in state variables and structures in the main PR.
  • test: e2e/staking to system tests #21882: This PR enhances the staking system tests to include checks for validator updates, which aligns with the main PR's focus on state transitions and validator status changes.
  • docs: remove invariants #22126: This PR discusses the removal of invariants, which may relate to the simplification of state management in the main PR.
  • docs: pre,begin,end block #22127: This PR updates documentation regarding the lifecycle methods in the Cosmos SDK, which is relevant to the changes in state management and transitions in the main PR.

Suggested labels

C:x/staking

Suggested reviewers

  • julienrbrt
  • akhilkumarpilli
  • tac0turtle

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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (20)
x/staking/types/params.go (2)

25-26: LGTM: Enhanced constant documentation with a minor suggestion

The updated comment for DefaultMaxEntries provides a more detailed explanation of the constant's purpose, including the full meaning of the acronyms UBD and RED. This improvement aligns with best practices for code documentation.

Consider adding a brief explanation of what a "pair" means in this context for even greater clarity.


Line range hint 185-196: LGTM: Well-implemented new validation function

The new ValidatePowerReduction function is a good addition to the existing validation functions. It properly checks the type and value of the input, returning appropriate error messages for invalid cases.

Consider using a constant for the minimum allowed value (1) to improve maintainability. For example:

const MinPowerReduction = 1

// In the function
if v.LT(math.NewInt(MinPowerReduction)) {
    return fmt.Errorf("power reduction cannot be lower than %d", MinPowerReduction)
}
x/staking/README.md (18)

72-72: Update LastTotalPower description for clarity

The description of LastTotalPower has been updated to use a new storage prefix. Consider adding a brief explanation of why this change was made and its implications.

Consider updating the line to:

* LastTotalPower: `collections.NewPrefix(18)` // Stores the last total power value

78-78: Clarify UnbondingID storage and usage

The UnbondingID description has been updated with a new storage value. It would be helpful to explain the significance of this change and how it affects the unbonding process.

Consider expanding the description:

* UnbondingID: `55` // Stores the latest unbonding operation ID, used to create unique IDs for unbonding operations

85-85: Update Params storage description

The Params storage has been simplified. It would be beneficial to explain why this change was made and its impact on the module's functionality.

Consider updating the line to:

* Params: `81` // Stores the staking module parameters

120-124: Review and update Validators storage descriptions

The storage prefixes for various validator-related data have been updated. Ensure that these changes are consistent with the actual implementation and explain their purpose.

Consider adding brief explanations for each storage prefix:

* Validators: `33 | OperatorAddrLen (1 byte) | OperatorAddr -> ProtocolBuffer(validator)` // Stores validator data
* ValidatorsByConsAddr: `34 | ConsAddrLen (1 byte) | ConsAddr -> OperatorAddr` // Maps consensus address to operator address
* ValidatorsByPower: `23 | BigEndian(ConsensusPower) | OperatorAddrLen (1 byte) | OperatorAddr -> OperatorAddr` // Indexes validators by power
* LastValidatorsPower: `17 | OperatorAddrLen (1 byte) | OperatorAddr -> ProtocolBuffer(ConsensusPower)` // Stores the last known power for each validator
* UnbondingIndex: `56 | UnbondingID ->  21 | OperatorAddrLen (1 byte) | OperatorAddr` // Maps unbonding IDs to validator addresses

131-132: Clarify UnbondingIndex usage

The description of UnbondingIndex is new and might benefit from more context about its purpose and how it's used in the unbonding process.

Consider expanding the description:

`UnbondingIndex` is an additional index that enables lookups for
validators by the unbonding IDs corresponding to their current unbonding. This helps in tracking and managing the unbonding process more efficiently.

166-166: Update Delegation storage prefix

The storage prefix for Delegation has been updated. Ensure this change is consistent with the implementation and explain its significance.

Consider updating the line to:

* Delegation: `49 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValidatorAddrLen (1 byte) | ValidatorAddr -> ProtocolBuffer(delegation)` // Stores delegation information

204-206: Review and update UnbondingDelegation storage descriptions

The storage prefixes for unbonding delegations have been updated, and a new UnbondingIndex has been added. Ensure these changes are consistent with the implementation and explain their purpose.

Consider adding brief explanations for each storage prefix:

* UnbondingDelegation: `50 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValidatorAddrLen (1 byte) | ValidatorAddr -> ProtocolBuffer(unbondingDelegation)` // Stores unbonding delegation data
* UnbondingDelegationByValIndex: `51 | ValidatorAddrLen (1 byte) | ValidatorAddr | DelegatorAddrLen (1 byte) | DelegatorAddr -> nil` // Index for querying unbonding delegations by validator
* UnbondingIndex: `56 | UnbondingId -> 0x32 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValidatorAddrLen (1 byte) | ValidatorAddr` // Maps unbonding IDs to unbonding delegations

210-214: Clarify usage of UnbondingDelegationByValIndex and UnbondingIndex

The descriptions of UnbondingDelegationByValIndex and UnbondingIndex are new and might benefit from more context about their purpose and how they're used in the unbonding process.

Consider expanding the descriptions:

`UnbondingDelegationByValIndex` is used in slashing, to look up all
unbonding delegations associated with a given validator that need to be
slashed. This index improves the efficiency of the slashing process.

`UnbondingIndex` is an additional index that enables
lookups for unbonding delegations by the unbonding IDs of the containing
unbonding delegation entries. This helps in tracking and managing the unbonding process more efficiently.
🧰 Tools
🪛 LanguageTool

[grammar] ~210-~210: The word “lookup” is a noun. The verb is spelled with a white space.
Context: ...tionByValIndex` is used in slashing, to lookup all unbonding delegations associated w...

(NOUN_VERB_CONFUSION)


235-238: Review and update Redelegation storage descriptions

The storage prefixes for redelegations have been updated, and a new RedelegationByUnbondingId has been added. Ensure these changes are consistent with the implementation and explain their purpose.

Consider adding brief explanations for each storage prefix:

* Redelegations: `52 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValidatorAddrLen (1 byte) | ValidatorSrcAddr | ValidatorDstAddrLen (1 byte) | ValidatorDstAddr -> ProtocolBuffer(redelegation)` // Stores redelegation data
* RedelegationsByValSrc: `53 | ValidatorSrcAddrLen (1 byte) | ValidatorSrcAddr | ValidatorDstAddrLen (1 byte) | ValidatorDstAddr | DelegatorAddrLen (1 byte) | DelegatorAddr -> nil` // Index for querying redelegations by source validator
* RedelegationsByValDst: `54 | ValidatorDstAddrLen (1 byte) | ValidatorDstAddr | ValidatorSrcAddrLen (1 byte) | ValidatorSrcAddr | DelegatorAddrLen (1 byte) | DelegatorAddr -> nil` // Index for querying redelegations by destination validator
* RedelegationByUnbondingId: `56 | UnbondingId -> 0x34 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValidatorAddrLen (1 byte) | ValidatorSrcAddr | ValidatorDstAddr` // Maps unbonding IDs to redelegations

243-251: Clarify usage of RedelegationsByValSrc, RedelegationsByValDst, and RedelegationByUnbondingId

The descriptions of these indices have been updated or added. Provide more context about their purpose and how they're used in the redelegation process.

Consider expanding the descriptions:

`RedelegationsByValSrc` is used for slashing based on the `ValidatorSrcAddr`. This index allows efficient lookup of redelegations that need to be slashed when the source validator is penalized.

`RedelegationsByValDst` is used for slashing based on the `ValidatorDstAddr`. This index allows efficient lookup of redelegations that need to be considered when the destination validator is penalized.

`RedelegationByUnbondingId` is an additional index that enables
lookups for redelegations by the unbonding IDs of the containing
redelegation entries. This helps in tracking and managing the redelegation process more efficiently, especially when coordinating with the unbonding process.
🧰 Tools
🪛 LanguageTool

[style] ~245-~245: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...atorSrcAddr. RedelegationsByValDstis used for slashing based on theValidat...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[grammar] ~247-~247: The word “lookup” is a noun. The verb is spelled with a white space.
Context: ... first map here is used for queries, to lookup all redelegations for a given delegator...

(NOUN_VERB_CONFUSION)


320-320: Update UnbondingQueue storage prefix

The storage prefix for UnbondingQueue has been updated. Ensure this change is consistent with the implementation and explain its significance.

Consider updating the line to:

* UnbondingQueue: `65 | format(time) -> []DVPair` // Stores the queue of unbonding delegations

331-331: Update RedelegationQueue storage prefix

The storage prefix for RedelegationQueue has been updated. Ensure this change is consistent with the implementation and explain its significance.

Consider updating the line to:

* RedelegationQueue: `66 | format(time) -> []DVVTriplet` // Stores the queue of redelegations

342-342: Update ValidatorQueue storage prefix

The storage prefix for ValidatorQueue has been updated. Ensure this change is consistent with the implementation and explain its significance.

Consider updating the line to:

* ValidatorQueue: `67 | format(time) -> []sdk.ValAddress` // Stores the queue of unbonding validators

Line range hint 351-365: Add description for ValidatorConsensusKeyRotationRecordQueueKey

A new section has been added for ValidatorConsensusKeyRotationRecordQueueKey. This is an important addition that should be explained clearly.

Consider restructuring this section for clarity:

#### ValidatorConsensusKeyRotationRecordQueueKey

For the purpose of tracking progress of consensus pubkey rotations, the `ValidatorConsensusKeyRotationRecordQueueKey` is kept.

* ValidatorConsensusKeyRotationRecordQueueKey: `103 | format(time) -> types.ValAddrsOfRotatedConsKeys`

This queue serves the following purposes:
1. It acts as a unique identifier in the queue, representing a future time (calculated by adding the current block time to the unbonding period).
2. When a new item with the same waiting time enters the queue, the system retrieves the current store information, appends the `ValAddress` to the array, and updates the store.

The stored object is defined as follows:

```protobuf reference
https://github.com/cosmos/cosmos-sdk/blob/release/v0.52.x/x/staking/proto/cosmos/staking/v1beta1/staking.proto#L420-L424

This mechanism ensures efficient tracking and management of consensus pubkey rotations over time.


---

`401-401`: **Clarify the transition from unbonding to unbonded**

The description of the transition from unbonding to unbonded state could be clearer.


Consider rewording this line for clarity:
```markdown
A validator transitions from unbonding to unbonded state when the `ValidatorQueue` entry for this validator matures (i.e., the unbonding period has passed).

423-423: Clarify the delegation process

The description of the delegation process could be more detailed to provide a clearer understanding of what happens during delegation.

Consider expanding this section:

When a delegation occurs, both the validator and the delegation objects are affected. The process involves the following steps:
1. Calculate the delegator's shares based on the tokens delegated and the validator's current exchange rate.
2. Remove the delegated tokens from the delegator's account.
3. Add the calculated shares to the delegation object, or create a new delegation object if it doesn't exist.
4. Update the validator object with the new delegator shares.
5. Transfer the `delegation.Amount` from the delegator's account to the appropriate pool (`BondedPool` or `NotBondedPool`) based on the validator's status.
6. Update the `ValidatorByPowerIndex` to reflect the changes in the validator's total delegated tokens.

Line range hint 555-582: Add description for ConsPubkeyRotation

A new section has been added for ConsPubkeyRotation. This is an important addition that should be explained clearly.

Consider restructuring this section for clarity:

## ConsPubkeyRotation

The `ConsPubkey` of a validator can be instantly rotated to a new `ConsPubkey`. This rotation is tracked to allow only a limited number of rotations within an unbonding period.

`ConsPubkeyRotation` data is indexed in the store as follows:

* ValidatorConsPubKeyRotationHistoryKey: `101 | valAddr | rotatedHeight -> ProtocolBuffer(ConsPubKeyRotationHistory)`
* BlockConsPubKeyRotationHistoryKey (index): `102 | rotatedHeight | valAddr | -> ProtocolBuffer(ConsPubKeyRotationHistory)`
* ValidatorConsensusKeyRotationRecordQueueKey: `103 | format(time) -> ProtocolBuffer(ValAddrsOfRotatedConsKeys)`
* ValidatorConsensusKeyRotationRecordIndexKey: `104 | valAddr | format(time) -> ProtocolBuffer([]Byte{})`
* OldToNewConsAddrMap: `105 | byte(oldConsAddr) -> byte(newConsAddr)`
* ConsAddrToValidatorIdentifierMap: `106 | byte(newConsAddr) -> byte(initialConsAddr)`

These indices serve the following purposes:
- `ConsPubKeyRotationHistory` is used for querying the rotation history of a validator.
- `ValidatorConsensusKeyRotationRecordQueueKey` tracks rotations across the unbonding period and is pruned after the waiting period.
- `ValidatorConsensusKeyRotationRecordIndexKey` keeps track of how many rotations a validator has made within the unbonding period and is pruned after the waiting period.
- `OldToNewConsAddrMap` is updated for every rotation to handle evidences submitted with old consensus keys.
- `ConsAddrToValidatorIdentifierMap` is updated for every rotation to prevent validators from rotating to a consensus key that has been used in the past.

To prevent spam:
- There is a limit on the number of rotations allowed within the unbonding period.
- A non-negligible fee is deducted for rotating a consensus key.

This mechanism ensures the integrity and security of the consensus process while allowing validators to update their keys when necessary.

207-207: Address grammar issues with "lookup" usage

The word "lookup" is used as a verb in several places, but it's grammatically incorrect. It should be "look up" when used as a verb.

Consider updating the following lines:

  • Line 207: "...is used in queries, to look up all unbonding delegations for..."
  • Line 210: "...is used in slashing, to look up all unbonding delegations associated with..."
  • Line 240: "...is used for queries, to look up all redelegations for a given delegator..."
  • Line 247: "The first map here is used for queries, to look up all redelegations for a given delegator..."

Also applies to: 210-210, 240-240, 247-247

🧰 Tools
🪛 LanguageTool

[grammar] ~207-~207: The word “lookup” is a noun. The verb is spelled with a white space.
Context: ...ndingDelegation` is used in queries, to lookup all unbonding delegations for a given ...

(NOUN_VERB_CONFUSION)

📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 3a03804 and d4e65d1.

📒 Files selected for processing (2)
  • x/staking/README.md (16 hunks)
  • x/staking/types/params.go (5 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
x/staking/README.md (1)

Pattern **/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"

x/staking/types/params.go (1)

Pattern **/*.go: Review the Golang code for conformity with the Uber Golang style guide, highlighting any deviations.

🪛 LanguageTool
x/staking/README.md

[grammar] ~207-~207: The word “lookup” is a noun. The verb is spelled with a white space.
Context: ...ndingDelegation` is used in queries, to lookup all unbonding delegations for a given ...

(NOUN_VERB_CONFUSION)


[grammar] ~210-~210: The word “lookup” is a noun. The verb is spelled with a white space.
Context: ...tionByValIndex` is used in slashing, to lookup all unbonding delegations associated w...

(NOUN_VERB_CONFUSION)


[grammar] ~240-~240: The word “lookup” is a noun. The verb is spelled with a white space.
Context: ...Redelegations is used for queries, to lookup all redelegations for a given delegato...

(NOUN_VERB_CONFUSION)


[style] ~245-~245: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...atorSrcAddr. RedelegationsByValDstis used for slashing based on theValidat...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[grammar] ~247-~247: The word “lookup” is a noun. The verb is spelled with a white space.
Context: ... first map here is used for queries, to lookup all redelegations for a given delegator...

(NOUN_VERB_CONFUSION)

🔇 Additional comments (2)
x/staking/types/params.go (2)

22-22: LGTM: Improved constant documentation

The updated comment for DefaultMaxValidators provides a clearer description of the constant's purpose, which aligns with best practices for code documentation.


67-67: LGTM: Improved function documentation

The updated comments for MustUnmarshalParams and UnmarshalParams provide more accurate descriptions of the functions' behavior. The comment for MustUnmarshalParams now correctly indicates that it may panic, which is important information for users of this function.

Also applies to: 77-77

@julienrbrt julienrbrt added this pull request to the merge queue Oct 10, 2024
Merged via the queue into main with commit db6a835 Oct 10, 2024
81 of 82 checks passed
@julienrbrt julienrbrt deleted the julian/docs-staking-v0.52 branch October 10, 2024 13:06
mergify bot pushed a commit that referenced this pull request Oct 10, 2024
julienrbrt pushed a commit that referenced this pull request Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport/v0.52.x PR scheduled for inclusion in the v0.52's next stable release C:x/staking
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants