Repository navigation
chore: merge v5.0-dev into v5.1-dev (5.0.1) - #5608
Merged
Merged
Conversation
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…/0383 (#5582) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…68/0369 (#5583) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…LID_ARGUMENT (#5557) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…ol version (#5560) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…nning nodes (#5561) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…neration from the verifier (#5559) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Brings 5.0.1 (v5.0-dev 093268c) into v5.1-dev: the 5.0.0 release (#5594, with #5352, #5582, #5583), #5557, #5558, #5560, #5561, #5559 and the 5.0.1 release bump (#5606). Conflict resolutions: - CHANGELOG.md: [Unreleased] on top, then the 5.0.1 and 5.0.0 entries. - rs-sdk error.rs: both sides added methods to Error; kept v5.1's consensus_error and #5560's spares_responder and into_exhausted_error. - rs-drive-abci tests/signed_response/mod.rs, moved from drive-proof-verifier by #5559: #5559's location, doc and drive_proof_verifier ContextProvider import, with v5.1's dpp::bls port. Semantic conflicts resolved: - rs-drive-abci tests/older_node_answers.rs (#5561): ported to dpp::bls, since v5.1-dev no longer ships blsful (#5320). The key is the scalar blsful's SecretKey::from_hash derived from the same label, so the public key and Basic-scheme signature bytes are unchanged. - rs-sdk protocol_gate_tests.rs (#5561): should_ask_a_fresh_sdk_network_for_its_version_once_then_send expected the SDK at 14 after its calls. The mock answers every expectation at the latest version, which was 14 on v5.0-dev and is 15 here, so the mocked fee-pots answers raise an unpinned SDK on to 15 (left: 15, right: 14). The test now expects the higher of 14 and the latest version; that the probe raised the SDK to 14 is shown by the first call being sent at all. Fails on the merge without this change, passes with it. Workspace and package versions follow v5.0-dev to 5.0.1, as the previous forward merges did. rust-dashcore stays on dev aca02026. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#5560's tests chose their versions relative to the latest one: the previous and the latest version, or the latest version paired with recorded protocol 13 and 14 producers. On v5.0-dev, where latest is 14, that covered 13 (mainnet) and 14 (testnet). With protocol 15 as the latest version, the document query tests no longer ran at 13, and the outcome layout test lost its SDK at the producer's version. They now run over every version from 13 through the latest: - drive-abci document_query_signature: a signed document answer is verified at each version from 13 through the latest. - drive-abci document_query_signed_version: every document verifier reaches proof verification at each version from 13 through the latest. - dash-sdk signed_version_tests: the outcome layouts of the protocol 13 and 14 producers are verified by an SDK stored at each version from 13 through the latest, so above, at and below each producer. With latest = 14 the first two give the lists they had, and the third adds an SDK at 13 reading a protocol 13 outcome, so the change is equally correct on v5.0-dev. The refusal tests between the previous and the latest version are unchanged; the guard they test compares numbers. The comment on #5559's verifier dispatch said protocol version 14 selects generation 1; protocol 15 does too, so it now says "from 14". Mutation check: with the document query guard refusing answers signed at protocol 13, should_verify_a_signed_document_answer_at_its_signed_version and should_verify_document_answers_at_the_version_that_signed_them pass before this change and fail after it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
Important Review skippedToo many files! This PR contains 126 files, which is 26 over the limit of 100. To get a review, reduce the PR to 100 files or fewer by splitting it into smaller PRs or changing its base branch. Upgrade to a paid plan to raise the limit. This review couldn't start because sufficient usage credits or metered capacity aren't available. Add credits or update usage-based reviews in the billing tab, then retry.
 |
Contributor
|
Waiting for bot review — thepastaclaw not yet. Wait for the missing reviews, or a writer can post |
github-actions
Bot
added
the
waiting-bots
Collaborator
|
⛔ Final review complete — 1 blocking finding(s) (commit c5872a9) · triage: critical |
thepastaclaw
suggested changes
Oct 27, 2026
thepastaclaw
left a comment
thepastaclaw
left a comment
Collaborator
There was a problem hiding this comment.
Final validation — Phase 1 + Phase 2
The merge preserves the intended protocol-version and proof-verification changes, but the public Fetch path can still send a V1 non-unique identity request without protocol gating. The new document-query preflight also omits grouped/HAVING document shapes and pending-window conflicts for aggregate queries, allowing malformed requests to reach the network. CI has queued checks but no reported code failures in the supplied snapshot.
🔴 1 blocking | 🟡 3 suggestion(s)
1 finding(s) not shown inline (the lines are not part of this PR's diff)
🔴 Blocking: Gate V1 non-unique identity requests before sending
packages/rs-dapi-client/src/transport/grpc.rs:952-959
The generated transport implementation leaves needs_protocol_version as None for GetIdentityByNonUniquePublicKeyHashRequest. The IdentityRequest delegate forwards that value, and the blanket Query<T> for T implementation makes a raw IdentityRequest::GetIdentityByNonUniquePublicKeyHash(...) usable through the public Identity::fetch path. A caller can therefore supply a V1 request while the SDK has only established protocol 13; the SDK sends it to an older node, whose unsupported-query response is retryable and can cause the node to be banned. This bypasses the central purpose of the protocol gate. Declare protocol 14 for V1 requests, while leaving V0 ungated, and add a regression test covering a raw V1 request through Identity::fetch.
source: gpt-6.1-sol (phase2-reviewer: general)
Review provenance
Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: muse-spark-1.3-contributor (agent: phase1-reviewer, role: rust-quality); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: architecture-layering); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: ffi-engineer); reviewer 6: gpt-6.1-sol (agent: phase2-reviewer, role: platform-versioning); reviewer 7: gpt-6.1-sol (agent: phase2-reviewer, role: rust-quality); reviewer 8: gpt-6.1-sol (agent: phase2-reviewer, role: security-auditor); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
criticalbygpt-6.1-sol(effort low) — This is a large, intricate merge whose diff changes cryptographic proof verification and signed-response handling across peer-facing SDK, Drive, and verifier code, including protocol-gated compatibility behavior. - Phase 1 reviewers:
muse-spark-1.3-contributor— general (completed, effort xhigh); agentphase1-reviewer,muse-spark-1.3-contributor— rust-quality (completed, effort xhigh); agentphase1-reviewer - Phase 1 model:
muse-spark-1.3-contributor— not quota-gated; passed overgemini-3.8-flash-high(antigravity quota lookup failed),glm-5.3-flash(not used above high effort; tier asks max) - Single stage: Phase 1 and Phase 2 reviewed this head side by side, with no blocker gate between them (triage tier)
- Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort xhigh); agentphase2-reviewer,gpt-6.1-sol— architecture-layering (completed, effort xhigh); agentphase2-reviewer,gpt-6.1-sol— ffi-engineer (completed, effort xhigh); agentphase2-reviewer,gpt-6.1-sol— platform-versioning (completed, effort xhigh); agentphase2-reviewer,gpt-6.1-sol— rust-quality (completed, effort xhigh); agentphase2-reviewer,gpt-6.1-sol— security-auditor (completed, effort xhigh); agentphase2-reviewer
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-dapi-client/src/transport/grpc.rs`:
- [BLOCKING] packages/rs-dapi-client/src/transport/grpc.rs:952-959: Gate V1 non-unique identity requests before sending
The generated transport implementation leaves `needs_protocol_version` as `None` for `GetIdentityByNonUniquePublicKeyHashRequest`. The `IdentityRequest` delegate forwards that value, and the blanket `Query<T> for T` implementation makes a raw `IdentityRequest::GetIdentityByNonUniquePublicKeyHash(...)` usable through the public `Identity::fetch` path. A caller can therefore supply a V1 request while the SDK has only established protocol 13; the SDK sends it to an older node, whose unsupported-query response is retryable and can cause the node to be banned. This bypasses the central purpose of the protocol gate. Declare protocol 14 for V1 requests, while leaving V0 ungated, and add a regression test covering a raw V1 request through `Identity::fetch`.
In `packages/dash-platform-queries/src/documents/document_query.rs`:
- [SUGGESTION] packages/dash-platform-queries/src/documents/document_query.rs:632-647: Reject grouped and HAVING document queries during preflight
`Documents::check_request` validates only the absence of subqueries and that the projection is `SelectFunction::Documents`. It does not reject `group_by` or `having`. The server's `validate_and_route` rejects `GROUP BY` with `SELECT DOCUMENTS`, and rejects HAVING for non-aggregate projections, before producing a proof. Since this preflight exists to prevent sending shapes that the verifier cannot reproduce, these invalid requests should be rejected locally; the same check is inherited by the single `Document` view.
In `packages/dash-platform-queries/src/documents/count_proof_helpers.rs`:
- [SUGGESTION] packages/dash-platform-queries/src/documents/count_proof_helpers.rs:79-88: Validate pending window selections in aggregate request preflight
`check_count_request` constructs its shape only from `request.where_clauses`; it ignores `time_range_clauses` and `integer_range_clauses`. The verifier later resolves those pending selections and calls `validate_resolved_time_range_clause_shapes`, which rejects an ordinary range or `IN` clause on the same field as a resolved window selection. Consequently, aggregate count requests with such conflicting clauses pass the local check and are sent before failing during proof verification. Apply the same pending-selection conflict rule in `check_count_request`; the equivalent omission exists in `check_sum_request` and `check_average_request`.
In `packages/rs-sdk/src/sdk.rs`:
- [SUGGESTION] packages/rs-sdk/src/sdk.rs:463-479: Preserve protocol-version ratcheting in the public metadata verifier
`verify_response_metadata` remains public and documents that callers provide metadata from a proof and quorum signature they already verified, but it now performs only the freshness check. Before this change it also recorded the authenticated protocol version, updating the SDK's effective version and verified-version information. Consumers that manually verify a response and then call this public method no longer bootstrap protocol-version state, so later protocol-gated requests may probe unnecessarily or remain refused, and protocol-version observers do not receive the authenticated update. Restore the ratcheting behavior in this public method, while keeping the crate-private `_as_of` helper's separate semantics for internally handled mock or arrival-time paths.
Contributor
|
Your move: thepastaclaw requested changes on this head; dismiss the review or push a fix. |
github-actions
Bot
added
waiting-self-review
Contributor
|
📖 Book Preview built successfully. Download the preview from the workflow artifacts. Updated at 2026-10-27T18:06:48.463Z |
Merged
6 of 13 tasks
Collaborator
Author
|
Re the blocking finding on Agreed, this is a real gap: a hand-built V1 non-unique identity request reaches the network through |
This was referenced Oct 28, 2026
shumkov
added a commit
that referenced
this pull request
Oct 28, 2026
…is proven The getIdentityByNonUniquePublicKeyHash transport entry declared no needs_protocol_version. NonUniquePublicKeyHashQuery picks V1 only once the network basis is 14, but the blanket `Query<T> for T` lets a caller pass a raw IdentityRequest carrying V1 to Identity::fetch, skipping that selector. On a network proven only at 13 the request went out, every node below 14 refused it with UNKNOWN, and the SDK retried and banned honest nodes. V1 now declares protocol 14 (V0 and an empty version declare nothing), so the fetch path refuses it with ProtocolVersionNotActive, or asks the network first, without contacting a node. The selector is unchanged: it picks V1 only at a basis the gate already lets through. The request inventory verdict for the V1 arm is now Gate(14). Answers thepastaclaw's blocking finding on #5608. Tests would have caught this in CI: ✖ before fix, ✔ after, with grpc.rs swapped back to origin/v5.0-dev and the new tests kept: - should_refuse_a_v1_non_unique_key_lookup_until_protocol_14_is_verified: ✖ "expected a refusal ..., got Err(DapiClientError(Transport(Grpc( Status { code: Unknown, message: "unsupported query version", ... }))))" (the V1 request reached the node) - should_send_a_v1_non_unique_key_lookup_once_protocol_14_is_verified: ✖ probes 0 != 1 (a fresh SDK sent the caller's V1 without asking) - request_inventory should_need_the_declared_protocol_version_for_each_addition and should_need_protocol_14_only_for_composite_chained_token_pool_and_non_unique_v1_requests: ✖ left: None, right: Some(14) All ✔ with the fix. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Basic explanation
What this does: Brings
v5.1-devup to date withv5.0-devat093268c09b: the 5.0.0 and 5.0.1 releases, ten PRs in all. The last forward merge was #5551. It merged78d494f525, which is the base of this merge.Value:
v5.1-devgets the 5.0.0 and 5.0.1 fixes:Risks: Low.
CHANGELOG.md, rs-sdkerror.rsand the moved signed-response test harness. Beyond those, one new test is ported todpp::blsand one gate test's expectation is corrected; it depended on the latest protocol version.DRIVE_VERSION_V9andDRIVE_ABCI_QUERY_VERSIONS_V2as PV14, so fix(drive-abci): answer queries for features not active yet with INVALID_ARGUMENT #5557's and test(sdk): run operation-proof tests in CI and select the verifier generation from the verifier #5559's version logic reaches PV15 unchanged (see "Protocol versions").v5.0-devandv5.1-dev, so v5.1 has no request of its own to declare. The field-level request inventory test passes.v5.1-dev'sdevpin (aca02026). None of the ten PRs touches it.Issue being fixed or feature implemented
v5.1-devwas ten PRs behindv5.0-dev.What was done?
Merged
origin/v5.0-dev(093268c09b) intoorigin/v5.1-dev(0d91c133f0) as a merge commit (ea5edddac8). One test-only commit follows (c5872a9b93, see "Test coverage of protocols 13 and 14").Incoming PRs:
Pins and
Cargo.lockrust-dashcore:
v5.1-devkeepsdevataca02026. None of the ten PRs changes the rust-dashcore pin.GroveDB: unchanged on both branches (
2128ea18, 6.1.1).Cargo.lock:v5.1-dev's lockfile plus exactlyv5.0-dev's own lockfile changes:All builds and tests ran with
--locked.Workspace and package versions go from
5.0.0-rc.8to5.0.1, following chore: merge v5.0-dev into v5.1-dev (5.0.0-rc.8) #5551 and chore: merge v5.0-dev into v5.1-dev (5.0.0-rc.5 to rc.7) #5527:v5.1-devcarriesv5.0-dev's version until its own first release.Conflicts resolved by hand
CHANGELOG.md:[Unreleased]on top, then the 5.0.1 and 5.0.0 entries, as in chore: merge v5.0-dev into v5.1-dev (5.0.0-rc.8) #5551.rs-sdk/src/error.rs: both sides added methods at the same place inimpl Error. The merge keepsv5.1-dev'sconsensus_errorand fix(sdk): retry document queries answered by nodes on an older protocol version #5560'sspares_responderandinto_exhausted_error.rs-drive-abci/tests/signed_response/mod.rs: test(sdk): run operation-proof tests in CI and select the verifier generation from the verifier #5559 moved this harness here fromrs-drive-proof-verifier/tests, added a doc paragraph and tookContextProviderfromdrive_proof_verifier.v5.1-devhad already ported the old copy todpp::bls(chore: merge v5.0-dev into v5.1-dev (5.0.0-rc.8) #5551). The merge keeps test(sdk): run operation-proof tests in CI and select the verifier generation from the verifier #5559's location, doc and import together with thedpp::blsport. Againstv5.0-devthe file differs by exactly that port. Againstv5.1-dev's old copy it differs by exactly test(sdk): run operation-proof tests in CI and select the verifier generation from the verifier #5559's change.Semantic conflicts resolved (in the merge commit)
dpp::blsport ofrs-drive-abci/tests/older_node_answers.rs(new in #5561). This test signs its proofs through blsful (dpp::bls_signatures), whichv5.1-devno longer ships (#5320). It is ported the same wayv5.1-devportedtests/nonunique_merged_proof.rs'smod signed:v5.0-dev(blsful)v5.1-dev(dpp::bls)SecretKey::<Bls12381G2Impl>::from_hash(b"older-node-answers-quorum-fixture")SecretKey::from_be_bytes(&scalar), scalar13b8f447…7bfe(&key().public_key()).into()key().public_key().to_bytes()sign(SignatureSchemes::Basic, &digest)…as_raw_value().to_compressed()sign(&digest)…to_bytes()dpp::blshas nofrom_hash, so the test uses the scalar that blsful derives from the same label. blsful computes it with HKDF-SHA256: saltBLS-SIG-KEYGEN-SALT-, input the label followed by a zero byte, info[0, 48], 48 bytes read big-endian modulo r. The same computation gives6f295ecb…eea0fornonunique-merged-proof-quorum-fixture, which is the scalarv5.1-devalready hardcodes. So the quorum key and signatures are the same onesv5.0-dev's test produces. No recorded vector depends on this key: the test signs answers it generates itself.rs-sdkprotocol_gate_tests::should_ask_a_fresh_sdk_network_for_its_version_once_then_send(#5561). The test ended withassert_eq!(sdk.protocol_version_number(), V14)and failed on the merge (left: 15, right: 14). The cause is the mock SDK, which answers every expectation with metadata atLATEST_VERSION(mock/sdk.rs). So the two mocked fee-pots answers raise the unpinned SDK on to the latest version, which is 14 onv5.0-devand 15 here. #5560's description already notes this mock behaviour as a follow-up.The test now expects
max(14, latest). It still checks that the probe raised the SDK to 14, becauseensure_network_servessends only oncemin(SDK version, verified version) ≥ 14, so without that the first call would have been refused. Theverified == 14and single-probe assertions are unchanged. The test fails on the merge without this change and passes with it.Protocol versions (LATEST = 15)
fix(sdk)!: refuse requests the network cannot serve yet instead of banning nodes #5561's gate.
needs_protocol_versiondeclaration is fix(sdk)!: refuse requests the network cannot serve yet instead of banning nodes #5561's, all at 14 (PROTOCOL_VERSION_OF_5_0): the 13 methods 5.0 added,GetDocumentsRequestV1.chainedandsub_queries, and the shielded requests'token_id.packages/dapi-grpc/protosis byte-identical betweenv5.0-devandv5.1-dev. So v5.1 adds no method, field, oneof arm or enum value that would need its own version (15), andrs-dapi-client --test request_inventorypasses against v5.1's proto.TransportRequestimpls, and the wrappers forward the declaration (delegate.rsandIdentitiesContractKeysQuery).EvoNodesendsgetStatus, which needs no version.Fetch,FetchManyandFetchUnprovedpaths.fix(sdk): retry document queries answered by nodes on an older protocol version #5560's exact-match document guard. An answer is verified only at the version that signed it, or at the latest known version when a newer version signed it. At LATEST = 15:
v5.1 adds no document-proof verifier.
document_query_signed_version's source scan, which checks that every verifier reads proof bytes only through the guard, passes.test(sdk): run operation-proof tests in CI and select the verifier generation from the verifier #5559's verifier-generation dispatch. PV15 selects
DRIVE_VERSION_V9, as PV14 does: verifier generation 1 and prover generation 1. Protocols 1–13 select 0 and 0. The dispatch knows generations 0 and 1, so it serves every version from 1 to 15.fix(drive-abci): answer queries for features not active yet with INVALID_ARGUMENT #5557. PV15 shares
DRIVE_ABCI_QUERY_VERSIONS_V2with PV14. v5.1's changes underrs-drive-abci/src/queryadd no query feature with an activation version.features_not_activeruns at 14 and at the latest version, so now at 14 and 15.Tests that follow "latest". I went through every test the ten PRs added or changed whose versions depend on
PlatformVersion::latest():protocol_gate_tests's decision matrix over every stored and verified version,nonunique_merged_proof,identity_by_non_unique_public_key_hashandidentity_discovery::signed_versions. So do tests that pin 13 or 14:older_node_answers, drive-abciprotocol_gateand the recorded vectors.document_query_signed_versionanddocument_query_signaturecompare the previous version with the latest: 13 against 14 onv5.0-dev, 14 against 15 here. The guard they test only compares numbers, so they mean the same.Test coverage of protocols 13 and 14 (
c5872a9b93)#5560's tests chose their versions relative to the latest one. On
v5.0-dev, where latest is 14, that covered 13 (mainnet) and 14 (testnet). At 15 the document query tests no longer run at 13, and the outcome layout test lost its case of an SDK at the producer's version. The follow-up commit makes them run over every version from 13 through the latest:rs-drive-abci/tests/document_query_signature.rsshould_verify_a_signed_document_answer_at_its_signed_version:[previous(), latest()]→13..=latest.rs-drive-abci/tests/document_query_signed_version.rsshould_verify_document_answers_at_the_version_that_signed_them:previousandlatest→13..=latest, for every document verifier.rs-sdk/src/sdk/signed_version_tests.rsshould_verify_signed_document_outcome_layouts_without_lowering_security_or_pins:[(latest, 13), (latest, 14), (13, 14)]→ stored13..=latest× the recorded producers 13 and 14. That restores the "above, at or below the producer" its doc comment describes.It also updates the comment on #5559's dispatch: it said protocol version 14 selects generation 1, and protocol 15 does too, so it now says "from 14".
With latest = 14 the first two ranges produce the lists those tests had. The third adds one case, an SDK at 13 reading a protocol 13 outcome. So the commit is equally correct on
v5.0-dev. Mutation check: with the document guard temporarily refusing answers signed at protocol 13, both document tests pass on the merge commit and fail onc5872a9b93.Files changed on both branches and merged automatically (worth a look in review)
v5.0-devchanged 137 paths. At the merge commit, 99 of them are asv5.0-devhas them: 98 byte-identical, plus #5559's deletedv1verifier, which is absent on both branches. The other 38 are the five hand edits above and these 33 files. Each of the 33 is byte-for-byte what a clean three-way merge of the base,v5.1-devandv5.0-devproduces:rs-sdk/src/sdk.rs: fix(sdk): retry document queries answered by nodes on an older protocol version #5560's and fix(sdk)!: refuse requests the network cannot serve yet instead of banning nodes #5561's retry and gate code, next tov5.1-dev's SOCKS5 proxy andprotocol_version_info.rs-sdk/src/platform/{fetch,fetch_many,identities_contract_keys_query}.rsandrs-sdk/src/sdk/signed_version_tests.rs.rs-dapi-client/src/transport.rsandtransport/grpc.rs: fix(sdk)!: refuse requests the network cannot serve yet instead of banning nodes #5561's declarations next to the proxy.rs-drive-proof-verifier/src/{proof,verify}.rsandrs-drive/.../verify_state_transition_was_executed_with_proof/v0/mod.rs.rs-drive-abci/src/query/service.rsandrs-drive-abci/src/query/document_query/v1/tests.rs.rs-drive-abci/tests/nonunique_merged_proof.rs, left asv5.1-devhad it becausev5.0-dev's hunk was already there (62db704b76).wasm-sdk/src/context_provider.rs..github/workflows/tests-rs-workspace.yml:v5.0-dev'sdrive-proof-verifierin both test phases, next tov5.1-dev'splatform-encryptionand storage filter.SUMMARY.md,evo-sdk/getting-started.mdandsdk/put-operations.md, andjs-evo-sdk/README.md.Cargo.toml,Cargo.lock, and the version bumps of 12package.jsonfiles.Please merge with a merge commit (not squash) so the
v5.0-devhistory stays shared withv5.1-dev.How Has This Been Tested?
Run locally on macOS (arm64).
On the merge commit
ea5edddac8:cargo check --workspace --all-targets --locked: passes.cargo clippy --workspace --all-targets --all-features --locked -- --no-deps -D warnings(CI's invocation): passes. The amend that corrected the gate test touched onlydash-sdk, so clippy was then run again with the same flags ondash-sdkalone, which passes.cargo fmt --all -- --check: passes.v5.0-dev,v5.1-devand the merge (only the version fields ofdapi-grpc'sCargo.tomlandpackage.jsonchanged), so there is nothing to regenerate.yarn install --immutable --immutable-cacheandyarn constraints: both pass, and the tree stays clean.--all-features --locked, all with 0 failed:protocol_gate: 3 passed (1 ignored, the vector exporter);document_query_signed_version: 6 passed;document_query_signature: 3 passed (1 ignored, the exporter);document_outcome: 6 passed (1 ignored);identity_discovery: 13 passed (1 ignored);older_node_answers: 3 passed;nonunique_merged_proof: 12 passed;query_request_errors, includingfeatures_not_active: 20 passed.drive-abci --lib -- identity_by_non_unique document_query: 175 passed (1 ignored).dash-sdk --lib: all 508 passed. Of these, 69 are inprotocol_gate_tests,signed_version_tests,identity_discovery_tests,platform::types::identity::testsanddocument_query_shape_tests.drive-proof-verifier: lib and vector tests, 377 passed.dash-platform-queries, includingcheck_request_tests: 77 passed.rs-dapi-client --test request_inventory: 5 passed (1 ignored).drive --lib -- verify_state_transition_was_executed_with_proof: 83 passed.platform-wallet-storage --lib -- parent_permissions(fix(platform-wallet-storage): open the wallet store on Android #5352): 7 passed.cargo testbecausecargo-nextestis not installed here:--all-features --locked --lib --bins --tests --no-fail-fast -- --skip shieldand CI'sRUST_MIN_STACK=4194304 CARGO_PROFILE_DEV_DEBUG=0 CARGO_PROFILE_DEV_CODEGEN_UNITS=256. It runs the fullstrategy_testsbinary, not only the comprehensive simulation a PR run takes.dpp: 5,517 passed.drive-abcilib: 4,169 passed (14 ignored);strategy_tests: 115 passed (4 ignored).drive: 4,065 passed (6 ignored).platform-wallet: 1,389;platform-wallet-storage: 438;platform-wallet-ffi: 427;rs-sdk-ffi: 392.dash-sdklib: 505;drive-proof-verifierlib: 349.cargo check -p wasm-sdk -p wasm-dpp2 -p wasm-drive-verify --target wasm32-unknown-unknown --locked: passes.On
c5872a9b93:document_query_signature3 passed,document_query_signed_version6,dash-sdksigned_version_tests26, and thedriveverifier tests 83.drive-abci,dash-sdk,driveanddrive-proof-verifier, and fmt.Two independent reviews of the merge, by separate agents with different lenses. Neither found a must-fix issue.
v5.0-devhunk is present and nov5.1-devchange was reverted. The 33 auto-merged files are exactly whatgit merge-fileproduces. Function counts in the merged.rsfiles equal v5.1 + v5.0 − base, so no hunk was duplicated. Nothing references the deletedv1verifier or the old test paths. The lockfile delta equalsv5.0-dev's. The reviewer also recomputed the three BLS fixture scalars on its own.Known limitations and notes
rs-drive-abci/tests/document_outcome.rs'sshould_verify_signed_older_document_outcome_with_current_verifier_securityruns at[13, latest], and severalidentity_discoverytests use[13, latest]as their verifier or signed versions.v5.1-dev, so at 15 they skip protocol 14.v5.0-devfirst.LATEST_VERSIONin the metadata of every expectation. A test that asserts the SDK's version after a mocked answer therefore depends on the latest version. Indash-sdk, the gate test above was the only such test.IdentitiesContractKeysQuery::needs_protocol_version(fix(sdk)!: refuse requests the network cannot serve yet instead of banning nodes #5561) goes throughGetIdentitiesContractKeysRequest::try_from(self.clone()), whilev5.1-dev's neighbouring methods callself.request(). The result is the same: the conversion cannot fail, and the request needs no version. I left it as merged.latest_coinbase()). Nothing here changes it.Breaking Changes
The merge adds none of its own. #5560's and #5561's API changes carry over as they are:
drive_proof_verifier::Error::ProofProtocolVersionMismatch,dash_sdk::Error::ProtocolVersionNotActive, andStaleNodeError::ProtocolVersionandBehindProtocolUpgradeare new variants of exhaustive enums.TransportRequestgains the provided methodneeds_protocol_version.Checklist:
structure.rs, regeneratedgrovedb-structure.json, and checked the structure viewer link posted on this pull requestFor repository code-owners and collaborators only
🤖 Generated with Claude Code
PR Hygiene ·
c5872a9/self-reviewedgithub(.github/workflows/tests-rs-workspace.yml) — ktechmidasdashmate— you own itsystem-contracts— you own itjs-wasm-sdk— you own itrs-drive-abci— you own itrs-drive— you own itwallet-storage(packages/rs-platform-wallet-storage/SECRETS.md,packages/rs-platform-wallet-storage/src/parent_permissions.rs) — lklimekrust-sdk-ffi— you own itrust-sdk— you own itWhen every merge requirement is met, the
PR Hygienecheck passes. Reviewer limits do not block merging; other required GitHub checks and protections still apply.