ERC-2334 BLS key hierarchy path standard (BLS12-381 Deterministic Account Hierarchy)
Review · Accounts & wallets · created 2019-09-30
A path convention that defines which key in the BLS key tree generated by ERC-2333 is used for which purpose. It also defines the withdrawal key and signing key paths for beacon chain validators.
Why it is needed
The Ethereum beacon chain uses a new signature scheme called BLS12-381, and ERC-2333 was newly defined as the key generation method for it. However, this method does not fit BIP44, the path standard used by existing wallets, because it uses only hardened keys, allows more keys to be generated at a single level, and does not use BIP32 for key derivation. Without a path standard, wallets would differ on the order and manner in which keys are drawn from a single secret value. In the past, Ethereum actually suffered confusion from four different wallet paths in use, which led to draft proposals ERC-600 and ERC-601 aiming to clean this up. This standard aims to avoid repeating that confusion by defining a common path for traversing the BLS key tree, with a structure more general than BIP44.
In depth
Path structure and notation
A path represents ancestry by joining integers denoting sibling indices with /. m denotes the master node (root) of the tree, and i / j means j is a child of i. Excluding the master node, the path consists of four levels: purpose, coin_type, account, and use, and must have at least 4 levels (5 including the master node). The full form is m / purpose / coin_type / account / use.
purpose is 12381
purpose is fixed at 12381, following the name of the new curve, BLS12-381. To comply with this standard, ERC-2333 must be implemented as the key derivation function (KDF); otherwise the purpose value 12381 cannot be used. It notes that since the KDF and path are mutually incompatible with BIP43/BIP44, the purpose value needed to be distinguished, and 12381 was a natural choice.
coin_type is 3600
coin_type is a per-coin number that separates keys used on different chains. Ethereum's BLS12-381 keys use 3600. This is a newly assigned value chosen to cleanly separate BLS12-381 keys from existing secp256k1 keys, and was selected because it is the square of 60 (3600 == 60^2), Ethereum's secp256k1 coin_type.
The account and use levels
account is a field that lets a user maintain separate key sets for different purposes if desired; it is recommended (SHOULD) that a user's multiple accounts be implemented at this level. use is a level intended to provide multiple keys that are related but must be kept separate for security within a single account. Support for this level is required, though in many cases the value remains 0. The use value is typically determined at the application level, providing a separate key for each non-overlapping purpose.
Beacon chain validator key paths
Each validator has two keys: a withdrawal key used for withdrawals and transfers, and a signing key used to perform validator duties. The withdrawal key path is m/12381/3600/i/0 and the signing key path is m/12381/3600/i/0/0, where i denotes the i-th validator key set. That is, the signing key is the 0th child of that validator's withdrawal key. In cases such as distributed-secret-sharing or custodial validators where this path cannot be used directly, that key may be omitted and derived another way, but implementations should make a reasonable effort to use the appropriate key for its purpose. For example, in custodial staking the depositing user follows this standard for the withdrawal key, while the service provider's signing key derivation method is separate.
Why the signing key and withdrawal key are separated
The two keys are separated because security requirements differ by role within the beacon chain. The signing key is a hot key loaded into the validator client to sign messages. If it leaks, the worst case is that a slashable message gets signed, causing the validator to be slashed and forcibly exited. The withdrawal key is needed only for actions outside of validation and has access to all of that validator's deposited funds, so it should be treated as a cold key with higher security requirements. Because the signing key is a child of the withdrawal key, the signing key can be recovered when needed as long as the withdrawal key is kept safe.
Relationship to BIP44 and hardened key notation
The terms purpose, coin_type, and account are carried over directly from concepts widely used in BIP43 and BIP44. However, because ERC-2333 uses a new KDF, a new path standard was needed, and this ERC implements one with some modifications. The purpose 12381 path does not support hardened key notation, so the ' character must not be used. This standard also aims for a structure more general than BIP44 by removing UTXO-centric features.
Proposal status
This ERC is currently in Review status. As a proposal still under review, its content may change.