feat(platform): add token contract info and query#2641
feat(platform): add token contract info and query#2641QuantumExplorer merged 6 commits intov2.0-devfrom
Conversation
|
Caution Review failedThe pull request is closed. WalkthroughThis update introduces a new gRPC endpoint and supporting infrastructure for querying token contract information by token ID. It adds new protobuf messages, request/response handlers, storage paths, proof generation and verification, cost estimation, and versioning support for token contract info. Several method signatures are updated to include contract-specific parameters. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant gRPC Service
participant Platform
participant Drive
Client->>gRPC Service: GetTokenContractInfoRequest(token_id)
gRPC Service->>Platform: query_token_contract_info(request, state, version)
Platform->>Drive: fetch_token_contract_info(token_id, ...)
Drive-->>Platform: TokenContractInfo or None
Platform-->>gRPC Service: GetTokenContractInfoResponse(data/proof)
gRPC Service-->>Client: GetTokenContractInfoResponse
Suggested labels
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (5)
✨ 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 (
|
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
packages/rs-drive/src/drive/tokens/info/prove_identities_token_infos/mod.rs (1)
17-17: Correct parameter name in documentation
The doc comment still refers totoken_ids(plural) but the function signature uses a singletoken_id. Please update the parameter name and description to match the signature.Proposed diff:
- /// * `token_ids` - A list of token IDs whose infos are to be proved. + /// * `token_id` - The token ID whose infos are to be proved. + /// * `identity_ids` - A list of identity IDs whose token infos are to be proved.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (47)
packages/dapi-grpc/build.rs(4 hunks)packages/dapi-grpc/protos/platform/v0/platform.proto(3 hunks)packages/rs-dpp/src/tokens/contract_info/methods.rs(1 hunks)packages/rs-dpp/src/tokens/contract_info/mod.rs(1 hunks)packages/rs-dpp/src/tokens/contract_info/v0/mod.rs(1 hunks)packages/rs-dpp/src/tokens/mod.rs(1 hunks)packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs(2 hunks)packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/direct_selling/mod.rs(1 hunks)packages/rs-drive-abci/src/query/service.rs(2 hunks)packages/rs-drive-abci/src/query/token_queries/mod.rs(1 hunks)packages/rs-drive-abci/src/query/token_queries/token_contract_info/mod.rs(1 hunks)packages/rs-drive-abci/src/query/token_queries/token_contract_info/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/contract/insert/insert_contract/v1/mod.rs(4 hunks)packages/rs-drive/src/drive/contract/update/update_contract/v1/mod.rs(1 hunks)packages/rs-drive/src/drive/initialization/v1/mod.rs(2 hunks)packages/rs-drive/src/drive/tokens/balance/prove_identities_token_balances/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/balance/prove_identity_token_balances/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/contract_info/fetch_token_contract_info/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/contract_info/fetch_token_contract_info/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/contract_info/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/contract_info/prove_token_contract_info/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/contract_info/prove_token_contract_info/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/contract_info/queries.rs(1 hunks)packages/rs-drive/src/drive/tokens/estimated_costs/for_token_contract_infos/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/estimated_costs/for_token_contract_infos/v0/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/estimated_costs/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/info/prove_identities_token_infos/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/info/prove_identity_token_infos/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/mod.rs(1 hunks)packages/rs-drive/src/drive/tokens/paths.rs(6 hunks)packages/rs-drive/src/drive/tokens/system/create_token_trees/mod.rs(7 hunks)packages/rs-drive/src/drive/tokens/system/create_token_trees/v0/mod.rs(8 hunks)packages/rs-drive/src/util/batch/grovedb_op_batch/mod.rs(3 hunks)packages/rs-drive/src/verify/tokens/mod.rs(1 hunks)packages/rs-drive/src/verify/tokens/verify_token_contract_info/mod.rs(1 hunks)packages/rs-drive/src/verify/tokens/verify_token_contract_info/v0/mod.rs(1 hunks)packages/rs-platform-version/src/version/dpp_versions/dpp_token_versions/mod.rs(1 hunks)packages/rs-platform-version/src/version/dpp_versions/dpp_token_versions/v1.rs(1 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_query_versions/mod.rs(1 hunks)packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_query_versions/v1.rs(1 hunks)packages/rs-platform-version/src/version/drive_versions/drive_identity_method_versions/mod.rs(1 hunks)packages/rs-platform-version/src/version/drive_versions/drive_identity_method_versions/v1.rs(1 hunks)packages/rs-platform-version/src/version/drive_versions/drive_token_method_versions/mod.rs(2 hunks)packages/rs-platform-version/src/version/drive_versions/drive_token_method_versions/v1.rs(2 hunks)packages/rs-platform-version/src/version/drive_versions/drive_verify_method_versions/mod.rs(1 hunks)packages/rs-platform-version/src/version/drive_versions/drive_verify_method_versions/v1.rs(1 hunks)packages/rs-platform-version/src/version/mocks/v2_test.rs(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 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.
packages/rs-drive/src/drive/tokens/estimated_costs/for_token_contract_infos/mod.rs (1)
Learnt from: QuantumExplorer
PR: dashpay/platform#2431
File: packages/rs-drive/src/drive/tokens/system/fetch_token_total_aggregated_identity_balances/v0/mod.rs:42-50
Timestamp: 2025-01-19T07:36:09.383Z
Learning: The `add_estimation_costs_for_token_balances` method in Drive is a properly implemented estimation logic method used for token balance operations, and the warning about incomplete estimation logic was incorrect.
🧬 Code Graph Analysis (8)
packages/rs-drive/src/verify/tokens/mod.rs (1)
packages/rs-drive/src/verify/tokens/verify_token_contract_info/mod.rs (1)
verify_token_contract_info(45-70)
packages/rs-drive/src/drive/tokens/contract_info/queries.rs (2)
packages/rs-drive/src/drive/initialization/v1/mod.rs (1)
drive(53-146)packages/rs-drive/src/drive/tokens/paths.rs (1)
token_contract_infos_root_path_vec(130-132)
packages/rs-drive/src/verify/tokens/verify_token_contract_info/mod.rs (1)
packages/rs-drive/src/verify/tokens/verify_token_contract_info/v0/mod.rs (1)
verify_token_contract_info_v0(15-53)
packages/rs-dpp/src/tokens/contract_info/methods.rs (1)
packages/rs-dpp/src/tokens/contract_info/v0/mod.rs (8)
contract_id(18-18)contract_id(31-33)set_contract_id(21-21)set_contract_id(35-37)token_contract_position(24-24)token_contract_position(39-41)set_token_contract_position(27-27)set_token_contract_position(43-45)
packages/rs-dpp/src/tokens/contract_info/v0/mod.rs (1)
packages/rs-dpp/src/tokens/contract_info/methods.rs (4)
contract_id(7-11)set_contract_id(13-17)token_contract_position(19-23)set_token_contract_position(25-29)
packages/rs-drive/src/drive/tokens/estimated_costs/for_token_contract_infos/v0/mod.rs (5)
packages/rs-drive/src/drive/initialization/v1/mod.rs (1)
drive(53-146)packages/rs-drive/src/drive/tokens/paths.rs (2)
token_contract_infos_root_path(122-127)tokens_root_path(70-72)packages/rs-drive/src/drive/contract/insert/insert_contract/v1/mod.rs (1)
None(106-106)packages/rs-drive/src/drive/contract/update/update_contract/v1/mod.rs (1)
None(152-152)packages/rs-drive/src/drive/tokens/system/create_token_trees/v0/mod.rs (1)
None(87-87)
packages/rs-drive/src/drive/tokens/contract_info/fetch_token_contract_info/v0/mod.rs (2)
packages/rs-drive/src/drive/initialization/v1/mod.rs (1)
drive(53-146)packages/rs-drive/src/drive/tokens/paths.rs (1)
token_contract_infos_root_path(122-127)
packages/rs-drive/src/drive/tokens/system/create_token_trees/mod.rs (2)
packages/rs-dpp/src/tokens/contract_info/v0/mod.rs (4)
contract_id(18-18)contract_id(31-33)token_contract_position(24-24)token_contract_position(39-41)packages/rs-dpp/src/tokens/contract_info/methods.rs (2)
contract_id(7-11)token_contract_position(19-23)
⏰ Context from checks skipped due to timeout of 90000ms (17)
- GitHub Check: Rust packages (drive-abci) / Detect immutable structure changes
- GitHub Check: Rust packages (drive-abci) / Linting
- GitHub Check: Rust packages (drive-abci) / Formatting
- GitHub Check: Rust packages (drive) / Linting
- GitHub Check: Rust packages (drive) / Formatting
- GitHub Check: Rust packages (drive) / Tests
- GitHub Check: Rust packages (drive) / Unused dependencies
- GitHub Check: Rust packages (wasm-dpp) / Tests
- GitHub Check: Rust packages (wasm-dpp) / Linting
- GitHub Check: Rust packages (dpp) / Tests
- GitHub Check: Rust packages (dpp) / Linting
- GitHub Check: Rust packages (dpp) / Unused dependencies
- GitHub Check: Rust packages (dpp) / Check each feature
- GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
- GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
- GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
- GitHub Check: Build JS packages / Build JS
🔇 Additional comments (77)
packages/rs-drive/src/drive/tokens/balance/prove_identities_token_balances/mod.rs (1)
17-17: Typo fixed in documentation comment.The change corrects “proveed” to “proved” in the
token_idsargument description. This improves readability and accuracy of the doc.packages/rs-dpp/src/tokens/mod.rs (1)
8-8: Add newcontract_infomodule declaration
The newpub mod contract_info;correctly exposes the submodule for token contract info. It follows the existing alphabetical ordering of modules.packages/rs-drive/src/drive/tokens/balance/prove_identity_token_balances/mod.rs (1)
17-17: Typo fix in documentation is correct
The change updates "proveed" to "proved" in thetoken_idsdescription, and the comment now accurately matches thetoken_idsparameter.packages/rs-drive/src/verify/tokens/mod.rs (1)
4-4: Registerverify_token_contract_infosubmodule
Addingmod verify_token_contract_info;integrates the new proof verification functionality. The module ordering remains consistent and alphabetical.packages/rs-drive/src/drive/tokens/info/prove_identity_token_infos/mod.rs (1)
17-17: Typo fix in documentation is correct
The documentation now correctly uses "proved" fortoken_ids, matching the function signaturetoken_ids: &[[u8; 32]].packages/rs-drive-abci/src/query/token_queries/mod.rs (1)
5-5: LGTM! Clean module integration.The addition of the
token_contract_infomodule follows the established pattern and properly integrates the new token contract information query functionality into the existing token queries structure.packages/rs-drive/src/drive/tokens/mod.rs (1)
51-51: LGTM! Proper module organization.The
contract_infomodule addition is well-placed and follows the existing module structure within the tokens subsystem.packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/direct_selling/mod.rs (1)
154-154:Details
❓ Verification inconclusive
Verify the updated expected balance calculation.
The expected buyer credit balance has been updated from
699_868_051_500to699_868_130_120(an increase of ~78,620 credits). This change suggests modifications to fee calculations or transaction costs as part of the token contract info implementation.Please verify that this new expected balance correctly reflects the actual transaction costs and fee structure with the new functionality.
🏁 Script executed:
#!/bin/bash # Description: Verify if there are other similar balance assertion changes in token tests # This will help understand if the balance change is consistent across tests # Search for similar balance assertions in token tests rg -A 2 -B 2 "assert_eq.*credit_balance.*Some\(" packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/ # Search for fee-related changes in token processing rg -A 5 "fee.*token|token.*fee" packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/Length of output: 35661
Confirm updated direct_selling test balances
I’ve checked the
direct_selling/mod.rstests and found bothassert_eq!s forbuyer_credit_balancenow use the new expected values:
Some(699_868_130_120)// 10.0 − 3.0 spent − fees ≃ 7 DASH leftSome(999_987_872_760)// 10.0 − bump action feesNo remaining tests reference the old
699_868_051_500value, so the updates are consistent across this file. Please double-check that these figures accurately reflect the new fee calculations introduced by the token contract info feature.packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_query_versions/mod.rs (1)
37-37: LGTM! Proper versioning support.The addition of the
token_contract_infofield withFeatureVersionBoundstype follows the established pattern and properly enables version management for the new token contract info query functionality.packages/rs-platform-version/src/version/dpp_versions/dpp_token_versions/v1.rs (1)
6-6: LGTM: Proper version constant addition for new feature.The addition of
token_contract_info_default_structure_versionwith version 0 is appropriate for introducing the new token contract info feature. The naming follows the established pattern and the initial version value is correct.packages/rs-platform-version/src/version/drive_versions/drive_verify_method_versions/mod.rs (1)
73-73: LGTM: Consistent addition of verification method version field.The
verify_token_contract_infofield addition follows the established pattern in theDriveVerifyTokenMethodVersionsstruct. The naming is consistent with other verification method fields and properly supports the new token contract info verification functionality.packages/rs-platform-version/src/version/dpp_versions/dpp_token_versions/mod.rs (1)
9-9: LGTM: Essential struct field addition for version system.The
token_contract_info_default_structure_versionfield addition to theDPPTokenVersionsstruct is necessary and correctly typed. This field definition supports the version constant added in v1.rs and maintains consistency in the versioning system.packages/rs-drive/src/drive/tokens/estimated_costs/mod.rs (1)
25-26:Details
✅ Verification successful
LGTM: Proper module declaration with consistent documentation.
The
for_token_contract_infosmodule declaration follows the established pattern and documentation style. The placement is logical alongside other token-related cost estimation modules.Verify that the module file actually exists:
🏁 Script executed:
#!/bin/bash # Description: Verify that the for_token_contract_infos module exists # Expected: The module directory and implementation files should exist fd "for_token_contract_infos" packages/rs-drive/src/drive/tokens/estimated_costs/Length of output: 158
Approve: Verified
for_token_contract_infosmodule exists
- Confirmed the directory
packages/rs-drive/src/drive/tokens/estimated_costs/for_token_contract_infos/is present.- Documentation and placement match existing modules.
LGTM!
packages/rs-platform-version/src/version/mocks/v2_test.rs (1)
262-266: LGTM! Consistent versioning pattern for new token contract info feature.The addition of the
token_contract_infofield follows the established pattern used by other token query features in the platform versioning system. Setting all version bounds to 0 is appropriate for introducing a new feature.packages/rs-platform-version/src/version/drive_versions/drive_identity_method_versions/v1.rs (1)
140-140: LGTM! Appropriate addition of cost estimation support for token contract infos.Adding
for_token_contract_infosto the cost estimation method versions is necessary to support the new token contract info functionality. The field name and version (0) are consistent with the established patterns.packages/rs-drive-abci/src/execution/platform_events/protocol_upgrade/perform_events_on_first_block_of_protocol_change/v0/mod.rs (2)
28-28: LGTM! Import updated to include the new token contract info key.The addition of
TOKEN_CONTRACT_INFO_KEYto the imports is necessary for the protocol upgrade implementation.
418-425: LGTM! Proper token contract info tree initialization during protocol upgrade.The addition of the token contract info tree creation follows the established pattern used for other token-related trees in the same function. Using
grove_insert_if_not_existswith an empty tree is the correct approach for initializing this storage structure during the protocol upgrade to version 9.packages/rs-platform-version/src/version/drive_versions/drive_verify_method_versions/v1.rs (1)
55-55: LGTM! Necessary addition of token contract info verification support.Adding
verify_token_contract_infoto the token verification method versions is essential for supporting proof verification of the new token contract info functionality. The field name and version (0) are consistent with established patterns.packages/rs-platform-version/src/version/drive_versions/drive_identity_method_versions/mod.rs (1)
77-77: LGTM! Versioning field properly added.The new
for_token_contract_infosfield correctly integrates token contract info cost estimation into the platform's versioning framework, following the established pattern of other cost estimation fields.packages/rs-drive/src/drive/tokens/contract_info/mod.rs (1)
1-6: LGTM! Well-organized module structure.The conditional compilation approach correctly separates server-specific functionality (
prove_token_contract_info,fetch_token_contract_info) from always-available query functionality, following good modular design principles.packages/rs-drive/src/drive/tokens/contract_info/queries.rs (1)
5-13: LGTM! Clean and correct query implementation.The
token_contract_info_querymethod is well-implemented:
- Uses the appropriate root path from
token_contract_infos_root_path_vec()- Correctly constructs a single-key PathQuery for specific token lookup
- Sets a reasonable limit of 1 for the query
- Method naming and signature follow established conventions
packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_query_versions/v1.rs (1)
123-127: LGTM! Consistent versioning addition.The new
token_contract_infofield withFeatureVersionBoundsproperly integrates into the ABCI query versioning system, following the established pattern of other token query fields with appropriate initial version bounds.packages/rs-drive/src/drive/initialization/v1/mod.rs (2)
9-11: LGTM: Proper import ordering maintained.The
TOKEN_CONTRACT_INFO_KEYimport is correctly positioned alphabetically within the token constants.
97-101: LGTM: Consistent initialization pattern followed.The token contract info tree initialization follows the exact same pattern as other token subtrees, creating an empty tree at the appropriate path. The positioning after
TOKEN_DIRECT_SELL_PRICE_KEYis logical.packages/rs-platform-version/src/version/drive_versions/drive_token_method_versions/mod.rs (2)
39-39: LGTM: Proper versioning field added.The
token_contract_infofield is correctly added toDriveTokenFetchMethodVersionswith the appropriateFeatureVersiontype, following the established pattern.
55-55: LGTM: Consistent versioning across method types.The
token_contract_infofield is properly added toDriveTokenProveMethodVersions, maintaining consistency with the fetch methods versioning.packages/dapi-grpc/build.rs (4)
76-76: LGTM: Array size correctly updated.The
VERSIONED_REQUESTSarray size is properly incremented from 42 to 43 to accommodate the newGetTokenContractInfoRequest.
113-113: LGTM: Request message properly registered.The
GetTokenContractInfoRequestis correctly added to the versioned requests array, enabling proper gRPC message handling.
130-130: LGTM: Response array size correctly updated.The
VERSIONED_RESPONSESarray size is properly incremented from 40 to 41 to accommodate the newGetTokenContractInfoResponse.
165-165: LGTM: Response message properly registered.The
GetTokenContractInfoResponseis correctly added to the versioned responses array, completing the gRPC endpoint registration.packages/rs-drive/src/util/batch/grovedb_op_batch/mod.rs (3)
10-12: LGTM: Import list properly updated.The
TokenContractInfoRootvariant is correctly added to the import list in the appropriate alphabetical position.
65-65: LGTM: Enum variant properly defined.The
TokenContractInfoRootvariant is correctly added to theKnownPathenum with the appropriate level comment (Level 2), maintaining consistency with other token path variants.
253-255: LGTM: Readable path formatting implemented correctly.The new match arm for
TOKEN_CONTRACT_INFO_KEYfollows the established pattern perfectly, providing descriptive formatting and returning the appropriateTokenContractInfoRootvariant for continued path resolution.packages/rs-drive/src/drive/contract/update/update_contract/v1/mod.rs (1)
234-235: LGTM! Proper parameter addition for token contract info support.The addition of
contract.id()and*token_posparameters to thecreate_token_trees_operationscall correctly provides the necessary contract and token position information for the token contract info feature implementation.packages/rs-platform-version/src/version/drive_versions/drive_token_method_versions/v1.rs (2)
23-23: LGTM! Proper versioning for new token contract info fetch method.The addition of
token_contract_info: 0toDriveTokenFetchMethodVersionscorrectly establishes the initial version for the new token contract info fetch functionality.
37-37: LGTM! Proper versioning for new token contract info prove method.The addition of
token_contract_info: 0toDriveTokenProveMethodVersionscorrectly establishes the initial version for the new token contract info proof functionality.packages/rs-drive/src/drive/contract/insert/insert_contract/v1/mod.rs (4)
14-14: LGTM! Necessary import for token contract info path handling.The import of
token_contract_infos_root_pathis required for the token contract info storage implementation added later in the file.
24-24: LGTM! Necessary import for token contract info data structure.The import of
TokenContractInfois required for creating and storing token contract information during contract insertion.
187-190: LGTM! Proper cost estimation for token contract info feature.The addition of
add_estimation_costs_for_token_contract_infoscorrectly includes cost estimation for the new token contract info storage, following the established pattern for other token-related cost estimations.
267-279: LGTM! Correct implementation of token contract info storage.The implementation properly:
- Creates a
TokenContractInfowith the contract ID and token position- Serializes the data for storage
- Inserts it into the batch operations under the correct path keyed by token ID
This follows the established pattern for storing token-related data in the system.
packages/rs-drive-abci/src/query/service.rs (2)
43-44: LGTM! Necessary imports for token contract info gRPC types.The imports of
GetTokenContractInfoRequestandGetTokenContractInfoResponseare required for the new gRPC endpoint implementation.
769-779: LGTM! Correct implementation of token contract info query endpoint.The
get_token_contract_infomethod correctly follows the established pattern used by all other query methods in the service:
- Uses the standard
handle_blocking_queryhelper- Calls the appropriate platform method
Platform::<DefaultCoreRPC>::query_token_contract_info- Uses a descriptive endpoint name for logging and metrics
packages/rs-drive/src/verify/tokens/verify_token_contract_info/mod.rs (1)
1-71: Well-structured verification method with comprehensive documentation!The implementation follows the established versioning pattern and includes thorough documentation covering all parameters, return values, and error cases. The dispatch mechanism to versioned implementations is clean and maintainable.
packages/rs-dpp/src/tokens/contract_info/methods.rs (1)
1-30: Clean trait implementation with proper delegation pattern!The accessor methods correctly delegate to the V0 variant, following the standard versioning pattern for enums. This provides a clean interface while maintaining version flexibility.
packages/rs-drive/src/drive/tokens/estimated_costs/for_token_contract_infos/mod.rs (1)
36-41:Details
❌ Incorrect review comment
Verify the version path configuration.
The version path uses
drive_version.methods.identity.cost_estimation.for_token_contract_infoswhile this module is undertokens, notidentity. Please verify this is the intended configuration.Run the following script to check how other token-related cost estimation methods are versioned:
🏁 Script executed:
#!/bin/bash # Description: Check version paths for other token cost estimation methods # Search for other token cost estimation version paths ast-grep --pattern 'drive_version.methods.$_.cost_estimation' | head -20 # Check if there are other occurrences of identity.cost_estimation in token modules rg -A 2 'methods\.identity\.cost_estimation' --glob '**/tokens/**'Length of output: 2464
I’ll verify the
Methodsstruct to see whether there is atokennamespace or if everything is indeed underidentity.
🏁 Script executed:
#!/bin/bash # Locate the file declaring `Methods` in DriveVersion echo "Searching for 'pub struct Methods'..." rg -n "pub struct Methods" -n packages/rs-drive/src/drive # Capture the Methods file path METHODS_FILE=$(rg -l "pub struct Methods" packages/rs-drive/src/drive) echo "Methods file: $METHODS_FILE" # Print the definition of `Methods` to inspect its fields sed -n '1,200p' "$METHODS_FILE" | sed -n '/pub struct Methods/,/}/p'Length of output: 363
I wasn’t able to locate where
DriveVersionand itsmethodsfield are defined—let’s find that definition to confirm whether there’s a dedicatedtokennamespace or if all cost estimations live underidentity.
🏁 Script executed:
#!/bin/bash # Find the file defining DriveVersion DRIVE_FILE=$(rg -l "struct DriveVersion" packages/rs-drive/src/drive | head -1) echo "DriveVersion struct in: $DRIVE_FILE" # Print the DriveVersion struct with its fields sed -n '1,200p' "$DRIVE_FILE" | sed -n '/struct DriveVersion/,/}/p' # Show where `methods` is referenced in that file rg -n "methods" "$DRIVE_FILE"Length of output: 303
I haven’t located where
DriveVersionand itsmethodsfield are defined yet—let’s widen our search across the repo to pinpoint the file and inspect its contents.
🏁 Script executed:
#!/bin/bash # List all Rust files under the drive module find . -type f -path "*packages/rs-drive/src/drive*" -name "*.rs" # Search for every occurrence of DriveVersion rg -n "DriveVersion" -n . # Search for the Methods struct declaration rg -n "pub struct Methods" -n .Length of output: 65663
No change needed: token cost estimations live under
identity.cost_estimationby designAll of the token‐related
estimated_costsmodules (e.g. for total supply, status infos, pre-programmed distribution, perpetual distribution, contract infos, etc.) consistently reference:drive_version.methods.identity.cost_estimation.for_…()There is no
methods.token.cost_estimationnamespace in theDriveVersionAPI, so the use of.identity.cost_estimationis intentional and correct.Likely an incorrect or invalid review comment.
packages/rs-drive-abci/src/query/token_queries/token_contract_info/v0/mod.rs (1)
49-51:Details
✅ Verification successful
Verify safe casting of token_contract_position to u32.
The code casts
token_contract_position()tou32. Please ensure thatTokenContractPositioncannot exceedu32::MAXto prevent overflow.Run the following script to check the
TokenContractPositiontype definition:
🏁 Script executed:
#!/bin/bash # Description: Find the definition of TokenContractPosition to verify it can be safely cast to u32 # Search for TokenContractPosition type definition ast-grep --pattern 'type TokenContractPosition = $_' # Also search for struct or enum definitions ast-grep --pattern 'struct TokenContractPosition' ast-grep --pattern 'enum TokenContractPosition' # Search with ripgrep as backup rg -A 3 'TokenContractPosition\s*=' --type rustLength of output: 487
Safe cast confirmed for
token_contract_position
TokenContractPositionis aliased tou16, so its maximum value (65 535) is well within theu32range and cannot overflow when cast.packages/rs-drive/src/verify/tokens/verify_token_contract_info/v0/mod.rs (1)
1-54: LGTM! Well-structured proof verification implementation.The implementation correctly handles proof verification for token contract info with proper error handling for all edge cases. The code follows the established patterns for proof verification in the codebase.
packages/rs-drive/src/drive/tokens/contract_info/prove_token_contract_info/mod.rs (1)
25-45: Well-implemented versioned method with proper error handling.The method correctly uses platform versioning to dispatch to the appropriate implementation and provides clear error messages for unsupported versions.
packages/rs-dpp/src/tokens/contract_info/v0/mod.rs (1)
1-46: Clean and well-structured data model implementation.The
TokenContractInfoV0struct and its accessor trait are well-designed with appropriate derives and clear documentation. The implementation follows Rust best practices.packages/rs-drive-abci/src/query/token_queries/token_contract_info/mod.rs (1)
1-61: LGTM! Well-structured versioned query handler.The implementation follows the established pattern for versioned query handling in the platform. The error handling is comprehensive, covering missing versions and unsupported version ranges appropriately.
packages/rs-drive/src/drive/tokens/estimated_costs/for_token_contract_infos/v0/mod.rs (1)
52-99: LGTM! Cost estimation values are appropriate.The estimation structure provides reasonable values for the hierarchical token contract info storage:
- Root level estimation with 1 subtree
- Token root path with mixed tree types and appropriate weights
- Token contract infos with 10-level depth and 36-byte values matching the expected structure
packages/rs-drive/src/drive/tokens/contract_info/prove_token_contract_info/v0/mod.rs (2)
6-22: LGTM! Clean and straightforward proof generation.The implementation correctly constructs a path query and delegates to the GroveDB proof generation method.
43-164: Excellent test coverage!The test comprehensively covers the entire proof generation and verification workflow:
- Drive setup with initial state
- Identity and contract creation with multiple tokens
- Data insertion and fetching verification
- Proof generation and verification
- Assertion that proved data matches fetched data
This provides strong confidence in the correctness of the implementation.
packages/rs-drive/src/drive/tokens/contract_info/fetch_token_contract_info/v0/mod.rs (2)
14-28: LGTM! Clean wrapper method.The simplified interface properly delegates to the operations method with sensible defaults.
57-68: Excellent error handling coverage.The match statement comprehensively handles all possible response cases:
- Successful item retrieval with deserialization
- Not found cases (both None and PathKeyNotFound)
- Corrupted element type detection
- Error propagation
packages/dapi-grpc/protos/platform/v0/platform.proto (3)
89-90: LGTM: New RPC method follows established patterns.The new
getTokenContractInfoRPC method is correctly defined and follows the same naming convention and structure as other token-related endpoints in the service.
1445-1488: Well-structured token contract info messages with proper documentation.The new
GetTokenContractInfoRequestandGetTokenContractInfoResponsemessages are well-designed with:
- Proper versioning support using oneof
- Clear field documentation
- Consistent structure with other token endpoints
- Support for both direct data and cryptographic proofs
The
TokenContractInfoDatamessage appropriately captures the contract ID and token position within the contract.
1375-1393:Details
✅ Verification successful
Confirm this reorganization doesn't break existing clients.
The
GetTokenDirectPurchasePricesRequestmessage appears to have been reorganized with additional documentation. Ensure this change maintains backward compatibility.
🏁 Script executed:
#!/bin/bash # Description: Check if this is a reorganization or a new definition # Expected: Should find previous definition or confirm this is the first occurrence # Search for any previous definitions of GetTokenDirectPurchasePricesRequest rg -A 10 "message GetTokenDirectPurchasePricesRequest" --type protoLength of output: 99
🏁 Script executed:
#!/bin/bash # Search across the repo for any prior definitions or references grep -R "message GetTokenDirectPurchasePricesRequest" -n . grep -R "GetTokenDirectPurchasePricesRequestV0" -n . grep -R "GetTokenDirectPurchasePricesRequest" -n .Length of output: 105884
GetTokenDirectPurchasePricesRequest is newly introduced, no prior definition found
A search across the repo shows this is the first—and only—occurrence of
GetTokenDirectPurchasePricesRequest(and its nested V0 type). There was no existing top-level request with directtoken_ids/provefields to reorganize, so no backward-compatibility impact on existing clients.packages/rs-drive/src/drive/tokens/paths.rs (4)
16-17: Good documentation and appropriate key value.The new
TOKEN_CONTRACT_INFO_KEYconstant is well-documented and the value 160 fits appropriately in the key space between other token-related keys.
30-31: Tree diagram correctly updated to reflect new structure.The Merkle tree diagram comment has been properly updated to include the new
TOKEN_CONTRACT_INFO_KEYat the appropriate position in the tree hierarchy.
121-132: Consistent root path functions for token contract info.The new
token_contract_infos_root_pathandtoken_contract_infos_root_path_vecfunctions follow the exact same pattern as other token root path functions, ensuring consistency across the codebase.
512-546: Improved documentation clarity and consistent path functions.The updates include:
- Better documentation distinguishing identity info vs contract info functions (lines 512, 521)
- New contract info path functions that follow the established pattern
- Consistent naming convention with
token_contract_infos_pathandtoken_contract_infos_path_vecpackages/rs-dpp/src/tokens/contract_info/mod.rs (2)
15-29: Well-structured versioned enum with appropriate derives.The
TokenContractInfoenum follows the established pattern for versioned data structures in the DPP crate with:
- Proper derives for serialization, cloning, debugging, and comparison
- Platform versioning support
- Unversioned serialization attribute (appropriate since versioning is handled directly)
- From trait for easy conversion from V0
31-53: Robust constructor with proper version handling.The
newmethod implementation includes:
- Platform version-based dispatch
- Clear error handling for unknown versions
- Descriptive error messages with method name and version information
- Proper parameter validation by requiring both contract_id and token_contract_position
The use of the platform version path
dpp.token_versions.token_contract_info_default_structure_versionis consistent with other versioned structures.packages/rs-drive/src/drive/tokens/contract_info/fetch_token_contract_info/mod.rs (3)
27-47: Well-documented basic fetch method with proper versioning.The
fetch_token_contract_infomethod includes:
- Clear documentation explaining parameters and return values
- Proper platform version dispatch
- Consistent error handling with descriptive version mismatch errors
- Standard method signature following Drive patterns
49-77: Proper cost calculation integration.The
fetch_token_contract_info_with_costsmethod correctly:
- Uses the operations-based fetch method for cost collection
- Calculates fees using the standard
Drive::calculate_feemethod- Passes appropriate parameters for epoch and configuration
- Returns both the data and fee result as a tuple
93-122: Comprehensive operations method with clear documentation.The
fetch_token_contract_info_operationsmethod provides:
- Detailed documentation explaining the stateless operations concept
- Proper version dispatch matching the basic fetch method
- Consistent error handling
- Support for both apply and estimation modes through the
applyparameterpackages/rs-drive/src/drive/tokens/system/create_token_trees/mod.rs (5)
11-12: LGTM: New imports added correctly.The imports for
TokenContractPositionandIdentifierare properly added to support the new parameters.
20-31: LGTM: Method signature updated consistently.The
create_token_treesmethod correctly adds the newcontract_idandtoken_contract_positionparameters. The parameter order is logical (contract info before token-specific parameters).
39-49: LGTM: Parameters propagated correctly to v0 implementation.The new parameters are properly passed through to the versioned implementation, maintaining the established pattern.
60-72: LGTM: Consistent parameter additions across all methods.Both
create_token_trees_add_to_operationsand its v0 call correctly include the new parameters, maintaining consistency with the other methods.Also applies to: 80-91
102-115: LGTM: Operations method updated consistently.The
create_token_trees_operationsmethod and its v0 delegation follow the same pattern as the other methods, ensuring API consistency.Also applies to: 123-133
packages/rs-drive/src/drive/tokens/system/create_token_trees/v0/mod.rs (5)
3-5: LGTM: New imports added correctly.The necessary imports for
token_contract_infos_root_path,TokenContractPosition,Identifier, andTokenContractInfoare properly added to support the new functionality.Also applies to: 14-14, 16-16, 18-18
29-40: LGTM: Method signatures updated consistently.Both
create_token_trees_v0andcreate_token_trees_add_to_operations_v0correctly add the new parameters and propagate them through the call chain.Also applies to: 44-55
118-131: LGTM: Operations method signature updated correctly.The
create_token_trees_operations_v0method signature is updated consistently with the other methods.
222-224: LGTM: TokenContractInfo creation and serialization.The
TokenContractInfo::new()call properly uses the provided parameters and platform version. Error handling is correctly propagated, and the serialization follows the established pattern.
222-234:Details
❓ Verification inconclusive
Verify the use of
batch_insertvsbatch_insert_if_not_exists.The token contract info is stored using
batch_insert, which will overwrite existing data, unlike other operations in this method that usebatch_insert_if_not_existsorbatch_insert_sum_item_if_not_exists. This could potentially overwrite existing token contract info during token recreation.Consider whether this behavior is intentional or if it should use
batch_insert_if_not_existsfor consistency with other operations.
🏁 Script executed:
#!/bin/bash # Description: Check if token contract info should allow overwrites by examining related token creation patterns # Search for similar token info storage patterns to understand the intended behavior rg -A 5 -B 5 "batch_insert.*token.*info" --type rust # Look for any tests that might clarify the expected behavior for token recreation rg -A 10 -B 10 "allow_already_exists.*token" --type rustLength of output: 113
I’ll gather more context on how
batch_insert,batch_insert_if_not_exists, andbatch_insert_sum_item_if_not_existsare used in this module to confirm the intended behavior.
🏁 Script executed:
#!/bin/bash # Search for all batch_insert calls in the create_token_trees v0 module rg -n "batch_insert\(" packages/rs-drive/src/drive/tokens/system/create_token_trees/v0/mod.rs # Search for batch_insert_if_not_exists usages in the same file rg -n "batch_insert_if_not_exists" packages/rs-drive/src/drive/tokens/system/create_token_trees/v0/mod.rs # Search for batch_insert_sum_item_if_not_exists usages in the same file rg -n "batch_insert_sum_item_if_not_exists" packages/rs-drive/src/drive/tokens/system/create_token_trees/v0/mod.rs # Show surrounding context around the token_contract_info insertion sed -n '200,260p' packages/rs-drive/src/drive/tokens/system/create_token_trees/v0/mod.rsLength of output: 2500
Inconsistent overwriting of
token_contract_infoThe surrounding logic for token creation uses
batch_insert_if_not_exists(guarded byallow_already_exists) for the token status andbatch_insert_sum_item_if_not_existsfor the total supply, but the contract info is unconditionally written withbatch_insert, which will overwrite any existing entry. If token recreation shouldn’t replace previously stored contract info, consider usingbatch_insert_if_not_existshere as well and handling the returnedinsertedflag.• File: packages/rs-drive/src/drive/tokens/system/create_token_trees/v0/mod.rs
– Lines ~222–234:
```diff
- self.batch_insert(
- let inserted = self.batch_insert_if_not_exists(
PathKeyElementInfo::PathFixedSizeKeyRefElement::<2>((
token_contract_infos_root_path(),
token_id.as_slice(),
Element::Item(token_contract_info_bytes, None),
)),/* item_apply_type */, /* transaction */, &mut batch_operations, &platform_version.drive,- if !inserted && !allow_already_exists {
return Err(DriveError::CorruptedDriveState("token contract info already exists".to_string(),));- }
Please verify whether overwriting existing token contract info on recreation is intended or if this should be converted to a “_if_not_exists” insert for consistency.
packages/rs-drive/src/drive/tokens/estimated_costs/for_token_contract_infos/mod.rs
Outdated
Show resolved
Hide resolved
packages/rs-drive-abci/src/query/token_queries/token_contract_info/v0/mod.rs
Show resolved
Hide resolved
packages/rs-drive/src/drive/tokens/contract_info/prove_token_contract_info/mod.rs
Outdated
Show resolved
Hide resolved
packages/rs-drive/src/drive/tokens/estimated_costs/for_token_contract_infos/v0/mod.rs
Outdated
Show resolved
Hide resolved
packages/rs-drive/src/drive/tokens/contract_info/fetch_token_contract_info/v0/mod.rs
Show resolved
Hide resolved
…ontract_infos/mod.rs Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…info/v0/mod.rs Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…ontract_infos/v0/mod.rs Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…ontract_info/mod.rs Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Issue being fixed or feature implemented
With a token_id it was not possible to figure out the contract id.
What was done?
We added the ability to figure the contract id and token position of a token.
Added the query to platform.
How Has This Been Tested?
Added a unit test.
Breaking Changes
Not breaking
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit