@zkproofport-app/sdk 0.2.13 → 0.2.15

package/dist/index.js

@@ -1581,19 +1581,22 @@ function getCircuitSupportStatus(circuit) {
  * (through mopro's native Barretenberg); it was only the JavaScript side that
  * had no such thing.
  *
- * HOW IT WORKS. `bb` proofs are checked by `acirVerifyUltraKeccakHonk(proof,
- * vk)` — the keccak variant, matching how these proofs are produced. Two things
+ * HOW IT WORKS. Proofs here are made with `--oracle_hash keccak` and ZK on, so
+ * the matching check is `acirVerifyUltraKeccakZkHonk(proof, vk)`. Two things
  * have to line up:
  *
- *   The version. The verification key format is not stable across bb releases:
- *   the pinned build emits a 1816-byte key where bb 0.87.0 and 1.2.0 emit 1760.
- *   `@aztec/bb.js@1.0.0-nightly.20250723` is the WASM build of the same bb the
- *   circuits were compiled with. A different one will reject valid proofs.
+ *   The version. `@aztec/bb.js@1.0.0-nightly.20250723` is the WASM build of the
+ *   same bb the circuits are compiled with. Versions are not interchangeable:
+ *   measured on the Korea Mobile ID age circuit, the pinned bb writes a 16256-
+ *   byte proof where bb 1.2.0 writes 16224 for the identical circuit and
+ *   witness — and the verification key comes out the SAME either way, so the
+ *   key cannot warn you. A mismatch shows up only as verification failing.
  *
- *   The oracle hash. Proofs are generated with `--oracle_hash keccak` so the
- *   Solidity verifiers can check them, so the poseidon-flavoured verify — which
- *   is what `BarretenbergVerifier.verifyUltraHonkProof` uses — says false for a
- *   perfectly good proof.
+ *   The flavour. There are four verify entry points and picking the wrong one
+ *   is not a polite false. `acirVerifyUltraZKHonk` (poseidon) answers false for
+ *   a perfectly good proof, and `acirVerifyUltraKeccakHonk` — keccak without ZK
+ *   — TRAPS the WebAssembly with a bare "unreachable", which looks exactly like
+ *   a corrupt proof, a mismatched key, or a missing SRS.
  *
  * THE PROOF ARRIVES IN TWO PIECES. The mobile app splits what Barretenberg
  * produced into `proof` and `publicInputs` before sending it, because the
@@ -1612,6 +1615,38 @@ const CIRCUITS_VK_BASE = 'https://raw.githubusercontent.com/zkproofport/circuits
 /** How long a fetched verification key is reused. Keys change only on a recompile. */
 const VK_CACHE_TTL_MS = 60 * 60 * 1000;
 const vkCache = new Map();
+/**
+ * Make sure a Node-shaped `Buffer` exists before Barretenberg is loaded.
+ *
+ * WHY THE SDK DOES THIS RATHER THAN THE CALLER. bb.js's own BROWSER build —
+ * not just its node build — converts field elements through `Buffer.alloc` and
+ * `buf.writeBigUInt64BE`. Browsers have no Buffer, and bundlers stopped
+ * polyfilling Node globals years ago, so in a browser the first verification
+ * dies with "r.writeBigUInt64BE is not a function" — a message that names
+ * nothing a caller could act on. Measured on the demo page, 2026-09-04, against
+ * a real GIWA proof.
+ *
+ * Leaving it to callers would mean every browser customer editing their
+ * bundler config to make an SDK method work, which is the configuration this
+ * SDK promises not to require.
+ *
+ * Deliberately narrow:
+ *  - It only fills a GAP. A real Buffer (Node, or a page that already has one)
+ *    is left alone, so nothing is shadowed by a lesser implementation.
+ *  - It checks for the METHOD, not just the global. A partial Buffer — which is
+ *    what several bundlers leave behind, and what the demo page actually had —
+ *    passes a `typeof Buffer` test and then fails inside Barretenberg.
+ */
+async function ensureBufferForBarretenberg() {
+    const existing = globalThis.Buffer;
+    if (existing?.alloc) {
+        const probe = existing.alloc(8);
+        if (typeof probe.writeBigUInt64BE === 'function')
+            return;
+    }
+    const { Buffer } = await import('buffer/');
+    globalThis.Buffer = Buffer;
+}
 /** @internal Hex string (with or without 0x) to bytes. */
 function hexToBytes(hex) {
     const clean = hex.startsWith('0x') || hex.startsWith('0X') ? hex.slice(2) : hex;
@@ -1690,9 +1725,8 @@ async function fetchVerificationKey(circuit, timeoutMs) {
 /**
  * Verify a proof off-chain, against its verification key.
  *
- * Needs `@aztec/bb.js` at the pinned version. It is an optional peer dependency
- * — the WASM is large and most callers verify on-chain — so the failure to have
- * it installed says so plainly rather than surfacing as a module-not-found.
+ * Needs no setup from the caller: the verifier ships with this SDK and is
+ * loaded on first use.
  *
  * @param circuit - Canonical circuit identifier
  * @param proof - Proof bytes as hex, WITHOUT public inputs (as the relay sends it)
@@ -1712,15 +1746,31 @@ async function fetchVerificationKey(circuit, timeoutMs) {
  */
 async function verifyProofOffChain(circuit, proof, publicInputs, options = {}) {
     const timeoutMs = options.timeoutMs ?? 30000;
+    // A REQUIRED dependency, loaded lazily.
+    //
+    // It was briefly an optional peer dependency, on the reasoning that the WASM
+    // is 16MB and most callers verify on-chain. That was wrong: it would have
+    // meant a customer calling this method got an error telling them to install
+    // something, and "works with zero customer configuration" is the SDK's rule.
+    // A caller should never have to know this is implemented with Barretenberg.
+    //
+    // The dynamic import is what keeps the cost off everyone else — a bundler
+    // splits it out, and a caller who never verifies off-chain never loads it.
+    // Before bb.js, not after: its module-level code already reaches for Buffer.
+    await ensureBufferForBarretenberg();
     let bb;
     try {
         bb = await import('@aztec/bb.js');
     }
-    catch {
+    catch (error) {
+        // Reaching here means the install is broken, not that something is missing
+        // by design. Say so, rather than sending the caller off to install a
+        // package they should never have had to hear about.
         return {
             valid: false,
-            error: 'Off-chain verification needs @aztec/bb.js. Install the pinned version: ' +
-                'npm install @aztec/bb.js@1.0.0-nightly.20250723',
+            error: 'Could not load the proof verifier (@aztec/bb.js), which ships with this ' +
+                'SDK. This usually means a broken or partial install — try reinstalling ' +
+                `@zkproofport-app/sdk. Underlying error: ${error instanceof Error ? error.message : String(error)}`,
         };
     }
     let api;
@@ -2432,10 +2482,8 @@ class ProofportSDK {
      * chain's own opinion: use {@link verifyResponseOnChain} when the answer has
      * to be one a contract will agree with.
      *
-     * Requires the optional peer dependency:
-     * `npm install @aztec/bb.js@1.0.0-nightly.20250723`. The version is exact —
-     * verification keys are not portable across bb releases, so a different build
-     * rejects valid proofs.
+     * Needs no setup: the verifier ships with this SDK. It is loaded on first
+     * use, so a caller who only verifies on-chain never pays for it.
      *
      * @param response - Proof response from the relay
      * @param options - Optional verification key (skips the fetch) and timeout