chore(drive): increase withdrawal limits to 2000 Dash per day #2287
Conversation
WalkthroughThis pull request introduces version 8 of the platform, focusing on enhancing withdrawal functionality and versioning. The changes include adding a new daily withdrawal limit version, updating platform and protocol versions, and refining error handling for asset unlock transactions. The modifications span multiple packages, introducing new modules and constants to support versioning and improve the platform's flexibility and error management. Changes
Sequence DiagramsequenceDiagram
participant Platform
participant DailyWithdrawalLimit
participant EpochManager
participant BlockProposal
Platform->>DailyWithdrawalLimit: Request withdrawal limit
DailyWithdrawalLimit-->>Platform: Return 2000 Dash limit
Platform->>EpochManager: Check epoch transition
EpochManager-->>Platform: Provide epoch info
Platform->>BlockProposal: Process block with epoch context
BlockProposal-->>Platform: Validate and process block
Possibly related issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (19)
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-dpp/src/withdrawal/daily_withdrawal_limit/v1/mod.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-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
# Conflicts: # packages/rs-platform-version/src/version/v7.rs
| DriveAbciStateTransitionProcessingMethodVersions, DriveAbciVotingMethodVersions, | ||
| }; | ||
|
|
||
| pub const DRIVE_ABCI_METHOD_VERSIONS_V5: DriveAbciMethodVersions = DriveAbciMethodVersions { |
| @@ -0,0 +1,5 @@ | |||
| use crate::version::dpp_versions::dpp_method_versions::DPPMethodVersions; | |||
| pub const DPP_METHOD_VERSIONS_V2: DPPMethodVersions = DPPMethodVersions { | |||
|
|
||
| pub fn daily_withdrawal_limit( | ||
| total_credits_in_platform: Credits, | ||
| platform_version: &PlatformVersion, | ||
| ) -> Result<Credits, ProtocolError> { | ||
| match platform_version.dpp.methods.daily_withdrawal_limit { | ||
| 0 => Ok(daily_withdrawal_limit_v0(total_credits_in_platform)), | ||
| 1 => Ok(v1::daily_withdrawal_limit_v1()), |
There was a problem hiding this comment.
why make this a function?
| use crate::version::dpp_versions::dpp_method_versions::DPPMethodVersions; | ||
| pub const DPP_METHOD_VERSIONS_V2: DPPMethodVersions = DPPMethodVersions { | ||
| epoch_core_reward_credits_for_distribution: 0, | ||
| daily_withdrawal_limit: 1, | ||
| }; |
| use crate::version::drive_abci_versions::drive_abci_method_versions::{ | ||
| DriveAbciBlockEndMethodVersions, DriveAbciBlockFeeProcessingMethodVersions, | ||
| DriveAbciBlockStartMethodVersions, DriveAbciCoreBasedUpdatesMethodVersions, | ||
| DriveAbciCoreChainLockMethodVersionsAndConstants, DriveAbciCoreInstantSendLockMethodVersions, | ||
| DriveAbciEngineMethodVersions, DriveAbciEpochMethodVersions, | ||
| DriveAbciFeePoolInwardsDistributionMethodVersions, | ||
| DriveAbciFeePoolOutwardsDistributionMethodVersions, | ||
| DriveAbciIdentityCreditWithdrawalMethodVersions, DriveAbciInitializationMethodVersions, | ||
| DriveAbciMasternodeIdentitiesUpdatesMethodVersions, DriveAbciMethodVersions, | ||
| DriveAbciPlatformStateStorageMethodVersions, DriveAbciProtocolUpgradeMethodVersions, | ||
| DriveAbciStateTransitionProcessingMethodVersions, DriveAbciVotingMethodVersions, | ||
| }; | ||
|
|
||
| pub const DRIVE_ABCI_METHOD_VERSIONS_V5: DriveAbciMethodVersions = DriveAbciMethodVersions { | ||
| engine: DriveAbciEngineMethodVersions { | ||
| init_chain: 0, | ||
| check_tx: 0, | ||
| run_block_proposal: 0, | ||
| finalize_block_proposal: 0, | ||
| consensus_params_update: 1, | ||
| }, | ||
| initialization: DriveAbciInitializationMethodVersions { | ||
| initial_core_height_and_time: 0, | ||
| create_genesis_state: 0, | ||
| }, | ||
| core_based_updates: DriveAbciCoreBasedUpdatesMethodVersions { | ||
| update_core_info: 0, | ||
| update_masternode_list: 0, | ||
| update_quorum_info: 0, | ||
| masternode_updates: DriveAbciMasternodeIdentitiesUpdatesMethodVersions { | ||
| get_voter_identity_key: 0, | ||
| get_operator_identity_keys: 0, | ||
| get_owner_identity_withdrawal_key: 0, | ||
| get_owner_identity_owner_key: 0, | ||
| get_voter_identifier_from_masternode_list_item: 0, | ||
| get_operator_identifier_from_masternode_list_item: 0, | ||
| create_operator_identity: 0, |
There was a problem hiding this comment.
why did you add a v5 again here?
| @@ -1,5 +1,6 @@ | |||
| mod protocol_version; | |||
| use crate::version::v7::PROTOCOL_VERSION_7; | |||
| /// | ||
| /// * `Credits`: The calculated daily withdrawal limit based on the available credits. | ||
| /// | ||
| pub fn daily_withdrawal_limit_v1() -> Credits { |
There was a problem hiding this comment.
at least make this a const fn
QuantumExplorer
changed the title
commit 6776651 Author: QuantumExplorer <quantum@dash.org> Date: Sat Mar 1 22:23:41 2025 +0700 chore: update to latest dash core 37 (#2483) commit 1501103 Merge: a7c7a0f da17fc5 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Feb 27 14:21:41 2025 +0700 chore: merge master and resolve conflicts (#2481) commit da17fc5 Author: pshenmic <pshenmic@gmail.com> Date: Thu Feb 27 13:31:51 2025 +0700 feat(js-dash-sdk): fix tests after merge commit c7e40cb Merge: c57e8b2 f9eb069 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Feb 27 09:35:02 2025 +0700 Merge remote-tracking branch 'origin/chore/merge-master' into chore/merge-master commit c57e8b2 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Feb 27 09:34:40 2025 +0700 test(dpp): fix assertion with the same value commit 045b6fa Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Feb 27 09:32:33 2025 +0700 chore(dpp): remove unnecessary type conversion commit 8160ccd Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Feb 27 09:31:32 2025 +0700 chore: remove duplicated commented code commit f9eb069 Merge: 05d0085 a7c7a0f Author: pshenmic <pshenmic@gmail.com> Date: Wed Feb 26 20:03:00 2025 +0700 Merge branch 'v2.0-dev' into chore/merge-master commit a7c7a0f Author: pshenmic <pshenmic@gmail.com> Date: Wed Feb 26 19:52:02 2025 +0700 build: bump rust version to 1.85 (#2480) commit 05d0085 Merge: bcf1785 196976c Author: Ivan Shumkov <ivan@shumkov.ru> Date: Wed Feb 26 18:03:38 2025 +0700 Merge branch 'master' into v2.0-dev commit bcf1785 Author: lklimek <842586+lklimek@users.noreply.github.com> Date: Fri Feb 21 08:43:35 2025 +0100 feat: wasm sdk build proof-of-concept (#2405) Co-authored-by: Ivan Shumkov <ivan@shumkov.ru> commit 5e32426 Author: Paul DeLucia <69597248+pauldelucia@users.noreply.github.com> Date: Thu Feb 20 19:22:52 2025 +0700 fix: token already paused unpaused and frozen validation (#2466) commit 374a036 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Feb 20 17:46:57 2025 +0700 test: fix slowdown of JS SDK unit tests (#2475) commit 1fed09b Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Feb 20 13:46:36 2025 +0700 fix(dpp): invalid feature flag usage (#2477) commit 33507bb Author: Paul DeLucia <69597248+pauldelucia@users.noreply.github.com> Date: Thu Feb 20 13:18:55 2025 +0700 fix: destroy frozen funds used wrong identity and proof verification (#2467) commit 91a9766 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Wed Feb 19 16:57:32 2025 +0700 feat(sdk): return state transition execution error (#2454) commit cb915a7 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Wed Feb 19 16:46:54 2025 +0700 test: fix token history contract tests (#2470) commit 04276d5 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Tue Feb 18 21:00:05 2025 +0700 fix: xss vulnerability in mocha (#2469) commit 196976c Author: pshenmic <pshenmic@gmail.com> Date: Fri Feb 14 18:50:08 2025 +0700 fix(sdk)!: bigint for uint64 values (#2443) commit 0bd29a6 Author: pshenmic <pshenmic@gmail.com> Date: Fri Feb 14 17:29:35 2025 +0700 feat(dpp): extra methods for state transitions in wasm (#2462) commit 1eae781 Author: pshenmic <pshenmic@gmail.com> Date: Fri Feb 14 15:29:17 2025 +0700 chore(platform): npm audit fix (#2463) commit ddf4e67 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Fri Feb 14 11:28:08 2025 +0700 test: fix `fetchProofForStateTransition` tests and warnings (#2460) commit d88ea46 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Fri Feb 14 09:52:53 2025 +0700 fix(dpp): invalid imports and tests (#2459) commit 82e4d4c Merge: 125cfe7 4becf5f Author: Paul DeLucia <69597248+pauldelucia@users.noreply.github.com> Date: Thu Feb 13 19:05:51 2025 +0700 fix: check if token is paused on token transfers (#2458) commit 4becf5f Author: pauldelucia <pauldelucia2@gmail.com> Date: Thu Feb 13 18:34:24 2025 +0700 add costs commit 907971d Merge: 9026669 125cfe7 Author: Paul DeLucia <69597248+pauldelucia@users.noreply.github.com> Date: Thu Feb 13 18:05:06 2025 +0700 Merge branch 'v2.0-dev' into feat/token-paused-validation commit 125cfe7 Merge: 91f65c6 c286ec0 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Feb 13 15:51:46 2025 +0700 Merge branch 'v2.0-dev' into v2.0-tokens-dev commit 9026669 Author: pauldelucia <pauldelucia2@gmail.com> Date: Thu Feb 13 13:41:19 2025 +0700 feat: check if token is paused on token transfers commit c286ec0 Author: pshenmic <pshenmic@gmail.com> Date: Wed Feb 12 15:41:21 2025 +0700 feat(sdk): add option to request all keys (#2445) commit 91f65c6 Merge: d6b40e6 1a1c50b Author: Paul DeLucia <69597248+pauldelucia@users.noreply.github.com> Date: Wed Feb 12 12:04:58 2025 +0700 fix: wrong order of parameters in UnauthorizedTokenActionError (#2456) commit 1a1c50b Author: pauldelucia <pauldelucia2@gmail.com> Date: Wed Feb 12 11:51:31 2025 +0700 fix: wrong order of parameters in UnauthorizedTokenActionError commit 26aff36 Author: lklimek <842586+lklimek@users.noreply.github.com> Date: Tue Feb 11 13:06:54 2025 +0100 build: bump Alpine version to 3.21 (#2074) commit 9daa195 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Tue Feb 11 14:38:55 2025 +0700 ci: use github-hosted arm runner for release workflow (#2452) commit 2b1c252 Author: Paul DeLucia <69597248+pauldelucia@users.noreply.github.com> Date: Tue Feb 4 16:40:34 2025 +0700 fix: proof result error for credit transfers in sdk (#2451) commit d6b40e6 Author: QuantumExplorer <quantum@dash.org> Date: Tue Feb 4 06:49:03 2025 +0700 feat(platform): token distribution part two (#2450) commit 93f7d44 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Wed Jan 29 14:07:55 2025 +0700 fix(dpp): invalid feature flag instructions (#2448) commit 6d5af88 Author: QuantumExplorer <quantum@dash.org> Date: Mon Jan 27 16:59:39 2025 +0700 feat(dpp): token distribution model (#2447) commit e735313 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Mon Jan 27 14:24:26 2025 +0700 feat: add token transitions to SDK and DAPI (#2434) commit 0743be2 Author: pshenmic <pshenmic@gmail.com> Date: Sun Jan 26 22:00:40 2025 +0700 feat(dpp): extra methods for state transitions in wasm (#2401) commit f609bcf Merge: 3733f56 cbddb8d Author: Ivan Shumkov <ivan@shumkov.ru> Date: Fri Jan 24 18:16:38 2025 +0700 Merge branch 'v2.0-dev' into v2.0-tokens-dev commit cbddb8d Author: QuantumExplorer <quantum@dash.org> Date: Fri Jan 24 17:59:16 2025 +0700 chore(platform): make bls sig compatibility an optional feature (#2440) Co-authored-by: Ivan Shumkov <ivan@shumkov.ru> commit 764684b Author: Ivan Shumkov <ivan@shumkov.ru> Date: Fri Jan 24 17:57:27 2025 +0700 chore: ignore deprecated `lodash.get` (#2441) commit 3733f56 Author: QuantumExplorer <quantum@dash.org> Date: Thu Jan 23 09:16:12 2025 +0700 feat(platform)!: enhance token configuration and validation mechanisms (#2439) commit 2480ceb Author: QuantumExplorer <quantum@dash.org> Date: Wed Jan 22 16:33:13 2025 +0700 chore: dapi grpc queries (#2437) commit c9ab154 Author: QuantumExplorer <quantum@dash.org> Date: Wed Jan 22 15:50:25 2025 +0700 feat(platform)!: improved token validation and token config update transition (#2435) commit d9647cc Author: QuantumExplorer <quantum@dash.org> Date: Tue Jan 21 10:28:58 2025 +0700 feat: get proofs for tokens (#2433) commit e5964b8 Author: QuantumExplorer <quantum@dash.org> Date: Mon Jan 20 23:31:50 2025 +0700 feat: group queries (#2432) commit 0220302 Author: QuantumExplorer <quantum@dash.org> Date: Sun Jan 19 14:43:51 2025 +0700 feat(platform): proof verification for many queries and a few more queries (#2431) commit cd1527d Author: QuantumExplorer <quantum@dash.org> Date: Fri Jan 17 19:39:37 2025 +0700 fix(dpp)!: wrapping overflow issue (#2430) commit fd7ee85 Merge: d7143cc e4e156c Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Jan 16 21:45:47 2025 +0700 Merge branch 'master' into v1.9-dev commit e4e156c Author: QuantumExplorer <quantum@dash.org> Date: Thu Jan 16 18:11:57 2025 +0700 chore(release): update change log and release v1.8.0 (#2427) Co-authored-by: Ivan Shumkov <ivan@shumkov.ru> commit 55a1e03 Author: QuantumExplorer <quantum@dash.org> Date: Thu Jan 16 15:30:42 2025 +0700 feat(platform)!: token base support (#2383) commit 59bf0af Author: QuantumExplorer <quantum@dash.org> Date: Thu Jan 16 13:10:39 2025 +0700 chore(release): bump to v1.8.0-rc.2 (#2426) commit 410eb09 Author: QuantumExplorer <quantum@dash.org> Date: Thu Jan 16 06:31:26 2025 +0700 fix(drive-abci): rebroadcasting should not only take first 2 quorums too (#2425) commit 2abce8e Author: Ivan Shumkov <ivan@shumkov.ru> Date: Wed Jan 15 22:51:58 2025 +0700 chore(release): update changelog and bump version to 1.8.0-rc.1 (#2423) commit ad5f604 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Wed Jan 15 22:14:13 2025 +0700 chore: update bls library (#2424) commit c6feb5b Author: QuantumExplorer <quantum@dash.org> Date: Wed Jan 15 18:57:49 2025 +0700 feat(platform)!: distribute prefunded specialized balances after vote (#2422) Co-authored-by: Ivan Shumkov <ivan@shumkov.ru> commit 94dcbb2 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Wed Jan 15 05:51:45 2025 +0700 chore(drive): increase withdrawal limits to 2000 Dash per day (#2287) commit 6a0aede Author: Ivan Shumkov <ivan@shumkov.ru> Date: Tue Jan 14 21:42:59 2025 +0700 chore: fix test suite configuration script (#2402) commit e94b7bb Author: QuantumExplorer <quantum@dash.org> Date: Tue Jan 14 19:23:46 2025 +0700 fix(drive-abci): document purchase on mutable document from different epoch had issue (#2420) commit 4ee57a6 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Tue Jan 14 19:12:20 2025 +0700 fix(drive): more than one key was returned when expecting only one result (#2421) commit be5cd6d Author: Ivan Shumkov <ivan@shumkov.ru> Date: Mon Jan 13 15:12:33 2025 +0700 fix(sdk): failed to deserialize consensus error (#2410) commit e07271e Author: Ivan Shumkov <ivan@shumkov.ru> Date: Mon Jan 13 14:57:08 2025 +0700 chore: resolve NPM audit warnings (#2417) commit a809df7 Author: QuantumExplorer <quantum@dash.org> Date: Sun Jan 12 09:21:48 2025 +0700 test: unify identity versioned cost coverage (#2416) commit 6d637fe Author: Paul DeLucia <69597248+pauldelucia@users.noreply.github.com> Date: Fri Dec 27 09:42:04 2024 -0500 fix: try DriveDocumentQuery from DocumentQuery start field (#2407) commit cfd9c4d Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Dec 19 18:30:06 2024 +0700 chore(release): update changelog and bump version to 1.8.0-dev.2 (#2404) commit fecda31 Merge: 37d5732 fc7d994 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Dec 19 15:33:45 2024 +0700 Merge branch 'master' into v1.8-dev commit fc7d994 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Dec 19 14:40:44 2024 +0700 chore(release): update changelog and bump version to 1.7.1 (#2403) commit adcd3b8 Author: QuantumExplorer <quantum@dash.org> Date: Thu Dec 19 09:54:07 2024 +0300 fix!: emergency hard fork to fix masternode voting (#2397) commit 37d5732 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Wed Dec 18 22:24:37 2024 +0700 fix(dashmate): some group commands fail with mtime not found (#2400) commit 01a5b7a Author: Ivan Shumkov <ivan@shumkov.ru> Date: Wed Dec 18 20:44:44 2024 +0700 refactor(dpp): using deprecated param to init wasm module (#2399) commit c5f5878 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Wed Dec 18 18:04:14 2024 +0700 fix(dashmate): local network starting issues (#2394) commit 71c41ff Author: Ivan Shumkov <ivan@shumkov.ru> Date: Wed Dec 18 18:03:55 2024 +0700 perf(dpp): reduce JS binding size by 3x (#2396) commit 21ec393 Author: lklimek <842586+lklimek@users.noreply.github.com> Date: Wed Dec 18 10:47:58 2024 +0100 build!: update rust to 1.83 - backport #2393 to v1.7 (#2398) commit d7143cc Author: lklimek <842586+lklimek@users.noreply.github.com> Date: Wed Dec 18 08:53:53 2024 +0100 build!: optimize for x86-64-v3 cpu microarchitecture (Haswell+) (#2374) commit d318b1c Author: lklimek <842586+lklimek@users.noreply.github.com> Date: Tue Dec 17 14:56:15 2024 +0100 build: bump wasm-bindgen to 0.2.99 (#2395) commit 889d192 Author: Ivan Shumkov <ivan@shumkov.ru> Date: Tue Dec 17 19:25:58 2024 +0700 chore(release): update changelog and bump version to 1.8.0-dev.1 (#2391) commit 8185d21 Author: lklimek <842586+lklimek@users.noreply.github.com> Date: Tue Dec 17 10:47:53 2024 +0100 feat(sdk)!: allow setting CA cert (#1924) commit 82a6217 Author: lklimek <842586+lklimek@users.noreply.github.com> Date: Tue Dec 17 02:51:18 2024 +0100 build!: update rust to 1.83 (#2393) commit 494054a Author: QuantumExplorer <quantum@dash.org> Date: Mon Dec 16 13:47:58 2024 +0300 refactor(platform): replace bls library (#2257) Co-authored-by: Lukasz Klimek <842586+lklimek@users.noreply.github.com> commit 4c203e4 Author: lklimek <842586+lklimek@users.noreply.github.com> Date: Mon Dec 16 10:38:34 2024 +0100 test(sdk): generate test vectors using testnet (#2381) commit 0ff6b27 Author: lklimek <842586+lklimek@users.noreply.github.com> Date: Mon Dec 16 10:37:35 2024 +0100 chore: remove deprecated check_network_version.sh (#2084) commit b265bb8 Author: lklimek <842586+lklimek@users.noreply.github.com> Date: Fri Dec 13 13:25:40 2024 +0100 ci: fix artifact upload issue on release build (#2389) commit 40ae73f Author: Ivan Shumkov <ivan@shumkov.ru> Date: Fri Dec 13 17:35:40 2024 +0700 chore(release): update changelog and bump version to 1.7.0 (#2387) commit 257e3da Author: Ivan Shumkov <ivan@shumkov.ru> Date: Fri Dec 13 15:44:10 2024 +0700 chore(dashmate)!: update Core to version 22 (#2384) commit 19a4c6d Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Dec 12 18:30:14 2024 +0700 chore(dashmate): set tenderdash version to 1 (#2385) commit 0e9d4dc Author: lklimek <842586+lklimek@users.noreply.github.com> Date: Thu Dec 12 11:39:35 2024 +0100 chore: address vulnerabilty GHSA-mwcw-c2x4-8c55 (#2382) Co-authored-by: Ivan Shumkov <ivan@shumkov.ru> commit bdae90c Author: Ivan Shumkov <ivan@shumkov.ru> Date: Thu Dec 12 13:36:04 2024 +0700 chore(dashmate): increase subsidy for devnet (#2353)
Issue being fixed or feature implemented
Core 22 contains includes bug fixes for withdrawal-related logic:
Since they already activated on mainnet we need to apply corresponding changes on the platform side.
What was done?
How Has This Been Tested?
Locally and on devnet
Breaking Changes
None
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit
Release Notes
New Features
Improvements
Technical Updates