[0.30][Security] Define cryptographic capability and authorization-domain contracts

[a19q3]

Summary

Define the 0.30 cryptographic capability policy: which exact hash, signature, commitment, and authorization operations are compiler-supported primitives; which must use identity-pinned external verifiers; and how typed message domains prevent values from being used as authority in the wrong context.

The goal is sufficient cryptographic and authorization coverage for the frozen 0.30 business corpus. It is not to reimplement every Rust cryptographic crate or add a circuit language.

Current boundary

The current branch has executable CKB BLAKE2b and SHA-256 paths, bounded byte/preimage operations, an explicit-message BIP340 route, real multisig integration, and exact-data-hash trusted external EXEC or SPAWN/WAIT. env::sighash_all remains correctly deferred because it does not yet construct the canonical signing message. Raw Address, Script identity, hashes, public keys, signatures, message digests, commitments, proofs, and witness bytes do not yet form one accepted source-level type and conversion contract.

Required decisions

Define distinct types or checked conversions for:

• address payloads and decoded Lock Scripts;
• complete Script, Script hash, code hash, data hash, and Type Script hash;
• raw bytes, canonical transaction preimages, and domain-tagged message digests;
• public keys, signatures, signer sets, thresholds, and authorization results;
• commitments, authenticated openings, statements, and proof bytes; and
• local compiler-proved operations versus trusted-external verifier results.

For every primitive, specify algorithm and version, personalization or domain tag, accepted encodings, key and signature normalization, malleability rules, witness ownership, failure codes, cycle/stack/code-size budgets, and whether verification is native or delegated.

Required 0.30 capability

• canonical CKB signing-message construction for the selected standard Lock integration, or an exact standard external Lock boundary where constructing it inside CellScript would duplicate the consensus-adjacent implementation;
• domain-separated CKB BLAKE2b and SHA-256 over bounded gathered byte ranges;
• exact Script construction and full Script-hash comparison without confusing an address with a complete Script;
• signature verification required by the Token, NFT/DOB, multisig, order, and committed-state acceptance fixtures;
• exact issuer and signer authority binding with post-signing mutation rejection;
• authenticated commitment openings coordinated with [Language design] Add explicit typed openings for digest-committed substate #13; and
• typed external-verifier declarations for larger or protocol-specific cryptography, including exact identity, adapter, applicability, statement, and result enforcement.

Implementation phases

Phase 0 — capability and type matrix

• inventory implemented and deferred cryptographic paths;
• freeze the algorithms needed by the 0.30 corpus;
• define message-domain, Script-identity, key, signature, commitment, opening, statement, proof, and result types;
• decide native versus exact external-verifier ownership; and
• allocate stable error and evidence classifications.

Phase 1 — frontend and semantic records

• add only the required constructors and checked conversions;
• reject raw-byte substitution across semantic domains;
• retain exact algorithm, domain, source bytes, verifier identity, and enforcement location in typed semantics and ProofPlan; and
• update formatter, LSP, VS Code, builders, manifests, and source maps.

Phase 2 — native and delegated lowering

• implement or complete the selected native hash/signature/message operations;
• bind delegated calls to the exact CellDep, code/data identity, adapter, statement, and zero-success contract;
• ensure EXEC terminality and SPAWN/WAIT continuation are reflected in control-flow and claim evidence; and
• fail before artifact emission for missing, ambiguous, or unsupported verifier contracts.

Phase 3 — adversarial evidence

• cover wrong domains, algorithms, personalizations, keys, signatures, thresholds, Script identities, witness fields, commitments, openings, statements, verifier Cells, adapters, and result codes;
• mutate source records, sidecars, constants, and machine checks independently;
• compare selected native behavior with maintained reference implementations; and
• record worst-case cycles, stack, ELF bytes, witness bytes, and dependency size.

Completion criteria

• The capability matrix classifies every cryptographic API used by the 0.30 corpus.
• Domain and identity types prevent raw Address/Script/hash/digest/proof substitution.
• Canonical authorization message handling is executable or bound to an exact external standard contract.
• [Language design] Add explicit typed openings for digest-committed substate #13 openings compose with the shared witness envelope.
• Trusted-external evidence states that compiler proof stops at identity, adapter, statement, and result enforcement.
• Positive and adversarial CKB-VM cases cover every admitted primitive and adapter.
• Independent-checker mutations cover every machine property it claims.
• Resource budgets and dependency identities are release-gated.
• dev, ci, and backend gates pass.
• Independent cryptographic and authorization review is complete.

Non-goals

• supporting every Rust cryptographic crate;
• a circuit DSL or universal ZK system;
• treating a public owner value as proof of credential control;
• trusting a Registry name or builder-selected verifier without on-chain identity checks; or
• claiming the compiler proves an external verifier's parser or cryptographic internals.

Dependencies

• [Language/ABI] Bind runtime Script values to verified package interfaces #11 for typed Script and verifier handles;
• [Language design] Add explicit typed openings for digest-committed substate #13 for committed-state openings;
• [Language/Verifier][Research] Add typed zero-knowledge verifier contracts without a circuit DSL #22 for optional typed ZK verifier contracts;
• [0.30][Runtime] Complete typed bounded CKB transaction-view and syscall adapters #24 for typed transaction bytes, witnesses, Script values, and runtime adapters; and
• [Docs/strategy] Separate executable-surface closure from product capability completeness #14 for evidence-tier and capability-completeness reporting.