mirror of
https://github.com/luxfi/consensus.git
synced 2026-09-24 00:26:58 +00:00
Red proved H3's VerifyUnderPolicy was INERT: the live wire-level verifier
(QuantumPolicy.VerifyWithKeys -> QuasarCert.VerifyWithRealKeys) used the
implied-policy path (BLS-permissive), and the policy-driven path had ZERO
live callers. consensus/engine/pq (PostQuantum.SetCertPolicy) was dead —
nothing imported it.
Task 3 — make the LIVE path policy-driven from the SINGLE source of truth:
- config: ChainSecurityProfile.CertPolicy() — the one mapping from the
chain's security profile to its cert posture. strict-PQ/FIPS -> Strict
variant (BLS NOT a required leg) + Mode=PQ-strict (RequiredLegs =
{Pulsar, Corona}); other profiles -> Hybrid (BLS retained alongside PQ).
- pkg/wire: QuantumPolicy carries that CertPolicy. New VerifyCertUnderPolicy
is THE live verifier — routes through QuasarCert.VerifyUnderPolicy with
the chain's policy + full CertKeys. VerifyWithKeys is now a thin adapter
over it. NewQuantumPolicyForProfile derives the policy from the profile.
Leg presence is policy-driven (VerifyUnderPolicy Gate 1), never
cert-byte-driven: a CRQC that forges BLS and strips the PQ legs is
rejected.
- Deleted consensus/engine/pq (10 files, zero importers — the whole package
was dead, not just SetCertPolicy). The live verify is now the wire path.
Test (d): on a strict-PQ chain, the LIVE verifier rejects a BLS-only
(PQ-legs-stripped) cert even with a valid BLS key supplied; the policy is
Strict-variant (BLS not required, Corona required); the permissive default
is Hybrid (BLS required) — proving the switch is profile-driven, not
hardcoded. (The per-leg crypto half is covered in quasar/
cert_policy_verify_test.go.)
Lux Consensus Source Code Organization
This directory contains implementations of the Lux consensus framework in multiple programming languages. Each language implementation provides the same consensus algorithms with language-specific optimizations and idioms.
Directory Structure
src/
├── c/ # C implementation (high-performance, minimal overhead)
├── cpp/ # C++ implementation with MLX extensions (GPU acceleration)
├── go/ # Go implementation (production blockchain integration)
├── python/ # Python implementation (research and prototyping)
└── rust/ # Rust implementation (memory-safe systems programming)
Language Implementations
Go (/src/go/)
- Status: Production-ready
- Use Case: Core blockchain node integration
- Import Path:
github.com/luxfi/consensus(via go.work at root) - Features: Full integration with Lux node, concurrent processing
C (/src/c/)
- Status: Production-ready
- Use Case: Embedded systems, performance-critical applications
- Features: Minimal dependencies, ZeroMQ networking, SIMD optimizations
Rust (/src/rust/)
- Status: Production-ready
- Use Case: Memory-safe systems, async applications
- Features: Zero-cost abstractions, async/await, compile-time guarantees
Python (/src/python/)
- Status: Research/Development
- Use Case: Prototyping, research, data analysis
- Features: NumPy integration, ML frameworks, visualization
C++ (/src/cpp/)
- Status: Development
- Use Case: High-performance with GPU acceleration
- Features: MLX extensions, template metaprogramming, SIMD/GPU support
Building
From the repository root:
# Build all implementations
make build
# Build specific language
make build-go
make build-c
make build-rust
make build-python
make build-cpp
Testing
From the repository root:
# Test all implementations
make test
# Test specific language
make test-go
make test-c
make test-rust
make test-python
make test-cpp
Consensus Engines
All implementations support these consensus engines (Quasar family):
- Wave - Threshold voting with fast probabilistic consensus (production)
- Nova - Linear chain consensus (wraps Ray sub-protocol)
- Nebula - DAG consensus with safe-prefix commit (wraps Field sub-protocol)
- PostQuantum - Quantum-resistant consensus with BLS + Pulsar + ML-DSA
- Chain - Linear chain consensus for ordered blocks
- DAG - Full directed acyclic graph consensus
Performance Benchmarks
| Implementation | Votes/Second | Memory Usage | Latency |
|---|---|---|---|
| C | 14,000+ | < 10 MB | < 1ms |
| Rust | 13,500+ | < 15 MB | < 1ms |
| Go | 12,000+ | < 20 MB | < 2ms |
| C++ (w/ MLX) | 15,000+ | < 25 MB | < 1ms |
| Python | 5,000+ | < 50 MB | < 5ms |
Protocol Compatibility
All implementations use the same binary protocol for network communication:
┌─────────────┬────────────┬──────────┬───────────┬──────────┐
│ Engine Type │ Node ID │ Block ID │ Vote Type │ Reserved │
│ (1 byte) │ (2 bytes) │ (2 bytes)│ (1 byte) │ (2 bytes)│
└─────────────┴────────────┴──────────┴───────────┴──────────┘
This ensures interoperability between different language implementations.
Development Guidelines
- Consistency: All implementations should provide the same consensus guarantees
- Testing: Each implementation must have comprehensive test coverage
- Documentation: Language-specific documentation in
docs/{language}/ - Performance: Optimize for language strengths while maintaining correctness
- Compatibility: Maintain protocol compatibility across all implementations
Contributing
When adding features or fixes:
- Implement in the reference implementation (Go)
- Port to other languages maintaining consistency
- Add tests for all implementations
- Update documentation
See CONTRIBUTING.md for detailed guidelines.
License
Copyright (C) 2019-2025, Lux Industries Inc. All rights reserved.