This epic is a fork of the Account sequence mismatch errors Epic. Pigeons need new keys to sign transactions. These keys need to be derived from the validator key and added to the keychain so that validators will have their PigeonOperator keys linked to the validator keys. These keys will receive fee grant permissions to allow payments for all their fees from the validator key balance.
In order to resolve the account sequence mismatch issues, we propose to use the HD key formation to generate a series of addresses that will be used to sign transactions for pigeon relayers.
What are Hierarchical Deterministic Keys (HDKs)? Cosmos-SDK already adhere to the HDK model with the following properties:
- Deterministic means that keys are no longer created randomly, but instead generated as part of a linked chain. Regular backups are no longer required as long as the private-key seed that created the chain is safe. This makes key management very simple, and even allows easy caching of the master key in a paper wallet or cold storage–only having child keys stored on more vulnerable computer hardware.
- Hierarchical means that the chain of keys is ranked so that lower-rank keys cannot reveal information about their higher-ranked brethren. This also allows selective sharing of public
keys for auditing purposes.
- Cosmos Hub Format is The Cosmos Hub HD path which is derived in the format
m / 44' / 118' / 0' / 0 / address_indexwhere
44is the BIP44
118is the coin type for ATOM and the last component is used for multiple accounts of the same user.
Learn more about HD-KEYs in Cosmos here: Background on HD Key Paths
Given that COSMOS-SDK keys already confirm to BIP-32, we hypothesize that we can generate the first, five or ten derived keys using account 1 instead of account 0, and with Index 0 - Index 10 of this account path from the Validator key. These keys will be registered in Paloma as Pigeon keys for the validator key.
- The Pigeon Key Module is a series of keys that are derived from the validator Key. We propose using the Csomos Hub HD path format:
- The CLI provides a way to add the keys to key ring using the proposed derivation path of account 1 and index 0 - 5
palomad keys add <name> --account uint32 --index uint32
--accountusing account 1
—-indexusing index 0, 1, ….through 5
PigeonOperator Keys are selected for all pigeon signing transactions. Thus, the PigeonOperator keys are the default keys for all pigeon transactions.
- When pigeons needs to sign a transaction, pigeon will check to see the last PigeonOperator Key used
- Pigeon will use the next index PigeonOperator Key in the key ring
- Pigeon will then sign the transaction with the operator key
- Pigeons don’t need to keep track of which key is in use, just that each subsequent transaction will use the next key until all indexes are rotated from 0 through 5.
- Pigeon Operator Keys will use the Fee Grant Module
- The Fee Grant Module specification is here: https://github.com/cosmos/cosmos-sdk/tree/v0.47.0-rc1/x/feegrant
Grantis stored in the KVStore to record a grant with full context. Every grant will contain
granteeand what kind of
granteris an account address who is giving permission to
grantee(the beneficiary account address) to pay for some or all of
grantee’s transaction fees.
allowancedefines what kind of fee allowance (
PeriodicAllowance, see below) is granted to
allowanceaccepts an interface which implements
FeeAllowanceI, encoded as
Anytype. There can be only one existing fee grant allowed for a
granter, self grants are not allowed.
- PigeonOperatorKeys will receive allowance for the valdiator key to pay ALL of the fees for the PigeonOperatorKeys. This grant is made when the PigeonOperatorKeys are added to the key ring.
An “HD path” is an instruction as to how to derive a keypair from a root secret. BIP44 specifies a schema for such paths as follows:
m / 44' / coin_type' / account' / change / address_index
m is a constant symbol at the beginning of the path,
/ is the separator of path components,
44 is the the
purpose value from BIP43,
' denotes hardened derivation and the remaining four symbols are variable names for integers. A BIP44 path always has those five components where the first three are always hardened and the last two are always unhardened.
coin_type registry is maintained in SLIP44 and the pattern for some example blockchains looks like this.
Bitcoin: m / 44' / 0' / account' / change / address_index Litecoin: m / 44' / 2' / account' / change / address_index Ethereum: m / 44' / 60' / 0' / 0 / address_index Cosmos Hub: m / 44' / 118' / 0' / 0 / address_index EOS: m / 44' / 194' / address_index' / 0 / 0 Monero: m / 44' / 128' / address_index' Stellar: m / 44' / 148' / address_index'
As you can see for the blockchains that use an account based model instead of UTXOs, only one path component is variable (
address_index) and the differentiation between account and address does not help for those cases. For some chains the unused components are filled with zeros. Others follow Stellar’s model by simplifying the path to 3 components2, which results in paths that do not comply with BIP44 anymore. This shows how BIP44 is used for historical reasons but is not a great fit for account based blockchains. This concern is expressed in EIP600 as follows: Because Ethereum is based on account balances rather than UTXO, the hierarchy defined by BIP44 is poorly suited.