rob thijssen 1f1f5729ab feat(quantus-crypto): JS surface, build scripts and CSP-safe sync init
Wraps the crate for JS consumers and adds the build that produces it.

Init deliberately avoids fetch and avoids @polkadot/wasm-bridge. The consumer is
an MV3 service worker under `script-src 'self' 'wasm-unsafe-eval'`, which can
compile WASM but not usefully fetch it, and which can be cold-started between any
two messages; callers like pair.sign() are synchronous and have no await to give.
So the WASM is zlib-compressed and base64'd into bytes.js at build time and
instantiated with wasm-bindgen's initSync. Bridge is not usable here regardless:
it implements the 0.2.79 JS-heap ABI and this crate builds with 0.2.128, which
uses externref tables.

build-quantus.sh is separate from build-wasm.sh rather than folded into it,
because that script drives the nightly-2022-06-24 + xargo build wasm-crypto
needs. install-build-deps.sh gains a second wasm-bindgen for the same reason —
the two ABIs cannot share a binary. No asm.js step: wasm2js over ML-DSA would be
enormous and slow, and every context we ship into permits wasm.

bytes.js is emitted in both module systems, with the CJS copy under a directory
carrying its own {"type":"commonjs"} — the package is "type": "module" and node
otherwise refuses to load an exports.-style file from it.

Proven end to end against the real build output: base64 -> inflate -> initSync
with no fetch, crystal_alice's account id matching the CLI through the JS path,
sig||pk matching the runtime's fixed-array size, and JsError surfacing as a JS
exception across the boundary.

Sizes are read from the crate rather than exposed as constants to copy. They are
consensus-critical and a drifted JS constant would re-frame every byte after the
signature while looking entirely healthy.

Refs quantus/wasm#1

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012uDUodEcRbBwNRi3UCmw8f
2026-09-10 13:58:25 +03:00
2025-08-13 13:59:40 -03:00
2025-01-02 21:26:31 +02:00
2020-10-23 11:14:40 +02:00
2019-03-17 13:12:14 +01:00
2022-07-11 16:36:57 +03:00
2022-01-13 10:05:36 +02:00
2019-03-17 13:12:14 +01:00
2021-06-08 17:04:07 +02:00
2026-03-13 01:32:10 +02:00
2025-01-02 21:26:31 +02:00
2025-12-09 15:27:27 +05:30
2019-03-15 13:00:05 +01:00
2025-12-09 10:03:06 +00:00
2026-03-13 01:32:10 +02:00
2022-08-16 15:04:17 +03:00
2019-03-17 13:12:14 +01:00
2025-12-09 10:03:06 +00:00
2022-12-08 08:21:37 +02:00
2026-03-13 01:32:10 +02:00
2025-12-09 15:27:27 +05:30

@polkadot/wasm

Various WASM wrappers around Rust crates

overview

It is split up into a number of internal packages, namely utilities -

  • wasm-crypto Various hashing functions, sr25519 & ed25519 crypto

These are split from the polkadot-js/util repo where it is heavily used as part of @polkadot/util-crypto. (There JS fallbacks are available for some interfaces, e.g. hashing, but for sr25519 WASM is the only interface). Since these don't undergo massive changes on a daily basis and has a build overhead (WASM compilation & optimisation), it is better managed as a seperate repo with a specific CI configuration.

development

Contributions are welcome!

To start off, this repo (along with others in the @polkadot family) uses yarn workspaces to organise the code. As such, after cloning, its dependencies should be installed via yarn, not via npm; the latter will result in broken dependencies.

Description
Fork of polkadot-js/wasm. Adds ML-DSA-65/87 and Poseidon2-over-Goldilocks to the @polkadot/wasm-crypto build, wrapping the chain's own qp-rusty-crystals-dilithium / qp-poseidon-core / qp-rusty-crystals-hdwallet crates so the browser and the runtime share one implementation.
Readme Apache-2.0 32 MiB
Languages
Rust 45.7%
JavaScript 25.1%
TypeScript 25%
Shell 4%
HTML 0.2%