To use Web3Signer, you can-but shouldn't!-give it access to your raw, unencrypted keys. Many security-conscious stakers rely on remote signing software like Web3Signer, which manages keys and signs transactions. And, of course, the validator still holds unencrypted keys in memory when it's running (which, if all goes well, is all the time). That might be OK, except that by default the password is also stored in a file, usually in a neighboring subdirectory. So how do stakers protect their validator keys today? Some configure their local validator client (e.g., Lighthouse or Prysm) to use encrypted keys stored in a password-protected "keystore" file. To take advantage of slashing, an attacker might, for example, steal validator keys and hold them ransom or use them to topple a rival staking service. Such violations result in "slashing"-a forced exit from the network with a penalty of one ETH _and (often) up_ (the penalty calculation accounts for many factors). Unfortunately, validator keys' availability requirements are at odds with their security requirements: if an attacker compromises a validator key, they can use it to sign messages that violate the rules of the consensus protocol. On Ethereum, for example, staking validators sign attestations about every six minutes pulling keys in and out of ledgers, 24/7, at couple-minute increments is a job that no one wants. # Why you should secure your validator keysīut this best practice falls apart during "staking," participating in a blockchain's proof-of-stake protocol. You _know_ not to keep valuable secrets in memory, where an attacker can easily steal them. You probably keep the serious keys-the keys that control 4 or 64 or 164 ETH-in cold storage.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |