A standard for allocating keys generated by ERC-2333 to a specific purpose. It defines a path which is a string that parses into the indices to be used when traversing the tree of keys that ERC-2333 generates.
The Beacon chain uses BLS signatures over BLS12-381. This new scheme requires a new key derivation mechanism, which is established within ERC-2333. This new scheme is incompatible with BIP44 due to the exclusive use of hardened keys, the increased number of keys per level, not using BIP32 for key derivation. It is therefore necessary to establish a new path for traversing the ERC-2333 key-tree.
The path structure specified in this ERC aims to be more general than BIP44 by not having UTXO-centric features which gave rise to the 4 different types of wallet paths being used within Ethereum in the past and gave rise to (draft) ERC-600 & ERC-601
The path traversed through the tree of keys is defined by integers (which indicate the sibling index) separated by / which denote ancestor relations. There are 4 levels (plus the master node) in the path and at least 4 (5 including the master node) MUST be used.
The notation used within the path is specified within the ERC-2333, but is summarized again below for convenience.
m Denotes the master node (or root) of the tree/ Separates the tree into depths, thus i / j signifies that j is a child of iThe purpose is set to 12381 which is the name of the new curve (BLS12-381). In order to be in compliance with this standard, the ERC-2333 MUST be implemented as the KDF and therefore, the purpose 12381 MAY NOT be used unless this is the case.
The coin_type here reflects the coin number for an individual coin thereby acting as a means of separating the keys used for different chains.
account is a field that provides the ability for a user to have distinct sets of keys for different purposes, if they so choose. This is the level at which different accounts for a single user SHOULD to be implemented.
This level is designed to provide a set of related keys that can be used for any purpose. The idea being that a single account has many uses which are related yet should remain separate for security reasons. It is required to support this level in the tree, although, for many purposes it will remain 0.
The coin type used for the BLS12-381 keys in Ethereum is 3600.
Each Beacon chain validator has two keys, one for withdrawals and transfers (called the withdrawal key), and the other for performing their duties as a validator (henceforth referred to as the signing key).
The path for withdrawal keys is m/12381/3600/i/0 where i indicates the ith set of validator keys.
The path for the signing key is m/12381/3600/i/0/0 where again, i indicates the ith set of validator keys. Another way of phrasing this is that the signing key is the 0th child of the associated withdrawal key for that validator.
Note: If the above description of key paths is not feasible in a specific use case (eg. with secret-shared or custodial validators), then the affected keys may be omitted and derived via another means. Implementations of this ERC, must endeavour to use the appropriate keys for the given use case to the extent that is reasonably possible. (eg, in the case of custodial staking, the user making the deposits will follow this standard for their withdrawal keys which has no bearing on how the service provide derives the corresponding signing keys.)
purpose, coin_type, and account are widely-adopted terms as per BIP43 and BIP44 and therefore reusing these terms and their associated meanings makes sense.
The purpose needs to be distinct from these standards as the KDF and path are not inter-compatible and 12381 is an obvious choice.
account separates user activity into distinct categories thereby allowing users to separate their concerns however they desire.
use will commonly be determined at the application level providing distinct keys for non-intersecting use cases.
A new coin type is chosen for Beacon Chain BLS keys to help ensure a clean separation between BLS12-381 and secp256k1 keys. 3600 is chosen specifically because it is the square of the Ethereum's secp256k1 coin_type (3600==60^2).
The primary reason validators have separate signing and withdrawal keys is to allow for the different security concerns of actions within the Beacon Chain. The signing key is given to the validator client where it signs messages as per the requirements of being a validator, it is therefore a "hot key". If this key is compromised, the worst that can happen (locally) is that a slashable message is signed, resulting in the validator being slashed and forcibly exited. The withdrawal key is only needed when a validator wishes to perform an action not related to validating and has access to the full funds at stake for that validator. The withdrawal key therefore has higher security concerns and should be handled as a "cold key". By having the signing key be a child of the withdrawal key, secure storage of the withdrawal key is sufficient to recover the signing key should the need arise.
BIP43 and BIP44. Due to the use of a new KDF within ERC-2333, a new path standard is required. This ERC implements this, with minor changes.
purpose 12381 paths do not support hardened keys and therefore the ' character is invalid.
None.
Copyright and related rights waived via CC0.