EIP2334 - BLS12-381 Deterministic Account Hierarchy
# Simple Summary
This EIP defines the purpose of a given key, or family thereof, within a tree of keys. When combined with EIP-2333, the combination of a seed and knowledge of the desired purpose of a key is sufficient to determine a key pair.
# Abstract
A standard for allocating keys generated by EIP-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 EIP-2333 generates.
# A note on purpose
This specification is designed not only to be an Ethereum 2.0 standard, but one that is adopted by the wider community who have adopted BLS signatures over BLS12-381 (opens new window).. It is therefore important also to consider the needs of the wider industry along with those specific to Ethereum. As a part of these considerations, it is the intention of the author that this standard eventually migrate to a more neutral repository in the future.
# Motivation
Ethereum 2.0 alongside many other projects will use BLS signatures over BLS12-381, an (https://datatracker.ietf.org/doc/draft-irtf-cfrg-bls-signature/)[IETF proposed standard]. This new scheme requires a new key derivation mechanism, which is established within EIP-2333. This new scheme is incompatible with the current form of this specification (BIP44 (opens new window)) due to the: exclusive use of hardened keys, the increased number of keys per level, not using BIP32 (opens new window) for key derivation. It is therefore necessary to establish a new path for traversing the EIP-2333 key-tree.
The path structure specified in this EIP aims to be more general than BIP44 (opens new window) by not having UTXO-centric features which gave rise to the 4 different types of wallet paths being used within Ethereum 1.0 (opens new window) and gave rise to (draft) EIP-600 & EIP-601
# Specification
# Path
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.
m / purpose / coin_type / account / use
# Notation
The notation used within the path is specified within the EIP-2333, but is summarized again below for convenience.
mDenotes the master node (or root) of the tree/Separates the tree into depths, thusi / jsignifies thatjis a child ofi
# Purpose
The 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 EIP-2333 MUST be implemented as the KDF and therefore, the purpose 12381 MAY NOT be used unless this is the case.
# Coin Type
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
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.
# Use
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.
# Eth2 Specific Parameters
# Coin type
The coin type used for the BLS12-381 keys in Ethereum 2 is 3600.
# Validator keys
Each Eth2 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 EIP, 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.)
# Rationale
purpose, coin_type, and account are widely-adopted terms as per BIP43 (opens new window) and BIP44 (opens new window) 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.
# Eth2 Specific Parameters
A new coin type is chosen for Eth2 keys to help ensure a clean separation between Eth2 and Eth1 keys. Although the distinction between Eth1 ETH and Eth2 ETH is subtle, they are distinct entities and there are services which only distinguish between coins by their coin name (eg. ENS' multichain address resolution). 3600 is chosen specifically because it is the square of the Eth1's coin_type (3600==60^2) thereby signaling that it is second instantiation of Ether the currency.
The primary reason validators have separate signing and withdrawal keys is to allow for the different security concerns of actions within Eth2. 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.
# Backwards Compatibility
BIP43 (opens new window) and BIP44 (opens new window) are the commonly used standards for this purpose within Ethereum 1.0, however they have not been Accepted as standards as yet. Due to the use of a new KDF within EIP-2333, a new path standard is required. This EIP implements this, with minor changes.
purpose 12381 paths do not support hardened keys and therefore the ' character is invalid.
# Copyright
Copyright and related rights waived via CC0 (opens new window).