Proto: allow bakers to set a consensus key (part 1/4 : `Update_consensus_key`)

This MR is the first part of MR !5106 (closed) which implements the consensus key TZIP draft. See the original MR and the corresponding Tezosagora post for more general discussion about the proposed feature.

This first MR contains the most critical part of the series: it adds the ability for delegates to register a custom consensus key which will be used, with some delays, to sign block and endorsement on behalf of the delegate key.

It is based on !5054 (closed), and only the following commits need to be reviewed in this MR.

Changes in src/proto_alpha/lib_protocol: 34 files changed, 1132 insertions(+), 234 deletions(-)

Total changes: 90 files changed, 2528 insertions(+), 583 deletions(-)

The MR can be reviewed in four distinct part:

• the first part amends the low-level storage and allows delegates to register a consensus key but do not make any usage of this consensus key yet. The following properties are enforced:
  • there is only one active consensus key per delegate and per cycle,
  • a consensus key update is delayed by preserved_cycles + 1,
  • two delegates can not share the same consensus key in the a same cycle.
• the second part is the critical part which make use of the new consensus for signing consensus operation. This part is split in three steps:
  • introduce a new type Consensus_key.pk for snapshotting both the delegate public key and the consensus public key in the sampler state.
  • propagate this new type through the consensus code, while preserving the current behavior: the delegate public key is still used for signing consensus operations.
  • remove the delegate public key from Consensus_key.pk and do actually use the consensus key for signing consensus operations.
• the third part add small improvements in RPC and baker logging
• the last part add integration test for the new consensus key.

1. The storage part

The low-level storage

• Proto/Delegate: rename pubkey into manager_pubkey: a minor renaming to avoid confusion between the two keys associated to a delegate.
• Proto/Delegate: add Storage.Contracts.Consensus_key introduce the low-level storage for consensus keys and their delayed updates. It also introduces the associated module Delegate_consensus_key and the associated testsuite.
• Proto/Delegate: forbid two delegates with the same consensus key

A new manager operation and the associated client commands.

• Proto/Operation: add manager operation Update_consensus_key
• Proto/Client: add tezos-client set consensus key for <delagate> to <pk>
• Proto/Client: add tezos-client register key <pkh> as delegate with consensus key <pk>

Misc: RPC and activation

• Proto/RPC: add an RPC for querying a delegate's consensus key
• Proto/Bootstrap: allow to register a consensus key for bootstrap accounts

2. The critical consensus part

Snapshot the consensus key in sampler state

• Proto: make room for more ghosts in Storage_functors.: a minor patch to allow storage migration for Indexed_subcontext.
• Proto/Delegate: capture the consensus key in the sampler state

Propagate the consensus key where needed

• Proto/Delegate: propagate Consensus_key.pk (part 1)
• Proto/Delegate: propagate Consensus_key.pk (part 2)
• Proto/Delegate: propagate Consensus_key.pk (part 3)
• Proto/Delegate: propagate Consensus_key.pk (part 4)

Do actually use the new consensus key

• Proto/Delegate: use consensus_key for consensus operations
• Proto/Delegate: remove the delegate's public_key from sampler state

3. The baker part

• Proto/RPC: allow to filter baking/endorsing rights by consensus key
• Proto/Baker: display consensus key and delegate in logs

4. The testing part

• Proto: add a minimal tezt scenario for consensus key