From cd0f5f48641ab4097deeab3441b50b853266aa5e Mon Sep 17 00:00:00 2001 From: QuantumExplorer Date: Sat, 12 Sep 2026 00:34:59 +0700 Subject: [PATCH] docs: propose DashVM protocol and contract SDK DIP series --- README.md | 14 +++- dip-dashvm-activation.md | 84 ++++++++++++++++++++++ dip-dashvm-engine-abi.md | 96 +++++++++++++++++++++++++ dip-dashvm-execution.md | 99 ++++++++++++++++++++++++++ dip-dashvm-external-primitives.md | 85 ++++++++++++++++++++++ dip-dashvm-fees.md | 103 +++++++++++++++++++++++++++ dip-dashvm-governance.md | 86 ++++++++++++++++++++++ dip-dashvm-guards.md | 84 ++++++++++++++++++++++ dip-dashvm-proofs-clients.md | 84 ++++++++++++++++++++++ dip-dashvm-protocol.md | 102 ++++++++++++++++++++++++++ dip-dashvm-rust-sdk.md | 114 ++++++++++++++++++++++++++++++ dip-dashvm-scheduling.md | 82 +++++++++++++++++++++ dip-dashvm-storage.md | 103 +++++++++++++++++++++++++++ dip-dashvm/allocations.md | 63 +++++++++++++++++ 14 files changed, 1198 insertions(+), 1 deletion(-) create mode 100644 dip-dashvm-activation.md create mode 100644 dip-dashvm-engine-abi.md create mode 100644 dip-dashvm-execution.md create mode 100644 dip-dashvm-external-primitives.md create mode 100644 dip-dashvm-fees.md create mode 100644 dip-dashvm-governance.md create mode 100644 dip-dashvm-guards.md create mode 100644 dip-dashvm-proofs-clients.md create mode 100644 dip-dashvm-protocol.md create mode 100644 dip-dashvm-rust-sdk.md create mode 100644 dip-dashvm-scheduling.md create mode 100644 dip-dashvm-storage.md create mode 100644 dip-dashvm/allocations.md diff --git a/README.md b/README.md index 3e8d1cc4..74987df6 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ DIP stands for Dash Improvement Proposal. Similar to Bitcoin's [BIPs](https://github.com/bitcoin/bips/), a DIP is a design document providing information to the Dash community, or describing a new feature for Dash or its processes or environment. The DIP should provide a concise technical specification of the feature and a rationale for the feature. -Because Dash is forked from the Bitcoin codebase, many of the BIPs can be applied to Dash as well (a list of the BIPs updated to include Dash-specific details can be found [here](https://github.com/dashevo/bips)). The purpose of the DIPs is not to duplicate those which exist as BIPs, but to introduce protocol upgrades or feature specifications which are unique to Dash. +Because Dash is forked from the Bitcoin codebase, many of the BIPs can be applied to Dash as well (a list of the BIPs updated to include Dash-specific details can be found [Dash-specific BIPs](https://github.com/dashevo/bips)). The purpose of the DIPs is not to duplicate those which exist as BIPs, but to introduce protocol upgrades or feature specifications which are unique to Dash. ## Contributions @@ -47,6 +47,18 @@ Number | Layer | Title | Owner | Type | Status [29](dip-0029.md) | Consensus | Randomness Beacon For LLMQ Selection | Virgile Bartolo | Standard | Proposed [30](dip-0030.md) | Consensus | Replay Attack Prevention and State Transition Nonces | Samuel Westrich | Standard | Proposed [31](dip-0031.md) | Consensus | Platform Proof of Service | Ivan Shumkov, Pasta | Standard | Proposed +[Unassigned (dip-dashvm-protocol)](dip-dashvm-protocol.md) | Consensus | DashVM: Protocol integration and wire contracts | To be confirmed | Standard | Draft +[Unassigned (dip-dashvm-engine-abi)](dip-dashvm-engine-abi.md) | Consensus | DashVM: Deterministic Wasm engine, named bundles and ABI | To be confirmed | Standard | Draft +[Unassigned (dip-dashvm-activation)](dip-dashvm-activation.md) | Consensus | DashVM: Compilation readiness and executable lifecycle | To be confirmed | Standard | Draft +[Unassigned (dip-dashvm-storage)](dip-dashvm-storage.md) | Consensus | DashVM: Native storage, collections and capabilities | To be confirmed | Standard | Draft +[Unassigned (dip-dashvm-guards)](dip-dashvm-guards.md) | Consensus | DashVM: Bounded guards and native action rules | To be confirmed | Standard | Draft +[Unassigned (dip-dashvm-execution)](dip-dashvm-execution.md) | Consensus | DashVM: Atomic calls and ordered parallel execution | To be confirmed | Standard | Draft +[Unassigned (dip-dashvm-fees)](dip-dashvm-fees.md) | Consensus | DashVM: Admission bounds, fees, receipts and refunds | To be confirmed | Standard | Draft +[Unassigned (dip-dashvm-scheduling)](dip-dashvm-scheduling.md) | Consensus | DashVM: Time-based scheduled calls | To be confirmed | Standard | Draft +[Unassigned (dip-dashvm-governance)](dip-dashvm-governance.md) | Consensus | DashVM: Freeze, wipe and deleted-contract custody | To be confirmed | Standard | Draft +[Unassigned (dip-dashvm-proofs-clients)](dip-dashvm-proofs-clients.md) | Consensus | DashVM: Current-state proofs and client results | To be confirmed | Standard | Draft +[Unassigned (dip-dashvm-rust-sdk)](dip-dashvm-rust-sdk.md) | Applications | DashVM: Rust authoring and reproducible packages | To be confirmed | Informational | Draft +[Unassigned (dip-dashvm-external-primitives)](dip-dashvm-external-primitives.md) | Consensus | DashVM: ACL and randomness integration boundaries | To be confirmed | Standard | Draft ## License diff --git a/dip-dashvm-activation.md b/dip-dashvm-activation.md new file mode 100644 index 00000000..331b7caa --- /dev/null +++ b/dip-dashvm-activation.md @@ -0,0 +1,84 @@ +
+  DIP: Unassigned (dip-dashvm-activation)
+  Title: Compilation readiness and executable lifecycle
+  Chain: Platform
+  Layer: Consensus
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Standard
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Activate one immutable contract version only after at least 80% of the full active eligible evonode set reports compilation readiness, followed by an additional consensus-time delay. Specify pending replacement, permanent code, supported/deprecated/retired versions and latest-method routing. + +## Motivation + +Compilation should occur before execution becomes possible. Readiness must count the whole eligible network, survive report retransmission and membership changes, and never depend on a validator's local wall clock or artifact cache. Deprecated versions remain callable during a warning period without forcing contracts to link to stale versions. + +## Specification + +### State + +For each contract retain immutable manifests/blobs, one optional pending round, current latest active version, and per-version lifecycle metadata. A pending round contains contract/version/manifest/profile identifiers, acceptance time, round ID, keyed ready reports, membership-check cursor/reference if needed, first validated crossing and optional activation deadline. Supported/deprecated/unsupported status is distinct from pending/active selection and contract-wide freeze/wipe state. + +Only authorized update actions change a pending candidate. Replacing it atomically cancels the old round and its timer; old reports cannot count for the replacement. Cancelling it stops activation and refunds unused preparation funding after specified costs; all accepted canonical bytes remain. Collection has no automatic expiry. The previous latest version continues until the replacement activates, subject to its own freeze/retirement rules. + +### Membership and reports + +Use the agreed Core masternode list referenced by the Platform block at its specified membership-update phase. Never count the current validator quorum alone or query a newer node-local Core height. One authenticated eligible evonode identity has one yes report per round. A report binds network, contract/version, round, manifest and engine/preparation profile and can be sent only after full bundle compilation and binding checks. Duplicate reports are idempotent; failed delivery permits retransmission. Stale keys/profiles/rounds cannot be replayed. + +Let `N` be all active eligible evonodes in that same membership view and `Y` the eligible distinct yes reports. Threshold is `N > 0 && 5*Y >= 4*N`, evaluated with checked wide integers. A count tree accelerates tallying but does not establish current voter eligibility. Prune ineligible votes and revalidate against the agreed view when a raw count could cross, and reconsider on membership changes, including a decrease in N without a new report. Bounded paged validation uses one immutable membership reference and cannot establish a crossing from a partial/stale scan. If membership changes before the result is committed, revalidate or invalidate that scan's certificate. + +The exact active-eligibility predicate must be bound to the current native evonode eligibility implementation and versioned in the allocation register. It cannot be inferred from report participation. This is an implementation binding still requiring source-level vectors, not an unanswered threshold policy. + +### Timing and block phases — proposed engineering convention + +Use monotonic committed Platform consensus time, checked for overflow. At a beginning-of-block lifecycle phase, first apply the block's agreed membership update, then finish/revalidate pending threshold checks, apply due prior activation decisions, and apply approved governance outcomes before affected scheduled work. Reports/cancellations/replacements accepted from this block's ordered transition sequence become eligible for lifecycle decisions at the next block boundary. This prevents scheduled execution from depending on a report appearing later in the same block. The exact mapping onto existing ABCI event order is a reviewable proposal and must pass upgrade/order vectors before adoption. + +At the first boundary that validates a threshold crossing, let `T = crossing_time - accepted_deployment_time`. Set `wait = min(max(T, 120 seconds), 3600 seconds)` and `deadline = crossing_time + wait`. Activate at the first eligible block boundary whose consensus time is at least that deadline. There is no second quorum gate at the deadline and later membership changes do not restart an established timer. New nodes prepare to follow the active state. A replacement or authorized cancellation processed before activation removes the old pending deadline; a transaction processed after a boundary cannot retroactively cancel activation at that boundary. + +This is an additional wait equal to the time taken to reach 80%, bounded between two minutes and one hour. It is not an extra wait of 2T. Empty membership never approves; withholding readiness can leave a candidate pending indefinitely. No below-threshold fallback is allowed. + +### Version selection + +Activation atomically installs the complete bundle and latest public routing. Cross-contract calls and scheduled calls resolve stable method IDs on the latest version visible at their ordered execution point; no older-version fallback. A direct user may explicitly request a still-supported older version. With no direct selection, use latest. Missing methods return a structured failure under DVM-06/08. + +An authorized update can declare deprecation, warning/notice commitments and later unsupported status. Deprecation is a warning state, not rejection. A promised notice interval cannot be shortened by a later update. A newer active version does not itself make older versions unsupported. Once unsupported, new direct calls cannot select that version, but its canonical code remains. Supported older code never restores older schema/index permissions or obsolete authorization. Freeze is contract-wide; updates while network-frozen do not unfreeze execution. Wipe cannot be undone by activating a retained blob. + +## Backward compatibility and node operation + +Preparation on restart, cache loss and upgrades uses permanent canonical state and historical profiles. A node without a compatible compiled artifact is locally unready; it must not reject a consensus-valid call, charge a cold-cache surcharge or use another backend's behavior. Readiness is an availability mechanism, not a proof that compiled output is correct. Report transport, catch-up and membership-key upgrades are implementation work. + +## Security considerations + +Bind report signatures to exact rounds and profiles; count identities rather than messages. Bound repeated validation and membership work without allowing an unverified tally. Deployment fees cover specified validation/report verification, while operators pay local compilation. Timer overflow, membership churn, abandoned candidates and compilation storms require adversarial tests. The protocol deliberately trades pending-deployment liveness for the selected 80% condition. + +## Test vectors + +For N=5, Y=3 fails and Y=4 passes; N=400 requires 320; N=0 always fails. Duplicate, removed and wrong-round voters never inflate Y. If T is 30 seconds, wait is 120; T=600 gives wait=600; T=7200 gives wait=3600. Test exact deadline, no block exactly at deadline, membership-only crossing, churn during paged checking, cancellation/replacement on each phase boundary, old/latest routing, frozen update, code retention and all cache states. The phase table must have golden beginning/end-of-block cases. + +## Reference implementation, rationale and open allocations + +ABCI owns membership/report scheduling and activation phases; DPP owns messages; Drive owns version/round/vote records; DashVM owns compilation. DVM-04 specifies paths. Exact codecs, report signature/key reuse, active predicate binding and event-phase wiring remain registry entries. The proposed phase convention and support metadata are fleshed-out engineering drafts, not claims of additional owner approval. + +## Related drafts and implementation tracking + +[DVM-01](dip-dashvm-protocol.md) · [DVM-02](dip-dashvm-engine-abi.md) · [DVM-04](dip-dashvm-storage.md) · [DVM-05](dip-dashvm-guards.md) · [DVM-06](dip-dashvm-execution.md) · [DVM-07](dip-dashvm-fees.md) · [DVM-08](dip-dashvm-scheduling.md) · [DVM-09](dip-dashvm-governance.md) · [DVM-10](dip-dashvm-proofs-clients.md) · [DVM-11](dip-dashvm-rust-sdk.md) · [DVM-12](dip-dashvm-external-primitives.md) + +* [50-DEPLOY](https://github.com/dashpay/platform/issues/4684): Implement permanent bundles, registration, readiness and version routing (5.0-dev). +* [50-CLIENTS](https://github.com/dashpay/platform/issues/4693): Deliver DAPI, Rust, Wasm/JS and mobile parity (5.0-dev). +* [50-GOV](https://github.com/dashpay/platform/issues/4695): Implement governance, bounded wipes and vestige recovery (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm-engine-abi.md b/dip-dashvm-engine-abi.md new file mode 100644 index 00000000..c45ed07f --- /dev/null +++ b/dip-dashvm-engine-abi.md @@ -0,0 +1,96 @@ +
+  DIP: Unassigned (dip-dashvm-engine-abi)
+  Title: Deterministic Wasm engine, named bundles and ABI
+  Chain: Platform
+  Layer: Consensus
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Standard
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Specify the Wasmtime/Cranelift execution profile, deterministic validation and instrumentation, immutable multi-module bundles, host ABI, metering and local compiled-artifact lifecycle. Canonical Wasm is consensus state; native compiled artifacts are reproducible local acceleration. + +## Motivation + +Long-lived contracts need fast execution without depending on a node's CPU, cache state or compiler defaults. Several named modules per version allow large Rust contracts to share unchanged components across versions. This requires explicit linking and shared resource accounting rather than treating each module as an independent allowance. + +## Specification + +### Engine and validation boundary + +Use upstream Wasmtime with Cranelift. Pin its exact release/commit, transitive lockfile, compiler options, target CPU feature policy, memory guards, validation transform and metering generation in the profile. Winch/interpreters may be diagnostic comparison tools; they are not automatic production fallbacks. `rs-dashvm-validation` validates original Wasm, instruments required logical stack/resource checks, validates transformed output and returns metadata. It cannot compile native code or execute initialization. `rs-dashvm` compiles, instantiates and executes the resulting module. Stateful authority/capability validation stays above both. + +Scalar f32/f64 are allowed with Cranelift NaN canonicalization. Test NaN reinterpretation, signed zero, subnormals, conversions and trapping instructions on x86_64 and aarch64. NaN canonicalization alone is not a determinism proof. Proposed first feature set excludes threads/shared memory, memory64, SIMD/relaxed SIMD and ambient WASI I/O; every admitted opcode/import is listed and priced before activation. Features are not inherited from changing Wasmtime defaults. + +### Immutable bundle schema + +`BundleManifest` binds codec/ABI/profile IDs, ordered `Module{name, canonical_hash, interface}`, exact internal bindings, stable contract-wide method/type/index IDs, public routes, capabilities, initialization metadata and aggregate limits. Hash a domain-separated canonical encoding. Names are bounded and canonically encoded; duplicate names/IDs/routes and ambiguous encodings reject the bundle. Hash algorithm, widths and tags are explicit allocation entries, not silently chosen here. + +Each binding names a module/export/signature in this exact manifest. Public calls resolve a stable method ID to one module/export. Internal bindings never float to a different contract version. The proposed initial linker requires an acyclic dependency graph, separate instance memories/tables and host-mediated typed internal calls. Reject missing imports, conflicting signatures, cycles and unauthorized shared-memory/global access. No per-function on-chain code archive is created. + +Only the selected entry module's dependency closure is instantiated, in deterministic dependency order with canonical-name tie breaking. Proposed initialization permits bounded memory/global/table setup but no external state writes, transfers or nested contract calls before entry dispatch. Reject undeclared side-effectful starts; transformed and toolchain-produced start sections require explicit validation rather than incidental execution. Define data/element segment limits and initialization copy costs. Shared closure initialization runs once per invocation; no instance state survives to the next outer invocation. + +### ABI and guest memory + +Use versioned typed requests/results defined by `rs-dashvm-abi`. A host function receives a guest-memory range, decodes bounded canonical data, checks the invoked capability and returns a bounded encoded result through an explicitly owned response buffer/handle. Exact import/export names, function signatures and handle layout are allocated in the shared register. Semantic operation families include native document/query/collection/asset operations, nested calls, schedule/receipt policy operations, and gated ACL/randomness requests. + +Check pointer plus length for overflow and memory containment before access; cap nesting, collection counts and decoded expansion independently of stored byte size. Do not expose host pointers, OS resources or raw GroveDB paths. Handles are scoped to one invocation/authority context, cannot be forged into another capability, and expire at its end. Copying across separate module memories is metered. Input data is copied or safely borrowed only for a documented lifetime; host reentry cannot retain guest slices across memory growth. Host error variants have fixed bounded encodings. + +### Shared resources and metering + +An outer invocation owns one computation counter, logical stack/activation counter, memory reservation, host-call count, read/copy budget, proposed-operation budget and receipt bound. Local recursion, internal modules, predicates and cross-contract calls consume this same scope. A module call cannot reset a limit. Logical stack accounting includes locals and operand slots; native-stack headroom must be independently demonstrated so architecture-specific native exhaustion cannot precede the specified logical trap. + +Meter admitted Wasm semantics with a versioned schedule whose result is independent of compiler optimization and local cache state. Wasmtime raw fuel may implement only the portion proven equivalent to that schedule. If raw fuel affects consensus fees or limits, exact trapped-case parity is mandatory; otherwise it is diagnostic. Memory growth uses deterministic logical reservation and bounds, with metered initialization/copies. Local allocation failure within admitted resources is a node fault, not a different guest-visible `memory.grow` result. Meter native work exactly once as DVM-07 defines. + +### Compiled cache and replay + +Cache keys bind canonical hash, prepared hash, bundle binding digest where relevant, ABI/preparation/metering versions, exact engine build/profile, target architecture and CPU/guard configuration. Validate native artifact integrity and origin before unsafe deserialization; network-supplied native code is never trusted as a compiled contract. Store artifacts atomically, discard incompatible/corrupt entries and rebuild from canonical code. Instances and authority state are never shared between invocations. + +Maintain runnable supported-version modules, pending compilation and historical replay as distinct sets. Shared artifacts are retained while another executable version still needs them; eviction does not delete canonical state or make execution charge more. Readiness requires all modules compiled and all bindings checked. A node missing artifacts must prepare before validating/executing the affected work; it cannot manufacture a paid contract error. Retain historical profiles for historical replay and plan protocol-upgrade preparation before activation. + +## Backward compatibility and deployment + +Engine behavior changes use normal protocol upgrades; historical descriptors remain available. Old supported code uses its specified execution compatibility behavior plus current storage/authorization rules. A profile upgrade must state how existing accepted code is transformed/recompiled; it cannot silently invalidate it or freeze contracts. Canonical blobs/manifests stay permanent after cancellation, retirement and wipe. + +## Security considerations + +Compilation complexity, instrumented growth and aggregate bundle size need independent bounds. Native compilation is attackable even when guest computation is metered. Nodes pay compilation; bounded protocol validation/storage/readiness charges and admission limits must bound deployment spam. An 80% readiness statement proves availability work, not compiler correctness. Keep upstream advisory monitoring and minimal temporary patches with upstream fixes as the maintenance strategy. + +## Test vectors and acceptance + +Include integer edges, NaN/trap/stack/memory cases, giant functions/types, invalid pointers and handles, cyclic/missing imports, deterministic initialization, two versions reusing one blob, shared-resource exhaustion across modules, cold/warm/recovered cache, corrupted artifacts and historical replay. Compare results, fee/limit counters, trap classes, proposed operations and final roots on both architectures. Reproduce relevant advisories with an affected configuration where feasible; an unaffected default run is not a regression test. + +## Reference implementation and open allocations + +Owners: rs-dashvm-validation, rs-dashvm, rs-dashvm-abi, rs-platform-version; tooling consumes the same validator. Production engine pin, complete opcode schedule, feature allowlist, exact ABI bytes, initialization restrictions and numeric caps remain explicit engineering review/measurement entries. The provisional resource/price appendix supplies starting values without asserting measured safety. + +## Rationale + +Cranelift prioritizes long-term execution speed; deterministic preparation and native storage reuse provide the blockchain-specific boundary. Splitting validation from runtime lets DPP/tooling share it without embedding a compiler. Multi-module bundles preserve atomic version activation and allow reuse without a distributed floating linker or per-function lifecycle. + +## Related drafts and implementation tracking + +[DVM-01](dip-dashvm-protocol.md) · [DVM-03](dip-dashvm-activation.md) · [DVM-04](dip-dashvm-storage.md) · [DVM-05](dip-dashvm-guards.md) · [DVM-06](dip-dashvm-execution.md) · [DVM-07](dip-dashvm-fees.md) · [DVM-08](dip-dashvm-scheduling.md) · [DVM-09](dip-dashvm-governance.md) · [DVM-10](dip-dashvm-proofs-clients.md) · [DVM-11](dip-dashvm-rust-sdk.md) · [DVM-12](dip-dashvm-external-primitives.md) + +* [44-CODEC](https://github.com/dashpay/platform/issues/4679): Extract the shared guest value and codec foundation (4.4-dev). +* [44-ENGINE](https://github.com/dashpay/platform/issues/4681): Build a small isolated VM experiment and test foundation (4.4-dev). +* [50-ENGINE](https://github.com/dashpay/platform/issues/4683): Implement the deterministic runtime, validator and compatibility corpus (5.0-dev). +* [50-DEPLOY](https://github.com/dashpay/platform/issues/4684): Implement permanent bundles, registration, readiness and version routing (5.0-dev). +* [50-READS](https://github.com/dashpay/platform/issues/4686): Implement bounded current-state guest reads (5.0-dev). +* [50-AUTHOR](https://github.com/dashpay/platform/issues/4694): Deliver contract SDK, macros, build/test tools and worked example (5.0-dev). +* [50-VERIFY](https://github.com/dashpay/platform/issues/4696): Complete upgrade, sync, recovery and release evidence (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm-execution.md b/dip-dashvm-execution.md new file mode 100644 index 00000000..998a9dfc --- /dev/null +++ b/dip-dashvm-execution.md @@ -0,0 +1,99 @@ +
+  DIP: Unassigned (dip-dashvm-execution)
+  Title: Atomic calls and ordered parallel execution
+  Chain: Platform
+  Layer: Consensus
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Standard
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Define canonical sequential semantics for direct, internal-module and cross-contract calls, and permit parallel execution only when it produces exactly those semantics. Each transition sees current accepted predecessor state plus its own writes. One outer invocation has one atomic application-effect scope and one settlement. + +## Motivation + +Parallel workers can accelerate independent computation, but discovering only matching input/output keys is insufficient: absent keys, ranges, indexes, permissions and cost paths also affect results. The canonical writer must preserve native operations, Merk shape, fee accounting and the agreed transaction order. + +## Specification + +### Sequential reference semantics + +Let B be the agreed block work sequence, including native lifecycle/scheduled phases. Execute each accepted work item against the state produced by its accepted predecessors. For a guest invocation, expose prior native effects from that invocation through a transaction-local view. Later work and abandoned speculative branches are invisible. Apply native validation and action conversion for every proposed effect; commit a successful outer application's effects atomically with its specified settlement. Drive ABCI commits the block transaction once. + +Canonical order is the existing Platform ordering protocol plus explicit new phase conventions. This draft does not introduce a fairness/order auction or claim arbitrary transaction reorderings preserve outputs. Document ordering exposure for each value-moving capability. + +### Caller and authority model + +Context distinguishes the transaction signer, immediate caller contract, executing contract/version/module, resource owner and explicitly delegated rights. A direct call authenticates through native identity rules; the direct signer pays its invocation as specified by DVM-07. Nested calls do not inherit unrestricted signer authority. Delegation binds target, method/resource/action and bounded scope; receiving permission and native asset rules still apply. Same-contract module calls preserve the same contract authority and shared limits. + +Cross-contract calls target the latest visible stable method route. Direct users may choose supported older code. Maintain an active contract-ID stack: entering a contract already active in that call stack is forbidden, including through predicates. This does not forbid ordinary Rust recursion or calls between modules of the same active contract; those consume the shared logical stack. A callee cannot increase remaining bounds, change payer or independently commit. + +### Outcomes and atomicity + +Success accepts validated application effects plus settlement. An actual nested failure, guest trap, guard rejection, native-action validation error or exhausted deterministic bound marks the outer invocation failed; returning `Ok` after catching the error cannot restore success. Roll back all outer and nested application effects. Retain only specified fee/nonce/receipt/job-attempt bookkeeping. Native missing read results and randomness `NotReady` are ordinary typed values, not hidden failure exceptions. Infrastructure faults follow existing node/protocol recovery and cannot be relabeled as paid guest failures. + +The integration layer owns the failure latch; guest code cannot clear it. It also prevents writes, transfers or successful return from committing after poisoning. Native result classification must distinguish unsuccessful control/data queries from an attempted unauthorized/invalid state mutation. Tests cover those distinctions explicitly. + +### Parallel execution — proposed implementation algorithm + +The serial algorithm is authoritative. A correct serial implementation remains valid regardless of worker count. Parallel workers execute bounded speculative calls against an identified accepted prefix or a faithful isolated branch that exposes that prefix. The inspected GroveDB develop read-only snapshot is not a writable fork of the uncommitted transaction; building that capability is upstream work, not an existing guarantee. + +Each attempt records the prefix/profile identity, typed native intent log, return/failure and fee/resource result, and every semantic observation used to produce them. Dependencies include point values and absence, ranges and their ordering/limits, index/schema definitions, permissions/ACL/group membership, code routing/lifecycle, nonces/balances/fee tables, derived writes and native operation-cost assumptions. A write-only key is not independent if its validation reads existing state. Query range tracking must detect phantom inserts/removals and changes outside returned rows that affect rank/count/cost. + +At the canonical position of an attempt: + +1. Compare all recorded dependencies and behavior/profile inputs with the current accepted prefix. Include cost-sensitive observations even when returned application values happen to be equal. +2. If any dependency is changed, unavailable or incompletely tracked, discard the attempt and reexecute against the current prefix. Revalidation alone cannot repair changed control flow or metering. +3. If valid, replay the typed native operations through the same native paths and ordering as serial execution, including derived indexes and two-stage namespace insertion. Do not merge physical Merk deltas or independently calculated root hashes. +4. Validate replay outcome, actual cost/refund dependencies and final result. If replay reveals a missing dependency or mismatched application behavior, abort the attempt and execute canonically; do not publish partial speculative fees/results. +5. Accept one result and its settlement, advance the prefix and continue. + +The writer remains single and ordered. Parallelism applies to computation/read/validation work where safe; all accepted effects become externally committed together at block commit. Native work that cannot yet declare sound dependencies uses the serial path. A coarse contract/subtree dependency is safe but reduces concurrency. It is not acceptable to assume a disjoint declared input list is complete without host enforcement. + +### Bounds and fallback + +Bound workers, speculative memory, observation-log size and attempts. Overflow/coarsening selects serial execution; it cannot become a new paid error. Proposed initial fallback is at most one speculative attempt followed by a canonical serial retry for a conflicting item; more retries are a local optimization only if consensus charges/outcomes remain identical and resource exhaustion cannot invalidate a block. Internal retries consume node resources but add no user charge, nonce, receipt or scheduled attempt. Charge only the accepted canonical execution and its native work. + +## Compatibility and deployment + +Existing native state transitions must participate in conflict/observation handling or execute as serial barriers; they cannot bypass dependencies by being classified non-contract. Protocol upgrades and lifecycle events establish barriers before affected work. The implementation may ship a serial engine while parallel support is developed, but the tracked 5.0 acceptance for ordered parallel execution stays open until the required feature and equivalence tests pass. + +## Security and performance considerations + +An attacker can create shared balances, hot indexes, giant ranges or conflicts that erase parallel speedups. Bound speculation and retain deterministic serial fallback. Single-writer native storage is an explicit throughput limit. Hidden storage-cache costs cannot leak into consensus charging. No reentry reduces attack surface but limits composability; it is an approved rule rather than a claim of universal superiority. + +## Test vectors + +Include two increments to one key, disjoint writes sharing one payer, range phantoms, absent-key insertion, index/schema/ACL changes, latest-version activation, same-invocation writes, caught nested failure, logical stack across modules and native operation failure during replay. Compare serial and parallel roots, outputs, fees, nonces, refunds, receipt bytes and job outcomes at worker counts 1 and many. Inject a deliberately omitted dependency and show acceptance rejects or detects the mismatch. Host-fault scheduled recovery is a separate required rehearsal. + +## Reference implementation and open allocations + +rs-drive-contracts owns scope/context/dependency tracking, call routing and native-effect mediation; Drive owns isolated native views/replay and shared validation; GroveDB needs the proposed branch facility; ABCI owns order and commit. Exact observation representation, native cost/cache dependency coverage and upstream branch API require implementation evidence. The serial specification provides an executable oracle without dictating unsafe physical tree merging. + +## Related drafts and implementation tracking + +[DVM-01](dip-dashvm-protocol.md) · [DVM-02](dip-dashvm-engine-abi.md) · [DVM-03](dip-dashvm-activation.md) · [DVM-04](dip-dashvm-storage.md) · [DVM-05](dip-dashvm-guards.md) · [DVM-07](dip-dashvm-fees.md) · [DVM-08](dip-dashvm-scheduling.md) · [DVM-09](dip-dashvm-governance.md) · [DVM-10](dip-dashvm-proofs-clients.md) · [DVM-11](dip-dashvm-rust-sdk.md) · [DVM-12](dip-dashvm-external-primitives.md) + +* [44-ENGINE](https://github.com/dashpay/platform/issues/4681): Build a small isolated VM experiment and test foundation (4.4-dev). +* [50-GUARDS](https://github.com/dashpay/platform/issues/4685): Implement native guards and preserve contested-index awards (5.0-dev). +* [50-READS](https://github.com/dashpay/platform/issues/4686): Implement bounded current-state guest reads (5.0-dev). +* [50-CALLS](https://github.com/dashpay/platform/issues/4687): Implement atomic calls, delegation and ordered parallel execution (5.0-dev). +* [50-SCHEDULE](https://github.com/dashpay/platform/issues/4688): Implement time-only live-paid schedules and removal settlement (5.0-dev). +* [50-FEES](https://github.com/dashpay/platform/issues/4689): Implement contract bounds, actual charging, receipts and historical refunds (5.0-dev). +* [50-NATIVE](https://github.com/dashpay/platform/issues/4690): Implement the full native capability and collection adapters (5.0-dev). +* [50-VERIFY](https://github.com/dashpay/platform/issues/4696): Complete upgrade, sync, recovery and release evidence (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm-external-primitives.md b/dip-dashvm-external-primitives.md new file mode 100644 index 00000000..79e05f83 --- /dev/null +++ b/dip-dashvm-external-primitives.md @@ -0,0 +1,85 @@ +
+  DIP: Unassigned (dip-dashvm-external-primitives)
+  Title: ACL and randomness integration boundaries
+  Chain: Platform
+  Layer: Consensus
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Standard
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Define the contract-facing requirements for separately implemented native ACL and randomness primitives, their fail-closed stubs and activation gates. This draft specifies integration; it does not choose an unreviewed ACL policy engine or cryptographic randomness construction for those external projects. + +## Motivation + +Contract developers should be able to depend on native authorization and finalized randomness without importing them as guest libraries. Their delivery must appear in the dependency graph and release tracking even while the contract project provides only stubs. + +## Specification + +### Capability lifecycle + +Declare exact required capability/generation in the bundle. Until the native implementation and validated host adapter are active in the protocol profile, a requiring contract cannot become executable. SDK presence or an operator flag is not activation. Registration may retain a structurally valid pending artifact only if the deployment policy explicitly supports it; it cannot bypass unsupported-capability admission or falsely report executable readiness. + +Production stubs return a stable `CapabilityUnavailable` error and never allow authorization or provide entropy. Test-only fixtures have an explicit test feature/provider and must not link into the production profile. Pending randomness is a distinct successful `NotReady` result, not the same as an unavailable primitive or failed host call. + +### ACL semantic interface + +`require(Resource, Action)` receives authentic host signer/caller/executing-contract context and the current native policy/membership state. The resource names a declared contract/document/collection/asset scope, not a raw GroveDB path. Success grants only that requested operation under current native rights; denied authorization is an actual failure that poisons the outer invocation. Optional non-authorizing inspection/query methods must have distinct semantics so a Boolean check cannot be mistaken for enforcement. + +Delegation is explicit and bounded by the delegator's rights. Policy updates/revocation, group membership and applicable revision are current-state observations for conflict validation. A cached allow decision cannot survive a changed predecessor policy. Host enforcement remains mandatory for handwritten Wasm and native effects; guest assertions do not create rights. Native contested-index awards remain outside custom ACL/guest veto scopes and preserve their protocol-defined native checks. + +The external ACL project must specify subjects/resources/actions, inheritance and precedence, ownership/update authority, group semantics, revocation timing, delegation limits, default deny, costs, bounded evaluation, codecs, proof exposure and upgrade behavior. It must use native reusable storage/validation and pass its own conformance vectors. Contract integration cannot fill these gaps with an allow-all mock. ACL restrictions are not encryption or protection from reading public state through another route. + +### Randomness semantic interface + +`request(domain, application_binding)` creates a native request ID bound to network, contract, invocation/request nonce, purpose, profile and the fixed application intent. It must select a future source/round according to the native primitive so the result is not already knowable when the relevant application commitments are accepted. `get(request_id)` returns `NotReady` until the selected result is finalized, then a fixed `Ready{value, source_reference}` under the authorized native result contract. Repeated reads return the same result; a guest cannot substitute another source or resample the same intent after seeing an unfavorable result. + +The native primitive owns unpredictability, bias/withholding resistance, proof verification, finality and source selection. The host validates request ownership/binding, costs and current finalized result and records dependencies. Request creation and related application commitments are atomic. Consumers must fix participants/stakes before the result can be known and handle delayed/unavailable completion; the VM cannot enforce an application's fairness merely by returning random bytes. + +No immediate host entropy, timestamp/hash-of-current-block shortcut, insecure seed or automatic fallback is allowed. Node-local RNG cannot enter consensus. A pending result is ordinary control flow and may return successful `Pending` without poisoning the invocation. Genuine request/authorization/proof failures remain errors. + +The external randomness project must specify cryptographic source, future-round selection, domain/hash encoding, adversary assumptions, reorg/finality behavior, withholding/timeout policy, result uniqueness, costs/storage/retention, proof exposure and upgrade/replay behavior. DIP-0029 concerns randomness for LLMQ selection; it is related work, not evidence that Platform already has this application request/result primitive or that its exact construction is selected here. + +### Delivery and activation + +EXT-ACL targets 4.3-dev and EXT-RNG targets 4.4-dev as separate native projects. STUB-ACL/STUB-RNG and INT-ACL/INT-RNG remain tracked 5.0 contract integration work. Early native delivery does not require DashVM or activate smart contracts. Conversely, the presence of a stub does not complete the native task. Integration activation requires the real native implementation, current version/capability gate, matching ABI/client vectors and bounded fees/proofs/lifecycle handling. + +## Backward compatibility and security + +Unknown capability generations fail closed. Preserve old native policy/request decoding through versioned dispatch; do not silently change finalized results or authorization interpretation under a cache. Freeze/wipe and revocation prevent new unauthorized actions without fabricating random failure outcomes. Retained request/results follow their separately specified native ownership and lifecycle, including wiped refund destinations. + +## Test vectors + +ACL: unavailable stub, allow/deny, forged context/handle, delegation escalation, revoked predecessor rights, membership change, old code/current policy and caught denial. Randomness: unavailable stub, valid pending, repeated finalized read, wrong contract/domain, premature/wrong-round result, tampered proof, replay/resampling, withheld finality and rollback of request plus application commitment. Test fixtures must be impossible to enable in a production profile. Compare serial/parallel results and cost/dependency handling. + +## Reference implementation, rationale and open decisions + +Native project owners implement the primitives in their appropriate DPP/Drive/versioned services. rs-drive-contracts provides gated adapters; rs-dashvm-abi and contract SDK expose typed calls; clients/proof verifier share native result definitions. The external project specification tasks remain explicitly open: this boundary draft is complete enough to implement stubs and integration contracts, but it is not a cryptographic or full native ACL specification. Keeping them separate respects the selected scope and prevents an accidental insecure default. + +## Related drafts and implementation tracking + +[DVM-01](dip-dashvm-protocol.md) · [DVM-02](dip-dashvm-engine-abi.md) · [DVM-03](dip-dashvm-activation.md) · [DVM-04](dip-dashvm-storage.md) · [DVM-05](dip-dashvm-guards.md) · [DVM-06](dip-dashvm-execution.md) · [DVM-07](dip-dashvm-fees.md) · [DVM-08](dip-dashvm-scheduling.md) · [DVM-09](dip-dashvm-governance.md) · [DVM-10](dip-dashvm-proofs-clients.md) · [DVM-11](dip-dashvm-rust-sdk.md) + +* [43-ACL](https://github.com/dashpay/platform/issues/4677): Deliver the native ACL primitive as a separate project (4.3-dev). +* [44-AUTHOR](https://github.com/dashpay/platform/issues/4680): Settle contract declarations and the Rust author API (4.4-dev). +* [44-RNG](https://github.com/dashpay/platform/issues/4682): Deliver the native randomness primitive as a separate project (4.4-dev). +* [50-AUTHOR](https://github.com/dashpay/platform/issues/4694): Deliver contract SDK, macros, build/test tools and worked example (5.0-dev). +* [50-ACL](https://github.com/dashpay/platform/issues/4698): Integrate native ACL with fail-closed contract stubs (5.0-dev). +* [50-RNG](https://github.com/dashpay/platform/issues/4699): Integrate native randomness with fail-closed contract stubs (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +Related work: [DIP-0029, LLMQ-selection randomness](https://github.com/dashpay/dips/blob/master/dip-0029.md); its scope is not the application primitive proposed here. + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm-fees.md b/dip-dashvm-fees.md new file mode 100644 index 00000000..e3f8e553 --- /dev/null +++ b/dip-dashvm-fees.md @@ -0,0 +1,103 @@ +
+  DIP: Unassigned (dip-dashvm-fees)
+  Title: Admission bounds, fees, receipts and refunds
+  Chain: Platform
+  Layer: Consensus
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Standard
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Extend the native Platform fee pipeline with deterministic contract costs, full affordability before guest execution, one final charge, default-enabled receipts and historical-owner refunds. Repair native fee-version lookup before dependent infrastructure lands. + +## Motivation + +Metered execution is safe only if admission covers its worst permitted cost and balances are conserved on every outcome. Storage deletion must use historical fee context and refund the real recorded owner. Node-local compilation, caches and speculative retries must not become consensus-dependent charges. + +## Specification + +### Fee version integrity + +Registered fee-table identifiers must round-trip between persisted numbers, registry lookup and every PlatformVersion reference. Unknown identifiers are errors, not a fallback to the current table or array index. Preserve historical storage flags and refund rates on old records. Audit all deletion/refund callers, including scheduled/block lifecycle cleanup, for required historical context. A software correction that changes consensus behavior on historical blocks requires explicit versioned treatment, not retroactive reinterpretation. + +### Cost model and sound bounds + +Let F be the protocol fee profile and L the admitted resource limits. Before guest execution compute `U = validation_bound + computation_bound(F,L) + native_operation_bound(F,L) + storage_and_receipt_bound(F,L)`. Use checked arithmetic and bound derived index/reference/cascade work, memory growth/initialization, scanned keys, guest encoding expansion and repeated copies. An operation whose bound cannot be established is unavailable or constrained to a form with a sound bound. Output-size limits alone do not bound query work. + +Check that the authorized live payer can cover U, including other obligations in accepted order. Establish invocation-local holds that cannot be spent twice. The direct signer pays the direct/nested invocation scope; scheduled work uses its declared authorized live source. Native transfer amounts and storage deposits must be reserved consistently with actual payer/owner policy. Nested code cannot change payer or exceed delegated spending limits. Recheck at execution after CheckTx; no guest execution occurs in CheckTx/RecheckTx. + +One contract-only computation counter covers guards, all modules, nested calls and scheduled execution. Enforce both per-invocation and per-block contract limits on proposal creation and validation. Existing native event budgets remain; do not create the previously rejected combined native-event budget. Wall-clock time never decides a paid computation limit. + +### Actual settlement + +Charge deterministic accepted execution work plus existing native processing/storage charges exactly once. A host-entry overhead may be added where it represents separate work; do not charge a native query twice because it passes through a VM adapter. Native reference tests cannot provide consensus fuel prices; actual metered runtime vectors do. Local compilation time, artifact misses and internal retries have zero additional protocol execution charge. + +| Outcome | Application effects | Settlement | +| --- | --- | --- | +| Successful accepted invocation | All validated outer/nested effects atomically | Actual charge; release unused hold; native nonce outcome; optional bounded receipt | +| Deterministic paid failure after admitted execution | None of the outer/nested application effects | Charge specified consumed work and failure bookkeeping; native paid-failure nonce rule; optional receipt | +| Structural/authentication/admission rejection | No guest execution or application effects | Existing native rejection-stage fee/nonce rules; never invent an execution receipt for unexecuted guest work | +| Speculative attempt discarded | No accepted effects | No separate charge/nonce/receipt; later canonical attempt settles once | +| Genuine infrastructure/storage fault | No fabricated guest success/failure | Abort/recover through existing node/protocol rules; never hide it with paid settlement | + +The exact pre-execution error-to-fee/nonce mapping is bound to existing native validation stages in the allocation register. A numeric error ID alone does not define paidness. Refund unused invocation holds; storage fees remain subject to actual native allocation/deletion rules. + +### Code and preparation economics + +Charge accepted new canonical bytes permanently using native storage accounting. Deduplicate unchanged blobs within the same contract: new versions pay new manifest/binding storage and bounded validation, while already-stored bytes preserve their original owner/rate and do not earn another refund. No reference-count deletion of accepted code. Deployer charges cover protocol validation and accepted readiness verification; operators pay local native compilation. Refund unused preparation funding on authorized cancellation after applicable costs without deleting accepted bytes. Prototype one bounded upload before deciding any separate staging/chunking design. + +### Receipts + +Receipts default to enabled and the contract declares retention or disables them. Pre-reserve a bounded receipt/storage cost before execution so reporting failure cannot itself exceed the admitted bound. Store one outer receipt containing invocation/execution position, resolved version/method, success or deterministic paid failure, actual cost and bounded nested outcomes. Do not create one default receipt per function/module, or store speculative attempts. Deterministic truncation/omission of optional detail must be defined in its codec; required outcome/fee fields cannot be dropped. + +Proposed retention rule snapshots effective terms at creation; later policy changes apply to new receipts. Any retrospective change is an explicit bounded metered native operation. Infinite retention has no expiry index entry. Receipt deletion and expiry-index removal are atomic. The receipt stores native ownership/fee context; deletion refunds that owner, not the caller performing cleanup. A receipt's inclusion proof proves a stored current-state record, not arbitrary historical execution correctness. + +### Typed refund ownership and conservation + +Use a typed owner such as native identity, contract bucket or existing native destination where supported. Never reinterpret all ownership flags as identity IDs. Wiped contract credits and later refunds go to the current processing pool; another payer's refund remains theirs. Refunds to frozen contracts follow permitted native inbound rules without executing guest code. + +Reuse the existing prefunded ledger for job removal. Count its money once and keep purpose metadata nonmonetary. Registration debits the actual funder; settlement consumes removal cost and returns unused value once. Fee upgrades must preserve removal affordability or settle affected old jobs before raising an unpayable obligation. Incremental wipe/cleanup cannot credit a balance again after logical settlement. Test conservation across contract buckets, native identities, prefunds, processing/storage pools and per-token ledgers separately. + +## Backward compatibility and deployment + +The small 4.3-dev native fee-registry/refund prerequisite is separable from 5.0 contract pricing. Proposed early slices do not complete the full DashVM fee tasks. Preserve historical replay and old fee formats on both replay-from-genesis and saved-state upgrade paths. Exact new rates and limits require measurements and versioned allocation before activation. + +## Security considerations + +Affordability must include failure and receipt costs; no underfunded path can execute expensive guest work first. Repeated failed reads, deep nested structures, cache-dependent native costs, integer overflow and ownership misrouting are attack surfaces. A sound upper bound is a protocol obligation, not a UI estimate. Block boundaries and epochs may change fee destinations; settlement uses the specified current processing pool and historical storage context correctly. + +## Test vectors and reference implementation + +Require exact U/actual/refund vectors for success, guard rejection, nested failure, exhaustion, receipt on/off/expiry, same-payer calls, scheduled-only blocks, cancellation, wipe and late refunds across fee upgrades. Replay stored fee IDs through every registry entry and reject unknown IDs. DPP/native fee modules and rs-platform-version own tables; Drive owns storage flags/refunds/operations; rs-drive-contracts meters and holds; ABCI settles. The provisional appendix is a measurement starting point, not production price evidence. + +## Rationale + +Upfront full bounds prevent unpaid execution; actual final charging avoids billing discarded speculation. Existing storage accounting preserves compatibility. Default receipts improve usability while contract-controlled retention recognizes their real storage cost. + +## Related drafts and implementation tracking + +[DVM-01](dip-dashvm-protocol.md) · [DVM-02](dip-dashvm-engine-abi.md) · [DVM-03](dip-dashvm-activation.md) · [DVM-04](dip-dashvm-storage.md) · [DVM-05](dip-dashvm-guards.md) · [DVM-06](dip-dashvm-execution.md) · [DVM-08](dip-dashvm-scheduling.md) · [DVM-09](dip-dashvm-governance.md) · [DVM-10](dip-dashvm-proofs-clients.md) · [DVM-11](dip-dashvm-rust-sdk.md) · [DVM-12](dip-dashvm-external-primitives.md) + +* [43-FEES](https://github.com/dashpay/platform/issues/4675): Repair existing fee history (4.3-dev). +* [50-ENGINE](https://github.com/dashpay/platform/issues/4683): Implement the deterministic runtime, validator and compatibility corpus (5.0-dev). +* [50-GUARDS](https://github.com/dashpay/platform/issues/4685): Implement native guards and preserve contested-index awards (5.0-dev). +* [50-CALLS](https://github.com/dashpay/platform/issues/4687): Implement atomic calls, delegation and ordered parallel execution (5.0-dev). +* [50-SCHEDULE](https://github.com/dashpay/platform/issues/4688): Implement time-only live-paid schedules and removal settlement (5.0-dev). +* [50-FEES](https://github.com/dashpay/platform/issues/4689): Implement contract bounds, actual charging, receipts and historical refunds (5.0-dev). +* [50-CAP-COST](https://github.com/dashpay/platform/issues/4691): Validate cost and refund bounds for every native capability (5.0-dev). +* [50-GOV](https://github.com/dashpay/platform/issues/4695): Implement governance, bounded wipes and vestige recovery (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm-governance.md b/dip-dashvm-governance.md new file mode 100644 index 00000000..86dd5082 --- /dev/null +++ b/dip-dashvm-governance.md @@ -0,0 +1,86 @@ +
+  DIP: Unassigned (dip-dashvm-governance)
+  Title: Freeze, wipe and deleted-contract custody
+  Chain: Platform
+  Layer: Consensus
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Standard
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Specify contract lifecycle governance requiring strictly more than two-thirds of all active eligible evonodes, one-week voting windows and early approval. A wipe immediately disables contract authority and accounts for its assets, while bounded cleanup removes physical state without deleting canonical code. + +## Motivation + +Network decisions must count the intended electorate, settle credits and issuer tokens exactly once, and preserve foreign assets under tightly scoped custody. An unbounded physical deletion or an unrestricted recovery key would violate those goals. + +## Specification + +### Proposal and vote records + +A proposal binds network domain, unique proposal ID, action (`Freeze`, `Unfreeze`, `Wipe`, `RecoverVestige`), target contract, exact action payload, opening consensus time, one-week deadline, membership-check reference and outcome. Recovery binds exact token IDs, amounts and recipient. One evonode has one effective choice per proposal across all choice trees. Proposed vote-update convention permits replacing its choice while the proposal remains open, atomically moving the keyed record; repeated identical submissions are idempotent. This convention and ballot encoding require native vote-model review and replay vectors. + +Use the same agreed current active-eligible Core membership boundary as DVM-03, not only current validators or those casting ballots. For N active eligible evonodes and Y eligible yes choices require `N > 0 && 3*Y > 2*N`, using checked wide integers. Exactly two-thirds fails; minimum is `floor(2*N/3)+1`. Governance thresholds are distinct from 80% compilation readiness and native contested-index voting parameters. + +### Decision timing — proposed engineering convention + +Use the beginning-of-block lifecycle phase after the agreed membership update and before affected scheduled work. Revalidate voters and denominator against one consistent current view. Reconsider on ballot arrival and membership change; raw choice counts do not establish eligibility. A bounded paged scan cannot approve using mixed or stale membership. Apply approved actions exactly once with their proposal outcome. + +Proposed expiry boundary: decision times strictly before `opened_at + 604800 seconds` may approve early; at or after the deadline an unapproved proposal closes without approval. A vote accepted later in a block cannot retroactively change that block's prior lifecycle phase. Pending verification that has not established a valid crossing by expiry does not extend the window. This explicit ordering is an engineering proposal to be reconciled with native event phases, not a new threshold choice. + +### Freeze and unfreeze + +Native frozen state blocks affected guest calls, predicates and outbound guest-authorized effects; it cannot be implemented by skipping rules and accepting the write. Authorized code updates remain possible while frozen but do not clear a network freeze. Permitted native inbound credits/token transfers/refunds can continue under existing asset rules without executing frozen code. If authorization would require a guest callback that cannot run, the transfer is not silently authorized. Contract-defined freezes follow their declared native-compatible policy; a network freeze requires the same network vote to unfreeze. + +### Wipe transition + +At approved wipe, set permanent wiped/custody state, disable routing and pending activation, and prevent execution/spendability immediately. Retain accepted canonical blobs/manifests and required lifecycle facts forever. Introduce durable bounded cleanup work for deletable documents/indexes/collections/jobs/receipts and related locators. A cleanup step updates its native effects and cursor atomically and is safe to retry after a crash. A later update, query or cleanup resume cannot resurrect state. + +**Credits:** remove the contract's live credit total from spendable accounting and add it to the current processing pool exactly once. Proposed storage technique marks the populated ordinary SumTree as `NotSummed` while retaining its inner data for cleanup; this is an engineering mechanism requiring populated-tree cost/root/proof tests, not an already implemented primitive guarantee. Every balance/aggregate/spend path must respect the wipe exclusion. Later refunds owned by that contract enter the current processing pool; refunds owned by others remain theirs. Physical deletion never adds that money a second time. + +**Issuer tokens:** all tokens issued by the wiped contract cease to exist, including units held by native identities and other contracts. Implement a bounded logical issuer/token tombstone using the authoritative native token-to-issuer relation, and require all query, transfer, supply, mint/burn, freeze, distribution and proof paths to recognize it before any physical scan. Existing code paths lacking that check block completion of the wipe feature. Clear physical holdings/indexes incrementally without a second burn or resurrected supply. Populated pre-existing native issuances must be indexed or natively discoverable before smart activation. + +**Foreign tokens:** tokens issued by other contracts retain their existing authoritative native holdings but custody becomes the deleted-contract identity vestige. The vestige is native authority state, not a fabricated ordinary identity with a private key and not a copied balance ledger. No former owner, retained guest code or generic admin key can spend those holdings. + +### Specific vestige recovery + +An approved recovery proposal authorizes only its exact token/amount/recipient transfer. At application, recheck remaining custody balance, token existence and native token transfer restrictions. Execute transfer and consumed-authorization marker atomically. Reject replay or a substituted recipient/amount. Proposed failure convention: if approved payload cannot pass current native validation, record a deterministic failed-application terminal outcome with no partial transfer; a changed request needs a new vote. This must be reviewed against the native governance error model. Approval is not permission to bypass issuer freezes or native asset rules. + +## Engine recovery is separate + +There is no new engine emergency pause authority. Engine behavior changes and emergency recovery use normal protocol upgrades. Removing a bad ordinary transition may help a proposer, but a reproducible scheduled host fault can halt processing and require coordinated recovery. Release tests must rehearse that selected policy rather than claim freeze/wipe voting always remains reachable during an engine halt. + +## Backward compatibility and security + +Keep contract governance separate from contested-index polls and protocol-upgrade voting. Version its namespace/codecs and native token lifecycle checks. Fail closed on missing wipe/custody state where required; prove current balances together with relevant live/wiped/issuer state. Bound every cleanup and tally phase; retain original refund flags and permanent code. Native inbound permission is not outbound recovery authority. + +## Test vectors + +N=3 requires 3 yes; N=300 requires 201; N=400 requires 267; N=1000 requires 667; empty set fails. Test one-week boundaries, early approval, changed electorate, duplicate/replaced ballots and once-only application. Wipe fixtures cover all holder types, contracts issuing and holding multiple tokens, pre-existing tokens, late refunds, third-party prefunds, cleanup interruption and sync. Recovery vectors include wrong amount/recipient, replay, frozen/destroyed issuer token and native validation failure. Match roots, supply and credit conservation on both proposal paths. + +## Reference implementation, rationale and allocations + +DPP defines proposal/payload; ABCI handles current membership and decisions; Drive handles native tombstones, conservation, vestige custody and cleanup; clients prove explicit lifecycle state. Exact tags, vote-update and application-failure encoding, phase wiring and logical exclusion mechanisms remain engineering review entries. Logical invalidation plus bounded physical cleanup achieves immediate policy effects without unbounded traversal. + +## Related drafts and implementation tracking + +[DVM-01](dip-dashvm-protocol.md) · [DVM-02](dip-dashvm-engine-abi.md) · [DVM-03](dip-dashvm-activation.md) · [DVM-04](dip-dashvm-storage.md) · [DVM-05](dip-dashvm-guards.md) · [DVM-06](dip-dashvm-execution.md) · [DVM-07](dip-dashvm-fees.md) · [DVM-08](dip-dashvm-scheduling.md) · [DVM-10](dip-dashvm-proofs-clients.md) · [DVM-11](dip-dashvm-rust-sdk.md) · [DVM-12](dip-dashvm-external-primitives.md) + +* [50-NATIVE](https://github.com/dashpay/platform/issues/4690): Implement the full native capability and collection adapters (5.0-dev). +* [50-GOV](https://github.com/dashpay/platform/issues/4695): Implement governance, bounded wipes and vestige recovery (5.0-dev). +* [50-VERIFY](https://github.com/dashpay/platform/issues/4696): Complete upgrade, sync, recovery and release evidence (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm-guards.md b/dip-dashvm-guards.md new file mode 100644 index 00000000..04d202ec --- /dev/null +++ b/dip-dashvm-guards.md @@ -0,0 +1,84 @@ +
+  DIP: Unassigned (dip-dashvm-guards)
+  Title: Bounded guards and native action rules
+  Chain: Platform
+  Layer: Consensus
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Standard
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Define a small typed, bounded native expression guard and the context shared with read-only Wasm predicates. Both enforce ordinary document actions through native validation; neither can interfere with a native contested-index award. The grammar below is a concrete engineering proposal for review, not a previously approved language. + +## Motivation + +Simple rules such as immutable ownership, monotonic scores and permitted updates should not require compiling an entire Wasm program. More complex rules can use metered Wasm predicates while sharing the same target binding, current-state visibility and atomic failure behavior. + +## Specification + +### Proposed typed expression model + +Persist a canonical versioned AST, not Rust source or an arbitrary expression string. Initial nodes are `Literal`, `Field(context,path)`, `Exists`, `IsNull`, `Eq`, `Ne`, ordered comparisons, checked integer `Add/Sub/Mul`, `And`, `Or`, `Not` and `If`. No loops, recursion, dynamic code, unbounded regex, dynamic field traversal or ambient time/entropy are admitted. Explicit bounded byte/string equality and length operations may be added only with type and cost vectors. Floating-point expression arithmetic is excluded from this initial guard proposal without removing scalar floats from the Wasm profile. + +Nodes carry typed operands. There is no implicit signed/unsigned, string/number or null/missing coercion. Field paths are validated against the declared schema, with bounded depth and stable serialized property identity. `Missing`, `Null` and a present value are distinct. `Exists` handles missing; an inappropriate operand otherwise produces a typed guard error. Integers use schema-declared widths; overflow is an error, not wraparound. Comparisons require matching ordered types; bytes/strings use the canonical native ordering, not a locale. Final result must be Boolean. + +Evaluation order is left to right. `And`/`Or` short circuit and `If` evaluates one selected branch. Static admission computes a sound maximum over reachable alternatives and operation/byte bounds; actual charging follows evaluated work. Do not invoke an unbounded query from an AST node. Add future read expressions only with typed capability, range and cost limits under a new grammar generation. Wasm predicates may perform the explicitly permitted bounded reads under DVM-02/06. + +### Action context and old/new binding + +The host constructs `ActionContext{contract, document_type, document_id, action, signer, caller, native_origin, policy_generation}`. `old` is the actual target record immediately before this operation in accepted order, including this transition's earlier operations. `new` is the complete native-validated candidate for that same target. Create has no old record; delete has no new record. Reject ID/type substitution and forged old snapshots. Fields such as owner, revision and storage flags remain host/native-controlled. + +Proposed first action scopes are ordinary create, replace/update and delete plus separately enumerated native actions where the existing contract model supports rules. No generic wildcard that silently covers every future action is accepted. Native triggers, index maintenance and cascades retain their native authorization; specify whether each derived action invokes an ordinary rule through the capability/action matrix. The rule must never recursively authorize itself. + +### Native contested awards + +Award origin is an unforgeable internal native action. Existing contested-index eligibility, locks, tally, finalization, document validation and atomic index effects govern it. Contracts may declare validated supported parameters. Guest callbacks, Wasm predicates and the native generic guard evaluator are not invoked to approve, reject, delay, redirect or retry an award. Reject declarations that claim that scope. Ordinary guarded writes remain guarded. Freeze/wipe handling belongs to deterministic native lifecycle rules, never a contract veto over a poll outcome. + +### Registration, updates and legacy data + +Validate AST types, action scopes, maximum cost and supported generations during contract registration/update. Rule declarations are part of the signed schema/manifest. A direct call to a supported older module does not select stale authorization. Proposed guard update policy: current accepted rules apply prospectively to ordinary actions on all existing documents, with `old` decoded using its stored native format and `new` validated under current applicable native schema. Existing documents are not eagerly rewritten. Native contract-update validation must reject incompatible changes. + +If a promised rule policy requires creation-time applicability, represent it explicitly through a versioned native stamp with a defined legacy fallback; do not infer a stamp from code version or silently assign one. Such an extension is not activated until its encoding and old-document/deletion vectors are complete. Protected deletion remains enforced on the actual stored target. This avoids inventing a blanket migration or bypass for legacy documents. + +### Execution and failures + +Check full affordability before evaluating guards. CheckTx/RecheckTx type-check declarations and bounds but do not evaluate user guards. Freeze rejects affected ordinary execution; skipping a frozen guard must never permit its write. A false result, evaluation error, Wasm trap or native rule rejection fails the outer invocation under DVM-06/07, even if guest code catches a returned error. Read-only predicates cannot mutate state, create schedules or reenter an active contract through nested execution. Dependencies and costs are revalidated before accepting speculative results. + +## Backward compatibility and deployment + +Introduce new schema/evaluator generations only through the central profile. Old unguarded contracts retain their historical behavior; guard installation is an authorized native-compatible update, not an automatic protocol migration. Target 5.0-dev in the current release allocation. No separate early guard activation is assigned by this draft. + +## Security considerations + +AST depth, operator count, value expansion and comparison bytes are bounded before execution. Host-supplied old/new binding prevents validating one record and writing another. Native validation remains mandatory for handcrafted Wasm and clients that bypass generated SDK checks. Contract-only write permission and ACL authorization are independent of Rust method visibility. + +## Test vectors + +Test `Missing` versus `Null`, checked overflow, short-circuit costs, maximum depth and one over, invalid types/paths, create/delete absence, two writes to one record, changed predecessor data, failed outer rollback and cross-architecture equality. Award vectors must prove that even trap/false/infinite-loop guest guards are never invoked for native awards. Include freeze, legacy records, current-rule updates and protected deletion. + +## Reference implementation, rationale and open allocations + +DPP owns AST/declarations/type validation; a bounded native evaluator and rs-drive-contracts supply execution context; Drive owns action validation and writes. SDK macros emit the canonical rule model. Exact opcode tags, error IDs, initial supported operations, legacy applicability and costs are review entries. A small typed AST was chosen over unrestricted scripting to support sound admission bounds and stable cross-language serialization. + +## Related drafts and implementation tracking + +[DVM-01](dip-dashvm-protocol.md) · [DVM-02](dip-dashvm-engine-abi.md) · [DVM-03](dip-dashvm-activation.md) · [DVM-04](dip-dashvm-storage.md) · [DVM-06](dip-dashvm-execution.md) · [DVM-07](dip-dashvm-fees.md) · [DVM-08](dip-dashvm-scheduling.md) · [DVM-09](dip-dashvm-governance.md) · [DVM-10](dip-dashvm-proofs-clients.md) · [DVM-11](dip-dashvm-rust-sdk.md) · [DVM-12](dip-dashvm-external-primitives.md) + +* [44-AUTHOR](https://github.com/dashpay/platform/issues/4680): Settle contract declarations and the Rust author API (4.4-dev). +* [50-GUARDS](https://github.com/dashpay/platform/issues/4685): Implement native guards and preserve contested-index awards (5.0-dev). +* [50-NATIVE](https://github.com/dashpay/platform/issues/4690): Implement the full native capability and collection adapters (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm-proofs-clients.md b/dip-dashvm-proofs-clients.md new file mode 100644 index 00000000..171e8695 --- /dev/null +++ b/dip-dashvm-proofs-clients.md @@ -0,0 +1,84 @@ +
+  DIP: Unassigned (dip-dashvm-proofs-clients)
+  Title: Current-state proofs and client results
+  Chain: Platform
+  Layer: Consensus
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Standard
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Extend native queries and proof verification for smart-contract manifests, current lifecycle, balances, specialized collections, schedules and retained receipts. Clearly distinguish a proven current-state fact, an accepted stored receipt and unproven execution-result text. No past-height proof service or network preflight is added in 5.0. + +## Motivation + +Application developers need consistent data and errors across Rust, Wasm/JavaScript and mobile clients. A contract result must not be advertised as a proof of execution merely because the same response includes a valid state proof. + +## Specification + +### Query families + +Provide bounded native requests for contract kind/current metadata, latest/pending/supported versions, immutable manifest/module bytes and routes, readiness progress, freeze/wipe/custody, credit/token buckets, declared document/collection queries, job status and retained receipts. Reuse existing native range, projection, paging and element decoding. Capability-specific query combinations are enabled only where native semantics and proof verification are defined. + +Every request binds contract/resource identity, supported query generation, selectors/limits and relevant method/schema/collection IDs. Canonical paging cursors bind the query and ordering, not a raw host path. Enforce native smaller limits even if the general guest cap is larger. Bound scanned work and encoded bytes separately; partial results explicitly indicate limits/continuation. Missing records and unavailable capabilities use distinct typed results. + +### Proof verification contract + +A verified result is bound to the trusted Platform state root and the complete expected path/query. Verify parent/ancestor paths, Element types, field projections, inclusion/absence, query order, range boundaries and limit semantics through existing Drive proof verification. A valid proof for another contract/version/query/root is not interchangeable. Protocol/codec IDs select the expected verifier; unknown variants fail closed. + +To prove a module, bind contract, version manifest, module name/hash and exact requested bytes. Retained unsupported/cancelled/wiped code can still be proven in current state because its archive is permanent. That is not a proof of what the state was at its original deployment height. A latest-route proof must include lifecycle/routing state, not merely one older immutable manifest. + +For ordinary SumTree aggregate balances, authenticate the parent Element carrying the aggregate and its full path to the trusted root; a bare child Merk hash does not authenticate arbitrary internal sum metadata. Range-sum proof interfaces use the appropriate supported provable structure. Live balance/token results must include or otherwise authenticate relevant wipe/issuer exclusion/custody facts. Old retained physical holdings after logical wipe cannot be presented as spendable balances. + +### Results and receipts + +Expose `ExecutionOutcome`, optional `StoredReceipt`, and optional `VerifiedStateResult` as distinct result types. Outcomes have stable bounded success/error data and actual fees. A proof of a retained receipt proves that the current state contains that outcome record under its key; it is not a zero-knowledge execution proof or arbitrary historical-state proof. Receipt absence can reflect configured omission or expired retention; clients must not equate it with a failed call. Show effective policy/status when needed to interpret it. + +Readiness status must distinguish raw reported count, membership-validated tally, pending verification, established deadline and activated state. UI estimates cannot replace consensus activation. Show deprecation as a warning, unsupported as unavailable for new direct calls, and frozen/wiped as separate contract lifecycle conditions. Cross-contract/scheduled APIs expose latest-method routing; only direct-call APIs offer supported-version selection. + +### Transport and cross-language parity + +Use DAPI/protobuf versions only where needed; keep existing proof/result APIs where compatible. Apply code upload and response bounds consistently across gRPC, mempool/block transport, native/Wasm decoders and mobile wrappers. Keep one canonical vector corpus for schemas, method calls, values including explicit floating-point representations, errors, proofs and fee estimates. Do not allow JSON to silently round large integers or collapse required tagged values. + +Rust SDK, Wasm SDK/JavaScript and Swift/Kotlin wrappers must preserve optional version/receipt/policy fields and structured errors in persistent application models. CLI/local fixture simulation is permitted, but no client method should imply an unavailable network preflight service. Downloaded native compiled artifacts are not a client-trusted substitute for canonical code/proofs. + +## Backward compatibility and deployment + +New query/proof variants use allocated protocol versions and old clients receive explicit unsupported errors rather than misdecoding Elements. Test saved pre-upgrade records, post-upgrade sync, historical code in current state and shared native query behavior. Existing data-contract queries remain valid. + +## Security considerations + +Prevent wrong-root/path substitution, misleading aggregate interpretation, pagination omission, invalid absence proofs and unproven metadata attached to proven records. Private Rust fields and ACL-restricted queries do not imply encrypted state. Proof-visible data is governed by the actual native capability, not UI labels. + +## Test vectors and reference implementation + +Include valid and tampered proofs for every enabled projection/tree family, wrong contract/version/root, missing/latest versus pending route, empty/limited pages, ordinary versus provable sums, wiped/destroyed-token holdings, receipt off/expired/retained and large value boundaries. Cross-language converters must produce identical verified semantics and reject the same malformed vectors. Drive/DAPI own query services; rs-drive-proof-verifier owns verification; rs-sdk/wasm-sdk/mobile layers expose it. The capability appendix identifies unsupported/private interfaces whose proof contract must be completed before enabling. + +## Rationale and open allocations + +Typed result separation prevents overclaiming proofs. Reusing native query/proof machinery preserves established indexing and verification semantics. Exact protobuf/query IDs, proof/result compatibility entries, paging codecs and private-store exposure remain tracked allocations; arbitrary historical proof endpoints remain out of scope. + +## Related drafts and implementation tracking + +[DVM-01](dip-dashvm-protocol.md) · [DVM-02](dip-dashvm-engine-abi.md) · [DVM-03](dip-dashvm-activation.md) · [DVM-04](dip-dashvm-storage.md) · [DVM-05](dip-dashvm-guards.md) · [DVM-06](dip-dashvm-execution.md) · [DVM-07](dip-dashvm-fees.md) · [DVM-08](dip-dashvm-scheduling.md) · [DVM-09](dip-dashvm-governance.md) · [DVM-11](dip-dashvm-rust-sdk.md) · [DVM-12](dip-dashvm-external-primitives.md) + +* [44-GROVE](https://github.com/dashpay/platform/issues/4678): Adopt the reviewed GroveDB foundation (4.4-dev). +* [50-READS](https://github.com/dashpay/platform/issues/4686): Implement bounded current-state guest reads (5.0-dev). +* [50-PROOFS](https://github.com/dashpay/platform/issues/4692): Implement current-root queries and proof verification (5.0-dev). +* [50-CLIENTS](https://github.com/dashpay/platform/issues/4693): Deliver DAPI, Rust, Wasm/JS and mobile parity (5.0-dev). +* [50-VERIFY](https://github.com/dashpay/platform/issues/4696): Complete upgrade, sync, recovery and release evidence (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm-protocol.md b/dip-dashvm-protocol.md new file mode 100644 index 00000000..a7858512 --- /dev/null +++ b/dip-dashvm-protocol.md @@ -0,0 +1,102 @@ +
+  DIP: Unassigned (dip-dashvm-protocol)
+  Title: Protocol integration and wire contracts
+  Chain: Platform
+  Layer: Consensus
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Standard
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Introduce smart contracts as a protocol-versioned extension of Platform data contracts. Define the boundary between accepted wire messages, native validation, execution and persistent outcomes. DVM-02 through DVM-12 own the detailed runtime, lifecycle, storage, calls, fees and developer rules. This draft owns their shared envelope and activation contract. + +## Motivation and scope + +Existing documents, indexes, identities and tokens already have native rules. Executable contracts must compose with those rules and the existing nonce and fee pipeline. They must not create an alternative database, a second token ledger, or an execution path that changes when an operator changes a local setting. Smart execution targets 5.0-dev; earlier preparation does not enable it. + +## Specification + +### Protocol profile + +Every consensus entry point resolves one immutable `PlatformVersion` profile from the active protocol version. Its DashVM descriptor references exact model/serialization generations, admitted Wasm features, validation/preparation generation, engine behavior, ABI, capability catalogue, guard grammar, metering/fee tables, storage codecs, error taxonomy and resource limits. These are independently identified components of one approved profile, not independent node configuration switches. Historical blocks resolve their historical descriptor. + +Unknown profile or required capability is rejected before execution. Software-only changes may replace an engine build only with evidence that consensus-visible results, fees, limits, traps and roots are equivalent. A behavior change uses the normal protocol-upgrade mechanism. No new emergency pause, deployer allowlist, audit approval or funding gate is introduced. + +### Semantic wire schemas + +The following are semantic records, not final field numbers. Their concrete encoding must reuse DPP/platform serialization and the central allocation register. + +| Record | Required signed/bound fields | +| --- | --- | +| Create/update smart contract | Native contract identity/authority/revision fields; contract kind; executable version; ABI/profile declarations; module bundle manifest; new canonical blobs; existing-blob references; methods/capabilities; update/freeze/receipt policy; native schemas; fee bound; applicable native nonce | +| Invoke | Contract ID; stable public method ID; optional supported version for a direct caller; canonical arguments; declared rights/read bounds; payment source and maximum charge; applicable native nonce and signer | +| Readiness report | Network domain; evonode identity; contract/version; activation round; manifest hash; preparation/engine profile; authenticated ready statement | +| Cancel/replace pending version | Contract and expected pending round/version; update authority; replacement if any; native nonce/fee context | +| Governance vote | Network domain; proposal ID; exact action/target/payload digest; voting identity and authenticated choice | +| Schedule create/cancel | Job identity; target method; canonical arguments; time policy; payer/cancellation authority; failure policy; prefunded-removal purpose; nonce and fee context | + +Identity authentication and replay handling build on DIP-0011 and DIP-0030. Do not replace their nonce-window algorithm with a new sequential nonce. Proposed allocation: creation uses the existing identity nonce; updates and direct contract calls use the signer/contract nonce domain where applicable; reports/votes use their domain-bound idempotent report/proposal keys plus their native authenticated transport. Exact transition-family assignment and paid-failure nonce mappings are allocation work, with signed-byte vectors required before enabling them. Unknown fields/variants, duplicate map keys, noncanonical ordering or integer overflow cannot acquire alternate valid interpretations. + +### Admission and execution phases + +1. Enforce the outer message-family size cap before allocating large buffers, decompressing or decoding all code. Bound nested lengths and total manifest/blob bytes; referenced existing blobs still count toward complete-bundle limits. +2. Decode canonically; check supported protocol and message type, signature, native authority, nonce, schema and declarations. Hash every newly supplied blob and bind its exact bytes to the manifest. +3. Compute a sound full affordability bound from declared limits and native cost rules. Check current permitted payment sources. CheckTx/RecheckTx perform these structural and affordability checks without guest execution, including native expression guards. +4. During ordered block execution, revalidate against the current accepted state prefix. Apply lifecycle checks, reserve the sound bound and execute through the shared service. No client preflight endpoint is added in 5.0. +5. Accept exactly the outcome and settlement prescribed by DVM-06/07. Only Drive ABCI commits the final block transaction. Rejected speculative attempts never become independent paid invocations. + +Both proposal construction and proposal validation use the same semantics. Local worker count, cache size, compilation time, OS clock and memory pressure cannot change a valid block's result. Existing native event budgeting remains; only the specified additional contract-computation budget is introduced. + +### Error contract + +Allocate symbolic families `Malformed`, `UnsupportedProfile`, `Unauthorized`, `NonceInvalid`, `InsufficientBound`, `InactiveVersion`, `Frozen`, `GuestRejected`, `GuestTrap`, `ResourceExceeded`, `NativeActionFailed` and `NodeFault`. Stable structured details are bounded and exclude OS strings/backtraces. A semantic read result such as absence, or a randomness `NotReady` variant, is not automatically an execution failure. Actual nested execution or action-validation failures poison the outer invocation. Genuine storage/runtime infrastructure faults do not get converted into paid guest errors merely to keep a node running. + +## Backward compatibility and deployment + +Data-only contracts retain their existing representation and native behavior; smart namespace insertion is specified in DVM-04. Unsupported transitions are rejected before the corresponding protocol feature activates. Release branch names 4.3-dev/4.4-dev/5.0-dev are engineering destinations, not assigned protocol numbers. The existing plan's PV15–PV17 budget must be reconciled with real version registries; this draft does not invent three required activations. + +## Security considerations + +Sign the entire execution intent, network and payment bound; never let an unsigned module route, recipient or delegated right alter it. Decode with checked arithmetic and bounded expansion. Recheck authority and nonces against accepted predecessor state, including shared signers used by multiple transitions. No CheckTx execution means admission is not a promise of later success. + +## Test vectors and acceptance + +Require byte vectors for every envelope, signature/hash domain, empty/duplicate/unknown fields, maximum lengths and one byte over each bound. Exercise duplicate nonces, paid failures, changed balances between CheckTx and execution, pre-activation rejection and historical decoding. Compare both proposal paths, serial/parallel execution and supported architectures. These are required vectors, not tests claimed to have passed. + +## Reference implementation and open allocations + +Models: rs-dpp; profile: rs-platform-version; encoding: rs-platform-serialization/value and rs-dashvm-abi; orchestration: rs-drive-abci; execution adapter: rs-drive-contracts. The shared allocation register owns exact profile, message/error/field IDs, nonce-family mappings, hash encodings and production limits. Drafting does not close those implementation tasks. + +## Rationale and alternatives + +One versioned descriptor prevents partially upgraded nodes from selecting incompatible pieces. Native nonces and validation preserve existing replay protection. Running contracts in CheckTx was rejected because it repeats expensive execution against state that may change. Per-node execution limits and a second storage/index engine were rejected because they break deterministic behavior or duplicate existing guarantees. + +## Related drafts and implementation tracking + +[DVM-02](dip-dashvm-engine-abi.md) · [DVM-03](dip-dashvm-activation.md) · [DVM-04](dip-dashvm-storage.md) · [DVM-05](dip-dashvm-guards.md) · [DVM-06](dip-dashvm-execution.md) · [DVM-07](dip-dashvm-fees.md) · [DVM-08](dip-dashvm-scheduling.md) · [DVM-09](dip-dashvm-governance.md) · [DVM-10](dip-dashvm-proofs-clients.md) · [DVM-11](dip-dashvm-rust-sdk.md) · [DVM-12](dip-dashvm-external-primitives.md) + +* [43-PLAN](https://github.com/dashpay/platform/issues/4676): Establish specifications and implementation tracking (4.3-dev). +* [44-CODEC](https://github.com/dashpay/platform/issues/4679): Extract the shared guest value and codec foundation (4.4-dev). +* [50-DEPLOY](https://github.com/dashpay/platform/issues/4684): Implement permanent bundles, registration, readiness and version routing (5.0-dev). +* [50-CALLS](https://github.com/dashpay/platform/issues/4687): Implement atomic calls, delegation and ordered parallel execution (5.0-dev). +* [50-FEES](https://github.com/dashpay/platform/issues/4689): Implement contract bounds, actual charging, receipts and historical refunds (5.0-dev). +* [50-CLIENTS](https://github.com/dashpay/platform/issues/4693): Deliver DAPI, Rust, Wasm/JS and mobile parity (5.0-dev). +* [50-VERIFY](https://github.com/dashpay/platform/issues/4696): Complete upgrade, sync, recovery and release evidence (5.0-dev). +* [50-DOCS](https://github.com/dashpay/platform/issues/4697): Maintain public documentation and protocol-change checklist (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +Related native specifications: [DIP-0011 identities](https://github.com/dashpay/dips/blob/master/dip-0011.md), [DIP-0030 nonces](https://github.com/dashpay/dips/blob/master/dip-0030.md). + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm-rust-sdk.md b/dip-dashvm-rust-sdk.md new file mode 100644 index 00000000..17595ea0 --- /dev/null +++ b/dip-dashvm-rust-sdk.md @@ -0,0 +1,114 @@ +
+  DIP: Unassigned (dip-dashvm-rust-sdk)
+  Title: Rust authoring and reproducible packages
+  Chain: Platform
+  Layer: Applications
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Informational
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Describe the proposed Rust developer experience: ordinary free functions and impl methods, annotated persistent structs, native index/rule declarations, generated dispatch and typed capabilities. This is an Informational DIP draft; macro spelling and crate-file organization are developer conventions, while emitted manifest/ABI behavior is governed by the consensus DIPs. + +## Motivation + +Developers should write Rust while retaining Drive's document storage, indexing and validation. Persistence must be explicit enough to avoid hidden writes and expensive whole-state serialization, and tooling must reveal incompatible schema/version changes before deployment. + +## Specification + +### Author model + +The guest SDK directory is `packages/rs-dash-sdk-contract`, Cargo package `dash-sdk-contract`, import `dash_sdk_contract`. Keep it distinct from the application/client `dash-sdk`. Use ordinary modules, structs, free functions, trait impls and multiple impl blocks. Only annotated entries are externally callable; Rust `pub` alone is not a contract method. + +Proposed syntax: + +```rust +use dash_sdk_contract::prelude::*; + +#[persistent(collection = "scores", schema = 1, write = "contract")] +#[index(name = "by_class", fields(class = "asc"), count, sum = "points")] +pub struct Score { + #[document_id] + pub id: DocumentId, + #[field(position = 0, max_chars = 64)] + pub class: String, + #[field(position = 1, min = 0, max = 1_000_000)] + pub points: i64, +} + +impl Score { + #[entry(name = "score.add")] + pub fn add(&mut self, _ctx: &mut Context, delta: i64) -> Result<()> { + self.points = checked_add(self.points, delta)?; + Ok(()) + } +} + +fn checked_add(value: i64, delta: i64) -> Result { + value.checked_add(delta).ok_or(Error::Arithmetic) +} +``` + +This sketch does not compile against a released SDK today. Native schema/rule validation still checks the candidate and actual authority; the helper does not replace those checks. A free `#[entry]` may coordinate multiple records/contracts. A singleton is a native document with a declared stable key/schema, not an opaque alternative storage engine. + +### Persistence contract + +Constructing or mutating a detached Rust value is transient. `get(id)` loads current ordered state and records dependencies. `insert(value)` stages a native create. `edit(id, closure)` loads, invokes and stages the native update only on successful return. An exported `&mut self` wrapper loads exactly the addressed record, supplies authentic Context, invokes the method and stages the receiver update on success. It never commits independently or loads the whole collection. IDs, revisions, owners and storage flags remain host controlled. + +No persistence on Drop, no escaping mutable database references and no ambient global persistent singleton. A caught actual host/nested failure still poisons the outer invocation. Generated wrappers and hand-written Wasm have the same native checks. A direct unmarked helper invocation does not magically save its receiver. + +### Declarations and code generation + +Attributes handle common schemas/indexes/rules; typed `IndexSpec`, `CollectionSpec` and `RuleSpec` builders handle advanced native features. Merge both into one canonical manifest and reject duplicate/conflicting/unknown declarations. Stable serialized property, method, type and index identities survive Rust/module refactors. Bound every variable-length field. The complete capability catalogue must map to a declaration, typed operation or explicit unavailable boundary; no unsupported option is silently dropped. + +Generate native count/sum/ranked/compound queries rather than computing secondary indexes in guest code. A count-and-sum query returns one consistent native result. Require bounded pagination, preserve empty-population semantics and use checked arithmetic for averages. Advanced collection handles refer only to authorized declared templates. Runtime instance creation is a bounded native operation; build-time schema generation does not create chain data. + +Expose native bounded rules and read-only Wasm predicates with explicit action scopes. Native contested awards remain parameterized native behavior, never a callback. ACL calls require the gated native capability; private Rust fields are not private chain data. Randomness uses request/result handles with `NotReady`, never an ambient `rand()` fallback. + +### Named modules and generated clients + +A contract package may contain several deployable Wasm module targets. Build one version manifest with exact bindings and stable contract-wide public routes, even when a method moves between Rust modules. Unchanged blobs may be referenced in the next version. Produce an interface/binding report, per-module and aggregate sizes, supported-profile check and schema compatibility report. Do not add a code archive per function. + +Generated cross-contract clients target latest stable methods and explicit delegated rights without an old-version parameter. Direct application clients may select supported older versions. Deprecation warnings, missing methods, freeze/wipe and receipt policy are visible. Current native schema/index update validation applies; generation cannot promise automatic index migrations or backfills. + +### Toolchain artifacts and ownership + +The nine proposed reusable crates are ABI, validation, runtime, Drive integration, contract SDK, proc macros, build support, test support and CLI; one unpublished example demonstrates the system. The architecture appendix names exact directories/modules and dependency arrows. ABI/value codecs and guest SDK stay no_std/Wasm compatible where designed; Drive, ABCI and Wasmtime do not leak into the guest dependency graph. + +`cargo dash-contract` is the proposed command family for build/check/inspect/cost/deploy and local fixtures. Emit canonical Wasm blobs, canonical manifest, generated typed clients and readable schema/ABI/change reports. Use pinned toolchain/target/link flags and deterministic manifest ordering. Hash canonical output and compare repeat builds. Host admission independently validates it; a build attestation grants no extra authority. + +## Testing and compatibility + +Native reference tests compare application behavior; exact-engine Wasm tests establish metering, traps and runtime parity. Include compile-pass/compile-fail macro diagnostics, no_std builds, stable generated metadata, detached versus staged updates, repeated impl/free functions, multi-module reuse, queries/index updates and failure rollback. The worked sum/count example must run on the actual runtime and through native storage; a sketch or stub is insufficient for task completion. + +Keep shared wire/error/proof/fee vectors for application SDKs and mobile examples. Match accepted old modules to historical profiles while using current storage/authorization. No network preflight, SDK funding sign-off or deployer allowlist is added. Normal package release automation and install/use checks remain required. + +## Security, rationale and open allocations + +The native host is the security boundary; macros provide ergonomics and errors. Annotated native documents were selected over one serialized root blob to preserve granular queries/indexes/proofs. Exact attribute grammar, generated symbol naming, package versions and toolchain pin remain reviewed implementation choices. The complete existing Rust API sketch is linked as an appendix, explicitly labeled future API. + +## Related drafts and implementation tracking + +[DVM-01](dip-dashvm-protocol.md) · [DVM-02](dip-dashvm-engine-abi.md) · [DVM-03](dip-dashvm-activation.md) · [DVM-04](dip-dashvm-storage.md) · [DVM-05](dip-dashvm-guards.md) · [DVM-06](dip-dashvm-execution.md) · [DVM-07](dip-dashvm-fees.md) · [DVM-08](dip-dashvm-scheduling.md) · [DVM-09](dip-dashvm-governance.md) · [DVM-10](dip-dashvm-proofs-clients.md) · [DVM-12](dip-dashvm-external-primitives.md) + +* [43-PLAN](https://github.com/dashpay/platform/issues/4676): Establish specifications and implementation tracking (4.3-dev). +* [44-CODEC](https://github.com/dashpay/platform/issues/4679): Extract the shared guest value and codec foundation (4.4-dev). +* [44-AUTHOR](https://github.com/dashpay/platform/issues/4680): Settle contract declarations and the Rust author API (4.4-dev). +* [50-CLIENTS](https://github.com/dashpay/platform/issues/4693): Deliver DAPI, Rust, Wasm/JS and mobile parity (5.0-dev). +* [50-AUTHOR](https://github.com/dashpay/platform/issues/4694): Deliver contract SDK, macros, build/test tools and worked example (5.0-dev). +* [50-DOCS](https://github.com/dashpay/platform/issues/4697): Maintain public documentation and protocol-change checklist (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm-scheduling.md b/dip-dashvm-scheduling.md new file mode 100644 index 00000000..7b20e86d --- /dev/null +++ b/dip-dashvm-scheduling.md @@ -0,0 +1,82 @@ +
+  DIP: Unassigned (dip-dashvm-scheduling)
+  Title: Time-based scheduled calls
+  Chain: Platform
+  Layer: Consensus
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Standard
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Schedule bounded contract calls using agreed consensus time, latest method routing, live execution payment and prepaid removal in the existing prefunded balance ledger. Separate actual scheduled failure policy from free internal speculative retries. + +## Motivation + +Contracts need recurring and delayed work without prepaying every future execution. A job must remain removable when operating funds run out, and deterministic ordering and bounded backlog handling must prevent timer storms from consuming a block. + +## Specification + +### Job record and registration + +Store `Job{id, owner_contract, target_contract, stable_method, arguments, authority, live_payer, cancel_authority, next_due_time, recurrence, failure_policy, occurrence, attempt, removal_balance_id}`. The canonical schema also binds creation/profile facts and ownership/refund context. Time-based triggers are the only supported triggers; reject height/epoch trigger variants and create no placeholder queues. Do not store an old target executable version. + +Registration validates caller/target authority, permitted payer, argument and timing bounds, cancellation policy and removal affordability. Atomically debit the real funder into the existing `40/128` prefunded balance, write purpose/owner metadata, primary job and one due-time locator. New purpose IDs are domain-separated and cannot impersonate legacy vote funding. A job cannot fund itself from an unrelated reserve supplied by guest input. + +### Processing order — proposed engineering convention + +After agreed membership, due lifecycle and approved governance effects, process eligible jobs before ordinary user transitions in the block's existing scheduled-event integration point. Wire this exact phase into both proposal paths. Ordered due keys are `(consensus_due_time, contract_id, job_id, occurrence)` with explicit canonical encodings; never use a wall clock or database iteration order outside that key order. A job created by an ordinary transition becomes eligible no earlier than a later scheduled phase. + +Process bounded work and obey the contract-computation budget plus existing native event constraints. Stop deterministically at the selected bound and retain backlog. Do not admit an invocation if its required bound cannot fit the remaining permitted computation. Skipping for block capacity is not a paid attempt. Native queue bookkeeping has its own bounded work/cost specification; it must not become the rejected combined execution budget. + +### Attempt state machine + +For each eligible occurrence, resolve the latest target method and lifecycle at its accepted position. Frozen executing contracts pause; no guest code runs. On unfreeze advance to an eligible future run under the recurrence convention rather than replaying every missed occurrence. Proposed permanently missing method/unsupported target outcome is terminal removal using its reserve, with a structured reason. This terminal policy is an engineering proposal, explicitly tested with method removal/version updates. + +Check live affordability before each real execution attempt. The first inability to pay removes the job using its prepaid removal funds, regardless of the declared execution-failure policy. It does not run the guest to discover failure. Otherwise invoke through the shared outer scope and settle once. Internal parallel retries do not increment attempts or create extra fees/receipts. + +Require explicit `Drop`, `Skip`, or `Retry{max_attempts, interval, then}`. Drop removes the job. Skip advances a recurring job to its next normal occurrence; a one-shot completes. Retry preserves the current occurrence, schedules one later eligible attempt and cannot overlap itself. After its bounded attempts, `then` is Drop or Skip. The current starting proposal is at most ten total attempts with at least one later block between them; it remains a measured protocol allocation, not a confirmed production cap. + +Proposed recurrence convention: keep a fixed time anchor and positive period, selecting the smallest anchor-plus-period multiple strictly after the accepted processing time when advancing. Use checked arithmetic; overflow produces a defined terminal outcome. Never burst through missed times. A retry has a due time no earlier than the accepted failure time plus its declared interval and is ineligible in that same block even if time encoding rounds down. + +### Cancellation, freeze and wipe + +Each job declares who can cancel. Native cancellation checks current authority, removes the job/due index, charges bounded removal and refunds remaining prefunds to their recorded owner. If that owner is wiped, route to the current processing pool. Another funder's ownership remains intact. Cancellation/removal/retry index changes and settlement are atomic and idempotent. + +Network freeze cannot be bypassed by a scheduled invocation. Permitted native inbound funds/refunds to frozen recipients do not execute a guest callback; a required unavailable callback cannot be treated as successful authorization. Wipe disables execution immediately and schedules bounded native job removal. Old retained code does not revive jobs. Fee upgrades must maintain prepaid removal or settle affected jobs before an incompatible change. + +## Backward compatibility and deployment + +Extend the existing native scheduled-event pipeline and prefunded helpers; retain old voting IDs and purpose behavior. No jobs_due_height/jobs_due_epoch or new monetary reserve root is introduced. New job formats and clocks are protocol-versioned; historical fee context survives restarts and upgrades. + +## Security considerations + +Bound due scans, arguments, retries, recurrence overflow and cleanup work. Prevent same-block retry storms and duplicate settlement across crashes. A genuine scheduled host/storage fault is not a paid guest failure: the normal protocol-upgrade recovery policy remains, including its known possibility of a halt that cannot be fixed by simply dropping an ordinary transaction. + +## Test vectors + +Cover equal due times, one-shot/recurring success, each failure policy, first lack of funds, unpayable future fee changes, cancellation rights, empty live balance with funded removal, frozen pause/resume, missing latest method, wipe, foreign refund owner, crash between cleanup steps and scheduled-only epoch-boundary blocks. Compare proposer/validator and serial/parallel roots, queue contents, attempts, fees and receipts. Exact phase and recurrence boundary vectors are required before enabling. + +## Reference implementation and rationale + +Drive owns primary jobs/due indexes/prefund operations; rs-drive-contracts owns invocation adaptation; ABCI owns ordered bounded dispatch and commit; SDKs expose time-only builders and structured status. Live payment avoids locking the cost of an indefinite future schedule; prepaid removal ensures deterministic cleanup even after the live payer is exhausted. + +## Related drafts and implementation tracking + +[DVM-01](dip-dashvm-protocol.md) · [DVM-02](dip-dashvm-engine-abi.md) · [DVM-03](dip-dashvm-activation.md) · [DVM-04](dip-dashvm-storage.md) · [DVM-05](dip-dashvm-guards.md) · [DVM-06](dip-dashvm-execution.md) · [DVM-07](dip-dashvm-fees.md) · [DVM-09](dip-dashvm-governance.md) · [DVM-10](dip-dashvm-proofs-clients.md) · [DVM-11](dip-dashvm-rust-sdk.md) · [DVM-12](dip-dashvm-external-primitives.md) + +* [50-SCHEDULE](https://github.com/dashpay/platform/issues/4688): Implement time-only live-paid schedules and removal settlement (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm-storage.md b/dip-dashvm-storage.md new file mode 100644 index 00000000..3d9aab85 --- /dev/null +++ b/dip-dashvm-storage.md @@ -0,0 +1,103 @@ +
+  DIP: Unassigned (dip-dashvm-storage)
+  Title: Native storage, collections and capabilities
+  Chain: Platform
+  Layer: Consensus
+  Author(s): To be confirmed
+  Comments-Summary: Initial draft; discussion and implementation tracking linked below.
+  Status: Draft
+  Type: Standard
+  Created: 2026-09-11
+  License: MIT License
+
+ +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](dip-dashvm/allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +[Parent plan](https://github.com/dashpay/platform/issues/4626) · [Implementation tracking](https://github.com/dashpay/platform/issues/4676) · [Shared allocation register](dip-dashvm/allocations.md) + +## Abstract + +Map smart-contract code, declarations, native application state, balances and lifecycle records onto Drive/GroveDB. Preserve native documents, secondary indexes, validation, atomic operations, refunds and proofs. The attached 18-area mapping and 110-capability register are integral implementation appendices; catalogue inclusion is not a claim that every host interface already exists. + +## Motivation + +Contracts need sum/count trees, ranked and composite queries, relations and specialized collections without rebuilding those primitives in guest code. Typed declarations let Drive enforce the real native invariants and cost bounds while exposing stable contract APIs. + +## Specification + +### Contract namespace + +Existing root `64 / contract_id` contains raw byte `0` for contract/schema metadata and `1` for documents. Data-only contracts retain exactly this shape and receive no empty executable placeholders. Smart contracts add `2 = EXEC`, `3 = COLLECTIONS`, `4 = RUNTIME`. EXEC contains permanent modules/manifests, routing, policy and readiness; COLLECTIONS contains declared specialized instances; RUNTIME contains jobs, receipts and asset discovery indexes. + +For a new smart contract, apply the existing 0/1 skeleton first and the 2/3/4 extension as a second distinct Merk application inside the same outer GroveDB transaction. This produces local root 1, left child 0, right child 3 with children 2 and 4 under the inspected GroveDB implementation. Coalescing all five into an empty-tree batch chooses a different root and is forbidden for this layout generation. AVL balancing remains enabled. Descendant changes occur in child Merks and do not add siblings. Keep namespace parents structurally stable; any future sibling/removal change requires explicit layout handling. + +Authorized data-to-smart conversion preserves current schema, documents, native assets and history and adds the executable namespace atomically. Rejected conversion does not leave partial executable subtrees. Reads cannot create them. Pending, cancelled, retired or wiped smart code does not convert the contract back into a pristine data-only contract. Historical contract root shapes must be inspected and handled explicitly rather than silently rewritten. + +### Native data and collection declarations + +Persistent Rust records are ordinary native documents under key 1. DPP and Drive validate properties, identities, revisions, ownership, native permissions and index changes. Reuse versioned native index-update validation: the inspected current validator rejects changing existing document-type indexes; new types may declare indexes normally. This project introduces no general schema migration/backfill subsystem. + +Each specialized collection template declares a stable ID, native tree/bundle kind, key/value codecs, element constraints, authorized operation set, bounds, proof/result profile, retention and owner. Instances are created only by a bounded authorized operation against an already accepted template. The host maps typed handles to native paths; guest code cannot supply arbitrary paths, raw Elements, forged owners or an undeclared tree kind. Reject unsupported option combinations rather than ignoring them. + +The capability appendix covers ordinary/sum/big-sum/count/provable/ranked trees, native document/index/query families, ordinary and bidirectional references, append/MMR/commitment families, assets, identities/groups, system boundaries, proof projection, costs and lifecycle. Native private-store exposure remains unavailable until key management, ciphertext visibility, proof disclosure and availability are specified; catalogue coverage is not an encryption guarantee. ACL/randomness integration follows DVM-12. + +### Ownership and authority + +A capability descriptor binds namespace, schema/template, permitted operation, target contract, rights and limits. It is checked against current native authority on every use. Static declaration permits requesting an operation; it does not itself grant ownership or bypass native rules. Keep signer, caller contract and resource owner distinct. An old supported code version uses current storage permissions. Native contested-index awards cannot invoke any custom guard or guest veto; contracts only supply validated native parameters. + +### Monetary areas + +Use one authoritative credit holding per contract/bucket in the proposed contract-credit hierarchy, included once in conservation. Ordinary SumTree is the current engineering recommendation for the credit root and per-contract trees; prove aggregate totals through the authenticated parent element/path. ProvableSumTree remains suitable where compact arbitrary range-sum proofs are required. Exact new root allocation remains open. + +Contract token holdings extend the existing per-token ledger under `16/128/token_id` through a reserved holder branch whose key shape cannot collide with an identity ID. Keep one token per aggregate and one amount per holding. Native mint/burn/transfer/freeze/enumeration/proof code must understand that branch. Asset discovery indexes contain locators, never duplicate balances or supply. Token issuer discovery must include pre-existing native tokens when a data contract becomes smart. + +Contract credit/token/document transfers preserve receiving-side deposit rules, identity/group authorization, multi-recipient payout bounds and mutual permission for contract-to-contract transfers. Contracts are their own native owners, not ordinary identities without keys. No direct contract-to-Core unlock is introduced; any permitted outward movement must use the existing authorized native path through a valid recipient. Asset action validation and conservation apply even when initiated by handwritten guest code. + +Reuse existing prefunded balances at `40/128`; do not create DASHVM_RESERVES. New job-removal IDs bind a versioned purpose domain, contract and job, preserving legacy vote IDs. Ownership/purpose metadata is not money. Native paths derive and check permitted purposes so a guest cannot debit a vote fund as a job reserve. Removal/refund settlement is atomic and exactly once. + +### Native operations and ordered atomicity + +rs-drive-contracts requests typed native actions; DPP/Drive enforce shared validation and Drive produces operations including all secondary index/reference/aggregate effects. Canonical replay applies them in the required order under one ABCI-owned outer transaction. Never merge speculative physical Merk deltas. Track storage and cost dependencies as DVM-06 specifies. Fee estimation and actual application must use matching native paths and include the two-stage namespace insertion where relevant. + +### Retention, cleanup and synchronization + +Accepted module blobs/manifests are permanent, deduplicated only within their contract; original storage ownership survives reuse. Receipt retention is contract-controlled. Proposed cleanup records contain bounded deterministic phase/cursor information, use atomic step+cursor updates and can resume after crashes. A logical wipe immediately removes spendability/authority before physical cleanup. Cleanup does not delete code, re-credit settled money or resurrect destroyed tokens. Checkpoint, state sync and proof verification must understand every new Element/record version and durable progress state. + +## Compatibility and deployment + +All new keys, codecs, root variants and native dispatch are versioned. Preserve existing 0/1 data-only behavior, voting prefunds, identity token leaves and historical refund flags. Rehearse upgrade with populated trees and rollback/retry, including nodes syncing directly to post-upgrade state. No empty namespace migration is permitted for ordinary contracts. + +## Security considerations + +Enforce nonnegative monetary bounds and checked sums. Reject cross-purpose prefund access, wrong token namespaces, forged handles, unauthorized schema mutations and unbounded cascades. Bound derived work, not only explicit writes. Retained inner sums after logical wipe are not available balances; query/proof consumers must apply lifecycle exclusion. + +## Test vectors and acceptance + +For every capability, cover declaration, authorized/unauthorized operation, atomic derived effects, cost upper bound, rollback, current-root proof/result behavior and lifecycle disposition. Required storage vectors include fresh/reopened root-1 shape, data-only absence proofs, conversion rollback, ordinary versus provable aggregates, token-holder separation, mixed voting/job prefunds, code reuse, wipe cleanup restart and sync compatibility. Full capability/storage/task coverage is mechanically checked in the tracking manifest; production tests remain open. + +## Reference implementation, rationale and allocations + +Drive owns paths, native trees, operations, indexes and proofs. Integration owns guest-to-native adaptation; ABCI owns block order and commit. The detailed storage appendix supplies S01–S18 paths/record semantics; symbolic inner tags and new root values require collision checks against actual registries. Reusing native primitives avoids a second indexing implementation and preserves Platform query/proof behavior. + +## Related drafts and implementation tracking + +[DVM-01](dip-dashvm-protocol.md) · [DVM-02](dip-dashvm-engine-abi.md) · [DVM-03](dip-dashvm-activation.md) · [DVM-05](dip-dashvm-guards.md) · [DVM-06](dip-dashvm-execution.md) · [DVM-07](dip-dashvm-fees.md) · [DVM-08](dip-dashvm-scheduling.md) · [DVM-09](dip-dashvm-governance.md) · [DVM-10](dip-dashvm-proofs-clients.md) · [DVM-11](dip-dashvm-rust-sdk.md) · [DVM-12](dip-dashvm-external-primitives.md) + +* [44-GROVE](https://github.com/dashpay/platform/issues/4678): Adopt the reviewed GroveDB foundation (4.4-dev). +* [44-AUTHOR](https://github.com/dashpay/platform/issues/4680): Settle contract declarations and the Rust author API (4.4-dev). +* [50-DEPLOY](https://github.com/dashpay/platform/issues/4684): Implement permanent bundles, registration, readiness and version routing (5.0-dev). +* [50-READS](https://github.com/dashpay/platform/issues/4686): Implement bounded current-state guest reads (5.0-dev). +* [50-CALLS](https://github.com/dashpay/platform/issues/4687): Implement atomic calls, delegation and ordered parallel execution (5.0-dev). +* [50-NATIVE](https://github.com/dashpay/platform/issues/4690): Implement the full native capability and collection adapters (5.0-dev). +* [50-CAP-COST](https://github.com/dashpay/platform/issues/4691): Validate cost and refund bounds for every native capability (5.0-dev). +* [50-PROOFS](https://github.com/dashpay/platform/issues/4692): Implement current-root queries and proof verification (5.0-dev). +* [50-AUTHOR](https://github.com/dashpay/platform/issues/4694): Deliver contract SDK, macros, build/test tools and worked example (5.0-dev). +* [50-GOV](https://github.com/dashpay/platform/issues/4695): Implement governance, bounded wipes and vestige recovery (5.0-dev). +* [50-ACL](https://github.com/dashpay/platform/issues/4698): Integrate native ACL with fail-closed contract stubs (5.0-dev). +* [50-RNG](https://github.com/dashpay/platform/issues/4699): Integrate native randomness with fail-closed contract stubs (5.0-dev). + +[Complete storage mapping](https://github.com/dashpay/platform/issues/4626#issuecomment-5634141255) · [Capability catalogue and current amendments](https://github.com/dashpay/platform/issues/4626#issuecomment-5636957194) · [Module architecture](https://github.com/dashpay/platform/issues/4626#issuecomment-5636536959) · [Owner decisions and provisional limits](https://github.com/dashpay/platform/issues/4626#issuecomment-5583771268). These linked appendices retain their stated confirmed/proposed status. + +## Copyright + +This working proposal is released under the MIT License, following the default license of the Dash DIPs repository. diff --git a/dip-dashvm/allocations.md b/dip-dashvm/allocations.md new file mode 100644 index 00000000..79ce6d1a --- /dev/null +++ b/dip-dashvm/allocations.md @@ -0,0 +1,63 @@ +# DashVM shared allocation register + +These are draft proposals for review, not assigned/accepted DIPs or implemented features. Confirmed design decisions are preserved. Sections explicitly marked proposed and the [shared allocation register](allocations.md) contain engineering proposals requiring review and measurement. Exact wire identifiers, the production engine profile, limits and prices remain open. DVM aliases identify this proposal series and are not official DIP numbers. Final authorship and official numbering remain subject to editorial review. + +| ID | Allocation | Task owner | Current state / required evidence | +| --- | --- | --- | --- | +| A01 | Protocol/profile and feature generations | [R05-03](https://github.com/dashpay/platform/issues/4676#task-r05-03) | Open; reconcile real PV/model registries, no assumed extra activation | +| A02 | Wire fields, messages and signed hash domains | [R05-03](https://github.com/dashpay/platform/issues/4676#task-r05-03) | Open; inventory actual DPP discriminants and serialize golden vectors | +| A03 | Nonce-family and rejection/paid outcome mapping | [R12-07](https://github.com/dashpay/platform/issues/4689#task-r12-07) | Proposed native reuse; bind every stage to existing native rules | +| A04 | Engine release/lock/config/target profile | [R08-01](https://github.com/dashpay/platform/issues/4683#task-r08-01) | Open; Wasmtime/Cranelift confirmed, exact pin requires current advisories/corpus | +| A05 | Wasm feature allowlist and complete opcode metering | [R03-04](https://github.com/dashpay/platform/issues/4683#task-r03-04) | Proposed first feature profile; scalar floats confirmed, no implicit defaults | +| A06 | Logical stack/memory/compilation limits | [FIX-05](https://github.com/dashpay/platform/issues/4683#task-fix-05) | Provisional values in appendix; measure adversarial/native headroom | +| A07 | ABI signatures, handles, value/manifest encodings | [R08-04](https://github.com/dashpay/platform/issues/4683#task-r08-04) | Semantic schemas drafted; exact bytes/version IDs open | +| A08 | Named-module linking and initialization | [R08-01](https://github.com/dashpay/platform/issues/4683#task-r08-01) | Proposed DAG/separate memories/host-mediated calls and bounded starts | +| A09 | Root and inner storage tags/codecs | [R08-03](https://github.com/dashpay/platform/issues/4684#task-r08-03) | 0/1 and smart 2/3/4 confirmed; new root/inner tags unallocated | +| A10 | Active eligibility/key/report binding | [R08-12](https://github.com/dashpay/platform/issues/4684#task-r08-12) | Whole active set and one vote confirmed; native predicate binding open | +| A11 | Block phases and boundary conventions | [R08-13](https://github.com/dashpay/platform/issues/4684#task-r08-13) | Concrete DVM-03/08/09 convention proposed; source-level ABCI vectors required | +| A12 | Native guard grammar and legacy applicability | [R07-01](https://github.com/dashpay/platform/issues/4685#task-r07-01) | Concrete typed AST and prospective-current-rule proposal; review required | +| A13 | Native capability ABI and operation/proof matrix | [CAP-02](https://github.com/dashpay/platform/issues/4680#task-cap-02) | 110 catalogue rows retained; unsupported/private operations remain gated | +| A14 | Speculative branch and complete observation log | [FIX-01](https://github.com/dashpay/platform/issues/4687#task-fix-01) | New upstream GroveDB work; canonical replay, no physical delta merge | +| A15 | Fee tables and numeric prices | [R12-03](https://github.com/dashpay/platform/issues/4689#task-r12-03) | Provisional rates supplied; actual measured native/opcode tables open | +| A16 | Refund-owner encoding and old fee versions | [FIX-08](https://github.com/dashpay/platform/issues/4689#task-fix-08) | Typed owner semantics confirmed; encoding/history audit open | +| A17 | Upload/transport envelope and staging | [R06-05](https://github.com/dashpay/platform/issues/4684#task-r06-05) | Prototype one bounded upload; chunking only with complete separate design | +| A18 | Receipt codec and retention update behavior | [R10-03](https://github.com/dashpay/platform/issues/4689#task-r10-03) | Default on confirmed; snapshot retention and bounded detail proposed | +| A19 | Time queue/recurrence/retry/terminal failure | [R10-05](https://github.com/dashpay/platform/issues/4688#task-r10-05) | Time-only/live-pay/cancellation confirmed; phase/retry cap/terminal details proposed | +| A20 | Prefunded purpose IDs and metadata | [R12-10](https://github.com/dashpay/platform/issues/4689#task-r12-10) | 40/128 reuse confirmed; preserve voting IDs, derive new job purpose safely | +| A21 | Governance ballots/expiry/application failure | [R11-10](https://github.com/dashpay/platform/issues/4695#task-r11-10) | Strict >2/3 and week confirmed; choice update/phase/failure encoding proposed | +| A22 | Logical wipe/token exclusion/proof mechanism | [FIX-07](https://github.com/dashpay/platform/issues/4695#task-fix-07) | Disposition confirmed; NotSummed/tombstone implementation needs full native matrix | +| A23 | DAPI/proof/client variant identifiers | [CAP-12](https://github.com/dashpay/platform/issues/4692#task-cap-12) | Current-state-only contract confirmed; bytes and parity vectors open | +| A24 | Rust macro grammar and reproducible toolchain | [SDK-01](https://github.com/dashpay/platform/issues/4680#task-sdk-01) | Author API drafted; precise symbols/codegen/toolchain remain implementation | +| A25 | Native ACL full specification | [EXT-ACL](https://github.com/dashpay/platform/issues/4677#task-ext-acl) | Separate external project: policy, delegation, revocation, fees/proofs required | +| A26 | Native randomness full specification | [EXT-RNG](https://github.com/dashpay/platform/issues/4682#task-ext-rng) | Separate external project: source/finality/withholding/binding/proof design required | +| A27 | DIP editor numbering and author attribution | [R05-01](https://github.com/dashpay/platform/issues/4676#task-r05-01) | Unassigned descriptive aliases; do not self-assign official numbers | + +## Provisional measurement starting values + +These are engineering guesses requested by the owner. Benchmark them before selecting protocol values. They deliberately permit large contract create/update transitions. A contract limit never relaxes a smaller existing native document, query or operation limit. + +| Resource | Starting proposal | Rationale / validation needed | +| --- | --- | --- | +| Canonical WASM | 16 MiB per version | Room for large Rust contracts; stress compilation and permanent storage cost. | +| Signed contract create/update transition | 32 MiB total | Includes code, manifest, signatures and envelope; not 32 MiB per field. Keep other transition-family limits. Check DAPI, gRPC, mempool, proposal/block transport and replay all accept the same bounded envelope. | +| Upload form | One bounded create/update transition | Prototype this first; chunking remains an engineering option if transport/compilation measurements require it. | +| Guest linear memory | 128 MiB per instance; 256 MiB across the call tree | Reserve before execution; no machine-dependent `memory.grow` outcomes. Initial logical memory 16 MiB. | +| Memory/table shape | One 32-bit memory and one function table, at most 65,536 entries | Explicit initial profile; no shared memory, threads or memory64. Validate Rust toolchain compatibility. | +| Portable logical stack | 1 MiB total; 512 guest activation frames | Charge locals and operand slots, not only recursion depth; prove native-stack headroom separately. | +| Contract nesting | 8 active contract frames including the root | No repeated active contract ID; ordinary local Rust recursion uses the separate stack bound. | +| Module structure | 50,000 functions; 10,000 types; 128 params and 1,024 locals per function; 1,024 exports | Independent limits for large modules with costly shapes; reduce if adversarial Cranelift tests justify it. | +| Compilation complexity | 2 million decoded operators; 100,000 operators and 4,096 basic blocks per function; structural nesting 512 | Check before full compilation; reject excessive instrumented growth, initially cap instrumented bytes at 64 MiB. | +| Native host calls | 10,000 per outer invocation | One shared budget covers all nested work and predicates. | +| Returned read bytes | 8 MiB total; 1 MiB per query page | Also charge scanned/visited work; output limits alone do not bound query cost. | +| Logical dependency tracking | 100,000 distinct keys/range descriptors | Bound memory; coarsen or execute sequentially when necessary without changing ordered semantics. | +| Logical writes | 1,000 explicit operations and 4 MiB payload total | Meter and bound derived index/reference/cascade work too; native limits still apply. | +| Arguments / return / stored receipt | 256 KiB arguments; 64 KiB return; 64 KiB receipt | Shared nested byte accounting; reserve receipt bound before execution. Failure receipt cannot exceed reserved size. | +| Compute | 25 million units per outer invocation; 250 million contract units per block | Includes scheduled/guard/nested work; separate from existing native event budgets. No measured wall-clock limit decides consensus validity. | +| Readiness messages | 128 reports per batch; one pending executable version per contract | Deduplicate and rate-limit transport; membership sweeps need separate bounded accounting. | +| Scheduled retries | At most 10 attempts, interval at least one later block | Declared Drop/Retry/Skip policy; no same-block retry storm. | + +**Provisional computation weights:** simple/control operation 1 unit; integer multiply and floating add/multiply 2; load/store 4; divide/remainder, floating divide/sqrt and conversions 8. Copy/hash work adds units per byte or native measured work. Every admitted Wasm operator must have an explicit weight before launch; this short list is not a complete opcode table. Propose 100 units for host entry plus actual native operation cost, 1 unit per copied byte, and 65,536 units per 64-KiB memory growth page. Never price a complex query as only 100 units. + +**Provisional price:** 1 processing credit per computation unit, deployment validation 100,000 processing credits plus 20 per canonical WASM byte and 5 per decoded operator, readiness verification 10,000 processing credits per newly accepted signature plus metered membership lookup work. These are unbenchmarked candidate rates, not existing Platform prices. Add existing versioned native processing and storage charges exactly once; do not double-charge an operation already included in those tables. Permanent code, indexes and receipts pay actual native storage charges; use historical native refund rules with typed recorded owners. Local compilation time, cache misses and internal speculative retries add no fee. Verify admission estimates cover worst-case actual costs, charge only final ordered work, and adjust prices together with compute limits after measurements. + +For operations not covered here, reuse existing native fees if available; otherwise keep the allocation explicitly unresolved until a bounded implementation and measured formula exist. Reserve names for ABI/features now, then allocate numeric wire/error/storage IDs from the real registries. No fabricated numeric IDs or exact engine revision are selected here.