feat(platform)!: fees for data contract creation and update#2584
Conversation
|
""" WalkthroughThis update introduces a versioned registration cost calculation for data contracts, separating registration and validation fee logic. New modules and structs are added to represent registration and validation fee versions, with explicit fields for various cost components (e.g., document types, indexes, tokens, keywords). The control flow for processing paid execution events is refactored to handle an additional fixed registration cost fee for data contract creation and update actions. Platform version 9 is updated to use the new fee version, enabling registration fees for data contracts. Numerous tests are updated to reflect new fee calculations and increased initial credit balances. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Platform
participant FeeModule
participant DataContract
User->>Platform: Submit DataContractCreate/Update
Platform->>DataContract: registration_cost(platform_version)
DataContract->>Platform: Result<u64, ProtocolError>
Platform->>FeeModule: Validate fees (base + registration cost)
FeeModule-->>Platform: Fee validation result
Platform->>Platform: paid_function(...) (apply fees, update balance)
Platform-->>User: Execution result (success or error)
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (18)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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: 2
🔭 Outside diff range comments (2)
packages/rs-platform-version/src/version/fee/mod.rs (2)
11-13:⚠️ Potential issueMissing import of
FEE_VERSION2
FEE_VERSION2is declared in the newv2module but is never brought into scope.
Without the import the suggested fix forFEE_VERSIONS(next comment) will not compile.-use crate::version::fee::v1::FEE_VERSION1; +use crate::version::fee::v1::FEE_VERSION1; +use crate::version::fee::v2::FEE_VERSION2;
29-29:⚠️ Potential issue
FEE_VERSIONSdoes not expose version 2 – platform v9 will panic
PlatformVersion::v9()references fee-version 2, but the static array that backs
FeeVersion::getonly containsFEE_VERSION1.
A lookup withFeeVersion::get(2)will therefore returnNoneand trigger the
UnknownVersionError, effectively bricking any node that enables platform v9.-pub const FEE_VERSIONS: &[FeeVersion] = &[FEE_VERSION1]; +pub const FEE_VERSIONS: &[FeeVersion] = &[FEE_VERSION1, FEE_VERSION2];
♻️ Duplicate comments (13)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_update/mod.rs (13)
717-717: Duplicate: Ensure initial balance covers new registration fees in test
840-840: Duplicate: Ensure initial balance covers new registration fees in test
969-969: Duplicate: Ensure initial balance covers new registration fees in test
1083-1083: Duplicate: Ensure initial balance covers new registration fees in test
1237-1237: Duplicate: Ensure initial balance covers new registration fees in test
1339-1339: Duplicate: Ensure initial balance covers new registration fees in test
1439-1439: Duplicate: Ensure initial balance covers new registration fees in test
1545-1545: Duplicate: Ensure initial balance covers new registration fees in test
1650-1650: Duplicate: Ensure initial balance covers new registration fees in test
1737-1737: Duplicate: Ensure initial balance covers new registration fees in test
2533-2533: Duplicate: Ensure initial balance covers new registration fees in test
2835-2835: Duplicate: Ensure initial balance covers new registration fees in test
2897-2897: Duplicate: Ensure initial balance covers new registration fees in test
🧹 Nitpick comments (5)
packages/rs-platform-version/src/version/dpp_versions/dpp_contract_versions/mod.rs (1)
28-28: Add documentation for the newregistration_costfield.
Consider adding a///doc comment abovepub registration_cost: FeatureVersionto explain that it governs the dispatch for data contract registration cost calculations.packages/rs-drive-abci/src/execution/check_tx/v0/mod.rs (1)
462-462: Improved test assertions for better error reporting.Changed assertions from
assert!(validation_result.errors.is_empty())toassert_eq!(validation_result.errors.as_slice(), &[]), which will provide more helpful error messages by showing the actual errors when assertion fails.Also applies to: 605-605, 809-809, 959-959, 1113-1113, 1466-1466, 1679-1679, 2176-2176, 2576-2576, 3010-3010, 3312-3312
packages/rs-dpp/src/data_contract/methods/registration_cost/mod.rs (1)
47-84: Consider reducing duplication between implementationsThe implementations for
DataContractandDataContractInSerializationFormatare nearly identical, including documentation. Consider extracting the common logic to a shared private function to reduce duplication and maintenance burden.+ fn registration_cost_impl<T>( + registration_cost_version: u32, + registration_cost_v1_fn: impl FnOnce() -> u64, + ) -> Result<u64, ProtocolError> { + match registration_cost_version { + 0 => Ok(0), // Before 2.0 it's just 0 (There was some validation cost) + 1 => Ok(registration_cost_v1_fn()), + version => Err(ProtocolError::UnknownVersionMismatch { + method: "DataContract::registration_cost".to_string(), + known_versions: vec![0, 1], + received: version, + }), + } + } + impl DataContract { pub fn registration_cost( &self, platform_version: &PlatformVersion, ) -> Result<u64, ProtocolError> { - match platform_version - .dpp - .contract_versions - .methods - .registration_cost - { - 0 => Ok(0), // Before 2.0 it's just 0 (There was some validation cost) - 1 => Ok(self.registration_cost_v1(platform_version)), - version => Err(ProtocolError::UnknownVersionMismatch { - method: "DataContract::registration_cost".to_string(), - known_versions: vec![0, 1], - received: version, - }), - } + registration_cost_impl( + platform_version.dpp.contract_versions.methods.registration_cost, + || self.registration_cost_v1(platform_version), + ) } } impl DataContractInSerializationFormat { // Documentation omitted for brevity pub fn registration_cost( &self, platform_version: &PlatformVersion, ) -> Result<u64, ProtocolError> { - match platform_version - .dpp - .contract_versions - .methods - .registration_cost - { - 0 => Ok(0), // Before 2.0 it's just 0 (There was some validation cost) - 1 => Ok(self.registration_cost_v1(platform_version)), - version => Err(ProtocolError::UnknownVersionMismatch { - method: "DataContract::registration_cost".to_string(), - known_versions: vec![0, 1], - received: version, - }), - } + registration_cost_impl( + platform_version.dpp.contract_versions.methods.registration_cost, + || self.registration_cost_v1(platform_version), + ) } }packages/rs-dpp/src/data_contract/methods/registration_cost/v1/mod.rs (2)
35-49: Index-fee classification misses composite (contested + unique)
contested_index.is_some()already implies uniqueness, yet the branches are
mutually exclusive. If at some point we decide to apply both the contested
and the unique fee (spec allows it), this logic will need to change. Capture
this in a unit-test or leave a comment clarifying the intended precedence.
99-158: Duplicate implementation – extract a helperThe two
registration_cost_v1functions are byte-for-byte copies except for
schema traversal. A small helper that accepts iterators over
DocumentType/IndexandTokenConfigurationwould remove ~130 LoC and keep
future fee tweaks DRY.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (27)
packages/rs-dpp/src/data_contract/document_type/class_methods/mod.rs(2 hunks)packages/rs-dpp/src/data_contract/document_type/mod.rs(1 hunks)packages/rs-dpp/src/data_contract/methods/mod.rs(1 hunks)packages/rs-dpp/src/data_contract/methods/registration_cost/mod.rs(1 hunks)packages/rs-dpp/src/data_contract/methods/registration_cost/v1/mod.rs(1 hunks)packages/rs-dpp/src/fee/fee_result/mod.rs(1 hunks)packages/rs-dpp/src/validation/operations.rs(2 hunks)packages/rs-drive-abci/src/execution/check_tx/v0/mod.rs(26 hunks)packages/rs-drive-abci/src/execution/platform_events/state_transition_processing/execute_event/v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/platform_events/state_transition_processing/validate_fees_of_event/v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/types/execution_event/mod.rs(6 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/common/validate_simple_pre_check_balance/v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/mod.rs(35 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_update/mod.rs(16 hunks)packages/rs-platform-version/src/version/dpp_versions/dpp_contract_versions/mod.rs(1 hunks)packages/rs-platform-version/src/version/dpp_versions/dpp_contract_versions/v1.rs(1 hunks)packages/rs-platform-version/src/version/dpp_versions/dpp_contract_versions/v2.rs(1 hunks)packages/rs-platform-version/src/version/fee/data_contract/mod.rs(0 hunks)packages/rs-platform-version/src/version/fee/data_contract_registration/mod.rs(1 hunks)packages/rs-platform-version/src/version/fee/data_contract_registration/v1.rs(1 hunks)packages/rs-platform-version/src/version/fee/data_contract_registration/v2.rs(1 hunks)packages/rs-platform-version/src/version/fee/data_contract_validation/mod.rs(1 hunks)packages/rs-platform-version/src/version/fee/data_contract_validation/v1.rs(1 hunks)packages/rs-platform-version/src/version/fee/mod.rs(4 hunks)packages/rs-platform-version/src/version/fee/v1.rs(2 hunks)packages/rs-platform-version/src/version/fee/v2.rs(1 hunks)packages/rs-platform-version/src/version/v9.rs(2 hunks)
💤 Files with no reviewable changes (1)
- packages/rs-platform-version/src/version/fee/data_contract/mod.rs
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/src/mimic/test_quorum.rs:159-164
Timestamp: 2024-11-20T16:16:01.830Z
Learning: QuantumExplorer prefers not to receive auto-generated messages asking to post on social media.
🧬 Code Graph Analysis (2)
packages/rs-dpp/src/data_contract/methods/mod.rs (1)
packages/rs-dpp/src/data_contract/methods/registration_cost/mod.rs (2)
registration_cost(26-44)registration_cost(65-83)
packages/rs-dpp/src/data_contract/methods/registration_cost/v1/mod.rs (3)
packages/rs-platform-value/src/inner_value.rs (1)
inner_optional_array_slice_value(832-839)packages/rs-dpp/src/data_contract/document_type/index/mod.rs (1)
property_names(318-323)packages/rs-dpp/src/fee/fee_result/mod.rs (2)
try_from(68-74)try_from(79-89)
⏰ Context from checks skipped due to timeout of 90000ms (20)
- GitHub Check: Rust packages (dapi-grpc) / Check each feature
- GitHub Check: Rust packages (dapi-grpc) / Tests
- GitHub Check: Rust packages (drive-abci) / Linting
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (drive-abci) / Formatting
- GitHub Check: Rust packages (drive-abci) / Tests
- GitHub Check: Rust packages (drive-abci) / Unused dependencies
- GitHub Check: Rust packages (drive) / Unused dependencies
- GitHub Check: Rust packages (drive) / Linting
- GitHub Check: Rust packages (drive) / Tests
- GitHub Check: Rust packages (dapi-grpc) / Linting
- GitHub Check: Rust packages (wasm-dpp) / Unused dependencies
- GitHub Check: Rust packages (dapi-grpc) / Unused dependencies
- GitHub Check: Rust packages (wasm-dpp) / Tests
- GitHub Check: Rust packages (wasm-dpp) / Linting
- GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Rust crates security audit
- GitHub Check: Build JS packages / Build JS
🔇 Additional comments (76)
packages/rs-dpp/src/data_contract/methods/mod.rs (1)
2-2: Approve addition ofregistration_costmodule.
The newmod registration_cost;declaration correctly integrates the versioned registration cost logic into the DPP methods structure.packages/rs-dpp/src/data_contract/document_type/mod.rs (1)
41-41: Approve visibility change ofproperty_names.
Updatingmod property_namestopub(crate) mod property_namesappropriately exposes shared constants across the crate while keeping them hidden from external consumers.packages/rs-platform-version/src/version/dpp_versions/dpp_contract_versions/v2.rs (1)
24-24: Verifyregistration_costversion in V2.
Settingregistration_cost: 1enables detailed fee calculations for protocol 2.0. Please confirm that all downstream code (e.g., platform V9, drive-ABCI handlers, and tests) references this version correctly.packages/rs-platform-version/src/version/dpp_versions/dpp_contract_versions/v1.rs (1)
24-24: Confirm default registration cost behavior for V1.
Withregistration_cost: 0, pre-2.0 protocol versions incur no registration fee. Verify that no code paths mistakenly apply registration costs when using CONTRACT_VERSIONS_V1.packages/rs-platform-version/src/version/fee/data_contract_validation/v1.rs (2)
1-1: Import path correctly updatedThe import path has been correctly updated to reflect the new module structure, maintaining proper namespacing for the validation-specific fee version.
6-6: Field name aligned with struct definitionThe field name has been properly renamed from
document_type_size_feetodocument_type_schema_size_feeto align with the newFeeDataContractValidationVersionstruct definition, improving consistency across the codebase.packages/rs-dpp/src/fee/fee_result/mod.rs (1)
213-213: Arithmetic overflow protection addedGood change. Using
saturating_addinstead of the standard addition operator ensures the calculation won't overflow and panic but will instead saturate at the maximumCreditsvalue, improving robustness when dealing with large fee values.packages/rs-platform-version/src/version/v9.rs (2)
24-24: Updated fee version importThe import has been correctly updated to use
FEE_VERSION2which includes the new data contract registration fee structure.
61-61: Platform version updated to use new fee versionThe
PLATFORM_V9constant now usesFEE_VERSION2, enabling the new data contract registration fee structure as described in the PR objectives. The added comment provides clear context about the purpose of this change.packages/rs-platform-version/src/version/fee/data_contract_registration/v1.rs (1)
1-15: Registration fee baseline correctly establishedThis new file correctly establishes a baseline version (
FEE_DATA_CONTRACT_REGISTRATION_VERSION1) where all registration fees are set to zero, providing backward compatibility for versions before Protocol version 9. The comment on line 3 clearly explains the purpose of this constant.The comprehensive structure includes all the fee components mentioned in the PR objectives:
- Base contract registration fee
- Document type registration fee
- Various index registration fees (non-unique, unique, contested)
- Token registration and distribution fees
- Search keyword fee
This serves as a clean baseline for the introduction of actual fees in subsequent versions.
packages/rs-platform-version/src/version/fee/v1.rs (1)
1-2: Fee structure refactoring looks goodThe changes here correctly separate data contract validation fees from registration fees by splitting the previous single import into two distinct imports and updating the
FeeVersionstruct fields accordingly. This aligns with the PR objective to introduce a new fee model for data contract operations.Also applies to: 18-19
packages/rs-dpp/src/validation/operations.rs (1)
17-18: Updated validation operations to use new fee structureThe modifications correctly update all references from the old
data_contractfield to the newdata_contract_validationnamespace throughout the fee calculation logic. This ensures consistent use of the separated fee structure across the codebase.Also applies to: 22-23, 29-30, 40-41, 44-45, 50-51, 54-55
packages/rs-platform-version/src/version/fee/data_contract_registration/v2.rs (1)
3-15: New fee structure matches PR objectivesThe implementation correctly defines the fee structure for data contract registration in protocol version 9 with values matching the PR objectives:
- 0.1 Dash base fee
- 0.02 Dash per document type
- 0.01 Dash per non-unique/unique index
- 1 Dash for contested indexes
- 0.1 Dash for various token options and search keywords
The code uses clear, descriptive field names with inline comments showing Dash equivalents, making the fee structure transparent.
packages/rs-drive-abci/src/execution/validation/state_transition/common/validate_simple_pre_check_balance/v0/mod.rs (3)
5-6: Added necessary imports for data contract transition accessorsThese imports provide access to the data contract accessors needed for the registration cost calculation, enabling the validation logic to retrieve the data contract from the transition objects.
26-36: Updated minimum balance calculation for DataContractCreateThe implementation now correctly includes the data contract registration cost in addition to the base contract creation fee. Using
saturating_addis a good practice to prevent overflow, ensuring the system remains robust even with very large fee values.
37-47: Updated minimum balance calculation for DataContractUpdateSimilar to the create operation, the update logic now properly includes the registration cost in the minimum balance calculation. This ensures users have sufficient funds for both the base fee and the new registration costs associated with their data contract changes.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_update/mod.rs (2)
613-613: Ensure initial balance covers new registration fees in test
The setup identity’s credits have been bumped todash_to_credits!(1.0)to accommodate the new data contract registration and update fees.
2455-2455: Set high initial balance for validation-only tests
For the invalid‐keywords tests, the identity’s credits are increased to10.0Dash to isolate keyword validation errors (rather than insufficient‐funds errors).packages/rs-platform-version/src/version/fee/v2.rs (2)
1-9: Imports: fee version components
The newFEE_DATA_CONTRACT_REGISTRATION_VERSION2import correctly references the v2 registration fee parameters alongside existing v1 fee modules.
11-23: Define FEE_VERSION2 for protocol v9
FEE_VERSION2aggregates v1 fee components with onlydata_contract_registrationupdated to version 2, matching the new fee structure. Thefee_version_numberanduses_version_fee_multiplier_permillelook correct for protocol 9.packages/rs-drive-abci/src/execution/check_tx/v0/mod.rs (3)
562-564: Fee structure update: Identity balance increased to accommodate new costs.The initial balance is now set to 25_000_000_000 (0.25 Dash) to account for the new data contract registration fee structure introduced in this PR. This ensures tests can pass with the higher fee requirements.
633-636: Significant fee increase reflecting new data contract registration costs.The expected processing fee increased from a much smaller value to 24002489210, which aligns with the introduction of the new fixed base contract registration fee (0.1 Dash) plus additional fees for document types, indexes, and other contract components.
1147-1151: Added base cost and updated fee calculation.The comment and updated assertion correctly reflect that the user fee increase now applies on top of the new base costs of 24_000_000_000, properly calculating the expected total fee.
packages/rs-dpp/src/data_contract/document_type/class_methods/mod.rs (2)
12-25: Visibility change: Function made visible within crate.Changed
consensus_or_protocol_data_contract_errorfrom private topub(crate)to support the new registration cost calculation functionality. This function is likely needed by other components in the crate that deal with error handling during data contract processing.
28-41: Visibility change: Error conversion function made available within crate.Modified
consensus_or_protocol_value_errorto be accessible within the crate. This enables other components to properly handle platform value errors in a consistent way, supporting the new fee structure implementation.packages/rs-drive-abci/src/execution/platform_events/state_transition_processing/validate_fees_of_event/v0/mod.rs (3)
104-105: Added support for additional fixed fee cost.Updated the
ExecutionEvent::Paidvariant pattern to capture the newadditional_fixed_fee_costfield, which will contain the data contract registration fee when applicable.
135-140: Enhanced fee validation to include fixed registration cost.Modified fee calculation to incorporate the optional additional fixed fee cost, ensuring that data contract registration fees are properly accounted for during balance validation. This is a critical part of implementing the new fee structure described in the PR objectives.
-let total_fee = estimated_fee_result.total_base_fee(); +let mut required_balance = estimated_fee_result.total_base_fee(); + +if let Some(additional_fee_cost) = additional_fee_cost { + required_balance += *additional_fee_cost; +}
141-141: Updated balance check to use new required balance variable.Correctly using the new
required_balancevariable (which may include additional fixed costs) to verify the identity has sufficient funds.packages/rs-platform-version/src/version/fee/data_contract_validation/mod.rs (1)
1-14: New fee structure for data contract validation.Introduced a well-structured approach to defining data contract validation fees. The
FeeDataContractValidationVersionstruct provides a comprehensive set of fee parameters for document types, including:
- Base fees for document types
- Fees based on schema size
- Per-property fees
- Fees for unique and non-unique indexes
This supports the PR objective of implementing a detailed fee structure for data contract operations, separating validation fees from registration fees.
packages/rs-drive-abci/src/execution/types/execution_event/mod.rs (4)
36-37: Well-structured addition of fixed fee mechanismThe new field
additional_fixed_fee_costis properly documented and typed asOption<Credits>, providing a clear separation between regular processing fees and fixed registration costs that don't apply the user fee increase.
201-222: Appropriate implementation of data contract creation feesThe implementation correctly calculates and applies the registration cost for data contract creation. The code retrieves the cost from the data contract itself, ensuring that the fee calculation logic stays encapsulated within the data contract implementation.
223-246: Consider optimizing update costs in the futureThe current implementation charges the full registration cost for contract updates, regardless of the extent of changes. As noted in the comments, this is a pragmatic approach for now but might warrant optimization in the future to only charge for the actual changes.
Based on the PR description, is this full-cost approach for updates aligned with the economic model you intended to implement? If not, consider creating a technical debt ticket to track implementing incremental update costs in the future.
140-141: Consistent initialization of additional_fixed_fee_costThe code consistently initializes the new
additional_fixed_fee_costfield toNonefor all other state transition actions, maintaining a clean baseline where only data contract operations incur these fixed costs.Also applies to: 160-161, 180-181, 257-258
packages/rs-dpp/src/data_contract/methods/registration_cost/mod.rs (1)
1-45: Well-designed versioned registration cost implementation for DataContractThe registration cost implementation for
DataContractfollows good design patterns:
- Clean version dispatching based on platform version configuration
- Appropriate error handling for unknown versions
- Thorough documentation including version behavior
- Backward compatibility with version 0 (pre-2.0) returning zero cost
The implementation correctly encapsulates the fee calculation logic within the data contract module, which is where it logically belongs.
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/mod.rs (36)
217-278: Well-designed test for contested unique index registration feeThis test thoroughly verifies the new fee structure for data contracts with contested unique indexes. It properly sets up an identity with sufficient credits (2.0 Dash) to accommodate the higher fees introduced in this PR, then creates and processes a data contract with a contested unique index.
280-342: Good compatibility testing for previous platform versionThis test verifies that older platform versions (v8) can still process data contracts with contested unique indexes using a lower credit balance (0.1 Dash), confirming backward compatibility with pre-fee structure versions.
353-354: Appropriate adjustment of test credit balanceThe credit balance was increased from 0.1 to 2.0 Dash to accommodate the new fee structure, ensuring this test continues to pass with the higher fees for data contract operations.
416-417: Proper test balance update for contested unique index scenarioThe credit balance increase ensures this test remains valid with the new fee structure for data contracts that contain contested unique indexes.
494-495: Adjusted credit balance for token contract testThis test required an increased credit balance to accommodate the combined costs of data contract registration fees and token-related fees.
587-588: Updated credit balance for token contract with group testThe increased credit balance ensures the test can successfully cover both data contract registration and token group registration fees.
715-716: Adjusted credit balance for token contract with starting balance testThe test credit balance was increased to accommodate the new fee structure when testing tokens with initial balances.
809-811: Updated credit balance for token burn testThe test now provides sufficient credits for the combined costs of data contract registration and token burn configuration.
914-915: Credit balance increase for token transfer testThe test now provides 1.0 Dash in credits to cover the fees for creating a data contract with token transfer configuration.
1021-1022: Updated credit balance for token identifier testThe test balance was increased to accommodate the new fee structure when testing token identifiers.
1126-1128: Adjusted credit balance for external token testThe increased credit balance ensures this test can cover the higher fees associated with external token configurations.
1249-1251: Updated credit for perpetual token distribution testThe increased credit balance accommodates the additional fees for token perpetual distribution rules added in this PR.
1369-1371: Adjusted credit for pre-programmed distribution testThe credit balance increase ensures the test can cover the combined cost of data contract registration and pre-programmed token distribution configurations.
1553-1555: Increased credit balance for token supply limit testThe test now provides enough credits to cover the fees associated with testing token supply limits.
1647-1649: Updated test credit balance for testing group existenceThe increased credit balance ensures the test can pay the fees associated with data contract and group creation.
1760-1762: Adjusted credit for main group testThe credit balance was increased to accommodate the fees for testing main control group configurations in tokens.
1874-1876: Updated credit balance for token identifier error testThe test now provides enough credits to cover fees when testing error conditions with token identifiers.
1982-1984: Increased credit for token destination identity testThe credit balance was adjusted to ensure the test can cover fees when testing token destination identities.
2081-2083: Updated credit for pre-programmed distribution identity testThe credit balance increase ensures sufficient funds are available when testing pre-programmed distribution with identities.
2216-2218: Adjusted credit for external token burn testThe increased credit balance ensures this test can cover the fees associated with testing external token burn operations.
2343-2345: Credit increase for perpetual distribution error testThe test now provides enough credits to cover fees when testing error conditions with token perpetual distribution.
2461-2463: Adjusted credit for random distribution testingThe increased credit balance ensures this test can cover fees when testing random distribution functionality.
2570-2571: Updated credit for non-contiguous groups testThe credit balance was increased to accommodate the fees for testing error conditions with non-contiguous groups.
2701-2702: Increased credit for zero power group member testThe test now provides enough credits to cover fees when testing group members with zero power.
2829-2830: Updated credit for testing group members with high powerThe credit balance was adjusted to ensure sufficient funds when testing group members with large power values.
2958-2959: Increased credit for group power threshold testingThe test now provides enough credits to cover the fees when testing group power thresholds.
3086-3087: Credit adjustment for non-unilateral group power testThe increased credit balance ensures this test can cover fees when testing non-unilateral group power conditions.
3214-3215: Updated credit for group with member with too much powerThe credit balance was increased to accommodate the fees for testing group members with excessive power.
3357-3358: Increased credit for keyword limit testThis test now provides enough credits to handle the combined costs of data contract registration and keyword-related fees.
3440-3441: Adjusted credit for duplicate keywords testThe credit balance was increased to ensure the test can pay the fees associated with testing duplicate keywords validation.
3524-3525: Credit increase for keyword length testThe test now provides enough credits to cover fees when testing keyword length constraints.
3598-3599: Updated credit for keyword max length testThe credit balance was adjusted to accommodate the fees for testing maximum keyword length validation.
3669-3670: Increased credit for valid keywords testThe test now provides enough credits to handle the combined costs of data contract registration with valid keywords.
3868-3869: Credit adjustment for description length testThe increased credit balance ensures this test can cover fees when testing description length constraints.
3923-3924: Updated credit for description max length testThe credit balance was increased to accommodate the fees for testing maximum description length validation.
3980-3981: Increased credit for valid description testThis test now provides enough credits to cover the fees associated with data contract registration that includes a valid description.
packages/rs-platform-version/src/version/fee/data_contract_registration/mod.rs (4)
1-5: Well-structured module organization with versioning supportThe module correctly uses versioning (v1 and v2) to support backward compatibility while introducing the new fee structure. The imports are appropriate for the serialization needs of the fee structure.
6-9: Clear documentation explaining the fee purposeThe documentation clearly explains that these fees are specifically for registration actions and are separate from validation fees, which will be charged separately during re-validation for data contract updates.
9-21: Well-designed fee structure with appropriate traitsThe
FeeDataContractRegistrationVersionstruct implements all necessary traits for serialization, cloning, and comparison. The fee structure aligns perfectly with the PR objectives, defining specific fee types for:
- Base contract registration (0.1 Dash)
- Document type registration (0.02 Dash)
- Various index types (0.01 Dash for non-unique and unique, 1 Dash for contested)
- Token registration (0.1 Dash)
- Distribution rules (0.1 Dash each for perpetual and pre-programmed)
- Search keywords (0.1 Dash each)
15-16: Good clarification for contested index feesThe comment effectively clarifies that contested indexes are a special case of unique indexes, and the contested index fee replaces (not adds to) the unique index fee for affected indexes.
packages/rs-platform-version/src/version/fee/mod.rs (1)
16-18:data_contract_validationmade privateThe module is now declared as
mod data_contract_validation;.
If external crates (e.g.dpp) used to access types inside this module, they
will no longer compile. Double-check the visibility requirements and switch to
pub modif external access is still needed.packages/rs-drive-abci/src/execution/platform_events/state_transition_processing/execute_event/v0/mod.rs (1)
62-68: Order of operations matches spec – good jobAdding
additional_fixed_fee_costafter applying the user-selected fee
multiplier guarantees the “fixed” part stays untouched, exactly as described
in the PR objectives.
QuantumExplorer
left a comment
QuantumExplorer
left a comment
There was a problem hiding this comment.
Self reviewed.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/platform-test-suite/test/e2e/contacts.spec.js (1)
224-224: Consider updating Alice's funding amount for consistency.While Alice doesn't create data contracts in this test, I notice her funding remains at 500,000 units while Bob's was increased to 100,000,000. For future-proofing and consistency across test cases, consider increasing Alice's funding as well, especially if she might need to perform operations that could incur higher fees under the new model.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/platform-test-suite/test/e2e/contacts.spec.js(1 hunks)packages/platform-test-suite/test/functional/platform/Identity.spec.js(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/platform-test-suite/test/functional/platform/Identity.spec.js
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/src/mimic/test_quorum.rs:159-164
Timestamp: 2024-11-20T16:16:01.830Z
Learning: QuantumExplorer prefers not to receive auto-generated messages asking to post on social media.
🧬 Code Graph Analysis (1)
packages/platform-test-suite/test/e2e/contacts.spec.js (1)
packages/platform-test-suite/test/functional/platform/Identity.spec.js (1)
createClientWithFundedWallet(7-7)
⏰ Context from checks skipped due to timeout of 90000ms (19)
- GitHub Check: Rust packages (dash-sdk) / Formatting
- GitHub Check: Rust packages (dapi-grpc) / Check each feature
- GitHub Check: Rust packages (dapi-grpc) / Tests
- GitHub Check: Rust packages (rs-dapi-client) / Formatting
- GitHub Check: Rust packages (dash-sdk) / Check each feature
- GitHub Check: Rust packages (dash-sdk) / Linting
- GitHub Check: Rust packages (dapi-grpc) / Formatting
- GitHub Check: Rust packages (rs-dapi-client) / Check each feature
- GitHub Check: Rust packages (rs-dapi-client) / Linting
- GitHub Check: Rust packages (rs-dapi-client) / Tests
- GitHub Check: Rust packages (drive) / Tests
- GitHub Check: Rust packages (dapi-grpc) / Unused dependencies
- GitHub Check: Rust packages (drive) / Formatting
- GitHub Check: Rust packages (drive) / Linting
- GitHub Check: Rust packages (drive-abci) / Linting
- GitHub Check: Rust packages (drive-abci) / Check each feature
- GitHub Check: Rust packages (drive-abci) / Tests
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Build JS packages / Build JS
🔇 Additional comments (1)
packages/platform-test-suite/test/e2e/contacts.spec.js (1)
107-107: Appropriate funding adjustment to support new fee structure.The increase from 500,000 to 100,000,000 units (1 Dash) for Bob's wallet is necessary to accommodate the new data contract fee model introduced in this PR. This adjustment ensures Bob has sufficient funds to cover the costs of creating and publishing the data contract (lines 119-122), which now includes additional fees like the base registration fee of 0.1 Dash plus fees for document types and indexes defined in the contract.
* docs: correct data contract error range * docs(api): update token event info * docs(ref): fix contract links * docs: add token fee info to explanation * docs: update token config info and action rules * docs: add token direct purchase info * docs(ref): data contract updates * docs: link updates * docs: add contract fees info Based on dashpay/platform#2584 * docs: add js-sdk connection example for local build
1 participant
Issue being fixed or feature implemented
Data Contract registration was very cheap and represented only the base cost to the network. However as the Dash network needs fees to pay Evonode operators for economic viability we introduce fees for contract operations.
The updated fee model charges for specific components of a data contract to reflect their storage and processing impact on the system:
• base_contract_registration_fee (0.1 Dash):
A fixed fee applied to every data contract, regardless of its content. This represents the baseline cost of anchoring a contract into platform state.
• document_type_registration_fee (0.02 Dash):
A fee per document type defined in the contract. Each document type increases system complexity, requiring indexing and storage schema management.
• document_type_base_non_unique_index_registration_fee (0.01 Dash):
Applied for each non-unique index within a document type. These indexes are needed to perform queries.
• document_type_base_unique_index_registration_fee (0.01 Dash):
Charged per unique index. Unique indexes enforce constraints and ensure data integrity, requiring more validation logic and higher consistency guarantees.
• document_type_base_contested_index_registration_fee (1 Dash):
A significantly higher fee for contested indexes, which are used in username and identity resolution. These indexes require network-wide voting and conflict resolution, making them more burdensome on masternodes and evonodes.
• token_registration_fee (0.1 Dash):
Fee charged for each token declared within the contract. Token logic adds on-chain accounting, distribution logic, and balance management overhead.
• token_uses_perpetual_distribution_fee (0.1 Dash):
Additional fee for tokens that define perpetual distribution rules, such as block-based emissions. This introduces ongoing state changes and network-triggered logic.
• token_uses_pre_programmed_distribution_fee (0.1 Dash):
Charged when a token defines pre-programmed distributions, such as scheduled airdrops. This introduces periodic complexity that needs to be tracked by the platform.
• search_keyword_fee (0.1 Dash per keyword):
Applied per search keyword defined in the contract. These enable reverse lookups and filtering, which expand the on-chain indexing burden.
How Has This Been Tested?
Added tests.
Breaking Changes
This is a breaking change.
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
Refactor
Tests