Add a "Wish for Change" Track #4
Closed
Conversation
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
<!-- Remember that you can run `/merge` to enable auto-merge in the PR --> <!-- Remember to modify the changelog. If you don't need to modify it, you can check the following box. Instead, if you have already modified it, simply delete the following line. --> Will be needed for enabling the fix for paritytech/polkadot-sdk#3144 (unbricking paraids which acquire multiple cores via coretime). Will also be needed in the future for enabling other features, like paritytech/polkadot-sdk#1644 and paritytech/polkadot-sdk#628 --------- Signed-off-by: alindima <[email protected]> Co-authored-by: Bastian Köcher <[email protected]>
WalkthroughThe recent updates introduce a new "Wish for Change" track across the Kusama and Polkadot networks, enhancing governance mechanisms. Additionally, the parachains runtime API has been upgraded to version 9 in Kusama, enabling the Changes
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? TipsChatThere are 3 ways to chat with CodeRabbit:
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 as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (7)
- CHANGELOG.md (2 hunks)
- integration-tests/emulated/chains/src/lib.rs (1 hunks)
- relay/kusama/src/governance/origins.rs (2 hunks)
- relay/kusama/src/governance/tracks.rs (3 hunks)
- relay/kusama/src/lib.rs (3 hunks)
- relay/polkadot/src/governance/origins.rs (2 hunks)
- relay/polkadot/src/governance/tracks.rs (3 hunks)
Additional comments: 12
relay/polkadot/src/governance/origins.rs (2)
- 64-65: The addition of the
WishForChangeorigin is correctly implemented and follows the existing codebase's patterns. Ensure that its integration with the broader governance framework is thoroughly audited to prevent unintended behaviors or security vulnerabilities.- 108-108: The inclusion of
WishForChangein thedecl_unit_ensures!macro is correctly implemented. It's crucial to conduct thorough testing and auditing to ensure its seamless integration with the governance framework.relay/kusama/src/governance/origins.rs (2)
- 89-90: The addition of the
WishForChangeorigin for Kusama is correctly implemented and follows the existing codebase's patterns. Ensure that its integration with the broader governance framework is thoroughly audited to prevent unintended behaviors or security vulnerabilities.- 133-133: The inclusion of
WishForChangein thedecl_unit_ensures!macro for Kusama is correctly implemented. It's crucial to conduct thorough testing and auditing to ensure its seamless integration with the governance framework.CHANGELOG.md (2)
- 15-15: The documentation of the new "Wish for Change" track in the changelog is clear and concise. Ensure that the documentation remains up to date with any further developments or adjustments to this feature.
- 24-24: The documentation of the bump in parachains runtime API to v9 in Kusama is clear and informative. It's important to provide detailed documentation for such critical updates to ensure developers and users fully understand the changes and their implications.
relay/polkadot/src/governance/tracks.rs (2)
- 97-110: The addition of the "wish_for_change" track with an ID of 2 introduces a new governance mechanism. It's crucial to ensure that the parameters set for this track, such as
max_deciding,decision_deposit,prepare_period,decision_period,confirm_period,min_enactment_period,min_approval, andmin_support, align with the intended governance dynamics for non-state-altering referenda. Given thatmin_approvalandmin_supportare reused from theAPP_ROOTandSUP_ROOT, confirm that this reuse accurately reflects the governance intentions for "wish_for_change" referenda, as these parameters are critical for the decision-making process.- 311-311: The handling of the new
WishForChangeorigin with an ID of 2 in thetrack_forfunction correctly maps the custom origin to the newly introduced track. This is essential for the governance framework to recognize and process referenda submitted under the "wish_for_change" track. Ensure that all other governance components and modules that interact with governance tracks are updated to recognize and appropriately handle this new origin.Verification successful
The search results confirm that the
WishForChangeorigin has been integrated into the governance framework of both Polkadot and Kusama. It is recognized as a valid origin within theorigins.rsfiles and is explicitly handled in thetracks.rsfiles, where it is assigned an ID of 2. Furthermore, the presence oftrack_forfunction implementations across various governance components suggests that these parts of the system are designed to work with governance tracks, including the newWishForChangeorigin. This verifies the integration of theWishForChangeorigin with other governance components as intended.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that other governance components recognize the new WishForChange origin. # This script is a placeholder for the actual verification commands that would be needed. echo "Verify integration with other governance components for WishForChange origin."Length of output: 164
Script:
#!/bin/bash # Search for references to WishForChange in the codebase to verify its integration with governance components. rg "WishForChange" --context 2 # Additionally, search for general governance track handling to see if there's explicit handling of the new origin. rg "track_for" --context 2Length of output: 3641
relay/kusama/src/governance/tracks.rs (2)
- 97-110: The addition of the "wish_for_change" track for Kusama follows the same pattern as in Polkadot, with adjustments to parameters like
decision_periodto reflect Kusama's faster governance cycle. It's important to ensure that these parameter values, includingmax_deciding,decision_deposit,prepare_period,confirm_period,min_enactment_period,min_approval, andmin_support, are tailored to Kusama's governance needs and expectations. The reuse ofAPP_ROOTandSUP_ROOTformin_approvalandmin_supportshould be specifically validated to ensure it aligns with the governance intentions for "wish_for_change" referenda on Kusama.- 311-311: The handling of the
WishForChangeorigin with an ID of 2 in Kusama'strack_forfunction is consistent with the implementation in Polkadot. This consistency is key for maintaining parallel governance mechanisms across both networks. As with Polkadot, ensure that all other governance components and modules in Kusama that interact with governance tracks are updated to recognize and appropriately handle this new origin.integration-tests/emulated/chains/src/lib.rs (1)
- 59-59: The update of the
api_versionfrom8to9for the Kusama struct is noted. It's crucial to ensure that this version change is compatible with all parts of the codebase that interact with the Kusama relay chain. Additionally, it may be necessary to update integration tests and documentation to reflect this change.relay/kusama/src/lib.rs (1)
- 1972-1974: The addition of the
node_features()function to theParachainHostruntime API is a significant enhancement. It's crucial to ensure that the implementation inparachains_vstaging_api_impl::node_features::<Runtime>()is efficient, secure, and follows best practices. Additionally, verify that this new API function does not introduce any breaking changes or incompatibilities with existing runtime logic.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Posting this PR for discussion, but perhaps people have other solutions in mind.
The Root track was designed to handle only one referendum at a time, because calls requiring Root are usually sensitive and should be evaluated one at a time. However, we have also used the Root track to make remarks to signal desires/wishes of the network to various bodies in the network (e.g. RFC-12, instructing the Fellowship to add a collective).
These statements do not execute any stateful logic that would affect the network, and in my opinion more than one could be evaluated at a time. These referenda should not hold up voting on proposals that actually do require Root, nor be forced to queue (for example, it should be possible to propose two new collectives in parallel).
The approval/support requirements are the same as Root, but the origin does not map to any privilege. Passing something on the track is merely a signal.
Copied from polkadot-fellows#184
Summary by CodeRabbit
New Features
node_featuresfunction for improved network capabilities.Refactor
WishForChangeorigin, facilitating the signaling of network preferences and changes.Documentation