ADR034: Account Rekeying

docs/architecture/adr-034-change-pubkey.md

@@ -0,0 +1,63 @@
+# ADR 034: Change PubKey
+
+## Changelog
+
+- 30-09-2020: Initial Draft
+
+## Status
+
+Proposed
+
+## Context
+
+Currently, in the Cosmos SDK, the address of an auth account is always based on the hash of the public key.  Once an account is created, the public key for the account is set in stone, and cannot be changed.  This can be a problem for users, as key rotation is a useful security practice, but is not possible currently.  Furthermore, as multisigs are a type of pubkey, once a multisig for an account is set, it can not be updated.  This is problematic, as multisigs are often used by organizations or companies, who may need to change their set of multisig signers for internal reasons.
+
+Transferring all the assets of an account to a new account with the updated pubkey is not sufficient, because some "engagements" of an account are not easily transferable.  For example, in staking, to transfer bonded Atoms, an account would have to unbond all delegations and wait the three week unbonding period.  Even more significantly, for validator operators, ownership over a validator is not transferrable at all, meaning that the operator key for a validator can never be updated, leading to poor operational security for validators. 
+
+## Decision
+
+We propose the addition of a new feature to `x/auth` that allows accounts to update the public key associated with their account, while keeping the address the same.  This feature can be enabled using an `EnableChangePubKey` param.
+
+This is possible because the Cosmos SDK `StdAccount` stores the public key for an account in state, instead of making the assumption that the public key is included in the transaction (whether explicitly or implicitly through the signature) as in other blockchains such as Bitcoin and Ethereum.  Because the public key is stored on chain, it is okay for the public key to not hash to the address of an account, as the address is not pertinent to the signature checking process.
+
+To build this system, we design a new Msg type as follows:
+
+```protobuf
+message MsgChangePubKey {
+  string address = 1;
+  google.protobuf.Any pub_key = 2;
+}
+```
+
+The MsgChangePubKey transaction needs to be signed by the existing pubkey in state.
+
+Once, approved, the handler for this message type, which takes in the AccountKeeper, will update the in-state pubkey for the account and replace it with the pubkey from the Msg.
+
+Because an account can no longer be pruned from state once its pubkey has changed, we can charge an additional gas fee for this operation to compensate for this this externality (this bound gas amount is configured as parameter `PubKeyChangeCost`). The bonus gas is charged inside the handler, using the `ConsumeGas` function.
+
+```go
+	amount := ak.GetParams(ctx).PubKeyChangeCost
+	ctx.GasMeter().ConsumeGas(amount, "pubkey change fee")
+```
+
+
+## Consequences
+
+### Positive
+
+* Will allow users and validator operators to employ better operational security practices with key rotation.
+* Will allow organizations or groups to easily change and add/remove multisig signers.
+
+### Negative
+
+Breaks the current assumed relationship between address and pubkeys as H(pubkey) = address. This has a couple of consequences.
+
+* We cannot prune accounts with 0 balance that have had their pubkey changed (we currently do not currently do this anyways, but the reason we have account numbers is presumably for this purpose).
+* This makes wallets that support this feature more complicated. For example, if an address on chain was updated, the corresponding key in the CLI wallet also needs to be updated.
+
+### Neutral
+
+* While the purpose of this is intended to allow the owner of an account to update to a new pubkey they own, this could technically also be used to transfer ownership of an account to a new owner.  For example, this could be use used to sell a staked position without unbonding or an account that has vesting tokens.  However, the friction of this is very high as this would essentially have to be done as a very specific OTC trade. Furthermore, additional constraints could be added to prevent accouns with Vesting tokens to use this feature.
+* Will require that PubKeys for an account are included in the genesis exports.
+
+## References