Dash Platform v3.0.1-hotfix.1

Test #3018

Dash Platform v3.0.0

Executive Summary

Dash Platform 3.0 introduces Platform Addresses and related state transitions for holding and transferring credits in Platform state. The release also includes substantial SDK work to support these flows and to reduce integration complexity for clients interacting with Platform.

Much work in 3.0 was also done to improve various parts of the system, most notably in our JS SDK which had significant changes.

Key Improvements and Capabilities

1. Platform Addresses

Platform Addresses are address identifiers whose balances are represented as first-class state on the Platform chain.

Identities remain the mechanism for:

• authorization
• permissions
• participation in data contracts and application logic

1.1 Address representation

• 20-byte hash identifiers
• Encoded using bech32m
• Network-specific human-readable prefixes:
  • Mainnet: evo
  • Testnet: tevo

1.2 Address types

• P2PKH: single public-key-hash ownership
• P2SH: script-hash ownership, enabling multisignature and script-based control

P2SH Platform Addresses enable script-based ownership models.

This allows:

• M-of-N multisignature control of Platform-held credits
• shared custody for organizational workflows
• reduced reliance on single-key control for address-held credits

Platform Addresses are resolved entirely through Platform state (as opposed to computing balances by scanning payment-chain history).

---

2. Balance Storage and Synchronization Model

Platform Address balances are maintained as explicit state in Platform storage and are synchronized using a layered, tree-based mechanism referred to as BLAST Sync (Blockchain Layered Address Sync Tree).

This section describes how balances are stored, how they are queried, and how clients synchronize efficiently.

---

2.1 Balance Storage

Balances associated with Platform Addresses are stored as values in Platform state.

• Each address has a balance entry maintained by Platform state transitions
• Balance updates are applied atomically as part of finalized Platform blocks
• Balances are not derived from transaction history
• The current balance is obtained by querying Platform state directly

This differs from UTXO-based systems, where balances must be reconstructed by discovering and summing unspent outputs.

---

2.2 Address Balance Tree Structure

Platform Address balances are organized into a balanced tree structure.

• Each node represents a group of addresses
• Internal nodes store:
  • the aggregated balance of all descendant addresses
  • the count of descendant addresses
• Leaf nodes represent individual address balances

This structure allows:

• logarithmic access paths
• bounded proof sizes
• aggregation of balance changes across address ranges

The tree is deterministic and versioned as part of Platform state.

---

2.3 Balance Queries

Clients retrieve balance information by querying the address balance tree.

• Queries can target:
  • the full balance for a specific address
  • aggregated balances for address ranges
• Responses include cryptographic proofs rooted in Platform state
• Verification does not require historical block scanning

Clients do not need to download unrelated address data.

---

2.4 Compaction of Balance Changes

Balance updates occur on a per-block basis, but are compacted over time.

Compaction mechanism

• Multiple per-block balance changes are merged into a single compacted entry
• Compaction occurs at configurable intervals (e.g. every N blocks or M addresses)
• Compacted entries replace fine-grained history while preserving correctness

Effects of compaction

• Reduces storage overhead
• Reduces synchronization bandwidth
• Produces smaller proofs for balance verification
• Preserves the ability to reconstruct current balances

Compaction parameters are versioned and part of consensus rules.

---

2.5 BLAST Sync (Blockchain Layered Address Sync Tree)

BLAST Sync is the synchronization strategy used by clients to efficiently track Platform Address balances.

Synchronization proceeds in layers:

1. Trunk

• A compact checkpoint representing the full address balance tree at a given state version
• All balances are aggregated and compacted
• Serves as the synchronization anchor

2. Branches

• Subtrees below the trunk representing address ranges
• Clients fetch only branches relevant to their addresses
• Unrelated branches are ignored

3. Compacted Recent

• Compacted balance changes since the last trunk checkpoint
• Covers recent activity with reduced granularity

4. Recent

• Per-block balance changes since the most recent compaction
• Used to bring the client fully up to the current state

This layered approach allows clients to synchronize incrementally without downloading full state.

---

2.6 Terminal Sync Optimization

For clients that have synchronized recently, Platform supports a terminal sync mode.

• Terminal compacted balance entries are retained for a bounded time window
• If a client’s last known state is recent enough:
  • it may sync using only terminal compacted data
  • it avoids fetching trunk and branch data
• If the client is too far behind:
  • a full trunk/branch sync is required

This prevents unnecessary heavy synchronization for short offline periods.

---

2.7 Privacy-Preserving Querying

Clients do not need to reveal exact addresses when querying balance trees.

• Queries begin at higher tree levels
• Clients progressively request lower-level nodes
• Entire subtrees can be skipped if irrelevant
• Additional data may be requested near leaves to avoid leaking address position

This allows balance synchronization without revealing precise address interests to any single node.

---

3. Credit and Funding Flows

Platform 3.0 supports multiple flows between the payment chain, Platform Addresses, and identities.

3.1 Additional supported flows

• Asset lock → Platform Address: lock Dash on the payment chain and allocate credits to a Platform Address
• Platform Address → Platform Address: transfer credits between Platform Addresses
• Platform Address → Identity: allocate credits from one or more Platform Addresses to create or top up an identity
• Identity → Platform Address: move credits from an identity to a Platform Address
• Platform Address → Payment chain: transfer credits from a Platform Address to the Core payment chain

These flows allow movement of credits without requiring identity creation for every intermediate step.

---

4. SDK Work (Client Integration)

Platform 3.0 includes SDK changes required to support Platform Addresses and the associated flows.

4.1 Address support

• Address generation and encoding/decoding (bech32m + HRP selection by network)
• Typed handling for P2PKH vs P2SH addresses
• Signing workflows for address-related state transitions (including multisig workflows where applicable)

4.2 Funding and transfer workflows

• Constructors/builders for address funding and transfer transitions
• Serialization/deserialization support across supported languages
• Client helpers for composing multi-step flows (e.g., address funding → identity creation)

4.3 Query and sync support

• Client interfaces for retrieving:
  • current balances
  • compacted balance changes since a known version
  • proofs for verification
• Local state tracking primitives (e.g., “last seen” versions / checkpoints) to enable incremental synchronization

4.4 Ergonomics and consistency

• Normalized error mapping for Platform Address operations
• Consistent API surface across languages where feasible
• Test vectors and examples for address formats, transitions, and proof verification

PR List:

• chore: merge v2.1.2 into v2.2-dev by @lklimek in #2828
• build: use workspace version in Cargo.toml by @lklimek in #2831
• fix(dashmate)!: port conflicts with mainnet and testnet on the same host by @lklimek in #2829
• test: platform-test-suite accepts DAPI_ADDRESSES by @lklimek in #2798
• fix: resolve a few issues in iOS example app by @PastaPastaPasta in #2843
• build(sdk): wasm-sdk remove unmaintained wee_alloc (RUSTSEC-2022-0054) by @Copilot in #2844
• feat(drive): add next epoch info to GetStatusResponse by @lklimek in #2847
• refactor(dashmate): remove deprecated javascript dapi by @lklimek in #2827
• feat(sdk): entities for Evo SDK by @shumkov in #2800
• refactor(sdk): typed identifier by @shumkov in #2848
• build: script to configure environments for ai coding agents by @lklimek in #2845
• refactor(sdk): typed wasm-sdk params by @shumkov in #2849
• fix(dpp): deserialization of data contract JSON with token configuration by @shumkov in #2857
• fix(sdk): reset SDK nonce caches after failed transitions by @lklimek in #2851
• refactor(sdk)!: user-friendly evo sdk params by @shumkov in #2856
• feat(dashmate): add prometheus service discovery labels by @lklimek in #2818
• fix(sdk): fail on invalid proof by @shumkov in #2864
• refactor(sdk)!: cleanup JS SDK params and return types by @sh...

Dash Platform v3.0.0-rc.3

Features

• dashmate: add Let's Encrypt SSL provider support (#3000)
• drive: improve error handling in merk proof extraction (#3003)

Bug Fixes

• platform: update grovedb dependency to allow for larger proof sizes (#3005)

Dash Platform v3.0.0-rc.2

Bug Fixes

• sdk: toJSON returns empty object (#2995)

Code Refactoring

• sdk: introduce ProRegTxLike and NetworkLike types (#2990)

Dash Platform v3.0.0-rc.1

⚠ BREAKING CHANGES

• sdk: typed params for state transition methods (#2932)
• sdk: return last meaningful error on no available addresses (#2958)

Features

• dpp: add Identity new_with_input_addresses_and_keys() (#2971)
• drive: add WalletUtils system data contract during initialization on devnets/local networks (#2696)
• drive: update verification logic for compacted address balance changes (#2972)
• sdk: add validation/tests for registerName publicKeyId parameter (#2832)
• sdk: return last meaningful error on no available addresses (#2958)

Bug Fixes

• drive: not setting keeps_history in proof verification for DataContractCreate and DataContractUpdate (#2980)
• drive: use historical path query for contracts with keeps_history=true (#2976)
• wasm-sdk: support ECDSA_SECP256K1 keys in contract create/update (#2975)

Performance Improvements

• sdk: cache contracts in JS SDK (#2978)

Tests

• sdk: test sync_address_balances (#2957)
• wasm-sdk: enable contract token and group check (#2952)

Build System

• drive: update rkyv to 0.7.46 (#2982)

Code Refactoring

• sdk: dpns JS SDK methods
• sdk: re-use sdk methods (#2981) 1Code has comments. Press enter to view.
• sdk: typed params for state transition methods (#2932)

Dash Platform v3.0.0-dev.11

What's Changed

• fix(sdk): adjust metadata freshness criteria for get_addresses_trunk_state and get_addresses_branch_state by @lklimek in #2954
• fix(sdk): clamp address sync branch query depth to platform limits by @pauldelucia in #2955
• fix(sdk): match ItemWithSumItem in extract_balance_from_element by @pauldelucia in #2956
• fix(rs-sdk-ffi): auto-increment document revision in replace function by @PastaPastaPasta in #2960
• feat(platform): update address expiration time from 1 day to 1 week by @QuantumExplorer in #2964
• feat(platform): remove platform version patching and state migration logic by @QuantumExplorer in #2961
• feat(sdk): return checkpoint height with AddressSyncResult by @pauldelucia in #2965
• feat(platform)!: enhanced fetching of compacted address balance changes by @QuantumExplorer in #2966
• feat(platform)!: add block-aware credit operations to manage address balance changes by @QuantumExplorer in #2968
• fix(sdk)!: failed address sync on invalid proof by @shumkov in #2967
• feat(platform): add tests for proof verification of recent address balance changes by @QuantumExplorer in #2969
• chore(release): update changelog and bump version to 3.0.0-dev.11 by @QuantumExplorer in #2970

Full Changelog: v3.0.0-dev.10...v3.0.0-dev.11

Dash Platform v3.0.0-dev.10

⚠ BREAKING CHANGES

• platform: clean up expired compacted address balances (#2948)

Features

• platform: clean up expired compacted address balances (#2948)

Bug Fixes

• dpp: broken chain lock proof deserialization (#2950)
• wasm-sdk: enable identity_update to add ECDSA_SECP256K1 and BLS12_381 keys (#2947)

Dash Platform v3.0.0-dev.9

What's Changed

• fix(dpp): correct revision in identity update transition by @PastaPastaPasta in #2940
• fix(dashmate): npm security issue for qs's arrayLimit by @QuantumExplorer in #2942
• fix(wasm-sdk): support ECDSA_SECP256K1 keys in identity operations by @PastaPastaPasta in #2939
• feat(dashmate): bypass validation for total reset by @ktechmidas in #2941
• fix(dashmate): npm security qs 2 by @QuantumExplorer in #2943
• fix(dashmate): npm security issue for qs 3. by @QuantumExplorer in #2944

Full Changelog: v3.0.0-dev.8...v3.0.0-dev.9

Dash Platform v3.0.0-dev.8

What's Changed

• feat(platform)!: historical address balance storage by @QuantumExplorer in #2936
• fix(dpp): report correct values in IdentityInsufficientBalanceError by @pauldelucia in #2922
• chore: bump package versions to 3.0.0-dev.8 by @QuantumExplorer in #2938

Full Changelog: v3.0.0-dev.7...v3.0.0-dev.8

Dash Platform v3.0.0-dev.7

• dashmate: add quroum list service (#2868)

Features

• dashmate: add quroum list service (#2868)
• platform: sdk support for platform addresses and checkpoint fix (#2933)
• sdk: support platform address state transitions in JS SDK (#2931)

Bug Fixes

• drive: failing to prove absent platform addressess (#2934)
• sdk: non proved JS SDK methods (#2871)