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.
Blake3 Precompile
Address: 0x0000000000000000000000000000000000000504
Blake3 hash function precompile for the Lux EVM.
Overview
Blake3 is a cryptographic hash function that is:
- Fast: 6-17x faster than SHA-3 and SHA-256
- Parallelizable: Can utilize multiple cores
- Versatile: Supports XOF (extendable output), KDF, and MAC
- Simple: Single algorithm for all use cases
Operations
| Operation | Selector | Gas Cost | Description |
|---|---|---|---|
hash256 |
0x01 |
100 + 3/word | Standard 32-byte hash |
hash512 |
0x02 |
150 + 3/word | Extended 64-byte hash |
hashXOF |
0x03 |
200 + 3/in + 5/out | Arbitrary length output |
hashWithDomain |
0x04 |
150 + 3/word | Domain-separated hash |
merkleRoot |
0x10 |
500 + 100/leaf | Merkle tree root |
deriveKey |
0x20 |
300 + 3/word | Key derivation |
Input Formats
hash256 (0x01)
[1 byte: 0x01][data...]
Returns: 32 bytes
hash512 (0x02)
[1 byte: 0x02][data...]
Returns: 64 bytes
hashXOF (0x03)
[1 byte: 0x03][4 bytes: output_length][data...]
Returns: output_length bytes (max 1024)
hashWithDomain (0x04)
[1 byte: 0x04][1 byte: domain_length][domain bytes][data...]
Returns: 32 bytes
merkleRoot (0x10)
[1 byte: 0x10][4 bytes: num_leaves][32 bytes: leaf_0][32 bytes: leaf_1]...
Returns: 32 bytes (Merkle root)
deriveKey (0x20)
[1 byte: 0x20][1 byte: context_length][context bytes][32 bytes: key_material]
Returns: 32 bytes (derived key)
Solidity Usage
import {Blake3Lib} from "./IBlake3.sol";
contract MyContract {
using Blake3Lib for bytes;
function hashData(bytes memory data) external view returns (bytes32) {
return Blake3Lib.hash256(data);
}
function buildMerkleRoot(bytes32[] memory leaves) external view returns (bytes32) {
return Blake3Lib.merkleRoot(leaves);
}
function deriveEncryptionKey(bytes32 masterKey) external view returns (bytes32) {
return Blake3Lib.deriveKey("MyApp.encryption.v1", masterKey);
}
}
Use Cases
1. Fast Hashing
Blake3 is ideal for high-throughput applications that need fast hashing:
- Content addressing
- Transaction hashing
- State root computation
2. Merkle Trees
Built-in Merkle tree root computation:
- Rollup state commitments
- Data availability proofs
- Batch transaction verification
3. Key Derivation
Domain-separated key derivation for:
- Hierarchical key generation
- Deterministic wallet derivation
- Protocol-specific key isolation
4. Commitments
Domain-separated hashing for:
- Commit-reveal schemes
- Privacy protocols
- Zero-knowledge commitments
Security Considerations
-
Not Post-Quantum: Blake3 uses classical construction. For quantum-resistant hashing, use Poseidon2 (0x0502) or SHAKE256.
-
Domain Separation: Always use domain-separated hashing for different purposes to prevent cross-protocol attacks.
-
XOF Mode: When using XOF, ensure output length matches security requirements (256 bits = 128-bit security).
Performance
| Operation | Input Size | Gas Cost | Time (M1 Max) |
|---|---|---|---|
| hash256 | 1 KB | ~200 | ~1 μs |
| hash256 | 1 MB | ~100K | ~1 ms |
| merkleRoot | 256 leaves | ~26K | ~50 μs |
| deriveKey | 32 bytes | ~300 | ~0.5 μs |
Related Precompiles
| Address | Precompile | Use Case |
|---|---|---|
| 0x0502 | Pedersen | ZK-friendly commitments |
| 0x0503 | Poseidon2 | Post-quantum ZK hashing |
| 0x0504 | Blake3 | Fast general-purpose hashing |
| 0x031D | KZG4844 | Blob commitments (EIP-4844) |