mirror of
https://github.com/luxfi/precompile.git
synced 2026-07-27 03:33:45 +00:00
zeekay
cfaed2eb1d
Public permissionless launch policy: enable basically every precompile for builder convenience, ESPECIALLY wallet-curve VERIFY so users sign natively on Lux from other chains (ed25519=Solana, sr25519=Polkadot, secp256r1=WebAuthn, secp256k1/ecrecover=Ethereum). Disable ONLY actual security risks. Lux's own consensus and identity stay PQ (quasar/p3q) — enforced in the consensus layer, never by refusing an EVM verifier a dapp asked for. Two layers, decomplected: - builder EVM precompile surface : enable-all-verify (this change) - chain consensus / finality : PQ-strict (consensus module, untouched) Removed the RefuseUnderStrictPQ gate from 17 verify-only / key-safe custom precompiles: ed25519, sr25519, secp256r1, bls12381 (EIP-2537, x7 ops), kzg4844 (EIP-4844), blake3, poseidon, pedersen, babyjubjub, pasta, ring, vrf, hpke, curve25519, x25519, cggmp21, frost, and the classical SNARK verifiers in zk (Groth16/PLONK/Halo2/KZG/IPA/range/batch/commitment). zk fflonk (0x03) stays DISABLED — but on its OWN forge-bug mechanism (ErrFflonkDisabled, returned at dispatch), NOT strict-PQ: verifyFflonk has a nil-vk soundness hole that forges any statement. Security disable, fully PQ-independent. The RefuseUnderStrictPQ helper + ErrClassicalForbiddenInPQ + StrictPQReporter had zero remaining code callers (evm uses a local structural interface) — deleted contract/strict_pq.go and its test. Rewrote zk's gate test to assert the new policy (classical ops enabled, fflonk disabled). Removed the now- orphaned isPedersenCommitment; fixed stale comments referencing deleted symbols. Build: full module green. Tests: contract + zk + all 17 edited packages pass. NOTE: the STANDARD eth precompiles (ecrecover, p256Verify, sha256, ripemd160, blake2f, bls12381, kzg) are still refused by LuxStrictPQ() in the evm plugin — a follow-up commit flips that to Permissive so ecrecover (every Ethereum dapp) works at launch.
secp256r1 (P-256) Signature Verification Precompile
Implementation of the secp256r1 (NIST P-256) signature verification precompile for the Lux Network EVM.
Overview
This precompile enables efficient verification of ECDSA signatures using the NIST P-256 curve, commonly used by:
- WebAuthn/Passkeys: Modern password-less authentication
- Apple Secure Enclave: Face ID / Touch ID
- Windows Hello: Biometric authentication
- Android Keystore: Device-backed keys
- Enterprise HSMs: NIST-approved cryptography
Precompile Details
| Property | Value |
|---|---|
| Address | 0x0000000000000000000000000000000000000100 |
| Gas Cost | 3,450 |
| Input Size | 160 bytes |
| Output Size | 32 bytes (success) or 0 bytes (failure) |
Input Format
[32 bytes] message hash
[32 bytes] r (signature component)
[32 bytes] s (signature component)
[32 bytes] x (public key x-coordinate)
[32 bytes] y (public key y-coordinate)
Output Format
- Success: 32 bytes with value
0x0000000000000000000000000000000000000000000000000000000000000001 - Failure: Empty (0 bytes)
Usage
Solidity
import {Secp256r1Lib, P256PublicKey} from "./ISecp256r1.sol";
contract MyContract {
using Secp256r1Lib for bytes32;
function verifyBiometric(
bytes32 hash,
bytes32 r,
bytes32 s,
bytes32 pubX,
bytes32 pubY
) external view returns (bool) {
return Secp256r1Lib.verify(hash, r, s, pubX, pubY);
}
}
Go
import "github.com/luxfi/precompiles/secp256r1"
func verify(hash []byte, r, s, x, y *big.Int) bool {
return secp256r1.Verify(hash, r, s, x, y)
}
Gas Comparison
| Method | Gas Cost | Savings |
|---|---|---|
| Solidity implementation | 200,000 - 330,000 | - |
| This precompile | 3,450 | 99% |
Use Cases
- Biometric Wallets: Sign transactions with Face ID/Touch ID
- Enterprise SSO: Integrate with corporate identity systems
- WebAuthn/Passkeys: Password-less authentication for dApps
- Cross-Chain Identity: Unified authentication across Lux chains
Standards Compliance
- EIP-7212: secp256r1 Curve Support
- RIP-7212: Rollup precompile
- NIST FIPS 186-3: Digital Signature Standard
- LP-3651: Lux Network specification
Testing
go test -v ./...
Benchmarks
go test -bench=. -benchmem
Typical results (Apple M1 Max):
BenchmarkContract_Run-10 100000 10.5 µs/op 0 B/op 0 allocs/op
BenchmarkVerify-10 100000 10.3 µs/op 0 B/op 0 allocs/op
Security Considerations
- Constant Time: Uses Go stdlib
crypto/ecdsawhich provides constant-time operations - Point Validation: Validates that public key is on curve before verification
- Range Checks: Validates r, s are in range [1, n-1]
- No Malleability Check: Follows NIST specification exactly
License
MIT License - Copyright (C) 2025, Lux Industries, Inc.