{"id":18314,"date":"2026-03-15T12:04:00","date_gmt":"2026-03-15T12:04:00","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/03\/15\/validated-staking-on-eth2-4-keys-%f0%9f%94%91\/"},"modified":"2026-03-15T12:04:00","modified_gmt":"2026-03-15T12:04:00","slug":"validated-staking-on-eth2-4-keys-%f0%9f%94%91","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/03\/15\/validated-staking-on-eth2-4-keys-%f0%9f%94%91\/","title":{"rendered":"Validated, staking on eth2: #4 – Keys \ud83d\udd11"},"content":{"rendered":"


\n
<\/p>\n

\n

Special thanks to Sacha Yves Saint-Leger & Danny Ryan for their review.<\/em><\/p>\n

At the core of every Proof of Stake system is a signature scheme. Signatures are used to verify the identity of each validator allowing their actions, both good and bad, to be attributed to them.<\/p>\n

We can verify honesty by looking at a validator’s signed messages and we can prove malice by showing messages that violate the rules of consensus.<\/p>\n

In fact, in eth2, the identity of a validator is<\/em> their public key. Specifically, each validator has two sets of keys: a signing key and a withdrawal key.<\/p>\n

<\/g><\/svg><\/a>Signing keys<\/h2>\n

A signing key<\/em> is the key a validator needs to sign attestations and propose blocks. Because a validator needs to sign a message at least once per epoch, the client software must have custody of the key.<\/p>\n

<\/g><\/svg><\/a>Withdrawal keys<\/h2>\n

Because the client software is always connected to the internet, there is of course a chance that one\u2019s signing key is compromised. To reduce the impact of such a breach, the actions a validator can perform are split between two keys.<\/p>\n

The signing key, as explained above, is used for the validator to perform their duties. On the other hand, the withdrawal key<\/em> has the power to control a validator’s funds (transferring*, and withdrawing* ETH).<\/p>\n

A validator should only need to use their withdrawal keys a few times over the lifetime of being a validator. This means they can be put into cold storage and stored with a high degree of security (offline).<\/p>\n

* Transfers and withdrawals are not enabled until at least phase 1<\/p>\n

<\/g><\/svg><\/a>That’s a lot of keys!<\/h2>\n

If for every 32ETH staked, one needed to save and use 2 unrelated keys to make a deposit, this would get out of hand very quickly.<\/p>\n

Luckily, we have a solution. The remedy is to have the keys use a common secret, so that storing a single secret gives access to multiple keys.<\/p>\n

In eth2, this is achieved via EIPs 2333<\/a> and 2334<\/a>: a set of standards that describe how withdrawal and signing keys are related, and how they can be derived from a single mnemonic.<\/p>\n

<\/g><\/svg><\/a>Mnemonics<\/h3>\n

Mnemonics are another way of encoding secrets and are a much simpler means for people to store and back up their private keys.<\/p>\n

The idea being that it is simpler to remember or write down sausage solution loud isolate focus glide frame door clown million shuffle impulse<\/span> than 0x1e9f2afcc0737f4502e8d4238e4fe82d45077b2a549902b61d65367acecbccba<\/span> without making any mistakes.<\/p>\n

<\/g><\/svg><\/a>Deriving keys from other keys<\/h3>\n

When interacting with wallets, you may have encountered “paths” of the form m\/44’\/60’\/0’\/0\/0<\/span>. These paths describe a relationship between keys.<\/p>\n

According to EIP 2333<\/a>, this relationship takes the form of a tree structure in which a key is determined by a source of entropy (the tree\u2019s seed) and a tree path.<\/p>\n

We use the seed to calculate the root of the tree and then build the tree in layers on top of this root. This tree of keys is defined purely through the relationship between the branch followed in the tree, and the tree’s root.<\/p>\n

In practical terms, it allows us to find any key in the tree by starting at the root, and calculating the intermediate key at each branch we follow, until we reach the leaf we are interested in.<\/p>\n

A wonderful consequence of this is that we can start with a single source of entropy (a mnemonic, for example), and from there build out a practically unlimited number of keys.<\/p>\n

In addition, by securely storing just the mnemonic, you have a backup of every key that your validator uses.<\/p>\n

This idea is used in eth2 to allow a single mnemonic to generate as many keys as a validator needs. For example, if you wanted to run 3 validators, you could use a single mnemonic to generate the withdrawal keys located at
\nm\/0<\/span>,
\nm\/1<\/span>,
\nm\/2<\/span>.<\/p>\n

\n
      [m \/ 0]\n<\/span>     \/\n    \/\n[m] - [m \/ 1]\n    \\\n     \\\n      [m \/ 2]\n<\/code><\/pre>\n<\/div>\n
Each branch is separated by a \/<\/span> so m\/2<\/span> means start with the master key and follow branch 2.<\/p>\n
EIP 2334<\/a> states that the validator’s signing key is the 0<\/span>th child-branch of the withdrawal key. In practice this means that, when the standard is followed, if you know the private key for withdrawal, you can calculate the corresponding private key for signing.<\/p>\n
Continuing with the above example, the signing keys would be found at:
\nm\/0\/0<\/span>,
\nm\/1\/0<\/span>,
\nm\/2\/0<\/span>.<\/p>\n
\n
      [m \/ 0] - [m \/ 0 \/ 0]\n<\/span>     \/\n    \/\n[m] - [m \/ 1] - [m \/ 1 \/ 0]\n    \\\n     \\\n      [m \/ 2] - [m \/ 2 \/ 0]\n<\/code><\/pre>\n<\/div>\n
While we tried to keep this example as simple as possible, in practice the paths involved are a little longer (EIP 2334<\/a> requires using m\/12381\/3600\/i\/0<\/span>, and m\/12381\/3600\/i\/0\/0<\/span> for withdrawal and signing keys respectively). Nevertheless, the logic remains the same.<\/p>\n
The important thing to remember is that if you know the mnemonic, you can calculate your withdrawal keys, and from there derive your signing keys.<\/p>\n
<\/g><\/svg><\/a>Storing keys<\/h2>\n
Validator clients use keystores as a method for exchanging keys.<\/p>\n
Keystores<\/em> are files that contain private keys encrypted with a user’s password. They can be safely stored and transferred between computers provided the password is not stored on the same computer.<\/p>\n
When you are ready to start validating, you can give your client the keystores and the password encrypting them (it needs both pieces of information to import your keys).<\/p>\n
<\/g><\/svg><\/a>Becoming a validator<\/h2>\n
The first step in becoming a validator is to generate the appropriate keys. These will be generated once you’ve written down your mnemonic.<\/p>\n
Since there are no withdrawals or transfers in phase 0, you do not need to have keystores for your withdrawal keys; storing your mnemonic safely is sufficient.<\/p>\n
As your validator clients need your signing keys, you will receive a keystore for each of your validators to store these keys.<\/p>\n
Now it’s deposit time! To become a validator, you will need to send 32 ETH per validator in addition to your deposit data<\/em> containing all of your validator public keys.<\/p>\n
The deposit data are then recorded in the deposit contract on eth1. This contract is watched by eth2 nodes who are responsible for copying over the deposit data. Once your deposit data has been copied over, you are now officially a validator!<\/p>\n
<\/g><\/svg><\/a>Becoming a validator the easy way<\/h2>\n
We’re happy to announce that we’ve been working hard on a friendly interface to walk validators through this process. Stay posted for an update shortly on what the Eth2 Launchpad is and how to use it!<\/p>\n<\/div>\n

\n
Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Special thanks to Sacha Yves Saint-Leger & Danny Ryan for their review. At the core of every Proof of Stake system is a signature scheme. Signatures are used to verify the identity of each validator allowing their actions, both good and bad, to be attributed to them. We can verify honesty by looking at a […]<\/p>\n","protected":false},"author":6,"featured_media":18273,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"tdm_status":"","tdm_grid_status":"","footnotes":""},"categories":[24],"tags":[],"kronos_expire_date":[],"class_list":["post-18314","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ethereum"],"_links":{"self":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/18314","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/comments?post=18314"}],"version-history":[{"count":0,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/posts\/18314\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/media\/18273"}],"wp:attachment":[{"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/media?parent=18314"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/categories?post=18314"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/tags?post=18314"},{"taxonomy":"kronos_expire_date","embeddable":true,"href":"https:\/\/cryptoted.net\/index.php\/wp-json\/wp\/v2\/kronos_expire_date?post=18314"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}