Skip to content

[DashVM 4.4-dev] Deliver the native randomness primitive as a separate project #4682

Open

Description

@QuantumExplorer

Deliver the native randomness primitive as a separate project

Parent: #4626 · Complete tracking register

Proposed target: 4.4-dev. This is a workstream tracking issue, not a claim that the release branch exists or the implementation is done. Owner: QuantumExplorer. Dates and effort remain unset.

Scope

Proposed placement for the separate native request/finalized-result primitive, including withholding/finality assumptions, bounded verification, proofs and fees. The primitive must function without DashVM; its cryptographic mechanism is still separate design work.

Specification

DVM-12

The current parent acceptance and module/capability appendices remain authoritative; these DIP drafts add proposed engineering detail without silently approving open allocations.

Completion criteria

No clock/hash-based fake entropy and no instant random-result promise. STUB-RNG and INT-RNG remain 5.0. If external delivery slips, move its target explicitly and retain the fail-closed contract capability; a stub never counts as real delivery.

Early work-package prerequisites: 43-PLAN. These are separate from the 234 task-level links.

Task acceptance

EXT-RNG

  • External project: implement the native randomness primitive

Separate project defines unbiasedness/threat assumptions, withholding/finality, future request/result rules, proofs, deterministic verification and fees. No mechanism or release invented here; separate from deferred oracle feeds. Q37 (confirmed): Randomness uses request then finalized-result lookup, including ordinary NotReady. The separate native primitive defines production randomness/finality/proofs; current contract work supplies boundaries and stubs, with no fabricated instant entropy.

Prerequisites: None recorded.

Dependents: INT-RNG.

Modules: EXTERNAL_RNG, DPP, VIEW. Original task context. Capabilities: X02.

Coordination and dependencies

Task-level prerequisites above govern order. Workstreams contain multiple stages, so a cross-link is not a claim that the entire other issue must close first. These are Markdown relationships, not native GitHub blocked-by edges. The parent dependency register preserves all 234 links, reasons and explicit/inferred labels.

  • EXT-RNG → INT-RNG (inferred): Production randomness capability requires the separate native primitive.

PR and evidence tracking

Create focused PRs against the chosen development branch. Link this issue with Refs #<issue-number> for partial work. Do not use Fixes for the whole workstream until every listed full task and acceptance criterion is complete.

For a PR that completes an entire task, add a standalone line in its actual PR body: Dash-Tasks: <completed task IDs>. Replace the placeholder with only fully completed IDs. Preparation PRs use ordinary references and omit the completion marker for their broader parent tasks. The site reads this marker on PRs in dashpay/platform and dashpay/grovedb: draft = red, ready for review = yellow, merged with no linked open PR = green. Closed-unmerged is not completion. This does not automatically close issue checkboxes and does not prove acceptance tests passed; reviewers must record the evidence.

Evidence Link / result
Implementation PRs Pending
Canonical vectors and targeted tests Pending
Upgrade/replay/conservation evidence, where applicable Pending
Remaining full-task acceptance All unchecked above

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions