rob thijssenandClaude Opus 5
2bffbc62bc
Wires @quantus/crypto into the four TYPE_* maps, so a keyring pair of type dilithium65/dilithium87 can be created, addressed, signed with and verified. The curve arms are untouched: quantus/common#6 removes them, but only once post-quantum signing is proven end to end, so that a rejected first extrinsic has two suspects rather than three. util-crypto gains thin dilithium/ wrappers so keyring composes primitives the way it already does for ed25519, rather than reaching into @quantus/crypto directly. TYPE_ADDRESS is the interesting arm. Every other entry is identity or a cheap re-encoding because on Substrate the address *is* the public key; ML-DSA takes 1952 or 2592 bytes to 32 with no way back. dilithiumVerify therefore mirrors the runtime's Verify::verify rather than inventing anything: split sig||pk, hash the embedded public key, check it equals the account being verified against, and only then check the signature. Skipping the account check would accept a valid signature from *some* key rather than *the* key, which is the whole property. TYPE_PREFIX gets 0 for dilithium87 and 1 for dilithium65. For the curve types those index Substrate's MultiSignature; here they index the runtime's DilithiumSignatureScheme — a different enum reached by the same withType mechanism, so nothing upstream of createPair needs to know. Signing takes a mandatory context, which is quantus/common#5 arriving early because the two are inseparable: TYPE_SIGNATURE cannot have an ML-DSA arm without one. There is deliberately no default. Extrinsics on spec >= 148 verify under QUANTUS_EXTRINSIC and earlier ones under the empty context, and the wrong choice is a valid signature the chain rejects, indistinguishable locally. Only the caller knows the spec version. The curve sign functions are wrapped rather than passed by reference: ed25519Sign and sr25519Sign take a third argument of their own (onlyJs), and letting it line up with the context slot would silently reinterpret a Uint8Array as a boolean. VRF signing refuses for ML-DSA. The construction fakes a VRF from an ordinary signature, which is sound only given properties ML-DSA's signature does not have; producing something that looks like a VRF proof and cannot be verified as one is worse than refusing. Two runtime whitelists sat behind the KeypairType union and silently rejected the new types — the Keyring constructor and createFromJson. The compiler cannot see those, and the first failed at construction with a message listing four types. Both now use one named KEYPAIR_TYPES so the next change to the union has a single place to look and the message cannot drift from the check. Verified against quantus-cli, not against ourselves: keyring.addFromSeed with 32 zero bytes yields crystal_alice's address, signs to the runtime's wire length, verifies under the extrinsic context and fails under the spec-147 one, and another account's signature is rejected for it. Refs quantus/common#2, quantus/common#5 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012uDUodEcRbBwNRi3UCmw8f
@polkadot/common
Various useful utility functions that are used across all projects in the @polkadot namespace. It provides utility functions with additional safety checks, allowing not only for consistent coding, but also reducing the general boilerplate.
overview
This repository is split up into a number of internal packages, namely utilities -
- keyring Keyring management
- util General utilities
- util-crypto Crypto and hashing utilities
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.
To get started -
- Clone the repo locally, via
git clone https://github.com/polkadot-js/common <optional local path> - Ensure that you have a recent version of Node.js, for development purposes Node 10 is recommended.
- Ensure that you have a recent version of Yarn, for development purposes Yarn >=1.10.1 is required.
- Install the dependencies by running
yarn - Build the everything via
yarn run build - You can also launch the API Docs, via
yarn vuepress dev docs - Access the docs via http://localhost:8080
tutorials
Looking for tutorials to get started? Look at examples for guides on how to use the base utilities.