mirror of
https://github.com/luxfi/chains.git
synced 2026-09-24 00:26:00 +00:00
zeekay
29b808095c
The Z-Chain is DEFINITIVELY strict-PQ (shielded settlement on the canonical Lux strict-PQ profile), but the switches were inert: the default ZConfig omitted StrictPQ (->false) and RegisterZKPrecompiles had ZERO callers. Task 1 — drive BOTH switches from the single ZConfig.StrictPQ field: - Default ZConfig now pins StrictPQ=true + ProofSystem='stark' (the only system accepted under strict-PQ). A genesis with no explicit ZConfig yields a strict-PQ chain; a permissive deployment MUST set StrictPQ=false explicitly. - VM.Initialize now calls precompiles.RegisterZKPrecompiles(reg, config. StrictPQ) — same bit. On strict-PQ the classical Groth16 (0x80) / PLONK (0x81) verifiers are NOT registered (fail-closed by absence); only STARK/FRI (0x82) + the fail-closed stubs exist. Added VM.ZKPrecompiles() / VM.StrictPQ() accessors. LOW (Red) — TestStrictPQ_RealBN254VKLoadErrors drove a test-local mirror (reapplyStrictPQVKGuard), not the production loadVerifyingKeys. Added a config path (ZConfig.VerifyingKeys) to supply real keys in-memory; the test now drives the REAL NewProofVerifier->loadVerifyingKeys and asserts the strict-PQ real-bn254-VK guard fires there. Deleted the mirror. Tests (a)(c): default Z-Chain is strict-PQ + registers strictPQ=true; classical 0x80/0x81 absent, 0x82 present; a groth16 shielded proof is REFUSED before reaching bn254; explicit StrictPQ=false flips both switches in lockstep (profile-driven, not hardcoded); real-VK guard via the production loader; non-strict chain still accepts a real bn254 VK.