feat: Dash Platform client library over the Platform SDK behind --enable-platform-gui - #7670
Draft
PastaPastaPasta wants to merge 8 commits into
Draft
feat: Dash Platform client library over the Platform SDK behind --enable-platform-gui#7670PastaPastaPasta wants to merge 8 commits into
PastaPastaPasta wants to merge 8 commits into
Conversation
This was referenced Sep 8, 2026
Open
native_rust installs the pinned prebuilt Rust toolchain as a native package and rust_stdlib provides the precompiled standard library for every supported cross target; contrib/devtools/update-rust-hashes.py maintains both pins together. funcs.mk gains a cargo environment wired to the depends cross toolchain and a per-package crate-vendoring template: any package that declares a vendored archive name and a cargo manifest gets its vendored-crate archive modeled as a real make target, created by cargo vendor when absent and required by the package's preprocess stamp and by make download, so a clean build can never reach the offline cargo build without vendored sources. Preprocessing extracts the archive and generates a rustc linker wrapper that preserves the full configured compiler command (target and sysroot flags, and any env prefix), since -C linker= takes a single executable.
…I knob
PLATFORM_GUI=1 adds mbedtls, native_protobuf, tenderdash_sources and platform_cxx to the package set. platform_cxx builds libdash_platform_cxx.a and its installed headers from a pinned dashpay/platform commit (packages/rs-platform-cxx), offline via the per-package vendored crates. config.site.in exports enable_platform_gui and PLATFORM_CXX_{CFLAGS,LIBS} discovery for the configure flag that arrives with the first C++ consumer.
…lane The new lane builds depends with PLATFORM_GUI=1 (producing and hash-verifying the Platform CXX archive offline from vendored crates), then builds dash-qt against that prefix and runs the unit tests. The cache-sources producer generates and caches the platform-cxx vendored-crates archive, handing it to same-run consumers as an artifact on cache miss. The --enable-platform-gui configure flag is added to this lane's BITCOIN_CONFIG by the Platform client library PR; until then the lane proves the depends knob and prefix link-compatibility. build.yml runs PR validation from the base branch (pull_request_target), so the lane first runs on push CI for this branch and takes effect for PRs after merge.
The all-target rust-std downloader wrote directly to the final source-cache path and treated any existing file as complete, so a partial file left behind by an interrupted download made every subsequent 'make PLATFORM_GUI=1 download' fail on the same archive until it was removed by hand. Verify an existing archive against the pinned hash and re-fetch it when it does not match, downloading to a temp path and only moving a verified archive into place, matching fetch_file_inner.
…ry is missing Inside a Guix environment there are no default loader search paths, so a toolchain staged without libgcc_s/libz next to it is nonfunctional and would be cached in that state. Treat a missing required runtime library as a staging failure there, consistent with the existing fatal patchelf check; outside Guix it remains a warning since the system loader can still resolve the libraries.
The linker wrapper carries a shebang, so the lint-files check requires the executable bit; cargo invokes it through the RUSTFLAGS -C linker= path either way.
…crate dashpay/platform#4633 rebuilds the Platform CXX bindings as a thin bridge over dash-sdk: the SDK owns DAPI transport, retries and proof verification, and Core supplies endpoints, quorum keys, its ChainLock height and wallet signatures. The crate is an ordinary workspace member now, so the package vendors from the workspace root (the lockfile made vendorable by dashpay/platform#4631), builds with -p dash-platform-cxx, and installs the header tree the crate's build.rs stages plus the static archive; the nested standalone manifest and install.sh are gone with the old design. mbedtls leaves depends: the SDK carries its own TLS stack (rustls with the system trust store), so Core no longer links a TLS library for Platform. The vendoring config gains the workspace's git sources. Validated on aarch64-apple-darwin: make -C depends PLATFORM_GUI=1 platform_cxx vendors 840 crates (150 MB archive) and builds the crate offline in 3 minutes; the staged prefix carries include/dash/platform/{ffi.h,signer.h}, include/rust/cxx.h and lib/libdash_platform_cxx.a. The knob-off package set is unchanged.
…ble-platform-gui The Qt-free client library dash-qt drives for DashPay: per-network parameters and system contract ids, the PlatformClient interface, DPP decoding and state-transition adapters, and the wallet record formats. Where the earlier revision (dashpay#7626) carried its own gRPC-Web/TLS transport, hand-written protobuf and CBOR encoders, per-endpoint retry and freshness tracking, and handed request/response byte pairs to a transport-free verifier, this one is a thin consumer of the Dash Platform SDK through dash-platform-cxx (dashpay/platform#4633). The SDK owns query construction, DAPI transport, retries with address banning, proof verification (GroveDB replay plus the Tenderdash quorum signature against the keys this node pushes from its LLMQ store), protocol-version tracking and the chain-id and ChainLock freshness checks; the node supplies evonode endpoints from its deterministic masternode list, the Platform quorum keys, its best ChainLock height and wallet signatures through a digest callback, so private keys never leave the wallet. The PlatformClient interface the GUI programs against is unchanged apart from gaining an sdk() accessor; the production implementation keeps its single worker thread and callback marshalling and forwards each query to the SDK handle. Absence stays proven, never inferred: an empty result only reaches a callback after the SDK verified a proof of it. The DPP decoders and state-transition builders take the SDK handle so they build under the protocol version the SDK has seen the network run, ratcheted up from the per-network floor in params.cpp. The C++ transport, protobuf, CBOR, retry and freshness code and their unit tests are gone with the design; the DPP byte-exactness suite and the wallet key tests stay, and the fuzz harness keeps the decoder targets (proof verification is fuzzed upstream). Validated on aarch64-apple-darwin against a depends prefix carrying the SDK-backed archive: configure detects the bindings, libdash_platform.a and test_dash build, platform_dpp_tests and platformkeys_tests pass.
PastaPastaPasta
force-pushed
the
feat/platform-sdk-client
branch
from
September 8, 2026 19:57
e4f9868 to
1cbbc61
Compare
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
1 participant
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.
Issue being fixed or feature implemented
Stacked on #7623 → #7669 (their commits come first; review the last commit only). Replaces #7626 with the Platform client library rebuilt as a thin consumer of the Dash Platform SDK (dashpay/platform#4633). Tracking: #7512.
DashPay needs a client for Dash Platform: DAPI transport, proof verification, DPP handling and state-transition construction. #7626 carried its own gRPC-Web/TLS transport on mbedtls, hand-written protobuf and CBOR encoders, per-endpoint retry and freshness tracking, and handed request/response byte pairs to a transport-free verifier; that in turn needed dashpay/platform#4618 and #4619 to reconstruct document queries from wire bytes. Here the SDK owns query construction, DAPI transport, retries with address banning, proof verification (GroveDB replay plus the Tenderdash quorum signature against the keys this node pushes from its LLMQ store), protocol-version tracking and the chain-id and ChainLock freshness checks. The node supplies evonode endpoints from its deterministic masternode list, the Platform quorum keys, its best ChainLock height and wallet signatures through a digest callback, so private keys never leave the wallet.
What was done?
--enable-platform-gui: requires the GUI + wallet, locates the SDK archive viaPLATFORM_CXX_{CFLAGS,LIBS}(exported by depends'config.site) and link-tests it at configure time. No mbedtls detection.src/platform/(libdash_platform.a): per-network parameters (now carrying the protocol-version floor the SDK ratchets up from) and system contract ids; thePlatformClientinterface the GUI programs against, unchanged apart from ansdk()accessor; its production implementation (client.cpp), which keeps the single worker thread and callback marshalling and forwards each query to the SDK handle; the DPP decoders and state-transition adapters, which now take the SDK handle so transitions are built under the protocol version the SDK has seen the network run; the wallet record formats. Absence stays proven, never inferred: an empty result only reaches a callback after the SDK verified a proof of it.transport/(gRPC-Web, TLS, protobuf, CBOR, endpoint retry, freshness),drive/queries.*, their unit tests and the verify fuzz targets (proof verification is fuzzed upstream in rs-drive-proof-verifier and covered by dash-platform-cxx's tests, which replay the proof-vector corpus through the SDK's mock transport). Theplatform_client_tests/platform_drive_testsbehaviour that still matters (freshness floor, endpoint rotation, tampered proofs, wrong quorum) lives in that crate's suite.platform_dpp_tests(byte-exact identity decode and every state-transition builder against rs-dpp-generated vectors), theplatformkeys_testsadditions, and the decoder fuzz targets.linux64_platform_guilane now configures with--enable-platform-guiand runs the platform suites.How Has This Been Tested?
aarch64-apple-darwinagainst the depends prefix from build: pin platform_cxx to the SDK-backed dash-platform-cxx crate #7669: configure detects the bindings,libdash_platform.aandtest_dashbuild,platform_dpp_testsandplatformkeys_testspass,dash-qt(next PR) links.PlatformClientmethod was driven against live testnet from a release-built C++ driver over the same bridge (identity, nonce, DPNS resolve registered and proven absent, names-of-identity, prefix search, profile, contact requests, contested vote state, rejected broadcast), with corrupted quorum keys failing at the BLS check. That driver is the crate's own live check, not a Core unit test.Breaking Changes
None. Everything is behind
--enable-platform-gui(default off).Checklist: