mirror of
https://github.com/luxfi/node.git
synced 2026-07-27 03:39:39 +00:00
TestCurrentRPCChainVMCompatible has been red since v1.36.11: every release since then bumped defaultPatch without registering the version against RPCChainVMProtocol 42, so version.Current was absent from its own compatibility set. Protocol 42 has not moved across that range — the list was simply never updated. Backfilled through v1.36.31 (v1.36.29 omitted: that tag was pushed off a pre-rebase commit and deleted, it is not a release). v1.36.30 carries the health fix but was tagged before this backfill, so its tree still fails ./version. v1.36.31 is the green tag and the rollout target. Co-authored-by: Hanzo Dev <dev@hanzo.ai>
8.7 KiB
8.7 KiB
Changelog
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.
[1.36.31]
Fixed
/v1/healthreported a chain the node denies exists. Thebootstrappedcheck publisheschains.Nets.Bootstrapping()verbatim as its message, butNets.chainsis keyed by net ID and the aggregate appended the map key, not the chain. Every primary-network chain that failed to converge therefore surfaced as the single ID11111111111111111111111111111111LpoYY—constants.PrimaryNetworkID(ids.Empty) — so an operator resolving it got "there is no chain with alias/ID", and N stuck chains collapsed into one indistinguishable entry (measured on devnet/testnet:"message":["11111111111111111111111111111111LpoYY"],"contiguousFailures":3213). The net owns the bootstrapping set, so the net now names its own chains: newnets.Net.Bootstrapping() []ids.ID(nets/net.go), andchains/chains.goaggregates those instead of the keys.TestNetsBootstrappingReportsChainsNotNetsassertsids.Emptynever appears and that two stuck chains are individually named;TestNetsBootstrappingno longer asserts the bug (it demanded the net ID).- Ships the GET
/v1/healthencoder fix fromdada5a31({"healthy":…,"error":"health reply encode failed"}on every node — jsonv2 has no representation forapihealth.Result.Duration), which was onmainbut had never been tagged.
[1.36.13]
Fixed
- The durable rejoin fix (#66/#74) shipped INERT for the C-Chain — the exact chain whose 40h mainnet freeze motivated it.
chains/manager.gogatedexpectsStakedBeaconsonids.IsNativeChain(chainParams.ID)— the blockchain ID. Butids.IsNativeChainonly matches the symbolic111…Calias form, and every deployed C/X/Q carries a hash blockchain ID (devnet C21HieZng…, mainnet C2wRdZG…); only the P-chain has a symbolic blockchain ID (111…P), and it is excluded as the platform chain. SoisNativeChainwas always false for the real C-Chain →expectsStakedBeacons=false→ under the production--skip-bootstrap=truethe beacon set was emptied → a behind C-Chain named its STALE local tip the frontier and never caught up (verified on devnet v1.36.12: C-Chain wedged at height 0 with "using empty beacons for single-node mode"). Fix: discriminate on the validating Net (chainParams.ChainID == constants.PrimaryNetworkID) via newchainValidatesOnPrimaryNetwork, which isPrimaryNetworkIDfor C/X/Q and each sovereign L1's own net ID for an L2 — so C/X/Q now keep their staked beacons under--skip-bootstrap(peer-sync a behind validator) while L2s keep the empty-beacon single-node path. Regression testTestChainValidatesOnPrimaryNetwork_RealHashChainIDexercises the real discriminator with hash chain IDs (the prior hardcoded-bool tests could not catch this);TestRED_EmptyStakedSetFailsSafestill passes (forged-frontier gate intact).
[1.36.12]
Fixed
- EVM chains (C/D/L2) failed to initialize on v1.36.11 — bundled VM plugins were built against a stale
luxfi/api. The node pinsluxfi/api v1.0.16, whoseInitializeResponsecarries the appendedCapabilities uint64field (Quasar-export handshake, api commit1f2dc5a). The image baked the C-Chain EVM plugin fromluxfi/evm@v1.104.8and the D-Chain dexvm plugin fromluxfi/dex@v1.5.15, both of which resolveluxfi/api v1.0.15(noCapabilities). TheirInitializeResponse.Encodewrites a shorter payload than the node's strictInitializeResponse.Decodeexpects, sovms/rpcchainvm/zap/client.gofails every EVM VM handshake withzap decode initialize response: unexpected EOF. Native VMs (P/X/Q) were unaffected. Fix: bumpEVM_VERSIONv1.104.8 → v1.104.9(api v1.0.16) and forceluxfi/api@v1.0.16in the dexvm build stage. The api bump is code-free for plugins (luxfi/chains v1.7.4 → v1.7.5adopted it with a go.mod-only diff;CHAINS_REF=v1.7.6already carries v1.0.16). No node source change beyond the version bump — this is v1.36.11's node binary (durable rejoin fix, commit63f61429d1) rebuilt with plugin↔node ZAP-wire alignment.
[1.28.0]
Added
- Multi-version P-Chain block + tx codec. v1.23.x ("Apricot/Banff") wire layout is now registered as
CodecVersionV0on the platformvm tx and blockcodec.Managers; the current canonical layout isCodecVersionV1. Bytes carry their wire version in the standard 2-byte codec prefix andtxs.Parse/block.Parsedispatch by it. - Byte-preserving tx Initialization:
tx.InitializeFromBytes(c, version, signedBytes)andtx.InitializeFromBytesAtVersion(c, version)bind a tx to its originalsignedByteswithout re-marshalling.TxID = hash(signedBytes)is therefore stable across the v0->v1 migration — mainnet and testnet chain commitments hash back to byte-identical inputs. vms/platformvm/block/v0/subpackage holding the pure-data v0 block kinds (ApricotProposalBlock,BanffProposalBlock, ... — 9 types, slots 0-4 + 29-32). The package is a one-way decoder only; theliftedV0Blockadapter in the parent package translates each v0 block kind into the corresponding canonical v1Visitorarm without ever re-marshalling.- Cross-version tx + block tests:
TestCodecVersionV0V1Coexist,TestParseDispatchesByVersion,TestTxIDStabilityRoundTrip,TestCrossVersionRefuses,TestParseV0ApricotProposalBlock,TestParseV0BanffStandardBlock,TestParseV1RoundTrip,TestVersionPrefixDispatch.
Changed
tx.Initialize(c)is retained for the fresh-build path only (wallet, builder). The from-DB / from-wire paths ingenesis/genesis.goandblock/{standard,proposal}_block.gonow go throughInitializeFromBytesAtVersionagainst the codec version the surrounding container was decoded under.genesis.Parseis wire-version-aware: pre-codec-v1 P-Chain genesis blobs on mainnet / testnet decode atCodecVersionV0; new blobs are written atCodecVersionV1.- The L1-tx slot map advances by one to accommodate
CreateSovereignL1Txat slot 36:RegisterL1ValidatorTx=37,SetL1ValidatorWeightTx=38,IncreaseL1ValidatorBalanceTx=39,DisableL1ValidatorTx=40 (was 36-39). Both pre-rip mainnet/testnet bytes (no slot conflict; L1 txs did not exist) and current code paths line up with the new slot map. - Test fixtures in
vms/platformvm/txs/fee/calculator_test.goand the serialization tests undervms/platformvm/txs/*_test.goare regenerated to use the v1 wire prefix (0x0001) and the post-CreateSovereignL1Txslot map.
Migration notes
- Mainnet + testnet P-Chain DBs do NOT need to be rebuilt: pre-codec-v1 blocks continue to decode via the v0 path with their original
BlockID = hash(v0 bytes)preserved. Newly accepted blocks are written at v1. - Devnet, which was bootstrapped post-rip at wire-version 0 but with the post-rip slot map, must be rebuilt before rolling to
v1.28.0: its existing blobs would now decode against the v0 slot map (the pre-rip layout) and produce wrong types. A fresh bootstrap atv1.28.0writes v1 bytes from height 0 and is internally consistent thereafter.
[1.13.5-alpha] - 2025-01-23
Added
- L1 (Layer 1) validator support with complete transaction types:
ConvertNetToL1Tx- Convert existing chains to L1RegisterL1ValidatorTx- Register new L1 validatorsSetL1ValidatorWeightTx- Adjust validator weightsIncreaseL1ValidatorBalanceTx- Increase validator balanceDisableL1ValidatorTx- Disable validators
- LP-118 protocol implementation for warp message handling:
- Signature aggregation support
- BLS signature verification
- Cached handler for performance optimization
- Handler adapter for P2P integration
- Complete wallet support for L1 validator operations
- Extended AppSender interface for cross-chain messaging
Fixed
- P2P test package compatibility issues
- Set package import conflicts (math/set vs utils/set vs consensus/utils/set)
- Interface compatibility between consensus and local packages
- Handler function signatures for proper interface implementation
- Mock testing with gomock package updates
- BLS signature handling in tests
- AppError type conversions between packages
- All wallet examples now compile and run correctly
Changed
- Updated import paths to use luxfi packages consistently
- Improved error handling in P2P message handlers
- Enhanced test coverage for LP-118 protocol
- Standardized AppError usage across packages
Technical Details
- 100% of internal packages (351 packages) now build successfully
- All tests pass in modified packages
- Full CI/CD pipeline configured with GitHub Actions
- Compatible with Go 1.21.12+
[1.13.4] - Previous Release
[Previous release notes...]