@crisp-e3/zk-inputs 0.8.0 → 0.10.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,29 +1,64 @@
1
- # Wasm bundle for crisp-zk-inputs
1
+ # @crisp-e3/zk-inputs
2
2
 
3
- Here we export wasm functionality for consumption in TypeScript to enable us to share code between
4
- Rust and TypeScript.
3
+ WASM bindings for generating CRISP ZK proof inputs, compiled from Rust and shared between the
4
+ server-side Node.js environment and the browser. This package lets the CRISP SDK produce the circuit
5
+ witness data needed for Noir-based vote-validity proofs without duplicating the logic in TypeScript.
6
+
7
+ ## What it generates
8
+
9
+ The WASM module wraps a `ZKInputsGenerator` class that performs BFV encryption and produces the
10
+ witness data needed for CRISP's Noir circuits. Two main proof types are supported:
11
+
12
+ - **Vote proof** (`generateInputs`) — encrypts a vote under the committee's threshold BFV public key
13
+ and produces a witness proving the vote is correctly encrypted and that the voter is eligible
14
+ (e.g. holds the required token balance, verified via a Merkle membership proof).
15
+
16
+ - **Vote update / mask proof** (`generateInputsForUpdate`) — same structure, but used for revotes or
17
+ masker contributions under the
18
+ [vote masking](https://blog.theinterfold.com/vote-masking-receipt-freeness-secret-ballots/) scheme
19
+ that provides receipt-freeness. Unlike the first-vote path, this preserves the real
20
+ `prev_ct_commitment` (rather than zeroing it) to chain updates together.
21
+
22
+ The generator also exposes `encryptVote` / `decryptVote` for standalone BFV operations and
23
+ `generateKeys` for key generation.
24
+
25
+ These witness objects are then passed to `@noir-lang/noir_js` and `@aztec/bb.js` to generate the
26
+ actual ZK proofs.
5
27
 
6
28
  ## Usage
7
29
 
8
- This package exposes an `init` subpackage default function which should be used to universally load
9
- the wasm module instead of exporting the default loader.
30
+ This package requires a universal init pattern because:
10
31
 
11
- This is because in modern node there is no need for preloading however in the browser we still need
12
- to load the wasm bundle.
32
+ - In **Node.js** (>=18) WASM can be loaded synchronously no preloading needed.
33
+ - In the **browser** the WASM binary must be fetched and instantiated asynchronously.
13
34
 
14
- ### DONT USE THE DEFAULT INIT
35
+ The `init` subpackage handles both environments transparently.
36
+
37
+ ### ❌ Don't use the default export
15
38
 
16
39
  ```ts
17
- // Bad! Because this uses the raw loader which doesn't exist in node contexts
18
- import init, { bfvEncryptNumber } from '@crisp-e3/zk-inputs'
40
+ // Bad the raw default loader doesn't work in Node.js contexts
41
+ import init, { generateVoteInputs } from '@crisp-e3/zk-inputs'
19
42
  ```
20
43
 
21
- ### ✅ DO USE THE EXPORTED SUBMODULE
44
+ ### ✅ Use the universal subpackage loader
22
45
 
23
46
  ```ts
24
- // Good! Use the universal loader
25
47
  import init from '@crisp-e3/zk-inputs/init'
48
+ import { generateVoteInputs } from '@crisp-e3/zk-inputs'
26
49
 
27
50
  await init()
28
- // other package imports here
51
+ const inputs = generateVoteInputs(/* ... */)
52
+ ```
53
+
54
+ Call `init()` once before using any other imports from `@crisp-e3/zk-inputs`. In browser
55
+ environments `init()` fetches the WASM binary; in Node.js it is a no-op.
56
+
57
+ ## Building
58
+
59
+ The WASM bundle is compiled from the Rust source in `crates/crisp-zk-inputs` using `wasm-pack`:
60
+
61
+ ```bash
62
+ # From the CRISP root
63
+ pnpm build:wasm
29
64
  ```