proof generation off the ui thread, with circuit binaries fetched once and hash-pinned #46

New Issue

grenade · 2026-09-15T12:41:02Z

grenade commented

2026-09-15 12:41:02 +00:00

Parent: #9

Scope

Port the Flutter SDK's api/wormhole.rs and quantus-cli's wormhole_lib.rs into wallet-data: ensure_circuit_binaries from a URL on our infra with a pinned BLAKE3 hash per circuits version, generate_proof on a dedicated thread with progress events to the UI, and aggregate_proofs for several leaves. The circuits version is a property of the chain profile.

Operator decision to record here before starting

Where the circuit binaries are hosted.

Acceptance

A proof for a Heisenberg reward leaf generates with a progress bar and verifies locally before submission. A binary with the wrong hash is refused and the UI says which file.

Depends on

The wormhole derivation child.

Parent: #9 ## Scope Port the Flutter SDK's `api/wormhole.rs` and quantus-cli's `wormhole_lib.rs` into `wallet-data`: `ensure_circuit_binaries` from a URL on our infra with a pinned BLAKE3 hash per circuits version, `generate_proof` on a dedicated thread with progress events to the UI, and `aggregate_proofs` for several leaves. The circuits version is a property of the chain profile. ## Operator decision to record here before starting Where the circuit binaries are hosted. ## Acceptance A proof for a Heisenberg reward leaf generates with a progress bar and verifies locally before submission. A binary with the wrong hash is refused and the UI says which file. ## Depends on The wormhole derivation child.

grenade added the child label 2026-09-15 12:41:58 +00:00

grenade referenced this issue

2026-09-15 12:42:46 +00:00

epic: wormhole, shielded balance and exits #9

grenade commented

2026-09-16 17:53:33 +00:00

A constraint for this child, from the operator and from quantus/extension's experience: nothing that identifies which deposit is being spent may leave the client before the exit is submitted. Nullifiers are the obvious case (see the new leak issue under #9, where the wallet already gets this wrong). Proof generation adds a second one: the proof needs the Merkle path to the leaf, and zkTree_getMerkleProof(leaf_index, at_block) asks the node for that one index, which names the leaf, and a leaf carries its recipient and amount in the clear. Options to weigh before writing code: build the path locally from ZkTree::Nodes read in whole levels or large ranges, or ask for the target's proof among a shuffled set of decoy indices. Whichever is chosen, a test should assert the leaf index being spent never appears alone in a request.

A constraint for this child, from the operator and from quantus/extension's experience: **nothing that identifies which deposit is being spent may leave the client before the exit is submitted.** Nullifiers are the obvious case (see the new leak issue under #9, where the wallet already gets this wrong). Proof generation adds a second one: the proof needs the Merkle path to the leaf, and `zkTree_getMerkleProof(leaf_index, at_block)` asks the node for that one index, which names the leaf, and a leaf carries its recipient and amount in the clear. Options to weigh before writing code: build the path locally from `ZkTree::Nodes` read in whole levels or large ranges, or ask for the target's proof among a shuffled set of decoy indices. Whichever is chosen, a test should assert the leaf index being spent never appears alone in a request.

grenade referenced this issue from a commit

2026-09-16 18:00:37 +00:00

fix(wormhole): nullifiers never leave the client

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blackbeard/wallet#46