# Baking accounts with seamless migration

## Invariants
Let's document here wished invariants involved in the baking accounts feature, as a first step of https://gitlab.com/tezos/tezos/-/issues/1152.

## Arthur's proposal

The following describe a migration path to a version of baking accounts that maximizes backwards compatibility.

In general, for making this happen, we have to choose which invariant to break. Here, we break the invariant that a baker's consensus key needs to hash to its address. It's hard to depend on this property in Michelson, and there are few uses cases, making it somewhat safe to break.

Contracts currently delegate to a key_hash, this should continue to be true. At the same time, we want bakers to be able to rotate their keys.

Implicit accounts are already marked as being registered for baking or not. One solution is to let these accounts enrich their state with:

- a consensus key
- a multisig set-up for spending and voting
- a PVSS key

The multisig set-up can vote, spend and change its signatories. It cannot change the consensus key.

The consensus key has all of its usual powers, (baking, endorsing, spending and voting). In addition, it can also replace itself (with a delay), change the multisig set-up and the PVSS key.

The consensus key can become different from the original key that yielded the hash. This is OK, the original key loses its power and is superseded by the consensus key.

Invariants broken:

- A transaction from an implicit account may be signed by a key which does not hash to that account's address.
- Hashing a key and sending funds to that account may render the funds unretrievable if that account happens to be a baker's address which has replaced its old consensus key.

Since it's hard to rely on these invariants to do anything useful, it's probably OK to break them.

The migration works because it preserves the implicit account address, which is the abstraction most commonly used to think about accounts, and puts the logic of rotatin the key underneath this abstraction.

This can be done in a few phases if need be:

- first phase, allow changing the consensus key only and attaching PVSS key
- second phase, multisig support

## Mehdi's proposal

This probably break some invariants so let's document them above.

In a first amendment:
- we introduce SG1 baker addresses migrated from tz1 bakers, with their tz1 as consensus key.
> Arthur note: in Michelson, a delegate is not set based on an address but based on a `key_hash option` so having a new type of address for bakers could break smart-contracts that expect a key_hash option. You would have to make a baker address match the key_hash option type. Or do you have a new SET_DELEGATE2 instruction that takes a baking address and emulate SET_DELEGATE by maintaining a mapping?
- changing consensus key is not possible (yet)
- we introduce new instructions working on baker hashes but legacy ones still work thanks to a tz1 -> SG1 mapping

In a second amendment:
- we rewrite contracts using legacy instructions to use baker hashes instead.
- we migrate consensus keys to a new namespace (e.g. ck1/ck2/ck3) while keeping the underlying key identical
- changing consensus key becomes possible