@coordination-network/revocation-registry 0.0.1

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.
@@ -0,0 +1,351 @@
1
+ import { LeanIMTPlusHashFunctions, LeanIMTPlusLeaf, LeanIMTPlusProof, LeanIMTPlus } from '@zk-kit/lean-imt-plus';
2
+
3
+ /**
4
+ * The BN254 (alt_bn128) scalar field order. Every commitment stored in a
5
+ * revocation registry, and every hash the tree produces, is an element of this
6
+ * field. It matches `SNARK_SCALAR_FIELD` in the LeanIMT+ Solidity library and
7
+ * the field a BN254 zero-knowledge circuit works over.
8
+ */
9
+ declare const SNARK_SCALAR_FIELD = 21888242871839275222246405745257275088548364400416034343698204186575808495617n;
10
+ /**
11
+ * Domain-separation tag mixed into every leaf commitment as the third input of
12
+ * the 3-input leaf hash. Kept here so callers can reproduce a leaf commitment
13
+ * without depending on LeanIMT+ internals.
14
+ */
15
+ declare const TAG_LEAF = 1n;
16
+ /**
17
+ * Proof discriminator. `MEMBERSHIP` proves the commitment is in the registry
18
+ * (the credential is revoked); `NON_MEMBERSHIP` proves it is absent (the
19
+ * credential is not revoked). A holder proving a valid credential always
20
+ * produces a `NON_MEMBERSHIP` proof.
21
+ */
22
+ declare const PROOF_TYPE: {
23
+ readonly MEMBERSHIP: 0;
24
+ readonly NON_MEMBERSHIP: 1;
25
+ };
26
+ /**
27
+ * Version tag of the snapshot format produced by `export` and accepted by
28
+ * `import`. It must match the version the underlying LeanIMT+ writes, which
29
+ * enforces it on import.
30
+ */
31
+ declare const SNAPSHOT_VERSION = 1;
32
+
33
+ /**
34
+ * The hash pair every revocation registry uses, in every language.
35
+ *
36
+ * - `leaf` is a 3-input Poseidon over `(value, nextValue, TAG_LEAF)`. It matches
37
+ * `PoseidonT4` in the LeanIMT+ Solidity library and `poseidon::bn254::hash_3`
38
+ * in a BN254 Poseidon circuit.
39
+ * - `internal` is a 2-input Poseidon for inner nodes. It matches `PoseidonT3`
40
+ * and `poseidon::bn254::hash_2`.
41
+ *
42
+ * The differing arity is what domain-separates a leaf commitment from an
43
+ * internal-node hash, which closes the second-preimage attack in which an
44
+ * attacker repackages an internal node as a leaf. All three implementations
45
+ * must agree on this pair or their roots will not match.
46
+ */
47
+ declare const revocationHashes: LeanIMTPlusHashFunctions<bigint>;
48
+
49
+ /** Anything that can be coerced to a field element with `BigInt()`. */
50
+ type BigNumberish = bigint | number | string;
51
+ /**
52
+ * A revocation proof. Structurally a LeanIMT+ proof: a Merkle proof of a single
53
+ * indexed leaf plus a `proofType` that says which extra check the verifier runs.
54
+ *
55
+ * - `proofType: 0` (membership): `leaf.value === value`, so the commitment is in
56
+ * the registry and the credential is revoked.
57
+ * - `proofType: 1` (non-membership): `leaf` is the low leaf of `value`, so the
58
+ * commitment is absent and the credential is not revoked.
59
+ *
60
+ * `root` is the value the verifier must independently accept as one the
61
+ * authoritative registry currently publishes. The proof proves nothing on its
62
+ * own: its root is supplied by whoever built it.
63
+ */
64
+ type RevocationProof = LeanIMTPlusProof<bigint>;
65
+ /** An indexed leaf of the revocation tree: a commitment and its successor. */
66
+ type RevocationLeaf = LeanIMTPlusLeaf<bigint>;
67
+
68
+ /**
69
+ * A revocation registry: a
70
+ * {@link https://pse.dev/blog/lean-imt-plus-efficient-merkle-tree-for-membership-and-non-membership-proofs | LeanIMT+}
71
+ * whose leaves are the revocation commitments of revoked credentials.
72
+ *
73
+ * The class is a self-contained implementation of the structure, not a client
74
+ * for any particular backend. It can hold a registry outright, which is what a
75
+ * service that publishes revocations from its own database does, or mirror one
76
+ * whose authoritative copy lives elsewhere, which is what a holder does before
77
+ * building a proof. Nothing here reads or writes anything external.
78
+ *
79
+ * Two operations serve the two roles:
80
+ *
81
+ * - **Issuer.** {@link revoke} inserts a commitment. Where the authoritative
82
+ * registry is a separate system that validates a predecessor index rather than
83
+ * searching for one, {@link lowLeafIndexOf} computes that index.
84
+ * - **Holder.** {@link generateProof} produces a proof about a commitment. A
85
+ * non-membership proof (`proofType: 1`) is what shows a credential is not
86
+ * revoked, and is the witness a zero-knowledge circuit consumes to show it
87
+ * without revealing the commitment.
88
+ *
89
+ * When this instance is a mirror rather than the authority, it is trusted for
90
+ * availability only, never for integrity: compare {@link root} against the root
91
+ * the authority reports before using any proof built from it. Building the tree
92
+ * locally is also what keeps a holder private, since they read the whole public
93
+ * registry and never disclose which commitment they care about.
94
+ *
95
+ * An empty registry has a root of `0` and cannot produce proofs: nothing has
96
+ * been revoked yet, so there is nothing to prove against. Verifiers must handle
97
+ * that case as "no revocations", not as a failure.
98
+ */
99
+ declare class RevocationRegistry {
100
+ /** The underlying LeanIMT+ instance. */
101
+ leanIMTPlus: LeanIMTPlus<bigint>;
102
+ /**
103
+ * Creates a registry, optionally pre-loaded with revoked commitments.
104
+ * Passing the full list is more efficient than revoking them one by one,
105
+ * because each affected internal node is rehashed at most once.
106
+ *
107
+ * The tree is position-addressable, so a different insertion order produces
108
+ * a different root even for the same set of commitments. When rebuilding a
109
+ * registry that already exists elsewhere, the commitments must be supplied
110
+ * in the order that registry inserted them.
111
+ *
112
+ * This reconstructs a registry only while nothing has ever been un-revoked.
113
+ * An un-revocation leaves a tombstoned slot behind, and that slot still
114
+ * occupies a Merkle position, so replaying the surviving commitments would
115
+ * produce a different root. Use {@link RevocationRegistry.fromLeaves} or
116
+ * {@link RevocationRegistry.import} for a registry that may have tombstones.
117
+ *
118
+ * @param commitments Revoked commitments, in insertion order.
119
+ */
120
+ constructor(commitments?: BigNumberish[]);
121
+ /** The current revocation root. `0` while the registry is empty. */
122
+ get root(): bigint;
123
+ /** The current tree depth. */
124
+ get depth(): number;
125
+ /** The number of revoked commitments, excluding the sentinel and tombstones. */
126
+ get size(): number;
127
+ /**
128
+ * The revoked commitments in insertion order. Reading `.value` off each leaf
129
+ * gives the commitments; `.nextValue` exposes the sorted linked list the
130
+ * non-membership proof relies on.
131
+ */
132
+ get leaves(): RevocationLeaf[];
133
+ /**
134
+ * The revoked commitments, in insertion order. Excludes the sentinel and any
135
+ * tombstones, so this is a lossy view of the tree: it round-trips through the
136
+ * constructor only while nothing has been un-revoked. See
137
+ * {@link leafSlots}.
138
+ */
139
+ get commitments(): bigint[];
140
+ /**
141
+ * Every physical leaf slot in index order, sentinel and tombstones included.
142
+ *
143
+ * This is the lossless view of the registry and the counterpart of
144
+ * {@link RevocationRegistry.fromLeaves}: an authority publishes these slots,
145
+ * and anyone can rebuild the exact same tree from them. It mirrors what the
146
+ * on-chain registry exposes through `getLeaf`.
147
+ *
148
+ * Prefer {@link commitments} to enumerate what is revoked. This walks the
149
+ * whole tree, so treat it as a publishing operation rather than a hot path.
150
+ */
151
+ get leafSlots(): RevocationLeaf[];
152
+ /** Returns true if the commitment has been revoked. */
153
+ isRevoked(commitment: BigNumberish): boolean;
154
+ /**
155
+ * Returns the physical leaf index of a revoked commitment, or `-1` if it is
156
+ * not revoked.
157
+ *
158
+ * This is a slot in the tree, never a position in {@link commitments}. The
159
+ * two always differ by at least one, because slot 0 is the sentinel, and
160
+ * they drift further apart with every tombstone.
161
+ */
162
+ indexOf(commitment: BigNumberish): number;
163
+ /**
164
+ * Revokes a credential by inserting its commitment.
165
+ *
166
+ * @param commitment The revocation commitment of the credential.
167
+ */
168
+ revoke(commitment: BigNumberish): void;
169
+ /**
170
+ * Revokes several credentials in one pass. Cheaper than calling
171
+ * {@link revoke} once per commitment, because each affected internal node is
172
+ * rehashed at most once.
173
+ *
174
+ * Not transactional: if a commitment mid-batch is rejected, the earlier ones
175
+ * have already been applied. Validate with {@link isRevoked} first when the
176
+ * input is untrusted.
177
+ *
178
+ * @param commitments The revocation commitments, in insertion order.
179
+ */
180
+ revokeMany(commitments: BigNumberish[]): void;
181
+ /**
182
+ * Un-revokes a credential, tombstoning its slot.
183
+ *
184
+ * Revocation is normally permanent, and a registry that never un-revokes is
185
+ * the simpler thing to reason about: an un-revoked credential becomes valid
186
+ * again for every verifier that has not yet seen the new root. The operation
187
+ * is exposed because the underlying tree supports it and some issuers need
188
+ * to undo a mistaken revocation, but reach for it deliberately.
189
+ *
190
+ * It also leaves a tombstoned slot behind, after which the registry can no
191
+ * longer be rebuilt from {@link commitments} alone. Publish the leaf slots
192
+ * (see {@link RevocationRegistry.fromLeaves}) or a snapshot instead.
193
+ *
194
+ * @param commitment The revocation commitment to un-revoke.
195
+ */
196
+ unrevoke(commitment: BigNumberish): void;
197
+ /**
198
+ * Replaces a revoked commitment with another one, in place, reusing the old
199
+ * physical slot. Cheaper than an {@link unrevoke} followed by a
200
+ * {@link revoke}, which would tombstone a slot and append a new one.
201
+ *
202
+ * @param oldCommitment The revoked commitment to replace.
203
+ * @param newCommitment The commitment to put in its place.
204
+ */
205
+ updateCommitment(oldCommitment: BigNumberish, newCommitment: BigNumberish): void;
206
+ /**
207
+ * Generates a proof for a commitment: a non-membership proof
208
+ * (`proofType: 1`) if the credential is not revoked, a membership proof
209
+ * (`proofType: 0`) if it is.
210
+ *
211
+ * The proof carries the root it was built against. It proves nothing until
212
+ * the verifier independently accepts that root as one the authoritative
213
+ * registry currently publishes.
214
+ *
215
+ * @param commitment The revocation commitment of the credential.
216
+ * @returns The revocation proof.
217
+ */
218
+ generateProof(commitment: BigNumberish): RevocationProof;
219
+ /**
220
+ * Verifies a proof against this tree's current root. Use the static
221
+ * {@link RevocationRegistry.verifyProof} to check a proof without a local tree.
222
+ */
223
+ verifyProof(proof: RevocationProof): boolean;
224
+ /**
225
+ * Verifies that a proof is internally consistent with the root it carries.
226
+ *
227
+ * This does not bind the proof to any registry: the caller supplies
228
+ * `proof.root`, so on its own this returns true for a proof against an
229
+ * attacker-chosen root. Always compare `proof.root` against a root you
230
+ * independently accept.
231
+ */
232
+ static verifyProof(proof: RevocationProof): boolean;
233
+ /**
234
+ * Returns the physical index of the low leaf of a commitment: the
235
+ * predecessor a constrained implementation needs supplied rather than
236
+ * searched for.
237
+ *
238
+ * {@link revoke} does not need this, since it finds the predecessor itself.
239
+ * It exists for registries whose authoritative implementation validates a
240
+ * caller-supplied index in O(1) instead of searching, which is how a version
241
+ * that has to bound its own cost per write is built. Such an index is only
242
+ * valid against the tree state the write applies to, so if another revocation
243
+ * lands first it must be recomputed against the new state.
244
+ *
245
+ * @param commitment The commitment about to be revoked.
246
+ * @returns The physical index of its predecessor, or `0` for the first
247
+ * revocation, where the argument is ignored and the sentinel is created.
248
+ */
249
+ lowLeafIndexOf(commitment: BigNumberish): number;
250
+ /**
251
+ * Returns the low leaf indices for a batch of commitments, as a batched
252
+ * write expects them: index `i` is computed against the tree state after
253
+ * commitments `0..i-1` have been inserted.
254
+ *
255
+ * Computed on a throwaway copy, so this tree is left untouched.
256
+ *
257
+ * @param commitments The commitments about to be revoked, in insertion order.
258
+ */
259
+ lowLeafIndicesOf(commitments: BigNumberish[]): number[];
260
+ /**
261
+ * Returns the physical index of the leaf whose `nextValue` is this
262
+ * commitment. The counterpart of {@link lowLeafIndexOf} for un-revoking and
263
+ * for replacing a commitment.
264
+ *
265
+ * Returns `0` when the commitment is the smallest in the registry, because
266
+ * the sentinel at index 0 is then its predecessor.
267
+ *
268
+ * @param commitment A revoked commitment.
269
+ */
270
+ predecessorIndexOf(commitment: BigNumberish): number;
271
+ /**
272
+ * Serializes the whole tree, hashes included.
273
+ *
274
+ * This is the snapshot format: publishing a snapshot lets a holder rebuild a
275
+ * large registry without replaying every revocation since genesis. A snapshot
276
+ * is trusted for availability only, so an importing client must still compare
277
+ * {@link root} against the root the authoritative registry publishes.
278
+ */
279
+ export(): string;
280
+ /**
281
+ * Rebuilds a tree from {@link export} output.
282
+ *
283
+ * @param snapshot The serialized tree.
284
+ * @param validate Recompute every commitment and check it against the
285
+ * serialized hashes, rejecting a tampered snapshot. Defaults to `true`; pass
286
+ * `false` only for data you produced yourself.
287
+ */
288
+ static import(snapshot: string, validate?: boolean): RevocationRegistry;
289
+ /**
290
+ * Rebuilds a registry from its full physical leaf slots, sentinel and
291
+ * tombstones included.
292
+ *
293
+ * This is the reconstruction path that always works. The constructor takes
294
+ * only the active commitments, which is enough only while no commitment has
295
+ * ever been un-revoked: an un-revocation leaves a tombstoned slot behind, and
296
+ * a slot still occupies a Merkle position, so a registry that has one cannot
297
+ * be reproduced from its commitments alone.
298
+ *
299
+ * The leaf slots are exactly what an authoritative registry can publish
300
+ * verbatim: {@link leafSlots} here, or `getLeaf(registryId, i)` for `i` in
301
+ * `0..getRevocationTreeLeafCount(registryId) - 1` on chain.
302
+ *
303
+ * Hashes are recomputed here rather than taken on trust, so unlike a snapshot
304
+ * the input carries no node data to tamper with. The caller must still
305
+ * compare {@link root} against the root the authority publishes, which is
306
+ * what detects missing or reordered slots.
307
+ *
308
+ * @param leaves The physical leaf slots, in index order starting at the
309
+ * sentinel.
310
+ * @returns The reconstructed registry.
311
+ */
312
+ static fromLeaves(leaves: {
313
+ value: BigNumberish;
314
+ nextValue: BigNumberish;
315
+ }[]): RevocationRegistry;
316
+ }
317
+
318
+ /**
319
+ * Coerces a value to a BN254 field element, rejecting anything outside the
320
+ * field.
321
+ *
322
+ * Every leaf field and every hash the registry produces must be a field element:
323
+ * outside that range two distinct values reduce to the same element, which would
324
+ * let one revocation silently cover an unrelated credential and would break the
325
+ * sorted ordering a non-membership proof relies on.
326
+ *
327
+ * Zero is accepted, because the sentinel and tombstone leaf slots hold it. Use
328
+ * {@link toCommitment} for anything that must be a real commitment.
329
+ *
330
+ * @param value The value, as a bigint, number or decimal string.
331
+ * @returns The value as a bigint.
332
+ */
333
+ declare function toFieldElement(value: BigNumberish): bigint;
334
+ /**
335
+ * Coerces a value to a revocation commitment, rejecting anything the registry
336
+ * cannot hold as one.
337
+ *
338
+ * A commitment must be a field element, for the reason given on
339
+ * {@link toFieldElement}, and must additionally be non-zero, because zero is
340
+ * reserved for the sentinel leaf and for tombstones.
341
+ *
342
+ * These are the rules of the structure itself, so every implementation of a
343
+ * registry enforces them.
344
+ *
345
+ * @param value The commitment, as a bigint, number or decimal string.
346
+ * @returns The commitment as a bigint.
347
+ */
348
+ declare function toCommitment(value: BigNumberish): bigint;
349
+
350
+ export { PROOF_TYPE, RevocationRegistry, SNAPSHOT_VERSION, SNARK_SCALAR_FIELD, TAG_LEAF, revocationHashes, toCommitment, toFieldElement };
351
+ export type { BigNumberish, RevocationLeaf, RevocationProof };