PigeonOperator Keys - HD Keys for increased pigeon signing with FeeGrant for fee payments

R&D
1

Business Case

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.

Proposal

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_index where 44 is the BIP44 purpose, 118 is 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.

Requirements

HD Key Derivation using CosmosHub Format:

  1. 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:
    1. The CLI provides a way to add the keys to key ring using the proposed derivation path of account 1 and index 0 - 5
    2. palomad keys add <name> --account uint32 --index uint32
      1. <name> PigeonOpKey1…PigeonOpKey 5
      2. --account using account 1
      3. —-index using index 0, 1, ….through 5

PigeonOperatorKeys Selected for Pigeon Signing

PigeonOperator Keys are selected for all pigeon signing transactions. Thus, the PigeonOperator keys are the default keys for all pigeon transactions.

  1. When pigeons needs to sign a transaction, pigeon will check to see the last PigeonOperator Key used
  2. Pigeon will use the next index PigeonOperator Key in the key ring
  3. Pigeon will then sign the transaction with the operator key
  4. 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.

Fee Grant Module for Pigeon Operator Keys Transaction Fees

  1. Pigeon Operator Keys will use the Fee Grant Module
  2. The Fee Grant Module specification is here: https://github.com/cosmos/cosmos-sdk/tree/v0.47.0-rc1/x/feegrant
    1. Grant is stored in the KVStore to record a grant with full context. Every grant will contain granter, grantee and what kind of allowance is granted. granter is an account address who is giving permission to grantee (the beneficiary account address) to pay for some or all of grantee’s transaction fees. allowance defines what kind of fee allowance (BasicAllowance or PeriodicAllowance, see below) is granted to grantee. allowance accepts an interface which implements FeeAllowanceI, encoded as Any type. There can be only one existing fee grant allowed for a grantee and granter, self grants are not allowed.
  3. 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.

User stories

Open items / Question

Background on HD Key Paths

BIP44

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

where 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.

A 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.