Files
Claudeandhanzo-dev b38b686dcf
CI / C library (push) Successful in 12s
CI / build (amd64, windows) (push) Successful in 33s
CI / build (arm64, darwin) (push) Successful in 42s
CI / build (amd64, darwin) (push) Successful in 40s
CI / build (arm64, linux) (push) Successful in 48s
CI / build (amd64, linux) (push) Successful in 47s
CI / Rust FFI wrapper (push) Successful in 57s
CI / lint (push) Failing after 3m29s
CI / test (push) Canceled after 3m36s
lint: gofmt the seven files CI flags, and drop an ineffectual map read
golangci-lint has been failing the `lint` job on:

    engine/chain/attestation.go:89:1               (gofmt)
    engine/chain/cert.go:86:1                      (gofmt)
    pkg/wire/policies.go:777:1                     (gofmt)
    protocol/quasar/compact_evidence.go:96:1       (gofmt)
    protocol/quasar/consensus_cert.go:576:1        (gofmt)
    protocol/quasar/pulsar_sampled_cert.go:50:1    (gofmt)
    protocol/quasar/pulsar_sampled_subject.go:18:1 (gofmt)
    engine/chain/integration.go:864:2              (ineffassign)

The gofmt diffs are entirely struct-field comment alignment — no code moves.

The ineffassign is real. followVerifiedBlock did

    pending, exists := rt.Transitive.pendingBlocks[blockID]

and `pending` is never read: the only other mentions are the reassignment
inside `if !exists` and the store on the next line. Only presence matters, so
the value is no longer bound. Behaviour is identical — an already-tracked
block keeps its entry, a new one gets a fresh PendingBlock.

Scope note: `gofmt -l .` lists 30 files here, but `.golangci.yml` sets
`tests: false`, so the 23 test files are excluded and CI never sees them.
Only the 7 it actually flags are touched.

Verified: gofmt clean on all 8, `go build ./engine/... ./protocol/quasar/...
./pkg/wire/...` exits 0, and golangci-lint no longer reports gofmt or
ineffassign anywhere in those trees.

Does NOT address the separate `test` failure — protocol/quasar times out at
900s, which is its own investigation.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-08-01 08:18:52 -07:00
..

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: Data structures only — not real consensus (per SDK audit)
  • Use Case: Embedded systems, performance-critical applications
  • Features: Minimal dependencies, ZeroMQ networking, SIMD optimizations

Rust (/src/rust/)

  • Status: FFI wrapper around the C library — inherits C limitations, not native consensus (per SDK audit)
  • 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):

  1. Wave - Threshold voting with fast probabilistic consensus (production)
  2. Nova - Linear chain consensus (wraps Ray sub-protocol)
  3. Nebula - DAG consensus with safe-prefix commit (wraps Field sub-protocol)
  4. PostQuantum - Quantum-resistant consensus with BLS + Pulsar + ML-DSA
  5. Chain - Linear chain consensus for ordered blocks
  6. 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

Note. These per-implementation votes/sec figures are unverified and, per the SDK audit, several measure data-structure insertion on stub/wrapper SDKs (C = data structures only, Rust = FFI wrapper over C, C++ = Wave-only stub); only the Python SDK implements real consensus. Treat as illustrative, not measured consensus throughput. See .github/workflows/README.md and the "Honest Assessment" block in LLM.md.

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

  1. Consistency: All implementations should provide the same consensus guarantees
  2. Testing: Each implementation must have comprehensive test coverage
  3. Documentation: Language-specific documentation in docs/{language}/
  4. Performance: Optimize for language strengths while maintaining correctness
  5. Compatibility: Maintain protocol compatibility across all implementations

Contributing

When adding features or fixes:

  1. Implement in the reference implementation (Go)
  2. Port to other languages maintaining consistency
  3. Add tests for all implementations
  4. Update documentation

See CONTRIBUTING.md for detailed guidelines.

License

Copyright (C) 2019-2025, Lux Industries Inc. All rights reserved.