mirror of
https://github.com/luxfi/chains.git
synced 2026-09-24 00:26:00 +00:00
zeekayandHanzo Dev
d87600fbef
ParseBlock demanded a field the wire has no room for. The block format is timestamp, height, parentID, tx lengths, tx blob; the stamp lived only on the object the builder made and was gone the moment the block was serialized, which is every time it leaves the process. So the gate refused every block that ever crossed the wire, genesis included, and Q-Chain accepted nothing on any network for as long as it ran -- certAccepted=0, appliedHead=0, everywhere. The two doors into the format disagreed, which is what made it a loop rather than a stall. A responder answers a catch-up request through vm.parseBlock, which has no gate and succeeds; the requester admits the reply through VM.ParseBlock, which had the gate and failed. Same bytes, two verdicts: every node served the block every node refused. Putting the stamp on the wire would be worse than leaving it off. The block id is sha256 of its own bytes, so a stamp in those bytes makes the id depend on who signed, and two honest nodes compute two ids for one block. seedGenesis already refuses wall-clock time for exactly this reason. The stamp could not have been load-bearing anyway: it was made with a key generated fresh for each block, and a signature that ships its own throwaway public key states nothing an attacker cannot also state. Its thirty-second validity window is also the opposite of what catch-up needs, which is to serve blocks from hours ago. A block-level signature belongs to consensus, where it already is: a cert is a quorum's statement about a block, checkable by anyone holding the validator set, and it is not a field on the block. Quasar still signs there. Transaction-level quantum signatures are untouched -- those are serialized, and they are verified. The tests stayed green throughout because none of them sent a block through Bytes() and back. Three do now: parse what we serialize, parse GENESIS, and the two parse paths reach the same verdict on identical bytes. Restoring the gate fails all three. Co-authored-by: Hanzo Dev <[email protected]>
Lux Chains
Independent VM plugin binaries for the Lux Network.
Each directory builds to a standalone binary that the Lux node loads as a plugin via --plugin-dir.
Build
make # build all VMs
make evm # build one VM
make test # test all
Install
lpm install evm
lpm install dexvm
Or copy binaries to ~/.lux/plugins/<vmid>.
VMs
One row per directory in this repo. make derives its target list from the
directory listing, so a VM that has no directory here has no binary — the table
below and ls can never disagree.
Live means the VM has a chain registered on Lux mainnet 96369
(platform.getBlockchains).
| VM | Chain | Live on 96369 | Purpose |
|---|---|---|---|
| evm | C-Chain | ✅ | EVM smart contracts |
| dexvm | D-Chain | ✅ | Decentralized exchange |
| aivm | A-Chain | ✅ | AI/ML inference |
| bridgevm | B-Chain | ✅ | Cross-chain bridge — also owns all cross-chain messaging / relay / teleport (LP-6000); there is no separate teleportvm |
| graphvm | G-Chain | ✅ | GraphQL data layer |
| keyvm | K-Chain | ✅ | Key management |
| quantumvm | Q-Chain | ✅ | Post-quantum consensus signing (Pulsar) |
| zkvm | Z-Chain | ✅ | Groth16 over BLS12-381 (rolls N × ML-DSA-65 sigs into 192-byte proof) |
| identityvm | I-Chain | ❌ built, not deployed | Decentralized identity |
| oraclevm | O-Chain | ❌ built, not deployed | Oracle/off-chain data |
| relayvm | R-Chain | ❌ built, not deployed | Cross-chain relay |
| mpcvm | M-Chain | ❌ built, not deployed | MPC ceremonies (CGGMP21, FROST, Pulsar-general) — bridge custody for external wallets (LP-7100) |
| schain | S-Chain | ❌ built, not deployed | S3-style object storage (on-chain metadata / off-chain blob). Declares its own VMID = ids.ID{'s','c','h','a','i','n'} in schain/factory.go and is not in the canonical luxfi/constants VM-ID registry |
P-Chain (platformvm) and X-Chain (xvm) are in-process core VMs registered by
luxfi/node, not plugins built here. Together with the eight ✅ rows above they
are the ten chains live on 96369.
Not in this repo
| Name | Status |
|---|---|
teleportvm / T-Chain |
Removed. LP-134 dissolves T-Chain with zero remainder: threshold signing → M-Chain, FHE → F-Chain, cross-chain messaging/teleport → B-Chain (bridgevm). LP-5013 and LP-7330 are deprecated by LP-134; see LP-7050 for the migration map. No teleportvm VM ID exists in luxfi/constants. |
servicenodevm |
Never existed. The service-node registry was never built under this name; the S-Chain directory here is schain/ and is object storage, not a registry. |
fhevm / F-Chain |
Unbuilt. luxfi/constants reserves FHEVMID = {'f','h','e','v','m'} and luxfi/node/node/vms.go lists it in OptionalVMs as a plugin named fhevm, so luxd will scan --plugin-dir for it — but there is no fhevm/ directory in this repo and no plugin binary anywhere, so that scan always comes up empty. The FHE runtime library lives at mpcvm/fhe/; it is a package inside mpcvm, not a standalone chain. F-Chain is a spec (LP-8200, LP-167) with no shipping VM. |