zeekay
7cf87b230b
The module already called itself github.com/luxfi/node while containing no node in Go: cmd/luxd was twenty-one lines that printed the size of a few types, and the Go column of the matrix measured a VM plugin. A repo that fetches the thing it claims to be has not replaced it, so the Go sources move in — 1515 files, the daemon and everything under it — and the build reaches outside this module for nothing. Rust and C++ sit beside it unchanged and are still measured against it by the differential. That is the point of one repo: the reference implementation and the two ports are the same checkout, so parity is a thing you can run rather than a thing you assert. Verified: builds, and the closure carries no lux-private — checked at build time rather than believed. The daemon starts twelve chains on a local network (P X C Q Z A B G K M F, plus D through its plugin) and reports healthy.
1.6 KiB
Chain time update mechanism
The P-Chain tracks ChainTime as the network-agreed timestamp used to
score staker activity for rewards. This document describes how blocks
advance ChainTime on Lux. The legacy pre-upgrade gate is always active
on Lux; only the modern model is documented here.
About ChainTime
The P-Chain records staking periods for every staker (validator or delegator) on every net so that rewards can be computed at end-of-staking.
ChainTime is the network-agreed timestamp used to decide when a staker
started and stopped staking. It is the basic input to the per-staker
uptime fraction that decides whether a reward is paid.
Note: ChainTime is unrelated to the Linear++ timestamp. Linear++
timestamps are local times used to reduce network congestion and play no
role in staker rewards.
How blocks advance ChainTime
AdvanceTimeTx transactions are not used. Every P-Chain block explicitly
serialises a timestamp; on acceptance, ChainTime is set to that
timestamp.
Validation rules vary slightly by block type:
CommitBlockandAbortBlocktimestamps must equal the timestamp of theProposalBlockthey depend upon.StandardBlockandProposalBlocktimestamps obey:- Monotonicity — block timestamp must be greater than or equal to
the current
ChainTime(which is also the parent's timestamp if the parent was accepted). - Synchronicity — block timestamp must not exceed the node's local clock plus a 10-second synchrony bound.
- No skipping — block timestamp must not exceed the next staker start- or stop-event time.
- Monotonicity — block timestamp must be greater than or equal to
the current