BBetterSign· Rotatable identity for blockchain validators
1 / 5
A validator's identity is its public key — consensus and its peer-to-peer transport both key off it
🛡️
validator node
peerID = 0xPUBKEY
frozen to one key + algorithm
──▶ consensus · libp2p
🌐
every other peer
knows the node only by that key
Rotating a validator key means re-coordinating every peer and the chain at once — so painful it is basically never done. The key, and the algorithm behind it, are frozen for the life of the node.
The bootstrap validators each create a VLAD in BetterSign — a durable identity keys hang beneath
The VLAD is the identity; the consensus signing key and the libp2p comms key live under it as current state — either can change later without changing who the validator is.
The active set runs BFT consensus and votes the configuration onto the chain
⛓ on-chain validator set · committed by BFT vote of the active set
─ VLAD_A → sign: ml-dsa-65 · comms: /libp2p key · algo set
─ VLAD_B → sign: ed25519 · comms: /libp2p key · algo set genesis / bootstrap config also committed on chain — the newcomer recipe
Every validator's VLAD, current public keys, and algorithms are written on chain by vote — shared, public, and tightly controlled by the active set. It ends up on chain anyway, so BetterSign just makes the transitions verifiable.
Keys rotate independently — announced to peers via BetterSign, accepted by BFT vote
📡 rotate comms key
peer-to-peer · e.g. libp2p
① new key → signed plog entry ② announced to peers via BetterSign ③ chain accepts after BFT vote
↻ on its own cadence
✍️ rotate / upgrade signing key
consensus · pluggable algorithm
① new key — or new algorithm (PQ) ② signed plog entry → peers ③ chain records the change
↻ on its own cadence
The VLAD never changes, so rotation is finally painless. Crypto is pluggable — a validator can move to a stronger or post-quantum algorithm without a new identity.
A new validator joins with a single config-pull — config from chain, trust from the active validator it followed
🆕
joining validator
has nothing yet
config-pull ──▶
🛡️
any active validator
followed & trusted
reads ──▶
⛓
on-chain config
voted by the active set
bs config pull <ACTIVE_VALIDATOR_VLAD>
→ config read from the on-chain set (voted by the active set)
→ follow + trust the active validator you pulled from
→ verify plog, sync state, request admission ✓ voted in by the active set — now part of the active set
The config comes from the chain; trust flows from the active validator it followed. Once the set votes it in, the newcomer becomes part of the active set.