Hanzo AI
1a9dc4fda6
Mirrors the chains/aivm/aivm_gpu.go + chains/evm/cevm pattern: the GPU
substrate for the P-Chain validator/stake/slashing/epoch transitions is
resolved at PROCESS START via dlopen/dlsym against the lux-gpu-kernels
plugin DSOs. Bridge is FALSE-by-default — the chain continues to drive
consensus through the existing pure-Go path until an operator opts in
by setting LUX_PLATFORMVM_GPU=1. Any launcher error from the GPU falls
back to the Go path WITHOUT panic.
Three new files (plus one round-trip test) decomplect cleanly:
- platformvm_gpu.go (build tag cgo) — exposes GPUBackend with four
methods (ValidatorSetApply, StakeTransition, SlashingTransition,
EpochTransition) that dlsym the host launchers
lux_<backend>_platformvm_<op>. Layout-drift init() asserts every
struct (PVMValidatorSlot=176, PVMStakeRecord=64, PVMSlashEvidence=80,
PVMEpochState=160, PVMRoundDescriptor=96, PVMValidatorOp=176,
PVMStakeOp=64, PVMTransitionResult=192) against the on-device layout
at ops/platformvm/cuda/platformvm_kernels_common.cuh + the
authoritative platformvm_gpu_layout.hpp.
- platformvm_gpu_nocgo.go (build tag !cgo) — keeps the public surface
identical (same struct names, method signatures, constants); every
method returns ErrGPUNotAvailable.
- backend.go — pure-Go probe driver. Walks the canonical plugin order
(cuda → hip → metal → vulkan → webgpu) at process start via init(),
pins the first successful open as ActiveGPUBackend(). AutoBackend()
is the explicit re-entry point. Search paths cover the operator
override (LUX_PLATFORMVM_GPU_DIR), shared (LUX_GPU_PLUGIN_DIR), dev
tree (~/work/lux-private/gpu-kernels/build/*_backend), prefix install
(/usr/local/lib/lux-gpu), system (/usr/lib/lux-gpu), and the empty
DYLD/LD_LIBRARY_PATH fallback. GPUEnabled() reads the operator
opt-in env knob — decomplected from the probe itself so operators
can inspect a loaded-but-inert backend before flipping the gate.
- platformvm_gpu_test.go — three subtests:
1. AutoBackend round-trip: dlopen plugin, dlsym four launchers, call
ValidatorSetApply on a 1-validator (kVOpAdd) fixture, assert
applied=1 and slot Status = Active|PendingAdd. SKIPs cleanly when
no plugin is on disk (the production default).
2. Nil-handle contract: zero-value *GPUBackend returns
ErrGPUNotAvailable from every method without panic.
3. Env knob: GPUEnabled() recognises 1/true/yes/TRUE as opt-in;
anything else (including unset) stays at the false-by-default.
Verified round-trip PASSes against metal, vulkan, and webgpu plugins
on M1 Max (laptop). CUDA / HIP are the linux NVIDIA/AMD paths and
were verified in the spark.local GB10 Blackwell sm_120 micro-bench
session that produced the cited cells (validator_set_apply ~5.5ms,
stake_transition ~3.0ms, slashing_transition ~0.06ms, epoch transition
~7.0ms — gpu-kernels HEAD 4e166de).
Does NOT modify vm.go / block.go / state.go core paths; this is the
bridge surface only. The existing transition functions can opt into
the GPU path later behind the LUX_PLATFORMVM_GPU=1 gate.
All builds succeed: go build, go build -tags cgo, CGO_ENABLED=0 go
build. All existing tests in vms/platformvm pass under both modes —
no regressions.
Node implementation for the Lux network - a blockchains platform with high throughput, and blazing fast transactions.
Features
- High Performance: Optimized for throughput with sub-second finality
- Quasar Consensus: Quasar (BLS + Pulsar + ML-DSA) with Nova (linear chains) and Nebula (DAG chains) modes; sub-protocols include Photon, Wave, Focus, Flare, Horizon, Ray, Field
- EVM Compatible: Full Ethereum Virtual Machine support on C-Chain
- Multi-Chain Architecture: Platform (P), Exchange (X), and Contract (C) chains
- Custom Nets: Create custom blockchain networks with configurable VMs
- Cross-Chain Transfers: Native cross-chain asset transfers between chains
- L1 Validators: Support for L1 (Layer 1) validator operations with BLS signatures
- LP-118 Protocol: Implementation of LP-118 for warp message handling and aggregation
Installation
Lux is an incredibly lightweight protocol, so the minimum computer requirements are quite modest. Note that as network usage increases, hardware requirements may change.
The minimum recommended hardware specification for nodes connected to Mainnet is:
- CPU: Equivalent of 8 AWS vCPU
- RAM: 16 GiB
- Storage: 1 TiB
- Nodes running for very long periods of time or nodes with custom configurations may observe higher storage requirements.
- OS: Ubuntu 22.04/24.04 or macOS >= 12
- Network: Reliable IPv4 or IPv6 network connection, with an open public port.
If you plan to build Lux Node from source, you will also need the following software:
Building From Source
Clone The Repository
Clone the Lux Node repository:
git clone git@github.com:luxfi/node.git
cd node
This will clone and checkout the master branch.
Building Lux Node
Build Lux Node by running the build task:
./scripts/run_task.sh build
The node binary is now in the build directory. To run:
./build/node
Binary Install (GitHub Releases)
Download the latest build for your operating system and architecture.
The Lux binary to be executed is named luxd.
Linux (amd64/arm64)
VERSION="vX.Y.Z"
GOARCH="amd64" # or arm64
curl -L -o node.tar.gz "https://github.com/luxfi/node/releases/download/${VERSION}/node-linux-${GOARCH}-${VERSION}.tar.gz"
tar -xzf node.tar.gz
./luxd --help
macOS (amd64/arm64)
VERSION="vX.Y.Z"
curl -L -o node.zip "https://github.com/luxfi/node/releases/download/${VERSION}/node-macos-${VERSION}.zip"
unzip node.zip
./luxd --help
Docker Install
Make sure Docker is installed on the machine - so commands like docker run etc. are available.
Building the Docker image of latest node branch can be done by running:
./scripts/run-task.sh build-image
To check the built image, run:
docker image ls
The image should be tagged as ghcr.io/luxfi/node:xxxxxxxx, where xxxxxxxx is the shortened commit of the Lux source it was built from. To run the Lux node, run:
docker run -ti -p 9630:9630 -p 9631:9631 ghcr.io/luxfi/node:xxxxxxxx /node/build/node
Running Lux
Connecting to Mainnet
To connect to the Lux Mainnet, run:
./build/node
You should see some pretty ASCII art and log messages.
You can use Ctrl+C to kill the node.
Connecting to Testnet
To connect to the Testnet, run:
./build/node --network-id=testnet
Creating a Local Testnet
The lux-cli is the easiest way to start a local network.
lux network start
lux network status
Bootstrapping
A node needs to catch up to the latest network state before it can participate in consensus and serve API calls. This process (called bootstrapping) currently takes several days for a new node connected to Mainnet.
A node will not report healthy until it is done bootstrapping.
Improvements that reduce the amount of time it takes to bootstrap are under development.
The bottleneck during bootstrapping is typically database IO. Using a more powerful CPU or increasing the database IOPS on the computer running a node will decrease the amount of time bootstrapping takes.
Generating Code
Lux Node uses multiple tools to generate efficient and boilerplate code.
Running protobuf codegen
To regenerate the protobuf go code, run scripts/run-task.sh generate-protobuf from the root of the repo.
This should only be necessary when upgrading protobuf versions or modifying .proto definition files.
To use this script, you must have buf (v1.31.0), protoc-gen-go (v1.33.0) and protoc-gen-go-grpc (v1.3.0) installed.
To install the buf dependencies:
go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.33.0
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.3.0
If you have not already, you may need to add $GOPATH/bin to your $PATH:
export PATH="$PATH:$(go env GOPATH)/bin"
If you extract buf to ~/software/buf/bin, the following should work:
export PATH=$PATH:~/software/buf/bin/:~/go/bin
go get google.golang.org/protobuf/cmd/protoc-gen-go
go get google.golang.org/protobuf/cmd/protoc-gen-go-grpc
scripts/run_task.sh generate-protobuf
For more information, refer to the GRPC Golang Quick Start Guide.
Running mock codegen
See the Contributing document autogenerated mocks section.
Versioning
Version Semantics
Lux Node is first and foremost a client for the Lux network. The versioning of Lux Node follows that of the Lux network.
v0.x.xindicates a development network version.v1.x.xindicates a production network version.vx.[Upgrade].xindicates the number of network upgrades that have occurred.vx.x.[Patch]indicates the number of client upgrades that have occurred since the last network upgrade.
Library Compatibility Guarantees
Because Lux Node's version denotes the network version, it is expected that interfaces exported by Lux Node's packages may change in Patch version updates.
API Compatibility Guarantees
APIs exposed when running Lux Node will maintain backwards compatibility, unless the functionality is explicitly deprecated and announced when removed.
Supported Platforms
Lux Node can run on different platforms, with different support tiers:
- Tier 1: Fully supported by the maintainers, guaranteed to pass all tests including e2e and stress tests.
- Tier 2: Passes all unit and integration tests but not necessarily e2e tests.
- Tier 3: Builds but lightly tested (or not), considered experimental.
- Not supported: May not build and not tested, considered unsafe. To be supported in the future.
The following table lists currently supported platforms and their corresponding Lux Node support tiers:
| Architecture | Operating system | Support tier |
|---|---|---|
| amd64 | Linux | 1 |
| arm64 | Linux | 2 |
| amd64 | Darwin | 2 |
| amd64 | Windows | Not supported |
| arm | Linux | Not supported |
| i386 | Linux | Not supported |
| arm64 | Darwin | Not supported |
To officially support a new platform, one must satisfy the following requirements:
| Lux Node continuous integration | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| Build passes | ✓ | ✓ | ✓ |
| Unit and integration tests pass | ✓ | ✓ | |
| End-to-end and stress tests pass | ✓ |
Security Bugs
We and our community welcome responsible disclosures.
Please refer to our Security Policy and Security Advisories.