BetterSign™

The Problem: A Validator That Can Never Change Its Key

On most chains a validator’s identity is its public key, and its peer-to-peer networking identity is usually a public key too — many validators use libp2p, for example. Both consensus and networking key off that single value, so the moment a node is registered, its key — and the algorithm behind it — is effectively frozen for life.

Rotating that key means re-coordinating every peer and the chain at the same time. It is so painful that in practice it is almost never done, which leaves long-lived, high-value keys sitting in place far longer than any security team would choose. And when a stronger or post-quantum algorithm arrives, there is no smooth path to adopt it.

BetterSign breaks the identity away from the key. The durable identity becomes a VLAD; the consensus signing key and the libp2p communication key become current state that hangs beneath it and can change routinely.

Bootstrapping the Initial Validator Set

The initial validators each create a VLAD in BetterSign as their durable identity, then place a consensus signing key and a libp2p communication key underneath it as current state. The VLAD is who the validator is; the keys are what it currently uses.

They come online and form the initial active set. Because every key is addressed through the VLAD and recorded in a provenance log, later changes are signed transitions the rest of the set can verify — not disconnected new identities that have to be trusted from scratch.

Watch the whole lifecycle end to end — bootstrap set, on-chain config, independent rotation, and a new validator joining — in the blockchain validator identity demo.

Materializing the Config On Chain

The active set runs BFT consensus and votes the configuration onto the chain: every validator’s VLAD, its current public keys, and its algorithms. The bootstrap configuration a newcomer needs to join is committed on chain as well.

This is not extra exposure. Validator sets and their keys end up on chain and public anyway — that is how the network agrees on who is voting. BetterSign’s contribution is that each transition to that public state is a signed, verifiable lifecycle event authorized by the previous state, and the acceptance of it is tightly controlled by the active set’s vote.

Followers and clients can therefore derive the current validator set from verified state rather than trusting whatever keys happen to be served to them.

Rotating Keys Independently — and Swapping Algorithms

Because the VLAD is the identity, keys become disposable. A validator can rotate its libp2p communication key and its consensus signing key on separate cadences without disrupting its place in the set.

Each rotation is a signed entry in the validator’s provenance log, announced to peers through BetterSign, and accepted onto the chain after a BFT vote. Other validators discover the change through the same mechanism they already use to agree on everything else, so there is no separate key-distribution dance.

The cryptography is pluggable. A validator can upgrade a key to a stronger or post-quantum algorithm — the kind of migration that is nearly impossible when identity equals key — while keeping the exact same VLAD identity. Rotation, the thing validators dread, becomes routine.

Fixing Peer-to-Peer Identity

BetterSign does not require any particular peer-to-peer transport. Validators talk to each other over some networking layer, and the same trap tends to appear there whenever the peer identity is derived directly from a public key: change the key and you change the peer ID, so the key gets frozen.

libp2p is common enough that it is the example used throughout this page, but it is not a requirement. Anchoring whichever key the transport uses to a VLAD makes the networking identity pluggable and upgradable in exactly the same way as the consensus identity — peers follow the VLAD, verify the current comms key from provenance-log state, and keep a stable notion of the peer across rotations.

Joining the Set with Config-Pull

Once the bootstrap validators are online, onboarding a new validator is a single config-pull. The newcomer pulls the configuration from any existing validator instead of being hand-configured.

The configuration itself is read from the on-chain set that the active validators voted on, so it is authoritative. Trust, though, flows from the specific active validator the newcomer followed and verified — the config is pulled from the chain, but the active validator is the party that is followed and trusted. The newcomer verifies the provenance log, syncs state, and requests admission.

When the active set votes it in, it becomes part of the active set — with its own VLAD, its own rotatable keys, and no frozen identity to inherit.

Config-pull is the same joining mechanism BetterSign uses for peers generally — see how config-pull works on its own page.