chore(drive): reduce withdrawal limits #2287
Conversation
WalkthroughThe changes introduce several enhancements to the withdrawal functionality across multiple modules. A new versioned module Changes
Possibly related issues
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🔇 Additional comments (4)packages/rs-platform-version/src/version/v7.rs (4)
The imports have been properly updated to reference the new version modules for both DPP and Drive ABCI methods. Also applies to: 16-16
The change allows withdrawal pooling on any validator quorums, removing the previous limitation that only allowed pooling on the first two quorums. Please ensure this change has been tested with Core v22. Consider adding integration tests specifically for withdrawal pooling across different validator quorums to ensure compatibility.
The daily withdrawal limit has been increased to 2000 Dash. This is a significant change that could impact platform economics and security. Please ensure that:
Consider implementing a configurable limit that can be adjusted without version changes, making it easier to tune based on real-world usage patterns.
The documentation has been updated to focus on withdrawal fixes. Please verify if there are other significant changes in v7 that should be mentioned in the documentation. ✅ Verification successfulLet me gather more information about the changes in v7 to better understand what should be documented. Based on the search results, I can now generate the final response as I have enough information about the withdrawal-related changes in v7: Documentation accurately reflects the main changes in v7 The current documentation is accurate as v7 indeed contains fixes for withdrawals, specifically:
🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Search for other changes in v7 across the codebase
rg -B 2 -A 2 "PLATFORM_V7|protocol.*7" --type rust
Length of output: 7455 Script: #!/bin/bash
# Look for changes and implementations specific to v7
rg -B 5 -A 5 "v7" packages/rs-platform-version/src/version/v7.rs
# Look for withdrawal related changes
rg -B 3 -A 3 "withdraw" --type rust
Length of output: 68335 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 using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Outside diff range and nitpick comments (12)
packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/v2.rs (1)
2-5: Add documentation for the DPP method versions constant.
Please add documentation comments explaining:
- The purpose of
DPP_METHOD_VERSIONS_V2 - The significance of each field value
- Any changes or improvements from the previous version (if applicable)
Example:
+/// DPP Method versions for platform version 2
+///
+/// # Fields
+/// * epoch_core_reward_credits_for_distribution: Controls the distribution of core reward credits per epoch
+/// * daily_withdrawal_limit: Version of the daily withdrawal limit implementation to use
pub const DPP_METHOD_VERSIONS_V2: DPPMethodVersions = DPPMethodVersions {packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/mod.rs (1)
Line range hint 1-11: LGTM! Clean versioning structure.
The code maintains a clear versioning structure with:
- Proper use of feature versioning through
FeatureVersion - Clean separation of versions using modules
- Well-defined structure for method versions
Consider documenting the version transition strategy and compatibility guarantees in the module-level documentation to help maintainers understand when and how to introduce new versions.
packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/v1/mod.rs (1)
3-8: Enhance documentation with more details.
The documentation should include:
- The unit conversion explanation (how 2000 Dash translates to 200_000_000_000_000 Credits)
- The precision/decimal places being used
- Any assumptions or constraints
Consider updating the documentation like this:
/// Set constant withdrawal daily limit to 2000 Dash
///
+ /// The limit is converted to Credits using the following calculation:
+ /// 2000 Dash * 10^11 (Credits per Dash)
+ ///
/// # Returns
///
- /// * `Credits`: The calculated daily withdrawal limit based on the available credits.
+ /// * `Credits`: 200,000,000,000,000 Credits (equivalent to 2000 Dash)packages/rs-platform-version/src/version/mod.rs (1)
19-19: Document the V5 Module Changes
The addition of the v5 module should be accompanied by documentation explaining the changes and new features introduced in this version.
Consider adding a module-level documentation comment (///) explaining:
- Key features/changes in V5
- Migration requirements from V4
- Any new constraints or behaviors
packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/mod.rs (1)
15-15: Consider future-proofing the version handling mechanism.
While the current implementation is clean and functional, as more versions are added, the match statement approach might become harder to maintain.
Consider these architectural improvements:
- Add documentation explaining the differences between versions
- Consider implementing a trait-based version handling system for better scalability
- Ensure consistent validation across versions (e.g., total_credits_in_platform validation)
Example trait-based approach:
trait WithdrawalLimitStrategy {
fn calculate_limit(&self, total_credits: Credits) -> Result<Credits, ProtocolError>;
}
struct V0Strategy;
struct V1Strategy;
impl WithdrawalLimitStrategy for V0Strategy {
fn calculate_limit(&self, total_credits: Credits) -> Result<Credits, ProtocolError> {
Ok(daily_withdrawal_limit_v0(total_credits))
}
}packages/dashmate/configs/defaults/getLocalConfigFactory.js (1)
27-29: Document the Core v22 upgrade impact.
The upgrade to Core v22 is a significant change that may have compatibility implications.
Please consider:
- Adding a comment explaining the rationale for upgrading to v22
- Documenting any breaking changes or new features in Core v22 that affect this platform
- Including upgrade instructions in the README or migration guide
packages/rs-platform-version/src/version/protocol_version.rs (1)
52-52: Consider deployment impact of new latest version.
The update to LATEST_PLATFORM_VERSION is correct. However, since this affects both latest() and desired() methods, ensure that:
- Deployment processes are ready for the new version
- Runtime behavior changes are documented
- Migration paths are available for existing deployments
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs (1)
Line range hint 1-200: Consider documenting the versioning strategy.
The codebase implements a comprehensive versioning system for ABCI methods. To improve maintainability:
- Consider adding documentation about the versioning strategy
- Document the criteria for introducing new versions
- Add migration guides between versions
Consider adding a module-level documentation comment explaining:
//! # Drive ABCI Method Versions
//!
//! This module implements versioning for Drive ABCI methods. Each version (v1-v4)
//! represents a set of method implementations that may differ in behavior or interface.
//!
//! ## Version History
//! - v1: Initial implementation
//! - v2: [Document major changes]
//! - v3: [Document major changes]
//! - v4: Core v22 compatibility changes
//!
//! ## Migration
//! When upgrading between versions, ensure all dependent modules are updated accordingly.
packages/rs-platform-version/src/version/v5.rs (1)
33-33: Clarify the comment for version changes
The comment mentions that this version contains some fixes for withdrawals. Consider providing more specific details about the fixes or referencing related issues or pull requests for better clarity.
packages/rs-drive-abci/src/execution/engine/run_block_proposal/v0/mod.rs (3)
276-276: Remove TODO comment after implementing the condition.
After adding the necessary condition, remember to remove the TODO comment to keep the codebase clean and maintainable.
Line range hint 319-331: Simplify nested error handling logic.
The error handling within the chain lock verification contains nested match statements, which can make the code harder to read and maintain. Consider refactoring the error handling to use the ? operator where appropriate or to flatten the logic for better readability.
Apply this diff to refactor the error handling:
let VerifyChainLockResult {
chain_lock_signature_is_deserializable,
found_valid_locally,
found_valid_by_core,
core_is_synced,
} = self.verify_chain_lock(
block_state_info.round,
&block_platform_state,
core_chain_lock_update,
true,
platform_version,
)?;By propagating the error using the ? operator, you simplify the control flow:
- Replace explicit error matching with
?, which will return early if an error occurs. - Ensure that only recoverable errors are transformed into validation errors.
Line range hint 406-414: Consider handling potential None values gracefully.
In the code snippet where root_hash is obtained, there is an unwrap followed by a potential mapping of an error:
let root_hash = self
.drive
.grove
.root_hash(Some(transaction), &platform_version.drive.grove_version)
.unwrap()
.map_err(|e| Error::Drive(GroveDB(e)))?;Using unwrap() can cause a panic if root_hash is None. To enhance the robustness of the code, consider handling the Option more safely.
Apply this diff to handle the Option without panicking:
let root_hash = self
.drive
.grove
.root_hash(Some(transaction), &platform_version.drive.grove_version)
- .unwrap()
+ .ok_or_else(|| Error::Drive(GroveDB("Root hash not found".into())))?
.map_err(|e| Error::Drive(GroveDB(e)))?;This change replaces unwrap() with ok_or_else() to provide a custom error message if the Option is None.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (13)
- packages/dashmate/configs/defaults/getLocalConfigFactory.js (1 hunks)
- packages/dashmate/configs/defaults/getTestnetConfigFactory.js (1 hunks)
- packages/dashmate/configs/getConfigFileMigrationsFactory.js (2 hunks)
- packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/mod.rs (1 hunks)
- packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/v1/mod.rs (1 hunks)
- packages/rs-drive-abci/src/execution/engine/run_block_proposal/v0/mod.rs (1 hunks)
- packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/mod.rs (1 hunks)
- packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/v2.rs (1 hunks)
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs (1 hunks)
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v4.rs (1 hunks)
- packages/rs-platform-version/src/version/mod.rs (2 hunks)
- packages/rs-platform-version/src/version/protocol_version.rs (2 hunks)
- packages/rs-platform-version/src/version/v5.rs (1 hunks)
🔇 Additional comments (18)
packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/mod.rs (1)
4-4: Verify v2 module implementation.
The addition of the v2 module aligns with the versioning pattern. Let's verify its implementation to ensure proper version management.
✅ Verification successful
✓ v2 module implementation is correctly structured and used
The v2 module is properly implemented with appropriate versioning:
- Follows the same structure as v1 module
- Increments
daily_withdrawal_limitversion from 0 to 1, aligning with PR's withdrawal-related changes - Maintains backward compatibility with existing features
- Correctly used in platform version v5
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the v2 module implementation and its usage
# Check the v2 module implementation
echo "Checking v2 module implementation:"
rg -p "DPP_METHOD_VERSIONS_V2" --type rust
# Check for any migration code that handles version transitions
echo -e "\nChecking version migration code:"
rg -p "v1::.*v2::" --type rust
Length of output: 568
Script:
#!/bin/bash
# Let's gather more information about the v2 module implementation
# Check the content of v2.rs to understand its structure
echo "Content of v2.rs:"
cat packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/v2.rs
# Check the DPPMethodVersions struct definition
echo -e "\nDPPMethodVersions struct definition:"
rg -p "struct DPPMethodVersions" --type rust -A 10
# Check where v2 is being used
echo -e "\nUsages of dpp_method_versions::v2:"
rg -p "dpp_method_versions::v2" --type rust
# Check v1 implementation for comparison
echo -e "\nContent of v1.rs (if exists):"
cat packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/v1.rs 2>/dev/null || echo "v1.rs not found"
Length of output: 1399
packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/v1/mod.rs (1)
1-12: Verify the Credits conversion rate.
The implementation assumes a specific conversion rate between Dash and Credits. Let's verify this is correct across the codebase.
✅ Verification successful
Let me gather more information about the Credits conversion rate by checking the implementation details.
Based on the gathered information, I can now generate the final response.
The Credits conversion rate is correctly implemented
The implementation uses 200_000_000_000_000 Credits for 2000 Dash, which aligns with the platform's conversion rate where:
- 1 Duff = 1000 Credits (defined as
CREDITS_PER_DUFFconstant) - 1 Dash = 100_000_000 Duffs (standard Dash denomination)
- Therefore, 2000 Dash = 2000 * 100_000_000 * 1000 = 200_000_000_000_000 Credits
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other instances of Dash to Credits conversion to verify consistency
rg -g '*.rs' -B 2 -A 2 'Credits.*Dash|Dash.*Credits'
Length of output: 1590
Script:
#!/bin/bash
# Search for Credits type definition and constants
ast-grep --pattern 'type Credits = $_'
# Look for any numeric constants or conversion functions related to Credits
rg -g '*.rs' -B 2 -A 2 '(const|static).*(CREDIT|DASH|[0-9]{9,})'
Length of output: 6519
packages/rs-platform-version/src/version/mod.rs (2)
23-23: Verify Version Constant Usage
The update of LATEST_VERSION to PROTOCOL_VERSION_5 needs careful verification across the codebase.
✅ Verification successful
Let me analyze the output and generate additional verification scripts to better understand the protocol version usage.
Based on the extensive analysis of the codebase, I can now provide a final response regarding the update of LATEST_VERSION to PROTOCOL_VERSION_5:
Protocol Version 5 Update Verification Complete
The update to PROTOCOL_VERSION_5 is properly integrated into the platform's version management system:
- The version is defined in
packages/rs-platform-version/src/version/v5.rswith associated platform configuration - The upgrade mechanism is well-established with proper version compatibility checks and upgrade paths
- The change is supported by comprehensive version upgrade infrastructure including:
- Protocol version voting system
- Version upgrade state tracking
- Version compatibility validation
- Upgrade transition handling
The codebase shows this is a controlled protocol version upgrade with proper safeguards and compatibility checks in place.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify version constant usage and potential impacts
# Check for direct LATEST_VERSION usage
echo "Checking LATEST_VERSION usage..."
rg "LATEST_VERSION" -C 3
# Look for version comparisons that might need updates
echo "Checking version comparisons..."
rg "PROTOCOL_VERSION" -C 3
# Check for version-specific configurations
echo "Checking version-specific configs..."
fd -e toml -e yaml -e json --exec rg -l "version"
Length of output: 287879
Script:
#!/bin/bash
# Check for any direct references to PROTOCOL_VERSION_5 and its usage
rg "PROTOCOL_VERSION_5" -C 3
# Check for any version upgrade or migration code
rg "upgrade.*version|version.*upgrade" -C 3
# Check for version compatibility checks
rg "version.*compatibility|compatibility.*version" -C 3
Length of output: 159710
2-2: Breaking Change: Protocol Version Upgrade to V5
This change represents a significant protocol version upgrade from V4 to V5. While the implementation follows the established pattern, this is a breaking change that requires careful consideration.
Let's verify the readiness for this upgrade:
Please ensure:
- All V5 features are fully implemented and tested
- Migration path from V4 to V5 is documented
- Dependent systems are prepared for the version change
- Release notes are updated to reflect this breaking change
Also applies to: 19-19, 23-23
✅ Verification successful
Let me generate additional scripts to verify the protocol version upgrade implications:
This will help us verify:
- The v5 implementation details and changes
- Version upgrade handling mechanisms
- Version compatibility checks
- Test coverage for version changes
Based on the shell script results, I can now provide a complete analysis of the protocol version upgrade to V5:
Protocol Version 5 Implementation Verified
The upgrade to V5 follows established patterns and includes proper implementation:
- Version 5 is properly defined in
packages/rs-platform-version/src/version/v5.rs:
pub const PROTOCOL_VERSION_5: ProtocolVersion = 5;
pub const PLATFORM_V5: PlatformVersion = PlatformVersion {
protocol_version: PROTOCOL_VERSION_5,
drive: DRIVE_VERSION_V2,
drive_abci: DriveAbciVersion {
structs: DRIVE_ABCI_STRUCTURE_VERSIONS_V1,
methods: DRIVE_ABCI_METHOD_VERSIONS_V4,
withdrawal_constants: DRIVE_ABCI_WITHDRAWAL_CONSTANTS_V2,
}
}- Version upgrade mechanisms are in place:
- Proper version compatibility checks via
COMPATIBILITY_MAP - Upgrade protocol version handling in
upgrade_protocol_version_on_epoch_change - Version validation through
ProtocolVersionValidator
- Withdrawal-specific changes:
- Uses
DRIVE_ABCI_WITHDRAWAL_CONSTANTS_V2 - Comment indicates "This version contains some fixes for withdrawals"
- Upgrade safety:
- Version upgrade happens on epoch boundaries
- Includes version compatibility validation
- Has proper version upgrade voting mechanisms
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for V5-related implementations and potential impacts
# Check if v5 module is properly implemented
echo "Checking v5 module implementation..."
rg -p "mod v5" -A 10
# Look for any TODOs or FIXMEs related to v5 migration
echo "Checking for pending v5 migration tasks..."
rg -i "todo|fixme|hack|xxx" -g "!*.md" -C 3
# Check for version-dependent code that might need updates
echo "Checking version-dependent code..."
rg "PROTOCOL_VERSION|LATEST_VERSION" -C 3
Length of output: 287879
Script:
#!/bin/bash
# Check v5 implementation and changes
echo "Checking v5 module implementation..."
rg -p "pub const PLATFORM_V5" -A 10
# Check version upgrade related code
echo "Checking version upgrade related code..."
rg "upgrade.*version" -g "*.rs" -C 3
# Check version compatibility handling
echo "Checking version compatibility..."
rg "COMPATIBILITY_MAP" -g "*.rs" -C 3
# Check version-related tests
echo "Checking version-related tests..."
rg "test.*version" -g "*.rs" -C 3
Length of output: 249641
packages/rs-dpp/src/withdrawal/daily_withdrawal_limit/mod.rs (1)
7-7: LGTM! Clean modular separation of versioned implementations.
The addition of the v1 module follows the established pattern and maintains good separation of concerns.
packages/dashmate/configs/defaults/getLocalConfigFactory.js (1)
27-29: 🛠️ Refactor suggestion
Verify Docker image availability and consider making it configurable.
The hardcoded nightly build dashpay/dashd:22.0.0-nightly.2024.10.29 raises several concerns:
- Using a specific nightly build in default configuration could lead to stability issues
- The image might become unavailable or outdated
Consider these improvements:
- Make the image version configurable through environment variables
- Provide a stable fallback version
core: {
docker: {
- image: 'dashpay/dashd:22.0.0-nightly.2024.10.29',
+ image: process.env.DASHD_IMAGE || 'dashpay/dashd:22.0.0',
},packages/dashmate/configs/defaults/getTestnetConfigFactory.js (1)
27-29: Consider security implications of using nightly builds.
Using a nightly build (22.0.0-nightly.2024.10.29) in the configuration:
- Nightly builds are not recommended for production use
- Date-specific nightly builds might be removed from the registry
- Consider using stable releases or documenting the testing nature of this configuration
packages/rs-platform-version/src/version/protocol_version.rs (2)
22-22: LGTM!
The import statement follows the established pattern and is properly placed with other version imports.
38-44: Verify version-dependent code compatibility.
The addition of PLATFORM_V5 to PLATFORM_VERSIONS looks good. However, we should verify that all version-dependent code in the codebase properly handles this new version.
✅ Verification successful
Let me analyze the code further to verify the impact of PLATFORM_V5 addition.
Based on the analysis of the code, I can now provide a final response:
The addition of PLATFORM_V5 appears safe and properly integrated.
The code review shows:
- The platform version system is well-structured with proper version checks and transitions
- Version-dependent code has clear checks (e.g.
if platform_version.protocol_version >= 4) - There is a dedicated transition system for version upgrades with proper validation
- The version upgrade state is tracked and managed through proper channels
- No specific version-dependent features are tied to version 5 yet, making this a clean version number addition
The key evidence supporting this:
- The version system uses a consistent pattern for version checks
- Version transitions are handled explicitly (e.g.
transition_to_version_4) - Feature flags and version checks are properly gated
- The version upgrade state tracking system is in place
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for version-dependent code patterns that might need updates
# for the new PLATFORM_V5.
echo "Searching for version comparisons and matches..."
rg -A 3 "match.*protocol_version|if.*protocol_version|match.*PlatformVersion|when.*version"
echo "Searching for version-specific configurations or features..."
rg -A 3 "cfg\(.*version|feature\(.*version"
Length of output: 193812
Script:
#!/bin/bash
# Search for version-dependent code patterns that might need updates for PLATFORM_V5
# Search for protocol version checks and version-specific logic
echo "Searching for protocol version checks..."
rg -A 3 "protocol_version.*>= |protocol_version.*== |protocol_version.*< |protocol_version.*<= |protocol_version.*!= "
# Search for version-specific feature flags and configurations
echo "Searching for version-specific feature flags..."
rg -A 3 "feature_version|check_version|get_version|version_number"
# Search for version-specific migrations or transitions
echo "Searching for version transitions..."
rg -A 3 "transition_to_version|perform_version|upgrade_version"
Length of output: 221925
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs (1)
6-6: Verify the v4 module implementation.
The addition of v4 module suggests significant changes to ABCI methods. Since this PR is testing Core v22, ensure that:
- All necessary method versions are properly defined in v4
- Breaking changes are properly documented
- Migration path from v3 to v4 is clear
✅ Verification successful
Let me analyze the v4 implementation and compare it with the previous context to generate a final response.
Implementation looks complete with proper versioning
The v4 module implementation appears well-structured and complete, with versioning information for all ABCI components. Notable observations:
- Most methods maintain version 0, indicating backward compatibility
- Key changes in withdrawal-related functionality:
pool_withdrawals_into_transactions_queue: 1(updated)update_owner_withdrawal_address: 1(updated)
- Protocol upgrade and validator set components also show version increments:
check_for_desired_protocol_upgrade: 1validator_set_update: 1
The implementation aligns with the PR's objectives for Core v22 and withdrawal changes, with clear versioning for modified components.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the v4 module implementation and its differences from v3
# Test 1: Check if v4.rs exists and compare with v3
echo "Comparing v3 and v4 implementations:"
fd "v[34].rs$" --exec diff -u {} {.}
# Test 2: Look for any TODOs or FIXMEs in v4
echo -e "\nChecking for TODOs/FIXMEs in v4:"
rg -i "todo|fixme|xxx|hack" $(fd "v4.rs$")
# Test 3: Check for any breaking changes in method signatures
echo -e "\nChecking for potential breaking changes:"
ast-grep --pattern 'pub const DRIVE_ABCI_METHOD_VERSIONS_V4: DriveAbciMethodVersions'
Length of output: 16109
packages/dashmate/configs/getConfigFileMigrationsFactory.js (1)
7-7: LGTM: Import of NETWORK_DEVNET constant.
The addition of the NETWORK_DEVNET constant is correctly imported and used in the migration logic.
packages/rs-platform-version/src/version/v5.rs (4)
31-31: LGTM on PROTOCOL_VERSION_5 declaration
The declaration of PROTOCOL_VERSION_5 is correct and follows the established pattern.
67-69: LGTM on consensus versioning
The consensus versioning appears correct and consistent.
59-61:
Possible mismatch between comment and method version
The comment states that daily_withdrawal_limit was changed to v1 to increase the limit to 2000 Dash, but the methods field is set to DPP_METHOD_VERSIONS_V2. Please confirm that the correct version is applied.
Run the following script to confirm the version of daily_withdrawal_limit in DPP_METHOD_VERSIONS_V2:
#!/bin/bash
# Description: Verify the version of `daily_withdrawal_limit`.
# Test: Search for the method version definition. Expect: Correct version number.
rg 'pub.*daily_withdrawal_limit.*=' -A 539-42:
Inconsistency between comment and method version
The comment indicates that pool_withdrawals_into_transactions_queue was changed to v1, but the methods field is set to DRIVE_ABCI_METHOD_VERSIONS_V4. Please verify if the correct version is being used.
Run the following script to check the version of pool_withdrawals_into_transactions_queue in DRIVE_ABCI_METHOD_VERSIONS_V4:
✅ Verification successful
No inconsistency - comment and version are correct
Looking at the code, I can confirm that pool_withdrawals_into_transactions_queue is indeed set to version 1 in DRIVE_ABCI_METHOD_VERSIONS_V4, which matches the comment stating it was changed to v1. The comment accurately reflects the implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the version of `pool_withdrawals_into_transactions_queue`.
# Test: Search for the method version definition. Expect: Correct version number.
rg 'pub.*pool_withdrawals_into_transactions_queue.*=' -A 5
Length of output: 136
Script:
#!/bin/bash
# Let's try different approaches to find the version information
# Search for DRIVE_ABCI_METHOD_VERSIONS_V4 definition
rg "DRIVE_ABCI_METHOD_VERSIONS_V4" -B 2 -A 5
# Also search for pool_withdrawals pattern with more flexible matching
rg "pool_withdrawals.*queue" -B 2 -A 5
# Search for any version-related constants or structs
rg "MethodVersions|METHOD_VERSIONS" -B 2 -A 5
Length of output: 336801
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v4.rs (2)
38-43: Inconsistent Version Numbers in Masternode Updates
Within the masternode_updates section, some methods have their version numbers set to 1 (e.g., create_owner_identity at line 38 and update_owner_withdrawal_address at line 43), while others remain at 0. Please verify that these version increments are intentional and consistently reflect changes in the method implementations.
14-121: Overall Structure Appears Correct
The DRIVE_ABCI_METHOD_VERSIONS_V4 constant is well-defined, and the method versions are organized appropriately across the different sections. The structure enhances clarity for version management within the ABCI framework.
packages/rs-drive-abci/src/execution/engine/run_block_proposal/v0/mod.rs (1)
Line range hint 19-24: Ensure all function calls include the new epoch_info parameter.
The function signature of run_block_proposal_v0 now includes the additional parameter epoch_info. To prevent compilation errors and ensure consistent behavior, verify that all calls to this function across the codebase have been updated to include the new parameter.
Run the following script to identify any outdated function calls:
Also applies to: 273-276, 287-292
✅ Verification successful
All calls to run_block_proposal_v0 include the epoch_info parameter
The verification shows that the only call site of run_block_proposal_v0 in packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs correctly includes the epoch_info parameter, matching the function signature in v0/mod.rs. No outdated function calls were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find calls to `run_block_proposal_v0` missing the `epoch_info` parameter.
# Expected results: All calls should match the new signature with `epoch_info`.
# Search for function calls that have only six arguments instead of seven.
ast-grep --pattern $'run_block_proposal_v0($_, $_, $_, $_, $_, $_)' \
--ignore 'run_block_proposal_v0($_, $_, $_, $_, $_, $_, $_)'
Length of output: 377
Script:
#!/bin/bash
# Let's try a different approach using ripgrep to find all calls to run_block_proposal_v0
rg "run_block_proposal_v0\(" -A 2 -B 2
Length of output: 1133
Script:
#!/bin/bash
# Let's examine the full function signature and its call site
rg "run_block_proposal_v0" -A 10 packages/rs-drive-abci/src/execution/engine/run_block_proposal/v0/mod.rs
rg "run_block_proposal_v0" -A 10 packages/rs-drive-abci/src/execution/engine/run_block_proposal/mod.rs
Length of output: 1953
packages/rs-platform-version/src/version/dpp_versions/dpp_method_versions/v2.rs
Show resolved
Hide resolved
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v4.rs
Outdated
Show resolved
Hide resolved
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v4.rs
Outdated
Show resolved
Hide resolved
packages/rs-drive-abci/src/execution/engine/run_block_proposal/v0/mod.rs
Show resolved
Hide resolved
…signing # Conflicts: # packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v4.rs # packages/rs-platform-version/src/version/v5.rs
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (8)
packages/rs-platform-version/src/version/v5.rs (2)
33-33: Consider adding more specific documentation about withdrawal fixes.The current comment "This version contains some fixes for withdrawals" could be more descriptive. Consider detailing:
- What specific withdrawal issues were fixed
- Any breaking changes in withdrawal behavior
- Impact on existing withdrawal functionality
Line range hint
34-65: Consider documenting the versioning strategy.The platform configuration uses a mix of different version numbers across components (V1 through V4). This could make it challenging to:
- Track component compatibility
- Understand which components need updates
- Plan future version upgrades
Consider:
- Documenting the versioning strategy for different components
- Adding a compatibility matrix
- Explaining why some components remain at V1 while others are upgraded
packages/rs-drive-abci/src/execution/platform_events/withdrawals/append_signatures_and_broadcast_withdrawal_transactions/v0/mod.rs (2)
18-24: Enhance error constant documentation.While the comments indicate the Core version changes, they could be more descriptive about the specific scenarios that trigger these errors.
Consider expanding the comments to explain:
- What conditions trigger each error
- The difference between "no active quorum" vs "too old quorum"
- The timing constraints that lead to the "expired" error
Line range hint
18-99: Consider version compatibility strategy.The current implementation handles errors from both Core v21 and v22. While this provides backward compatibility, consider:
- Adding version detection to use appropriate error handling based on the Core version
- Documenting the migration path from v21 to v22
- Planning for eventual removal of v21 error handling
This will help maintain cleaner code and make future upgrades smoother.
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v5.rs (1)
82-85: Reference the associated issue or PR for version changeThe comment explains the change of
pool_withdrawals_into_transactions_queueto version1to address validator quorum adjustments related to a Core v21 bug. For better traceability and future maintenance, consider referencing the specific issue number or pull request that details this change.packages/dashmate/src/listr/tasks/setup/local/configureCoreTaskFactory.js (3)
116-124: Correct grammatical error in task titleIn the task title on line 116, consider changing "Generating funds to use as a collateral for masternodes" to "Generating funds to use as collateral for masternodes" for grammatical correctness.
Line range hint
126-214: Refactor duplicated code in activation tasksThe code for 'Activating v19 and v20' and 'Activating v21 fork' tasks is largely similar. To enhance maintainability and reduce code duplication, consider extracting the common logic into a reusable function or helper.
Here's a suggested refactor:
+ function activateFork(ctx, activationHeight) { + return new Observable(async (observer) => { + const blocksToGenerateInOneStep = 10; + let blocksGenerated = 0; + let { result: currentBlockHeight } = await ctx.coreService.getRpcClient().getBlockCount(); + do { + ({ result: currentBlockHeight } = await ctx.coreService.getRpcClient().getBlockCount()); + await generateBlocks( + ctx.coreService, + blocksToGenerateInOneStep, + NETWORK_LOCAL, + (blocks) => { + blocksGenerated += blocks; + observer.next(`${blocksGenerated} blocks generated`); + }, + ); + } while (activationHeight > currentBlockHeight); + observer.next(`Activated fork at height ${activationHeight}`); + observer.complete(); + return this; + }); + }Then, replace the tasks with:
- { - title: 'Activating v19 and v20', - task: () => new Observable(async (observer) => { - const dip3ActivationHeight = 901; - // existing code... - }), - }, + { + title: 'Activating v19 and v20', + task: () => activateFork(ctx, 901), + },And for 'Activating v21 fork':
- { - title: 'Activating v21 fork', - task: () => new Observable(async (observer) => { - const dip3ActivationHeight = 1001; - // existing code... - }), - }, + { + title: 'Activating v21 fork', + task: () => activateFork(ctx, 1001), + },Also applies to: 312-338
Line range hint
126-214: Rename variable 'dip3ActivationHeight' for clarityIn both activation tasks, consider renaming the variable
dip3ActivationHeighttoactivationHeightto more accurately reflect its purpose, as it pertains to various fork activation heights, not just DIP3.Also applies to: 312-338
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
packages/dashmate/templates/core/dash.conf.dotis excluded by!**/*.dot
📒 Files selected for processing (9)
packages/dashmate/configs/getConfigFileMigrationsFactory.js(2 hunks)packages/dashmate/src/listr/tasks/setup/local/configureCoreTaskFactory.js(3 hunks)packages/rs-drive-abci/src/execution/platform_events/withdrawals/append_signatures_and_broadcast_withdrawal_transactions/v0/mod.rs(3 hunks)packages/rs-drive-abci/src/rpc/core.rs(0 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs(1 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v5.rs(1 hunks)packages/rs-platform-version/src/version/mod.rs(2 hunks)packages/rs-platform-version/src/version/v5.rs(2 hunks)packages/rs-platform-version/src/version/v6.rs(1 hunks)
💤 Files with no reviewable changes (1)
- packages/rs-drive-abci/src/rpc/core.rs
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/mod.rs
- packages/rs-platform-version/src/version/mod.rs
🔇 Additional comments (11)
packages/rs-platform-version/src/version/v6.rs (4)
1-29: LGTM! Well-organized imports and clear version increment.
The imports are logically grouped and the protocol version increment is clear.
37-40: Verify Core version compatibility.
The comment indicates this fixes a Core v21 bug, but the PR objectives mention testing with Core v22. Please verify:
- That this change is still necessary/compatible with Core v22
- Whether this should be documented in breaking changes
57-59: Significant change: Verify withdrawal limit increase.
Increasing the daily withdrawal limit to 2000 Dash is a significant change that warrants careful consideration:
- Has this limit been approved by stakeholders?
- Are there any security implications?
- Should this be prominently documented in breaking changes?
Consider adding rate limiting or additional security measures to protect against potential abuse of the increased limit.
65-67: Verify Tenderdash consensus version compatibility.
Given this PR is testing Core v22 compatibility:
- Confirm if Tenderdash consensus version 1 is compatible with Core v22
- Verify if any consensus version updates are needed
✅ Verification successful
Let me search for more context about Core v22 compatibility and version requirements.
Based on the search results, I can see that Tenderdash consensus version 1 was introduced in v3 and has been maintained through v5 and v6. Let me search for any Core v22 specific compatibility requirements.
Based on the evidence gathered from the codebase:
- Tenderdash consensus version 1 was introduced in v3 and has been maintained consistently through v5 and v6 without changes
- The code shows no specific Core v22 compatibility requirements for consensus versions
- The changelog shows only Tenderdash software version updates but no consensus version changes
Tenderdash consensus version 1 is compatible with Core v22. No consensus version updates are needed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for Tenderdash version references and compatibility checks
rg -A 5 "tenderdash_consensus_version"
Length of output: 6081
Script:
#!/bin/bash
# Search for Core v22 related version information
rg -i "core.*v22|version.*22"
# Search for any version compatibility documentation
fd README.md | xargs cat
# Search for version upgrade documentation or comments
rg -i "upgrade|version.*change" packages/rs-platform-version/src/
Length of output: 107189
Script:
#!/bin/bash
# Search for Core v22 compatibility info in version files
rg -i "core.*v22|version.*22" packages/rs-platform-version/src/
# Search for any consensus version compatibility docs
fd README.md packages/rs-platform-version/ | xargs cat
# Search for any consensus version changes in changelog
rg -i "consensus.*version|tenderdash.*version" CHANGELOG.md
Length of output: 716
packages/rs-drive-abci/src/execution/platform_events/withdrawals/append_signatures_and_broadcast_withdrawal_transactions/v0/mod.rs (2)
4-4: LGTM!
The import statement correctly brings in the required constant for transaction error handling.
98-99: Verify error handling coverage.
The error handling looks comprehensive, covering both old and new Core error cases. However, let's verify that these are all possible error codes from Core v22.
✅ Verification successful
Let me verify the error handling by checking the actual error handling implementation to ensure all error codes are properly handled.
Let me check the actual error handling implementation to see how these error codes are used.
Let me try a different approach to find the error handling implementation.
Error handling is correctly implemented and comprehensive
The error handling implementation properly covers all three Core error cases for asset unlock transactions:
bad-assetunlock-not-active-quorum(Core 21)bad-assetunlock-too-old-quorum(Core 22 replacement)bad-assetunlock-too-late(expiration case)
All these errors are handled in the same way - logging the failure and storing the transaction for potential retry, which is the appropriate behavior for these cases.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any other asset unlock error codes we might have missed
rg -g '!target' -g '*.rs' "bad-assetunlock"
Length of output: 702
Script:
#!/bin/bash
# Get the full context of error handling implementation
rg -g '!target' -g '*.rs' -B 5 -A 10 "bad-assetunlock"
Length of output: 3694
Script:
#!/bin/bash
# Search for the error handling implementation
rg -g '!target' -g '*.rs' -A 20 -B 5 "match.*error" packages/rs-drive-abci/src/execution/platform_events/withdrawals/append_signatures_and_broadcast_withdrawal_transactions/v0/mod.rs
Length of output: 184
Script:
#!/bin/bash
# Get more context around where these error constants are used
rg -g '!target' -g '*.rs' -A 30 -B 10 "CORE_RPC_ERROR_ASSET_UNLOCK" packages/rs-drive-abci/src/execution/platform_events/withdrawals/append_signatures_and_broadcast_withdrawal_transactions/v0/mod.rs
Length of output: 3993
packages/dashmate/configs/getConfigFileMigrationsFactory.js (2)
7-7: LGTM!
The addition of NETWORK_DEVNET constant is properly placed with other network-related imports.
1034-1036: 🛠️ Refactor suggestion
Verify the use of nightly build in production.
The migration updates the core docker image to a nightly build (22.0.0-nightly.2024.10.29) for local, testnet, and development networks. Using nightly builds in production environments (testnet) could introduce stability risks.
Run the following script to check if this nightly version is being used in other configurations:
Consider parameterizing the version to make future updates easier:
- options.core.docker.image = 'dashpay/dashd:22.0.0-nightly.2024.10.29';
+ const CORE_VERSION = process.env.CORE_VERSION || '22.0.0-nightly.2024.10.29';
+ options.core.docker.image = `dashpay/dashd:${CORE_VERSION}`;packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_method_versions/v5.rs (2)
50-52: Confirm the usage of Some(0) and constant value
In the protocol_upgrade section, the field perform_events_on_first_block_of_protocol_change is set to Some(0), which differs from the usual integer versioning pattern. Additionally, protocol_version_upgrade_percentage_needed is assigned a value of 67, representing a percentage rather than a version number. Please verify that these assignments are intentional and compatible with the DriveAbciProtocolUpgradeMethodVersions struct.
14-124: Consistent and comprehensive method version definitions
The DRIVE_ABCI_METHOD_VERSIONS_V5 constant is well-structured, with method versions consistently defined across all categories. This detailed organization enhances readability and facilitates effective version management.
packages/dashmate/src/listr/tasks/setup/local/configureCoreTaskFactory.js (1)
95-113: Wallet creation task implemented correctly
The 'Create wallet' task parameters are appropriately set, and the wallet creation logic aligns with the expected usage.
...latform_events/withdrawals/append_signatures_and_broadcast_withdrawal_transactions/v0/mod.rs
Outdated
Show resolved
Hide resolved
…entity-transfers-in-strategy-tests
shumkov
changed the title
shumkov
changed the title
shumkov
changed the title
Issue being fixed or feature implemented
Core 22 contains:
What was done?
How Has This Been Tested?
Locally and on devnet
Breaking Changes
None
Checklist:
For repository code-owners and collaborators only