@G_B_Fefe and myself have been working on a protocol proposal called consensus key and would like to suggest it for inclusion in protocol K.
It allows a Tezos baker to use a separate key (the consensus key) to bake and endorse blocks, and rotate it at will, enhancing their operational security.
One version of the Florence protocol was doing something like this but it did not get voted in. Our proposal has key differences. It is minimalist by design and implements nothing but the consensus key:
- it does not let smart contacts be bakers,
- it does not change the 10% ratio of self-stake to total stake, or pave the way to doing so,
- it introduces no breaking changes.
More details in the links below:
-
TZIP
- TZIP motivation
- TZIP Q&A
- implementation
- testing
Last time, some community members were adamant that the consensus key should be spendable (see discussion). But in our proposal, the account associated with the consensus key has its own balance separate from the baker’s balance. Therefore, we introduce a new Drain_delegate
operation that lets the consensus key transfer all the free balance of the baker to themselves. Effectively, this makes the consensus key spendable.
We also introduce a new governance toggle to allow a majority of bakers (by stake) to disable this Drain_delegate
operation later, shall they prefer the consensus key not being spendable.
If the community’s position has changed, we can also resubmit a simpler version of this proposal without the Drain_delegate
operation and the governance toggle. The consensus key would be non-spendable from the get-go in this case. Please let us know.
We are attaching an invoice to this proposal. The proposed amounts are 30,000 tez to G.-B. Fefe and 20,000 tez to MIDL.dev (my company), credited to our respective accounts at protocol activation, shall this proposal be part of it.