xrpl-dev-portal
xrpl-dev-portal copied to clipboard
Concept article: validator tokens
basically, validator "manifests" is the internal name of a feature (initially introduced in 0.32 or so and iterated since) where you can define your validator based on a set of master keys and then delegate the day-to-day signing authority to an ephemeral token. Outside of the rippled source and release notes, we haven't really used the term "manifests" since it's very confusing.
By using manifests & tokens, you can keep your master keys offline where they're safe during day-to-day validation. If the token gets compromised or needs to be replaced (for example, a sysadmin with access to your rippled config file quits), you can rotate the old token without anyone else needing to take action, as long as they trust your master key. (Of course, if your master key gets compromised, then everyone who trusts you / lists you in your UNL needs to take action to update; that's the same as without tokens, but it's less likely to happen with tokens because you can keep your master key offline.)

New validators are already instructed to set up using tokens using the validator keys tool ( https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md ), but it doesn't really describe the keys and tokens themselves.
Acceptance criteria:
- A document explaining what validator tokens are:
- why they exist
- how they're different from the "old" (still usable, but not recommended) system of having a validator private key in your config file
- preferably including a diagram of the difference
- link to/from the relevant documentation how to set up a validator and how to use the validator keys tool to generate a token