Key management for validators
- Author
- CRYPTO PORT Editorial
- Published
- Updated
- Reading time
- 6 min
In short
Key management for validators means separating the signing key, which must stay online, from the key that withdraws the stake, and protecting each accordingly. The signing key has to live on a server; the withdrawal key does not. Skip that separation and a server breach becomes a loss of assets.
Key points
- Separate the signing key from the withdrawal key
- Assume the always-online signing key can be compromised
- The withdrawal key can and should stay offline
- Carrying over signing history is mandatory when migrating
Definition
The operational design that separates a validator's keys by purpose and exposure, and defines procedures for storing, using and migrating them.
A validator handles at least two kinds of key. One signs assigned proposals and attestations and must sit on the node at all times. The other controls unstaking and the withdrawal destination, and is not needed day to day.
Since the signing key lives on a server, treat compromise as a live possibility. If only the signing key is stolen, however, the attacker can at most provoke slashing through conflicting signatures — they cannot walk off with the assets. The damage is bounded.
A leaked withdrawal key is a different matter, because the destination of the stake can be rewritten. Keep it on a hardware wallet or in an offline environment and use it only when needed. Some chains, Ethereum among them, make the withdrawal address unchangeable once set.
When migrating or recovering, always carry over the record of previously signed heights. Starting without it risks signing again for something already signed. Restoring an old environment from backup carries exactly the same hazard.
Watch out for
- · Keeping both keys on one server means a single breach loses the stake
- · Restarting without the signing history invites slashing for double signing
- · On chains where the withdrawal address is immutable, a mistake at setup is permanent