From 7b2566e160c060ec6ded6dd714a3f86afda14f5e Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Fri, 15 Apr 2022 18:56:57 -0700 Subject: [PATCH 01/21] initial --- drafts/current/draft-consensus-key.md | 89 +++++++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 drafts/current/draft-consensus-key.md diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md new file mode 100644 index 0000000..5ca44da --- /dev/null +++ b/drafts/current/draft-consensus-key.md @@ -0,0 +1,89 @@ +--- +title: Rotating baking keys +status: Draft +author: G.B. Fefe , Nicolas Ochem +type: Interface +created: 2022-04-06 +date: 2022-04-06 +version: 0 +--- + +## Summary + +This TZIP describes a proposed protocol-amendment that would allow bakers to designate a consensus key responsible for signing baking and endorsing operations. This improves the operational security of Tezos bakers. + +## Abstract + +In the current version of the Tezos protocol (Ithaca), a baker is identified by a public key hash, e.g. a `tz1...` address. Like any public key hash in Tezos, this hash, or address, identifies an implicit account, i.e. a balance and the corresponding keypair allowed to withdraw funds. If for any reason a baker want to change its keypair, it has to ask all their delegator to redelegate to the hash of their new public key. This TZIP aims to ease this process and to avoid any redelegations. + +For this purpose, we propose to reuse the oldest trick in programming history: to add an intermediate pointer. With this proposal, the address of a baker does not designate an implicit account anymore but a reference to an implicit account. The baker may change the referenced implicit account by calling the newly introduced `update_consensus_key` operation, thus transfering to it all the block-signing rights and (pre)endorsements-signing rights after a delay of `PRESERVED_CYCLES + 1`. + +Separating keys allows separation of human responsibilities, which may alter the decentralization dynamics of the network. To neutralize this concern, a newly introduced `drain` operation allows the consensus key to transfer all the free balance of the baker to its own implicit account. This roughly confers the same powers to both keys. However, a newly introduced governance toggle `disable_consensus_key_drain` will allow a supermajority of bakers to disable this operation later on, if they so choose. + +## Design + +We propose to add a second key to delegates, called the consensus key. This consensus key is used instead of the regular key of the delegate (a.k.a. the manager key or the parent key) for signing blocks and (pre)endorsement. By default, the manager key and the consensus key are equal. + +We propose to add two new operations: + +- `Update_consensus_key ` + + This operation must be signed by the manager key of a delegate. It + will change the consensus key associated to the delegate: the new + key will be used instead of the old key when computing the future + baking rights distributions, meaning that the key will be required + for signing blocks and endorsement in `preserved_cycles` (currently + 5 cycles in Ithaca). + + + It is required that the account is allocated. The operation fails otherwise. + +- `drain` + + This operation must be signed by the consensus key of a delegate currently allowed to sign consensus operations. + + This operation immediately transfers all the free balance of the manager account into the consensus account. It has no effect on the frozen balance. + + This operation fails if the governance toggle `disable_consensus_key_drain` is set to True. + +### Protocol migration + +The migration establishes the correspondance table between the manager accounts and their consensus keys. Initially, all manager accounts and consensus keys are equal. + +## Motivation + +### `update_consensus_key` + +Key rotation is a common feature of any cryptosystem. Having a parent key delegate responsibilities to a child key allows for optimal protection of the parent key, for example in a cold wallet. + +It also allows establishment of baking operations in an environment where access is not ultimately guaranteed: for example, a cloud platform providing hosted Key Management Systems where the private key is generated within the system and can never be downloaded by the baker. The baker can designate such KMS key as consensus key. Shall they lose access to the cloud platform for any reason, they can simply rotate to a new key. + +Moreover, this proposal allows the baker to sign their consensus operations using new signature schemes as they get introduced in Tezos. They may elect to do so for performance or security reasons. The ultimate authority still rests on the parent key which can not be rotated. The security of the signature scheme of the parent key may decrease over time, however the fact that this key is used less often than the consensus key helps to mitigate this. + +As a private baker, it is possible to put 90% of the funds in cold storage, in an account that delegates to the baker. This is however an imperfect substitute to this proposal, given that it still leaves 10% of the funds in the baker's account. It is also not doable for a public baker who may have 100% of their balance frozen. + +### `drain` + +### As a deterrent against handing over the key to a third party + +When there is one key, whoever has access to it has full control over the baker. When there are two keys, the possibility emerges of each of these keys being controlled by different people or entities. For example, the delegate key could be in physical custody of the baker, while the consensus key could be: + +* hosted in a cloud platform where the cloud provider merely grants access to the baker, to be revoked at their discretion, +* handed to a service provider taking care of the baking operations on behalf of the baker (baking-as-a-service operator) + +This constitues a centralization risk: some cloud operators have a large market share, which may give them the power to disrupt or stop the network. Some baking providers may also become dominant. + +There are risks to this regardless of the existence of the `drain` operation: indeed, anyone with access to the consensus key has the ability to double sign, which can result in the delegate being slashed. Shall the attacker have baking rights, they may inject the denunciation operation in their own block, stealing half of the frozen balance, while the other half is burned. + +Therefore, a rigorous baker will not hand off their consensus key to an untrusted party. + +The drain operation acts as an additional deterrent and ensures that the consensus keys ultimately has the same rights than the delegate's key: indeed, the baking entity is able to stop baking, and empty the account after `PRESERVED_CYCLES` when all balance is unfrozen. + +### As a recovery mechanism from baker's key loss + +A baker may lose their baking key. In this case, they may stop baking, wait `PRESERVED_CYCLES`, and then recover their funds and start baking from another account. + +### `disable_consensus_key_drain` governance toggle +The drain operation is added in order to separate introduction of the consensus key mechanism, with the resolution of the question of the permissions of such a consensus key. + +[todo expand on this] -- GitLab From 1b241de9ee7628f2113d01ee7464ffde58d92b3f Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Fri, 15 Apr 2022 21:36:32 -0700 Subject: [PATCH 02/21] update --- drafts/current/draft-consensus-key.md | 78 +++++++++++++++++++++++---- 1 file changed, 67 insertions(+), 11 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 5ca44da..0f0ef3b 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -1,5 +1,5 @@ --- -title: Rotating baking keys +title: Consensus key status: Draft author: G.B. Fefe , Nicolas Ochem type: Interface @@ -18,12 +18,16 @@ In the current version of the Tezos protocol (Ithaca), a baker is identified by For this purpose, we propose to reuse the oldest trick in programming history: to add an intermediate pointer. With this proposal, the address of a baker does not designate an implicit account anymore but a reference to an implicit account. The baker may change the referenced implicit account by calling the newly introduced `update_consensus_key` operation, thus transfering to it all the block-signing rights and (pre)endorsements-signing rights after a delay of `PRESERVED_CYCLES + 1`. -Separating keys allows separation of human responsibilities, which may alter the decentralization dynamics of the network. To neutralize this concern, a newly introduced `drain` operation allows the consensus key to transfer all the free balance of the baker to its own implicit account. This roughly confers the same powers to both keys. However, a newly introduced governance toggle `disable_consensus_key_drain` will allow a supermajority of bakers to disable this operation later on, if they so choose. +Separating keys allows separation of human responsibilities, which may alter the decentralization dynamics of the network. To neutralize this concern, a newly introduced `drain` operation allows the consensus key to transfer all the free balance of the baker to its own implicit account. This roughly confers the same powers to both keys. However, a newly introduced governance toggle `allow_consensus_key_drain` will allow a majority of bakers to disable this operation later on, if they so choose. ## Design We propose to add a second key to delegates, called the consensus key. This consensus key is used instead of the regular key of the delegate (a.k.a. the manager key or the parent key) for signing blocks and (pre)endorsement. By default, the manager key and the consensus key are equal. +Internally, a table associates the manager keys to their respective consensus keys. This table is stored in the context. (right?) + +The consensus key of a given delegate is set per cycle to whatever the consensus key is set in the table at the time the snapshot is taken. + We propose to add two new operations: - `Update_consensus_key ` @@ -36,7 +40,9 @@ We propose to add two new operations: 5 cycles in Ithaca). - It is required that the account is allocated. The operation fails otherwise. + It is required that the account used as consensus key be allocated. The operation fails otherwise. + + Several bakers can have their consensus key set to the same key. - `drain` @@ -44,7 +50,39 @@ We propose to add two new operations: This operation immediately transfers all the free balance of the manager account into the consensus account. It has no effect on the frozen balance. - This operation fails if the governance toggle `disable_consensus_key_drain` is set to True. + This operation fails if the governance toggle `allow_consensus_key_drain` is set to False. + +- `allow_consensus_key_drain` toggle vote + +The Toggle Vote for the drain operation relies on the computation of an +exponential moving average (EMA) of the signals sent by bakers in +their blocks. These signals can have three possible values: **On**, +**Off**, and **Pass**. The EMA is updated once per block as follows: +- if the baker of the block chose the **Pass** option then the EMA is + not modified, +- if the baker of the block chose the **Off** option then the EMA is + increased, +- if the baker of the block chose the **On** option then the EMA is + decreased. + +At each block, the EMA is compared to a constant known as the the +_threshold_ of the Toggle Vote. When the EMA is above the threshold, +it means that **Off** votes have the majority. On the opposite, a +value below the threshold means that **On** votes have the majority. + +The subsidy is sent to the Liquidity Baking contract if and only if +the block level is below the liquidity baking sunset level and the EMA +is below the threshold. + +More precisely, the EMA is a natual number whose value can vary +between 0 and 2 billion and the threshold is 1 billion. +In each block, the EMA is updated as follows: +- if the baker votes **Pass** then the value is unchanged: EMA[n+1] = + EMA[n] +- if the baker votes **On** then EMA[n+1] = (EMA[n] * 1999) / 2000 +- if the baker votes **Off** then EMA[n+1] = ((EMA[n] * 1999) / + 2000) + 1,000,000 + ### Protocol migration @@ -64,7 +102,9 @@ As a private baker, it is possible to put 90% of the funds in cold storage, in a ### `drain` -### As a deterrent against handing over the key to a third party +The motivation of the `drain` operation is twofold. + +#### As a deterrent against handing over the key to a third party When there is one key, whoever has access to it has full control over the baker. When there are two keys, the possibility emerges of each of these keys being controlled by different people or entities. For example, the delegate key could be in physical custody of the baker, while the consensus key could be: @@ -77,13 +117,29 @@ There are risks to this regardless of the existence of the `drain` operation: in Therefore, a rigorous baker will not hand off their consensus key to an untrusted party. -The drain operation acts as an additional deterrent and ensures that the consensus keys ultimately has the same rights than the delegate's key: indeed, the baking entity is able to stop baking, and empty the account after `PRESERVED_CYCLES` when all balance is unfrozen. +When the drain operation is enabled, a compromise of the consensus key allows a motivated attacker to spend all of the baker's balance. Indeed, the drain operation always takes precedence over any transaction in any block (TODO confirm this). Therefore, a motivated attacker is able to steal all of the baker's money by timing their drain operations appropriately, even if all of the balance is initially frozen. + +The drain operation acts as an additional deterrent and ensures that the consensus keys ultimately has the same control over the balance than the delegate's key. + +#### As a recovery mechanism from baker's key loss + +A baker may lose their baking key. In this case, they may stop baking, wait `PRESERVED_CYCLES`, and then recover their funds with the `drain` operation. They may then start baking from another account. + +### `allow_consensus_key_drain` governance toggle +The introduction of the consensus key is an uncontroversial and long-standing request from the community. But the permissions granted to the key have been subject to vigourous debate in the past. + +The [liquidity baking toggle vote](https://gitlab.com/tezos/tzip/-/blob/master/drafts/current/draft-symmetric-liquidity-baking-toggle-vote.md) TZIP introduced a mechanism for fast and concurrent governance signaling mechanisms. + +A good case can be made for disabling the `drain` operation: it increases the security posture of the baker even further. Indeed, in the absence of the drain operation, a compromise of the consensus key does not put the unfrozen balance at risk. It still exposes the baker to a double signing attack, but this attack is complex to pull off and results in half of the frozen balance being burned. -### As a recovery mechanism from baker's key loss +On the other hand, disabling the `drain` operation also disables the recovery mechanism from loss of the baker key, and re-introduces concerns expressed above about changing the decentralization dynamics of the network. -A baker may lose their baking key. In this case, they may stop baking, wait `PRESERVED_CYCLES`, and then recover their funds and start baking from another account. +The `allow_consensus_key_drain` governance toggle leaves the matter for the community to decide, separately from the feature itself. -### `disable_consensus_key_drain` governance toggle -The drain operation is added in order to separate introduction of the consensus key mechanism, with the resolution of the question of the permissions of such a consensus key. +## Testing / edge cases -[todo expand on this] +* set the consensus key to a third key, then back to the baker key +* set two delegates to the same consensus key (should work) +* set a delegate to a consensus key that is also a delegate (should work) +* empty the account of the consensus key (what happens then?) +* delegate the consensus key to any baker (should always work) -- GitLab From 1dccb927c9cc4773c4fd11ee060fc14adada1b68 Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Fri, 15 Apr 2022 22:13:33 -0700 Subject: [PATCH 03/21] update --- drafts/current/draft-consensus-key.md | 52 ++++++++++++++++++++++----- 1 file changed, 44 insertions(+), 8 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 0f0ef3b..e0693ec 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -18,7 +18,7 @@ In the current version of the Tezos protocol (Ithaca), a baker is identified by For this purpose, we propose to reuse the oldest trick in programming history: to add an intermediate pointer. With this proposal, the address of a baker does not designate an implicit account anymore but a reference to an implicit account. The baker may change the referenced implicit account by calling the newly introduced `update_consensus_key` operation, thus transfering to it all the block-signing rights and (pre)endorsements-signing rights after a delay of `PRESERVED_CYCLES + 1`. -Separating keys allows separation of human responsibilities, which may alter the decentralization dynamics of the network. To neutralize this concern, a newly introduced `drain` operation allows the consensus key to transfer all the free balance of the baker to its own implicit account. This roughly confers the same powers to both keys. However, a newly introduced governance toggle `allow_consensus_key_drain` will allow a majority of bakers to disable this operation later on, if they so choose. +Separating keys allows separation of human responsibilities, which may alter the decentralization dynamics of the network. To neutralize this concern, a newly introduced `drain` operation allows the consensus key to transfer all the free balance of the baker to its own implicit account. This roughly confers the same powers to both keys. However, a newly introduced governance toggle `consensus_key_drain_toggle` will allow a majority of bakers to disable this operation later on, if they so choose. ## Design @@ -50,9 +50,9 @@ We propose to add two new operations: This operation immediately transfers all the free balance of the manager account into the consensus account. It has no effect on the frozen balance. - This operation fails if the governance toggle `allow_consensus_key_drain` is set to False. + This operation fails if the governance toggle `consensus_key_drain_toggle` is set to False. -- `allow_consensus_key_drain` toggle vote +### `consensus_key_drain_toggle` toggle vote The Toggle Vote for the drain operation relies on the computation of an exponential moving average (EMA) of the signals sent by bakers in @@ -70,9 +70,7 @@ _threshold_ of the Toggle Vote. When the EMA is above the threshold, it means that **Off** votes have the majority. On the opposite, a value below the threshold means that **On** votes have the majority. -The subsidy is sent to the Liquidity Baking contract if and only if -the block level is below the liquidity baking sunset level and the EMA -is below the threshold. +The `drain` operation works if and only if the EMA is below the threshold. More precisely, the EMA is a natual number whose value can vary between 0 and 2 billion and the threshold is 1 billion. @@ -88,6 +86,30 @@ In each block, the EMA is updated as follows: The migration establishes the correspondance table between the manager accounts and their consensus keys. Initially, all manager accounts and consensus keys are equal. +The migration also sets the initial EMA of the toggle vote to 1 billion. + +### Commands + + +A consensus key can be changed at any point. This may be done with the command: + +```shell +tezos-client set baker consensus key to +``` + +The current registration command still works: + +```shell +tezos-client register key as delegate +``` + +It is also possible to register as a delegate and immediately set the consensus key: + +```shell +tezos-client register key as delegate with consensus key +``` + +TODO discuss this and figure out if it's true ## Motivation ### `update_consensus_key` @@ -125,7 +147,7 @@ The drain operation acts as an additional deterrent and ensures that the consens A baker may lose their baking key. In this case, they may stop baking, wait `PRESERVED_CYCLES`, and then recover their funds with the `drain` operation. They may then start baking from another account. -### `allow_consensus_key_drain` governance toggle +### `consensus_key_drain_toggle` governance toggle The introduction of the consensus key is an uncontroversial and long-standing request from the community. But the permissions granted to the key have been subject to vigourous debate in the past. The [liquidity baking toggle vote](https://gitlab.com/tezos/tzip/-/blob/master/drafts/current/draft-symmetric-liquidity-baking-toggle-vote.md) TZIP introduced a mechanism for fast and concurrent governance signaling mechanisms. @@ -134,7 +156,21 @@ A good case can be made for disabling the `drain` operation: it increases the se On the other hand, disabling the `drain` operation also disables the recovery mechanism from loss of the baker key, and re-introduces concerns expressed above about changing the decentralization dynamics of the network. -The `allow_consensus_key_drain` governance toggle leaves the matter for the community to decide, separately from the feature itself. +The `consensus_key_drain_toggle` governance toggle leaves the matter for the community to decide, separately from the feature itself. + +### Q&A + +#### Why not introduce a mechanism to rotate the baking key altogether? + +We rejected the baking key rotation feature due to its intrusiveness. In particular, it would require all delegations to be changed. + +#### Why not change the encoding of the baking key to something different than a `tz` address such as `BAKxxx` + +This change would be disruptive in the community and mandate a lot of changes in tooling. We feel it is a useless distraction. + +#### Can the baking key be a multisig? Can we have smart contracts manage baking? Can the rewards be sent to a third address? + +All of these topics were discussed in the past. A previous TZIP called "Baking accounts" was implementing some of these ideas, but was ultimately rejected by the community because of some technical shortcoming. We are actively limiting the scope and the amount of code changes in this TZIP to solve a narrower problem of consensus key separation. ## Testing / edge cases -- GitLab From 41c05b6e86714d25ac1df071049fc79285777384 Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Fri, 15 Apr 2022 22:25:58 -0700 Subject: [PATCH 04/21] updates --- drafts/current/draft-consensus-key.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index e0693ec..596c961 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -14,15 +14,15 @@ This TZIP describes a proposed protocol-amendment that would allow bakers to des ## Abstract -In the current version of the Tezos protocol (Ithaca), a baker is identified by a public key hash, e.g. a `tz1...` address. Like any public key hash in Tezos, this hash, or address, identifies an implicit account, i.e. a balance and the corresponding keypair allowed to withdraw funds. If for any reason a baker want to change its keypair, it has to ask all their delegator to redelegate to the hash of their new public key. This TZIP aims to ease this process and to avoid any redelegations. +In the current version of the Tezos protocol (Ithaca), a baker is identified by a public key hash, e.g. a `tz1...` address. Like any public key hash in Tezos, this hash, or address, identifies an implicit account, i.e. a balance and the corresponding keypair allowed to withdraw funds. If for any reason a baker want to change the keypair used for signing consensus operations, they have to have all their delegator accounts redelegate to the hash of their new public key. This TZIP aims to ease this process and to avoid any redelegations. For this purpose, we propose to reuse the oldest trick in programming history: to add an intermediate pointer. With this proposal, the address of a baker does not designate an implicit account anymore but a reference to an implicit account. The baker may change the referenced implicit account by calling the newly introduced `update_consensus_key` operation, thus transfering to it all the block-signing rights and (pre)endorsements-signing rights after a delay of `PRESERVED_CYCLES + 1`. -Separating keys allows separation of human responsibilities, which may alter the decentralization dynamics of the network. To neutralize this concern, a newly introduced `drain` operation allows the consensus key to transfer all the free balance of the baker to its own implicit account. This roughly confers the same powers to both keys. However, a newly introduced governance toggle `consensus_key_drain_toggle` will allow a majority of bakers to disable this operation later on, if they so choose. +Separating keys allows separation of human responsibilities, which may alter the decentralization dynamics of the network. To neutralize this concern, a newly introduced `drain` operation allows the consensus key to transfer all the free balance of the baker to its own implicit account. This roughly confers the same powers to both keys. However, a newly introduced governance toggle `consensus_key_drain_toggle` will allow a majority of bakers to disable this `drain` operation later on, if they so choose. ## Design -We propose to add a second key to delegates, called the consensus key. This consensus key is used instead of the regular key of the delegate (a.k.a. the manager key or the parent key) for signing blocks and (pre)endorsement. By default, the manager key and the consensus key are equal. +We add a second key to delegates, called the consensus key. This consensus key is used instead of the regular key of the delegate (a.k.a. the manager key or the parent key) for signing blocks and (pre)endorsements. By default, the manager key and the consensus key are equal. Internally, a table associates the manager keys to their respective consensus keys. This table is stored in the context. (right?) @@ -148,23 +148,23 @@ The drain operation acts as an additional deterrent and ensures that the consens A baker may lose their baking key. In this case, they may stop baking, wait `PRESERVED_CYCLES`, and then recover their funds with the `drain` operation. They may then start baking from another account. ### `consensus_key_drain_toggle` governance toggle -The introduction of the consensus key is an uncontroversial and long-standing request from the community. But the permissions granted to the key have been subject to vigourous debate in the past. - -The [liquidity baking toggle vote](https://gitlab.com/tezos/tzip/-/blob/master/drafts/current/draft-symmetric-liquidity-baking-toggle-vote.md) TZIP introduced a mechanism for fast and concurrent governance signaling mechanisms. +The introduction of the consensus key is an uncontroversial and long-standing request from the community. Many competing blockchains already have this feature implemented. But the permissions granted to the key have been subject to vigourous debate in the past. A good case can be made for disabling the `drain` operation: it increases the security posture of the baker even further. Indeed, in the absence of the drain operation, a compromise of the consensus key does not put the unfrozen balance at risk. It still exposes the baker to a double signing attack, but this attack is complex to pull off and results in half of the frozen balance being burned. On the other hand, disabling the `drain` operation also disables the recovery mechanism from loss of the baker key, and re-introduces concerns expressed above about changing the decentralization dynamics of the network. +The [liquidity baking toggle vote](https://gitlab.com/tezos/tzip/-/blob/master/drafts/current/draft-symmetric-liquidity-baking-toggle-vote.md) TZIP introduced a mechanism for fast and concurrent governance signaling mechanisms. This mechanism is suitable for a binary decision such as enabling or disabling an operation. + The `consensus_key_drain_toggle` governance toggle leaves the matter for the community to decide, separately from the feature itself. ### Q&A #### Why not introduce a mechanism to rotate the baking key altogether? -We rejected the baking key rotation feature due to its intrusiveness. In particular, it would require all delegations to be changed. +We rejected the baking key rotation feature due to its intrusiveness. In particular, it would require all delegations to be changedm touching various parts of the storage, each time such operation runs. -#### Why not change the encoding of the baking key to something different than a `tz` address such as `BAKxxx` +#### Why not change the encoding of the baking key to something different than a `tz` address such as `BAKxxx` or `SG1xxx`? This change would be disruptive in the community and mandate a lot of changes in tooling. We feel it is a useless distraction. -- GitLab From cb16faa54fd4b839ab5a2b85df46e298a9bff738 Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Fri, 15 Apr 2022 23:38:38 -0700 Subject: [PATCH 05/21] updates --- drafts/current/draft-consensus-key.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 596c961..d946fae 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -162,20 +162,30 @@ The `consensus_key_drain_toggle` governance toggle leaves the matter for the com #### Why not introduce a mechanism to rotate the baking key altogether? -We rejected the baking key rotation feature due to its intrusiveness. In particular, it would require all delegations to be changedm touching various parts of the storage, each time such operation runs. +We rejected the baking key rotation idea due to its intrusiveness. In particular, it would require all delegations to be changed to the new key. #### Why not change the encoding of the baking key to something different than a `tz` address such as `BAKxxx` or `SG1xxx`? -This change would be disruptive in the community and mandate a lot of changes in tooling. We feel it is a useless distraction. +This change would be disruptive in the community and mandate a lot of changes in tooling, for questionable benefit. #### Can the baking key be a multisig? Can we have smart contracts manage baking? Can the rewards be sent to a third address? -All of these topics were discussed in the past. A previous TZIP called "Baking accounts" was implementing some of these ideas, but was ultimately rejected by the community because of some technical shortcoming. We are actively limiting the scope and the amount of code changes in this TZIP to solve a narrower problem of consensus key separation. +All of these topics were discussed in the past. A previous TZIP called "Baking accounts" was implementing some of these ideas, but was ultimately rejected by the community because of technical shortcomings. We are actively limiting the scope and the amount of code changes in this TZIP to solve the narrower goal of having a separate consensus key. + +#### Have you addressed all the unexpected breaking changes of the previous baking accounts proposal? + +Refer to: [Baking Accounts proposal contains unexpected breaking changes](https://forum.tezosagora.org/t/baking-accounts-proposal-contains-unexpected-breaking-changes/2844) + +Specifically this quote: + +> A future version of Baking Accounts which does not break current contracts and preserves important invariants is possible, and should be developed to take its place. + +We believe that the current proposal fits this description. Unlike the previous proposal, we are not allowing bakers to be controlled by multisignature smart contracts. As a result, we did not change any Michelson instruction and no smart contracts will break. Moreover, the consensus key is a regular implicit account with its own balance. In addition to signing consensus messages, it can do anything on chain that any other account can do, including calling smart contrats. ## Testing / edge cases * set the consensus key to a third key, then back to the baker key * set two delegates to the same consensus key (should work) * set a delegate to a consensus key that is also a delegate (should work) -* empty the account of the consensus key (what happens then?) +* empty the account of the consensus key when it's active (what happens then?) * delegate the consensus key to any baker (should always work) -- GitLab From e4c5b0eedf89f7c16641e7a50c86c6a5ff8d1fb5 Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Sat, 16 Apr 2022 10:30:22 -0700 Subject: [PATCH 06/21] move more paragraphs to Q&A for clarity --- drafts/current/draft-consensus-key.md | 32 ++++++++++++++++++--------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index d946fae..bee4a21 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -118,9 +118,8 @@ Key rotation is a common feature of any cryptosystem. Having a parent key delega It also allows establishment of baking operations in an environment where access is not ultimately guaranteed: for example, a cloud platform providing hosted Key Management Systems where the private key is generated within the system and can never be downloaded by the baker. The baker can designate such KMS key as consensus key. Shall they lose access to the cloud platform for any reason, they can simply rotate to a new key. -Moreover, this proposal allows the baker to sign their consensus operations using new signature schemes as they get introduced in Tezos. They may elect to do so for performance or security reasons. The ultimate authority still rests on the parent key which can not be rotated. The security of the signature scheme of the parent key may decrease over time, however the fact that this key is used less often than the consensus key helps to mitigate this. +Moreover, this proposal allows the baker to sign their consensus operations using new signature schemes as they get introduced in Tezos. They may elect to do so for performance or security reasons. -As a private baker, it is possible to put 90% of the funds in cold storage, in an account that delegates to the baker. This is however an imperfect substitute to this proposal, given that it still leaves 10% of the funds in the baker's account. It is also not doable for a public baker who may have 100% of their balance frozen. ### `drain` @@ -128,18 +127,16 @@ The motivation of the `drain` operation is twofold. #### As a deterrent against handing over the key to a third party -When there is one key, whoever has access to it has full control over the baker. When there are two keys, the possibility emerges of each of these keys being controlled by different people or entities. For example, the delegate key could be in physical custody of the baker, while the consensus key could be: - -* hosted in a cloud platform where the cloud provider merely grants access to the baker, to be revoked at their discretion, -* handed to a service provider taking care of the baking operations on behalf of the baker (baking-as-a-service operator) +When there is one key, whoever has access to it has full control over the baker. When there are two keys, the possibility emerges of each of these keys being controlled by different people or entities. For example, the delegate key would be in physical custody of the baker, while the consensus key could be: -This constitues a centralization risk: some cloud operators have a large market share, which may give them the power to disrupt or stop the network. Some baking providers may also become dominant. +* hosted in a cloud platform where the cloud provider may revoke access unilaterally, +* handed to a contractor or baking-as-a-service provider taking care of the baking operations on behalf of the baker. -There are risks to this regardless of the existence of the `drain` operation: indeed, anyone with access to the consensus key has the ability to double sign, which can result in the delegate being slashed. Shall the attacker have baking rights, they may inject the denunciation operation in their own block, stealing half of the frozen balance, while the other half is burned. +This constitues a centralization risk: -Therefore, a rigorous baker will not hand off their consensus key to an untrusted party. +* some cloud operators have a large market share, which may give them the power to disrupt or stop the network, +* dominant baking service providers may emerge. -When the drain operation is enabled, a compromise of the consensus key allows a motivated attacker to spend all of the baker's balance. Indeed, the drain operation always takes precedence over any transaction in any block (TODO confirm this). Therefore, a motivated attacker is able to steal all of the baker's money by timing their drain operations appropriately, even if all of the balance is initially frozen. The drain operation acts as an additional deterrent and ensures that the consensus keys ultimately has the same control over the balance than the delegate's key. @@ -164,11 +161,24 @@ The `consensus_key_drain_toggle` governance toggle leaves the matter for the com We rejected the baking key rotation idea due to its intrusiveness. In particular, it would require all delegations to be changed to the new key. +#### What if the signature scheme of the parent key turns out to be insecure? +In this proposal, the ultimate authority indeed rests on the parent key which can not be rotated. The security of the signature scheme of the parent key may decrease over time. However, the less often a key is used, the more secure it is. + +#### A baker can already self-delegate to put most funds in a cold wallet. Why do we need a consensus key? + +As a private baker, it is possible to put 90% of the funds in cold storage, in an account that delegates to the baker. This is however an imperfect substitute to this proposal, given that it still leaves 10% of the funds in the baker's account. It is also not doable for a public baker who may have 100% of their balance frozen. +#### Why is the drain operation necessary? Isn't giving away your consensus key risky, even in the absence of a drain operation? + +Indeed, anyone with access to the consensus key has the ability to double sign, which can result in the delegate being slashed. Shall the attacker have baking rights, they may inject the denunciation operation in their own block, stealing half of the frozen balance, while the other half is burned. + +Therefore, a rigorous baker will not hand off their consensus key to an untrusted party. But, the drain operation makes it more evident. + +When the drain operation is enabled, a compromise of the consensus key allows a motivated attacker to spend all of the baker's balance. Indeed, the drain operation always takes precedence over any transaction in any block (TODO confirm this). Therefore, a motivated attacker is able to steal all of the baker's money by timing their drain operations appropriately, even if all of the balance is initially frozen. #### Why not change the encoding of the baking key to something different than a `tz` address such as `BAKxxx` or `SG1xxx`? This change would be disruptive in the community and mandate a lot of changes in tooling, for questionable benefit. -#### Can the baking key be a multisig? Can we have smart contracts manage baking? Can the rewards be sent to a third address? +#### Can the baking key be a multisig? Can we have smart contracts manage baking? Can the rewards be sent to a third address? Can a third address be used for voting? All of these topics were discussed in the past. A previous TZIP called "Baking accounts" was implementing some of these ideas, but was ultimately rejected by the community because of technical shortcomings. We are actively limiting the scope and the amount of code changes in this TZIP to solve the narrower goal of having a separate consensus key. -- GitLab From d12efaf96b9e60eb4989c78e8be816e62a94dd7c Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Sat, 16 Apr 2022 15:50:18 -0700 Subject: [PATCH 07/21] clarify toggle motivation --- drafts/current/draft-consensus-key.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index bee4a21..6c6800c 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -145,15 +145,24 @@ The drain operation acts as an additional deterrent and ensures that the consens A baker may lose their baking key. In this case, they may stop baking, wait `PRESERVED_CYCLES`, and then recover their funds with the `drain` operation. They may then start baking from another account. ### `consensus_key_drain_toggle` governance toggle -The introduction of the consensus key is an uncontroversial and long-standing request from the community. Many competing blockchains already have this feature implemented. But the permissions granted to the key have been subject to vigourous debate in the past. -A good case can be made for disabling the `drain` operation: it increases the security posture of the baker even further. Indeed, in the absence of the drain operation, a compromise of the consensus key does not put the unfrozen balance at risk. It still exposes the baker to a double signing attack, but this attack is complex to pull off and results in half of the frozen balance being burned. +The permissions granted to a consensus key have been subject to vigourous debate in the past. -On the other hand, disabling the `drain` operation also disables the recovery mechanism from loss of the baker key, and re-introduces concerns expressed above about changing the decentralization dynamics of the network. +The core argument against the existence of the `drain` operation is that it increases the security posture of the baker even further. Indeed, in the absence of the drain operation, a compromise of the consensus key does not put the unfrozen balance at risk. -The [liquidity baking toggle vote](https://gitlab.com/tezos/tzip/-/blob/master/drafts/current/draft-symmetric-liquidity-baking-toggle-vote.md) TZIP introduced a mechanism for fast and concurrent governance signaling mechanisms. This mechanism is suitable for a binary decision such as enabling or disabling an operation. +On the other hand, we already listed the arguments for keeping the `drain` operation enabled: +* it stands as a recovery mechanism in case of baker's key loss, +* it deters bakers from handing off the baker key to third-parties, which is good for decentralization. -The `consensus_key_drain_toggle` governance toggle leaves the matter for the community to decide, separately from the feature itself. +It is useful to ask two questions: +* should the consensus key exist at all? The answer is an uncontroversial yes. A consensus key is long-standing request from the community. Many competing blockchains already have this feature implemented. +* what permissions should be granted to it? Opinions on the matter differ, but we believe they can coalesce into a binary question on whether the `drain` operation as proposed should exist or not. + +The [liquidity baking toggle vote](https://gitlab.com/tezos/tzip/-/blob/master/drafts/current/draft-symmetric-liquidity-baking-toggle-vote.md) TZIP introduced a mechanism for fast and concurrent governance signaling mechanisms. + +This mechanism is suitable for a binary decision such as enabling or disabling the `drain` operation. Therefore, the proposed `consensus_key_drain_toggle` governance toggle leaves the matter for the community to decide, separately from the feature itself. + +The operation will initially be enabled. When setting up their baker for the new protocol, bakers will have to choose whether to vote `pass`, `on` and `off`. ### Q&A -- GitLab From ae03dceda883789b63c0ac8c6b01afa70c1dcc94 Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Sat, 16 Apr 2022 16:18:43 -0700 Subject: [PATCH 08/21] phrasing --- drafts/current/draft-consensus-key.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 6c6800c..3b8d498 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -50,7 +50,7 @@ We propose to add two new operations: This operation immediately transfers all the free balance of the manager account into the consensus account. It has no effect on the frozen balance. - This operation fails if the governance toggle `consensus_key_drain_toggle` is set to False. + This operation fails if the governance toggle `consensus_key_drain_toggle` is set to **Off**. ### `consensus_key_drain_toggle` toggle vote @@ -127,18 +127,19 @@ The motivation of the `drain` operation is twofold. #### As a deterrent against handing over the key to a third party -When there is one key, whoever has access to it has full control over the baker. When there are two keys, the possibility emerges of each of these keys being controlled by different people or entities. For example, the delegate key would be in physical custody of the baker, while the consensus key could be: +When there is one key, whoever has access to it has full control over the baker. When there are two keys, the possibility emerges of each of these keys being controlled by different people or entities. For example, the delegate key would likely be in physical custody of the baker, while the consensus key could be handed to, or created by: -* hosted in a cloud platform where the cloud provider may revoke access unilaterally, -* handed to a contractor or baking-as-a-service provider taking care of the baking operations on behalf of the baker. +* a cloud platform, or +* a contractor or baking-as-a-service provider taking care of the baking operations on behalf of the baker. This constitues a centralization risk: -* some cloud operators have a large market share, which may give them the power to disrupt or stop the network, +* the cloud platform may revoke access unilaterally. Some cloud operators have a large market share, which may give them the power to disrupt or stop the network, * dominant baking service providers may emerge. +At any time, if over one third of the stake goes offline, the chain can not move forward. Decentralization is key to avoiding this. -The drain operation acts as an additional deterrent and ensures that the consensus keys ultimately has the same control over the balance than the delegate's key. +The drain operation acts as an deterrent against centralization and ensures that the consensus keys ultimately has the same control over the balance than the delegate's key. #### As a recovery mechanism from baker's key loss @@ -146,7 +147,7 @@ A baker may lose their baking key. In this case, they may stop baking, wait `PRE ### `consensus_key_drain_toggle` governance toggle -The permissions granted to a consensus key have been subject to vigourous debate in the past. +The permissions granted to a potential consensus key have been subject of vigourous debates in the past. The core argument against the existence of the `drain` operation is that it increases the security posture of the baker even further. Indeed, in the absence of the drain operation, a compromise of the consensus key does not put the unfrozen balance at risk. @@ -168,7 +169,7 @@ The operation will initially be enabled. When setting up their baker for the new #### Why not introduce a mechanism to rotate the baking key altogether? -We rejected the baking key rotation idea due to its intrusiveness. In particular, it would require all delegations to be changed to the new key. +The implmementation of such a rotation mechanism would be very intrusive. In particular, it would require all delegations to be changed to the new key. We believe that a parent/key design is a better path to solving the issue. #### What if the signature scheme of the parent key turns out to be insecure? In this proposal, the ultimate authority indeed rests on the parent key which can not be rotated. The security of the signature scheme of the parent key may decrease over time. However, the less often a key is used, the more secure it is. -- GitLab From de1b72b8e441bb36c256f1c6324c6db4e5686fbc Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Mon, 18 Apr 2022 09:40:43 -0700 Subject: [PATCH 09/21] switch initial EMA to 0 --- drafts/current/draft-consensus-key.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 3b8d498..2d42cfa 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -86,7 +86,7 @@ In each block, the EMA is updated as follows: The migration establishes the correspondance table between the manager accounts and their consensus keys. Initially, all manager accounts and consensus keys are equal. -The migration also sets the initial EMA of the toggle vote to 1 billion. +The migration also sets the initial EMA of the toggle vote to zero. ### Commands @@ -165,6 +165,8 @@ This mechanism is suitable for a binary decision such as enabling or disabling t The operation will initially be enabled. When setting up their baker for the new protocol, bakers will have to choose whether to vote `pass`, `on` and `off`. +The threshold for disabling the operation is at 50% (simple majority). The exponential moving average is initially set to zero, as if 100% of the stake was in favor of enabling it: this matches the current reality on the network where the owner of the consensus key can spend the free balance. In order to disable it, it is necessary to have more `Off` than `On` votes for a sufficiently long period before it goes over the threshold. + ### Q&A #### Why not introduce a mechanism to rotate the baking key altogether? -- GitLab From 1b8d82cc93cef81b20d39db7ec9e5802408b1c3f Mon Sep 17 00:00:00 2001 From: "G.B. Fefe" Date: Tue, 19 Apr 2022 22:37:01 +0200 Subject: [PATCH 10/21] update following the latest implementation --- drafts/current/draft-consensus-key.md | 94 ++++++++++++++++++--------- 1 file changed, 63 insertions(+), 31 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 2d42cfa..6b2be59 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -22,37 +22,50 @@ Separating keys allows separation of human responsibilities, which may alter the ## Design -We add a second key to delegates, called the consensus key. This consensus key is used instead of the regular key of the delegate (a.k.a. the manager key or the parent key) for signing blocks and (pre)endorsements. By default, the manager key and the consensus key are equal. +### A new consensus key table in the context -Internally, a table associates the manager keys to their respective consensus keys. This table is stored in the context. (right?) +We propose to add a second key to delegates, called the consensus key. This +consensus key is used instead of the regular key of the delegate +(a.k.a. the manager key or the parent key) for signing blocks and +(pre)endorsements. By default, the manager key and the consensus key are +equal. -The consensus key of a given delegate is set per cycle to whatever the consensus key is set in the table at the time the snapshot is taken. +Internally, a table associates the manager keys to their respective +consensus keys. This table is stored in the context, and is called the +consensus key table in this document. + +The key currently used to sign blocks and (pre)endorsements is called the +active consensus key of a given delegate. It is set per cycle to whatever +the consensus key is set in the consensus key table at the time the +stake snapshot is taken. + +### Two new operations in the protocol We propose to add two new operations: - `Update_consensus_key ` - This operation must be signed by the manager key of a delegate. It - will change the consensus key associated to the delegate: the new - key will be used instead of the old key when computing the future - baking rights distributions, meaning that the key will be required - for signing blocks and endorsement in `preserved_cycles` (currently - 5 cycles in Ithaca). + This operation must be signed by the manager key of a delegate. - - It is required that the account used as consensus key be allocated. The operation fails otherwise. + It will change the consensus key associated to the delegate in the + consensus key table. The new key will now be used instead of the old key + when computing the baking rights distributions, meaning that the key will + become active and be required for signing blocks and endorsement in + `preserved_cycles` (currently 5 cycles in Ithaca). - Several bakers can have their consensus key set to the same key. + At any time, only one baker can use a consensus key at any give time. -- `drain` +- `Drain_delegate ` - This operation must be signed by the consensus key of a delegate currently allowed to sign consensus operations. + This operation must be signed by the consensus key of a delegate, + as currently set in the consensus key table. This operation immediately transfers all the free balance of the manager account into the consensus account. It has no effect on the frozen balance. - This operation fails if the governance toggle `consensus_key_drain_toggle` is set to **Off**. + This operation fails if the governance toggle `drain_toggle` is set to + **Off** (see next section) -### `consensus_key_drain_toggle` toggle vote +### A new toggle vote `drain_toggle_vote` The Toggle Vote for the drain operation relies on the computation of an exponential moving average (EMA) of the signals sent by bakers in @@ -70,7 +83,8 @@ _threshold_ of the Toggle Vote. When the EMA is above the threshold, it means that **Off** votes have the majority. On the opposite, a value below the threshold means that **On** votes have the majority. -The `drain` operation works if and only if the EMA is below the threshold. +The `Drain_delegate` operation works if and only if the EMA is below the +threshold. More precisely, the EMA is a natual number whose value can vary between 0 and 2 billion and the threshold is 1 billion. @@ -84,17 +98,18 @@ In each block, the EMA is updated as follows: ### Protocol migration -The migration establishes the correspondance table between the manager accounts and their consensus keys. Initially, all manager accounts and consensus keys are equal. +The proposed amendment needs to initialize the new consensus key table. +It will iterate on all registered delegates (around ~2500) and set +the consensus key to be equal to the manager key. The migration also sets the initial EMA of the toggle vote to zero. -### Commands - +### New commands in `tezos-client` A consensus key can be changed at any point. This may be done with the command: ```shell -tezos-client set baker consensus key to +tezos-client set consensus key for to ``` The current registration command still works: @@ -109,10 +124,21 @@ It is also possible to register as a delegate and immediately set the consensus tezos-client register key as delegate with consensus key ``` -TODO discuss this and figure out if it's true +The drain operation might be sent with: + +```shell +tezos-client drain delegate to +``` + +### A new flag to the baker + +Like the mandatory flag `--liquidity-baking-togle-vote [on|off|pass]`, the +baker now requires the flag `--drain-toggle-vote [on|off|pass]`. + + ## Motivation -### `update_consensus_key` +### `Update_consensus_key` Key rotation is a common feature of any cryptosystem. Having a parent key delegate responsibilities to a child key allows for optimal protection of the parent key, for example in a cold wallet. @@ -121,9 +147,9 @@ It also allows establishment of baking operations in an environment where access Moreover, this proposal allows the baker to sign their consensus operations using new signature schemes as they get introduced in Tezos. They may elect to do so for performance or security reasons. -### `drain` +### `Drain_delegate` -The motivation of the `drain` operation is twofold. +The motivation of the `Drain_delegate` operation is twofold. #### As a deterrent against handing over the key to a third party @@ -143,15 +169,15 @@ The drain operation acts as an deterrent against centralization and ensures that #### As a recovery mechanism from baker's key loss -A baker may lose their baking key. In this case, they may stop baking, wait `PRESERVED_CYCLES`, and then recover their funds with the `drain` operation. They may then start baking from another account. +A baker may lose their baking key. In this case, they may stop baking, wait `PRESERVED_CYCLES`, and then recover their funds with the `Drain_delegate` operation. They may then start baking from another account. -### `consensus_key_drain_toggle` governance toggle +### `drain_toggle` governance toggle The permissions granted to a potential consensus key have been subject of vigourous debates in the past. -The core argument against the existence of the `drain` operation is that it increases the security posture of the baker even further. Indeed, in the absence of the drain operation, a compromise of the consensus key does not put the unfrozen balance at risk. +The core argument against the existence of the `Drain_delegate` operation is that it increases the security posture of the baker even further. Indeed, in the absence of the drain operation, a compromise of the consensus key does not put the unfrozen balance at risk. -On the other hand, we already listed the arguments for keeping the `drain` operation enabled: +On the other hand, we already listed the arguments for keeping the `Drain_delegate` operation enabled: * it stands as a recovery mechanism in case of baker's key loss, * it deters bakers from handing off the baker key to third-parties, which is good for decentralization. @@ -192,7 +218,7 @@ This change would be disruptive in the community and mandate a lot of changes in #### Can the baking key be a multisig? Can we have smart contracts manage baking? Can the rewards be sent to a third address? Can a third address be used for voting? -All of these topics were discussed in the past. A previous TZIP called "Baking accounts" was implementing some of these ideas, but was ultimately rejected by the community because of technical shortcomings. We are actively limiting the scope and the amount of code changes in this TZIP to solve the narrower goal of having a separate consensus key. +All of these topics were discussed in the past. A previous TZIP draft called "Baking accounts" was implementing some of these ideas, but was ultimately rejected by the community because of technical shortcomings. We are actively limiting the scope and the amount of code changes in this TZIP to solve the narrower goal of having a separate consensus key. #### Have you addressed all the unexpected breaking changes of the previous baking accounts proposal? @@ -202,7 +228,13 @@ Specifically this quote: > A future version of Baking Accounts which does not break current contracts and preserves important invariants is possible, and should be developed to take its place. -We believe that the current proposal fits this description. Unlike the previous proposal, we are not allowing bakers to be controlled by multisignature smart contracts. As a result, we did not change any Michelson instruction and no smart contracts will break. Moreover, the consensus key is a regular implicit account with its own balance. In addition to signing consensus messages, it can do anything on chain that any other account can do, including calling smart contrats. +We believe that the current proposal fits this description. Unlike the +previous proposal, we are not allowing bakers to be controlled by +multisignature smart contracts. As a result, we did not change any +Michelson instruction and no smart contracts will break. Moreover, the +consensus key is a regular implicit account with its own balance. In +addition to signing consensus messages, it can at any time do anything on +chain that any other account can do, including calling smart contrats. ## Testing / edge cases -- GitLab From 07688d96b19a6b5212aa1e57550432ffb060161a Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Tue, 19 Apr 2022 19:07:26 -0700 Subject: [PATCH 11/21] make TZIP more convincing Emphasize the arguments that it's good for bakers some phrasing fixes reomved the reference about ordering of transactions (too obscure) --- drafts/current/draft-consensus-key.md | 30 ++++++++++----------------- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 6b2be59..4afeb51 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -10,15 +10,15 @@ version: 0 ## Summary -This TZIP describes a proposed protocol-amendment that would allow bakers to designate a consensus key responsible for signing baking and endorsing operations. This improves the operational security of Tezos bakers. +This TZIP describes a proposed protocol-amendment that would allow bakers to designate a consensus key responsible for signing baking and endorsing operations. This allows bakers to improve their operational security without the need for redelegation. ## Abstract In the current version of the Tezos protocol (Ithaca), a baker is identified by a public key hash, e.g. a `tz1...` address. Like any public key hash in Tezos, this hash, or address, identifies an implicit account, i.e. a balance and the corresponding keypair allowed to withdraw funds. If for any reason a baker want to change the keypair used for signing consensus operations, they have to have all their delegator accounts redelegate to the hash of their new public key. This TZIP aims to ease this process and to avoid any redelegations. -For this purpose, we propose to reuse the oldest trick in programming history: to add an intermediate pointer. With this proposal, the address of a baker does not designate an implicit account anymore but a reference to an implicit account. The baker may change the referenced implicit account by calling the newly introduced `update_consensus_key` operation, thus transfering to it all the block-signing rights and (pre)endorsements-signing rights after a delay of `PRESERVED_CYCLES + 1`. +For this purpose, we propose to reuse the oldest trick in programming history: to add an intermediate pointer. With this proposal, the address of a baker does not designate an implicit account anymore but a reference to an implicit account. The baker may change the referenced implicit account by calling the newly introduced `Update_consensus_key` operation, thus transfering to it all the block-signing rights and (pre)endorsements-signing rights after a delay of `PRESERVED_CYCLES + 1`. -Separating keys allows separation of human responsibilities, which may alter the decentralization dynamics of the network. To neutralize this concern, a newly introduced `drain` operation allows the consensus key to transfer all the free balance of the baker to its own implicit account. This roughly confers the same powers to both keys. However, a newly introduced governance toggle `consensus_key_drain_toggle` will allow a majority of bakers to disable this `drain` operation later on, if they so choose. +Separating keys allows separation of human responsibilities, which may alter the decentralization dynamics of the network. To neutralize this concern, a newly introduced `drain` operation allows the consensus key to transfer all the free balance of the baker to its own implicit account. This roughly confers the same powers to both keys. However, a newly introduced governance toggle `--drain-toggle-vote` will allow a majority of voting bakers to disable this `drain` operation later on, if they so choose. ## Design @@ -53,7 +53,7 @@ We propose to add two new operations: become active and be required for signing blocks and endorsement in `preserved_cycles` (currently 5 cycles in Ithaca). - At any time, only one baker can use a consensus key at any give time. + At any time, a consensus key can only be used by a single baker, the operation fails otherwise. - `Drain_delegate ` @@ -142,7 +142,7 @@ baker now requires the flag `--drain-toggle-vote [on|off|pass]`. Key rotation is a common feature of any cryptosystem. Having a parent key delegate responsibilities to a child key allows for optimal protection of the parent key, for example in a cold wallet. -It also allows establishment of baking operations in an environment where access is not ultimately guaranteed: for example, a cloud platform providing hosted Key Management Systems where the private key is generated within the system and can never be downloaded by the baker. The baker can designate such KMS key as consensus key. Shall they lose access to the cloud platform for any reason, they can simply rotate to a new key. +It also allows establishment of baking operations in an environment where access is not ultimately guaranteed: for example, a cloud platform providing hosted Key Management Systems where the private key is generated within the system and can never be downloaded by the operator. The baker can designate such KMS key as consensus key. Shall they lose access to the cloud platform for any reason, they can simply rotate to a new key. Moreover, this proposal allows the baker to sign their consensus operations using new signature schemes as they get introduced in Tezos. They may elect to do so for performance or security reasons. @@ -175,7 +175,7 @@ A baker may lose their baking key. In this case, they may stop baking, wait `PRE The permissions granted to a potential consensus key have been subject of vigourous debates in the past. -The core argument against the existence of the `Drain_delegate` operation is that it increases the security posture of the baker even further. Indeed, in the absence of the drain operation, a compromise of the consensus key does not put the unfrozen balance at risk. +The core argument that has been made is as follows: removing the `Drain_delegate` operation increases the security posture of the baker even further. Indeed, in its absence, a compromise of the consensus key does not put the unfrozen balance at risk. On the other hand, we already listed the arguments for keeping the `Drain_delegate` operation enabled: * it stands as a recovery mechanism in case of baker's key loss, @@ -197,7 +197,7 @@ The threshold for disabling the operation is at 50% (simple majority). The expon #### Why not introduce a mechanism to rotate the baking key altogether? -The implmementation of such a rotation mechanism would be very intrusive. In particular, it would require all delegations to be changed to the new key. We believe that a parent/key design is a better path to solving the issue. +The implementation of such a rotation mechanism would be very intrusive. In particular, it would require all delegations to be changed to the new key. We believe that a parent/key design is a better path to solving the issue. #### What if the signature scheme of the parent key turns out to be insecure? In this proposal, the ultimate authority indeed rests on the parent key which can not be rotated. The security of the signature scheme of the parent key may decrease over time. However, the less often a key is used, the more secure it is. @@ -209,16 +209,16 @@ As a private baker, it is possible to put 90% of the funds in cold storage, in a Indeed, anyone with access to the consensus key has the ability to double sign, which can result in the delegate being slashed. Shall the attacker have baking rights, they may inject the denunciation operation in their own block, stealing half of the frozen balance, while the other half is burned. -Therefore, a rigorous baker will not hand off their consensus key to an untrusted party. But, the drain operation makes it more evident. +Therefore, a rigorous baker will not hand off their consensus key to an untrusted party. -When the drain operation is enabled, a compromise of the consensus key allows a motivated attacker to spend all of the baker's balance. Indeed, the drain operation always takes precedence over any transaction in any block (TODO confirm this). Therefore, a motivated attacker is able to steal all of the baker's money by timing their drain operations appropriately, even if all of the balance is initially frozen. +But the drain operation makes the risk of doing so more evident: when the drain operation is enabled, a compromise of the consensus key allows a motivated attacker to spend all of the baker's balance. #### Why not change the encoding of the baking key to something different than a `tz` address such as `BAKxxx` or `SG1xxx`? This change would be disruptive in the community and mandate a lot of changes in tooling, for questionable benefit. -#### Can the baking key be a multisig? Can we have smart contracts manage baking? Can the rewards be sent to a third address? Can a third address be used for voting? +#### Can the baking key be a multisig? Can we have smart contracts manage baking? Can the rewards be sent to a third address? Can a third address be used for voting? Can we have a toggle to disallow new delegations? -All of these topics were discussed in the past. A previous TZIP draft called "Baking accounts" was implementing some of these ideas, but was ultimately rejected by the community because of technical shortcomings. We are actively limiting the scope and the amount of code changes in this TZIP to solve the narrower goal of having a separate consensus key. +All of these topics were discussed in the past. A previous TZIP draft called "Baking accounts" was implementing some of these ideas, but was ultimately rejected by the community because of technical shortcomings. We are actively limiting the scope and the amount of code changes in this TZIP to solve the narrower goal of having a separate consensus key. Some of this ideas may be proposed in future TZIPs. #### Have you addressed all the unexpected breaking changes of the previous baking accounts proposal? @@ -235,11 +235,3 @@ Michelson instruction and no smart contracts will break. Moreover, the consensus key is a regular implicit account with its own balance. In addition to signing consensus messages, it can at any time do anything on chain that any other account can do, including calling smart contrats. - -## Testing / edge cases - -* set the consensus key to a third key, then back to the baker key -* set two delegates to the same consensus key (should work) -* set a delegate to a consensus key that is also a delegate (should work) -* empty the account of the consensus key when it's active (what happens then?) -* delegate the consensus key to any baker (should always work) -- GitLab From f714a5f404c842269805d252acae5c020ceb84b6 Mon Sep 17 00:00:00 2001 From: "G.B. Fefe" Date: Fri, 22 Apr 2022 12:02:58 +0200 Subject: [PATCH 12/21] Drain is signed by the "active" consensus key --- drafts/current/draft-consensus-key.md | 41 ++++++++------------------- 1 file changed, 12 insertions(+), 29 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 4afeb51..56c36f4 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -14,58 +14,39 @@ This TZIP describes a proposed protocol-amendment that would allow bakers to des ## Abstract -In the current version of the Tezos protocol (Ithaca), a baker is identified by a public key hash, e.g. a `tz1...` address. Like any public key hash in Tezos, this hash, or address, identifies an implicit account, i.e. a balance and the corresponding keypair allowed to withdraw funds. If for any reason a baker want to change the keypair used for signing consensus operations, they have to have all their delegator accounts redelegate to the hash of their new public key. This TZIP aims to ease this process and to avoid any redelegations. +In the current version of the Tezos protocol (Ithaca), a baker is identified by a public key hash, e.g. a `tz1...` address. Like any public key hash in Tezos, this hash, or address, identifies an implicit account, i.e. a balance and the corresponding keypair allowed to withdraw funds. If for any reason a baker want to change the keypair used for signing consensus operations, they have to have all their delegator accounts manually redelegate to the hash of their new public key. This TZIP aims to ease this process and to avoid any explicit redelegations. -For this purpose, we propose to reuse the oldest trick in programming history: to add an intermediate pointer. With this proposal, the address of a baker does not designate an implicit account anymore but a reference to an implicit account. The baker may change the referenced implicit account by calling the newly introduced `Update_consensus_key` operation, thus transfering to it all the block-signing rights and (pre)endorsements-signing rights after a delay of `PRESERVED_CYCLES + 1`. +For this purpose, we propose to associate a second keypair to registered bakers, called the consensus key or the child key. By default this key is equal to the regular key of the baker (a.k.a. the manager key or the parent key). A baker may change the consensus key by calling the newly introduced `Update_consensus_key` operation, thus transfering to it all the block-signing rights and (pre)endorsements-signing rights after a delay of `PRESERVED_CYCLES + 1`. -Separating keys allows separation of human responsibilities, which may alter the decentralization dynamics of the network. To neutralize this concern, a newly introduced `drain` operation allows the consensus key to transfer all the free balance of the baker to its own implicit account. This roughly confers the same powers to both keys. However, a newly introduced governance toggle `--drain-toggle-vote` will allow a majority of voting bakers to disable this `drain` operation later on, if they so choose. +Separating keys allows separation of human responsibilities, which may alter the decentralization dynamics of the network. To neutralize this concern, a newly introduced `Drain_delegate` operation allows the consensus key to transfer all the free balance of the baker to its own implicit account. This roughly confers the same powers to both keys. However, a newly introduced governance toggle `--drain-toggle-vote` will allow a majority of voting bakers to disable this `Drain_delegate` operation later on, if they so choose. ## Design ### A new consensus key table in the context -We propose to add a second key to delegates, called the consensus key. This -consensus key is used instead of the regular key of the delegate -(a.k.a. the manager key or the parent key) for signing blocks and -(pre)endorsements. By default, the manager key and the consensus key are -equal. - -Internally, a table associates the manager keys to their respective -consensus keys. This table is stored in the context, and is called the -consensus key table in this document. - -The key currently used to sign blocks and (pre)endorsements is called the -active consensus key of a given delegate. It is set per cycle to whatever -the consensus key is set in the consensus key table at the time the -stake snapshot is taken. +We propose to extend the context with a new table storing, per cycle and per baker, the public key of the active consensus key. In this document, this newly introduced table is referenced as the consensus key table. The key associated to the current cycle is called the active consensus key of a baker. The keys associated to the upcoming cycles are called pending consensus keys. When taking stake snapshot for computing baking rights and endorsing rights for a given cycle, the consensus key active for the cycle is used instead of the manager key. ### Two new operations in the protocol We propose to add two new operations: -- `Update_consensus_key ` +- `Update_consensus_key (, )` This operation must be signed by the manager key of a delegate. - It will change the consensus key associated to the delegate in the - consensus key table. The new key will now be used instead of the old key - when computing the baking rights distributions, meaning that the key will - become active and be required for signing blocks and endorsement in - `preserved_cycles` (currently 5 cycles in Ithaca). + It will change the consensus key associated to the signing delegate in the consensus key table, starting at cycle ``. The current implementation requires that `` is equal to the current cycle plus `PRESERVED_CYCLES + 1`. At any time, a consensus key can only be used by a single baker, the operation fails otherwise. - `Drain_delegate ` - This operation must be signed by the consensus key of a delegate, - as currently set in the consensus key table. + This operation must be signed by the active consensus key of a delegate. - This operation immediately transfers all the free balance of the manager account into the consensus account. It has no effect on the frozen balance. + This operation immediately transfers all the free balance of the manager implicit account into the consensus implicit account. It has no effect on the frozen balance. - This operation fails if the governance toggle `drain_toggle` is set to - **Off** (see next section) + This operation fails if the governance toggle `--drain-toggle-vote` is set to **Off**, see next section. -### A new toggle vote `drain_toggle_vote` +### A new toggle vote `--drain-toggle-vote` The Toggle Vote for the drain operation relies on the computation of an exponential moving average (EMA) of the signals sent by bakers in @@ -104,6 +85,8 @@ the consensus key to be equal to the manager key. The migration also sets the initial EMA of the toggle vote to zero. +The stake snapshots for the next `PRESERVED_CYCLES` are also reallocated. They now snapshot both the consensus public key and the manager public key hash. Yet, the baking and endorsing rights are unchanged. + ### New commands in `tezos-client` A consensus key can be changed at any point. This may be done with the command: -- GitLab From f8e0aba2ea0caecc677b38358d5c251d3e9881af Mon Sep 17 00:00:00 2001 From: "G.B. Fefe" Date: Fri, 22 Apr 2022 12:03:20 +0200 Subject: [PATCH 13/21] Document changes in RPC --- drafts/current/draft-consensus-key.md | 96 +++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 56c36f4..96c4549 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -218,3 +218,99 @@ Michelson instruction and no smart contracts will break. Moreover, the consensus key is a regular implicit account with its own balance. In addition to signing consensus messages, it can at any time do anything on chain that any other account can do, including calling smart contrats. + +## Change in RPCs + +- `GET /chains/main/blocks/head/header` + + The protocol specific part of a block header is extended with a new toggle vote: + +``` + "drain_toggle_vote": "off|on|pass", +``` + +- `GET /chains/main/blocks/head/context/constants` + + A new constant is exported: + +`` + "drain_toggle_ema_threshold": 1000000000 +`` + +- GET `/chains/main/blocks/head/metadata` + + The block metadata are extended with the active consensus key of the baker and proposer. The field `proposer` and `baker` still hold the respective public key hash of the manager keys of the proposer and baker. The block metadata also export the current value of the drain toggle ema. + +``` + "proposer_consensus_key": "[PUBLIC_KEY_HASH]", + "baker_consensus_key": "[PUBLIC_KEY_HASH]", + "drain_toggle_ema": 1234567890, +``` + +- `GET /chains/main/blocks/head/context/delegates/[PUBLIC_KEY_HASH]` + + The delegate data are extended with active and pending consensus keys. + +``` +{ "full_balance": "4000000000000", + "current_frozen_deposits": "200000000000", + "frozen_deposits": "200000000000", + "staking_balance": "4000000000000", + "delegated_contracts": [ "[PUBLIC_KEY_HASH]" ], + "delegated_balance": "0", + "deactivated": false, + "grace_period": 5, + "voting_power": "4000000000000", + "active_consensus_key": "[PUBLIC_KEY_HASH]", + "pending_consensus_keys": [ + { "cycle": 7, "pkh": "[PUBLIC_KEY_HASH]}, + { "cycle": 9, "pkh": "[PUBLIC_KEY_HASH]} + ] + } +``` + +- `GET /chains/main/blocks/head/helpers/baking_rights` + + The baking rights RPC now returns both the manager key, required to identify the rewarded delegate, and the active consensus key required to sign block. The RPC also accepts a new parameter `consensus_key=` to filter the result by active consensus key. + +``` +[ { "level": 2, "delegate": "[PUBLIC_KEY_HASH]", + "round": 0, "estimated_time": "[TIMESTAMP]", + "consensus_key": "[PUBLIC_KEY_HASH]" }, + { "level": 2, "delegate": "[PUBLIC_KEY_HASH]", + "round": 1, "estimated_time": "[TIMESTAMP]", + "consensus_key": "[PUBLIC_KEY_HASH]" }, + { "level": 2, "delegate": "[PUBLIC_KEY_HASH]", + "round": 2, "estimated_time": "[TIMESTAMP]", + "consensus_key": "[PUBLIC_KEY_HASH]" }, + { "level": 2, "delegate": "[PUBLIC_KEY_HASH]", + "round": 3, "estimated_time": "[TIMESTAMP]", + "consensus_key": "[PUBLIC_KEY_HASH]" }, + { "level": 2, "delegate": "[PUBLIC_KEY_HASH]", + "round": 10, "estimated_time": "[TIMESTAMP]", + "consensus_key": "[PUBLIC_KEY_HASH]" } ] +``` + +- `GET /chains/main/blocks/head/helpers/endorsing_rights` + + The endorsing rights RPC now returns both the manager key, required to identify the rewarded delegate, and the active consensus key required to sign block. The RPC also accepts a new parameter `consensus_key=` to filter the result by active consensus key. + +``` +[ { "level": 1, + "delegates": + [ { "delegate": "[PUBLIC_KEY_HASH]", + "first_slot": 11, "endorsing_power": 50, + "consensus_key": "[PUBLIC_KEY_HASH]" }, + { "delegate": "[PUBLIC_KEY_HASH]", + "first_slot": 4, "endorsing_power": 47, + "consensus_key": "[PUBLIC_KEY_HASH]" }, + { "delegate": "[PUBLIC_KEY_HASH]", + "first_slot": 2, "endorsing_power": 46, + "consensus_key": "[PUBLIC_KEY_HASH]" }, + { "delegate": "[PUBLIC_KEY_HASH]", + "first_slot": 1, "endorsing_power": 55, + "consensus_key": "[PUBLIC_KEY_HASH]" }, + { "delegate": "[PUBLIC_KEY_HASH]", + "first_slot": 0, "endorsing_power": 58, + "consensus_key": "[PUBLIC_KEY_HASH]" } ] } ] +``` -- GitLab From 41cbb104137c8424ff1b3d3fa13527408a4a5bd8 Mon Sep 17 00:00:00 2001 From: "G.B. Fefe" Date: Sat, 23 Apr 2022 05:57:55 +0200 Subject: [PATCH 14/21] Table of pending updates --- drafts/current/draft-consensus-key.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 96c4549..c63a654 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -24,7 +24,11 @@ Separating keys allows separation of human responsibilities, which may alter the ### A new consensus key table in the context -We propose to extend the context with a new table storing, per cycle and per baker, the public key of the active consensus key. In this document, this newly introduced table is referenced as the consensus key table. The key associated to the current cycle is called the active consensus key of a baker. The keys associated to the upcoming cycles are called pending consensus keys. When taking stake snapshot for computing baking rights and endorsing rights for a given cycle, the consensus key active for the cycle is used instead of the manager key. +We propose to extend the context with two new tables: +- one main table storing the active consensus key of a delegate, +- and a second table storing pending consensus-key updates for a delegate and at which cycle the key must be activated. + +At the end of each cycle, the table of pending updates is traversed: consensus keys that must be activated in the next cycle are removed fpr the pending consensus-key table and inserted into the active consensus-key table. ### Two new operations in the protocol @@ -34,7 +38,7 @@ We propose to add two new operations: This operation must be signed by the manager key of a delegate. - It will change the consensus key associated to the signing delegate in the consensus key table, starting at cycle ``. The current implementation requires that `` is equal to the current cycle plus `PRESERVED_CYCLES + 1`. + It will record the pending update in the pending consensus-key table. The current implementation requires that `` is equal to the current cycle plus `PRESERVED_CYCLES + 1`. At any time, a consensus key can only be used by a single baker, the operation fails otherwise. -- GitLab From 85265dfed8bf1e71cecdc6f58d028b8fdc661b84 Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Fri, 22 Apr 2022 22:29:52 -0700 Subject: [PATCH 15/21] move rpc before motivation add a Q&A "how to bake using consensus key" fix few typos add a "security considerations" section at the end --- drafts/current/draft-consensus-key.md | 226 ++++++++++++++------------ 1 file changed, 124 insertions(+), 102 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index c63a654..69dfd64 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -28,7 +28,7 @@ We propose to extend the context with two new tables: - one main table storing the active consensus key of a delegate, - and a second table storing pending consensus-key updates for a delegate and at which cycle the key must be activated. -At the end of each cycle, the table of pending updates is traversed: consensus keys that must be activated in the next cycle are removed fpr the pending consensus-key table and inserted into the active consensus-key table. +At the end of each cycle, the table of pending updates is traversed: consensus keys that must be activated in the next cycle are removed from the pending consensus-key table and inserted into the active consensus-key table. ### Two new operations in the protocol @@ -50,6 +50,8 @@ We propose to add two new operations: This operation fails if the governance toggle `--drain-toggle-vote` is set to **Off**, see next section. + This operation fails if the implicit account associated with the consensus key is not initialized. + ### A new toggle vote `--drain-toggle-vote` The Toggle Vote for the drain operation relies on the computation of an @@ -123,106 +125,6 @@ Like the mandatory flag `--liquidity-baking-togle-vote [on|off|pass]`, the baker now requires the flag `--drain-toggle-vote [on|off|pass]`. -## Motivation - -### `Update_consensus_key` - -Key rotation is a common feature of any cryptosystem. Having a parent key delegate responsibilities to a child key allows for optimal protection of the parent key, for example in a cold wallet. - -It also allows establishment of baking operations in an environment where access is not ultimately guaranteed: for example, a cloud platform providing hosted Key Management Systems where the private key is generated within the system and can never be downloaded by the operator. The baker can designate such KMS key as consensus key. Shall they lose access to the cloud platform for any reason, they can simply rotate to a new key. - -Moreover, this proposal allows the baker to sign their consensus operations using new signature schemes as they get introduced in Tezos. They may elect to do so for performance or security reasons. - - -### `Drain_delegate` - -The motivation of the `Drain_delegate` operation is twofold. - -#### As a deterrent against handing over the key to a third party - -When there is one key, whoever has access to it has full control over the baker. When there are two keys, the possibility emerges of each of these keys being controlled by different people or entities. For example, the delegate key would likely be in physical custody of the baker, while the consensus key could be handed to, or created by: - -* a cloud platform, or -* a contractor or baking-as-a-service provider taking care of the baking operations on behalf of the baker. - -This constitues a centralization risk: - -* the cloud platform may revoke access unilaterally. Some cloud operators have a large market share, which may give them the power to disrupt or stop the network, -* dominant baking service providers may emerge. - -At any time, if over one third of the stake goes offline, the chain can not move forward. Decentralization is key to avoiding this. - -The drain operation acts as an deterrent against centralization and ensures that the consensus keys ultimately has the same control over the balance than the delegate's key. - -#### As a recovery mechanism from baker's key loss - -A baker may lose their baking key. In this case, they may stop baking, wait `PRESERVED_CYCLES`, and then recover their funds with the `Drain_delegate` operation. They may then start baking from another account. - -### `drain_toggle` governance toggle - -The permissions granted to a potential consensus key have been subject of vigourous debates in the past. - -The core argument that has been made is as follows: removing the `Drain_delegate` operation increases the security posture of the baker even further. Indeed, in its absence, a compromise of the consensus key does not put the unfrozen balance at risk. - -On the other hand, we already listed the arguments for keeping the `Drain_delegate` operation enabled: -* it stands as a recovery mechanism in case of baker's key loss, -* it deters bakers from handing off the baker key to third-parties, which is good for decentralization. - -It is useful to ask two questions: -* should the consensus key exist at all? The answer is an uncontroversial yes. A consensus key is long-standing request from the community. Many competing blockchains already have this feature implemented. -* what permissions should be granted to it? Opinions on the matter differ, but we believe they can coalesce into a binary question on whether the `drain` operation as proposed should exist or not. - -The [liquidity baking toggle vote](https://gitlab.com/tezos/tzip/-/blob/master/drafts/current/draft-symmetric-liquidity-baking-toggle-vote.md) TZIP introduced a mechanism for fast and concurrent governance signaling mechanisms. - -This mechanism is suitable for a binary decision such as enabling or disabling the `drain` operation. Therefore, the proposed `consensus_key_drain_toggle` governance toggle leaves the matter for the community to decide, separately from the feature itself. - -The operation will initially be enabled. When setting up their baker for the new protocol, bakers will have to choose whether to vote `pass`, `on` and `off`. - -The threshold for disabling the operation is at 50% (simple majority). The exponential moving average is initially set to zero, as if 100% of the stake was in favor of enabling it: this matches the current reality on the network where the owner of the consensus key can spend the free balance. In order to disable it, it is necessary to have more `Off` than `On` votes for a sufficiently long period before it goes over the threshold. - -### Q&A - -#### Why not introduce a mechanism to rotate the baking key altogether? - -The implementation of such a rotation mechanism would be very intrusive. In particular, it would require all delegations to be changed to the new key. We believe that a parent/key design is a better path to solving the issue. - -#### What if the signature scheme of the parent key turns out to be insecure? -In this proposal, the ultimate authority indeed rests on the parent key which can not be rotated. The security of the signature scheme of the parent key may decrease over time. However, the less often a key is used, the more secure it is. - -#### A baker can already self-delegate to put most funds in a cold wallet. Why do we need a consensus key? - -As a private baker, it is possible to put 90% of the funds in cold storage, in an account that delegates to the baker. This is however an imperfect substitute to this proposal, given that it still leaves 10% of the funds in the baker's account. It is also not doable for a public baker who may have 100% of their balance frozen. -#### Why is the drain operation necessary? Isn't giving away your consensus key risky, even in the absence of a drain operation? - -Indeed, anyone with access to the consensus key has the ability to double sign, which can result in the delegate being slashed. Shall the attacker have baking rights, they may inject the denunciation operation in their own block, stealing half of the frozen balance, while the other half is burned. - -Therefore, a rigorous baker will not hand off their consensus key to an untrusted party. - -But the drain operation makes the risk of doing so more evident: when the drain operation is enabled, a compromise of the consensus key allows a motivated attacker to spend all of the baker's balance. -#### Why not change the encoding of the baking key to something different than a `tz` address such as `BAKxxx` or `SG1xxx`? - -This change would be disruptive in the community and mandate a lot of changes in tooling, for questionable benefit. - -#### Can the baking key be a multisig? Can we have smart contracts manage baking? Can the rewards be sent to a third address? Can a third address be used for voting? Can we have a toggle to disallow new delegations? - -All of these topics were discussed in the past. A previous TZIP draft called "Baking accounts" was implementing some of these ideas, but was ultimately rejected by the community because of technical shortcomings. We are actively limiting the scope and the amount of code changes in this TZIP to solve the narrower goal of having a separate consensus key. Some of this ideas may be proposed in future TZIPs. - -#### Have you addressed all the unexpected breaking changes of the previous baking accounts proposal? - -Refer to: [Baking Accounts proposal contains unexpected breaking changes](https://forum.tezosagora.org/t/baking-accounts-proposal-contains-unexpected-breaking-changes/2844) - -Specifically this quote: - -> A future version of Baking Accounts which does not break current contracts and preserves important invariants is possible, and should be developed to take its place. - -We believe that the current proposal fits this description. Unlike the -previous proposal, we are not allowing bakers to be controlled by -multisignature smart contracts. As a result, we did not change any -Michelson instruction and no smart contracts will break. Moreover, the -consensus key is a regular implicit account with its own balance. In -addition to signing consensus messages, it can at any time do anything on -chain that any other account can do, including calling smart contrats. - ## Change in RPCs - `GET /chains/main/blocks/head/header` @@ -297,7 +199,7 @@ chain that any other account can do, including calling smart contrats. - `GET /chains/main/blocks/head/helpers/endorsing_rights` - The endorsing rights RPC now returns both the manager key, required to identify the rewarded delegate, and the active consensus key required to sign block. The RPC also accepts a new parameter `consensus_key=` to filter the result by active consensus key. + The endorsing rights RPC now returns both the manager key, required to identify the rewarded delegate, and the active consensus key required to sign a block. The RPC also accepts a new parameter `consensus_key=` to filter the result by active consensus key. ``` [ { "level": 1, @@ -318,3 +220,123 @@ chain that any other account can do, including calling smart contrats. "first_slot": 0, "endorsing_power": 58, "consensus_key": "[PUBLIC_KEY_HASH]" } ] } ] ``` + +## Breaking changes + +This TZIP introduces no breaking changes. In particular, the RPC changes only consist of new fields added to maps. + +## Motivation + +### `Update_consensus_key` + +Key rotation is a common feature of any cryptosystem. Having a parent key delegate responsibilities to a child key allows for optimal protection of the parent key, for example in a cold wallet. + +It also allows establishment of baking operations in an environment where access is not ultimately guaranteed: for example, a cloud platform providing hosted Key Management Systems where the private key is generated within the system and can never be downloaded by the operator. The baker can designate such KMS key as consensus key. Shall they lose access to the cloud platform for any reason, they can simply rotate to a new key. + +Moreover, this proposal allows the baker to sign their consensus operations using new signature schemes as they get introduced in Tezos. They may elect to do so for performance or security reasons. + + +### `Drain_delegate` + +The motivation of the `Drain_delegate` operation is twofold. + +#### As a deterrent against handing over the key to a third party + +When there is one key, whoever has access to it has full control over the baker. When there are two keys, the possibility emerges of each of these keys being controlled by different people or entities. For example, the delegate key would likely be in physical custody of the baker, while the consensus key could be handed to, or created by: + +* a cloud platform, or +* a contractor or baking-as-a-service provider taking care of the baking operations on behalf of the baker. + +This constitues a centralization risk: + +* the cloud platform may revoke access unilaterally. Some cloud operators have a large market share, which may give them the power to disrupt or stop the network, +* dominant baking service providers may emerge. + +At any time, if over one third of the stake goes offline, the chain can not move forward. Decentralization is key to avoiding this. + +The drain operation acts as an deterrent against centralization and ensures that the consensus keys ultimately has the same control over the balance than the delegate's key. + +#### As a recovery mechanism from baker's key loss + +A baker may lose their baking key. In this case, they may stop baking, wait `PRESERVED_CYCLES`, and then recover their funds with the `Drain_delegate` operation. They may then start baking from another account. + +### `drain_toggle` governance toggle + +The permissions granted to a potential consensus key have been subject of vigourous debates in the past. + +The core argument against the `Drain_delegate` operation is as follows: removing the `Drain_delegate` operation increases the security posture of the baker even further. Indeed, in its absence, a compromise of the consensus key does not put the unfrozen balance at risk. + +It is useful to ask two questions: +* should the consensus key exist at all? The answer is an uncontroversial yes. A consensus key is long-standing request from the community. Many competing blockchains already have this feature implemented. +* what permissions should be granted to it? Opinions on the matter differ, but we believe they can coalesce into a binary question on whether the `Drain_delegate` operation as proposed should exist or not. + +The [liquidity baking toggle vote](https://gitlab.com/tezos/tzip/-/blob/master/drafts/current/draft-symmetric-liquidity-baking-toggle-vote.md) TZIP introduced a mechanism for fast and concurrent governance signaling mechanisms. + +This mechanism is suitable for a binary decision such as enabling or disabling the `Drain_delegate` operation. Therefore, the proposed `--drain-toggle` governance toggle leaves the matter for the community to decide, separately from the feature itself. + +The operation will initially be enabled. When setting up their baker for the new protocol, bakers will have to choose whether to vote `pass`, `on` and `off`. + +The threshold for disabling the operation is at 50% (simple majority). The exponential moving average is initially set to zero, as if 100% of the stake was in favor of enabling it: this matches the current reality on the network where the owner of the consensus key can spend the free balance. In order to disable it, it is necessary to have more `Off` than `On` votes for a sufficiently long period before it goes over the threshold. + +### Q&A + +#### Why not introduce a mechanism to rotate the baking key altogether? + +The implementation of such a rotation mechanism would be very intrusive. In particular, it would require all delegations to be changed to the new key. We believe that a parent/key design is a better path to solving the issue. + +#### What if the signature scheme of the parent key turns out to be insecure? +In this proposal, the ultimate authority indeed rests on the parent key which can not be rotated. The security of the signature scheme of the parent key may decrease over time. However, the less often a key is used, the more secure it is. + +#### A baker can already self-delegate to put most funds in a cold wallet. Why do we need a consensus key? + +As a private baker, it is possible to put 90% of the funds in cold storage, in an account that delegates to the baker. This is however an imperfect substitute to this proposal, given that it still leaves 10% of the funds in the baker's account. It is also not doable for a public baker who may have 100% of their balance frozen. +#### Why is the drain operation necessary? Isn't giving away your consensus key risky, even in the absence of a drain operation? + +Indeed, anyone with access to the consensus key has the ability to double sign, which can result in the delegate being slashed. Shall the attacker have baking rights, they may inject the denunciation operation in their own block, stealing half of the frozen balance, while the other half is burned. + +Therefore, a rigorous baker will keep their consensus key secure and will not hand it off to an untrusted party. + +But the drain operation makes the risk of doing so more evident: when the drain operation is enabled, a compromise of the consensus key allows a motivated attacker to spend all of the baker's balance. + +#### How to bake using the consensus key? + +In your baker's command, replace the delegate's key alias with the consenus key alias: + +``` +tezos-baker-0XX-Psxxxxxx run with local node ~/.tezos-node +``` + +While transitioning from the delegate's key, it is possible to pass the alias for both delegate's key and consensus key. The baker will seamlessly keep baking when the transition happens: +``` +tezos-baker-0XX-Psxxxxxx run with local node ~/.tezos-node +``` + +#### Why not change the encoding of the baking key to something different than a `tz` address such as `BAKxxx` or `SG1xxx`? + +This change would be disruptive in the community and mandate a lot of changes in tooling, for questionable benefit. + +#### Can the baking key be a multisig? Can we have smart contracts manage baking? Can the rewards be sent to a third address? Can a third address be used for voting? Can we have a toggle to disallow new delegations? + +All of these topics were discussed in the past. A previous TZIP draft called "Baking accounts" was implementing some of these ideas, but was ultimately rejected by the community because of technical shortcomings. We are actively limiting the scope and the amount of code changes in this TZIP to solve the narrower goal of having a separate consensus key. Some of this ideas may be proposed in future TZIPs. + +#### Have you addressed all the unexpected breaking changes of the previous baking accounts proposal? + +Refer to: [Baking Accounts proposal contains unexpected breaking changes](https://forum.tezosagora.org/t/baking-accounts-proposal-contains-unexpected-breaking-changes/2844) + +Specifically this quote: + +> A future version of Baking Accounts which does not break current contracts and preserves important invariants is possible, and should be developed to take its place. + +We believe that the current proposal fits this description. Unlike the +previous proposal, we are not allowing bakers to be controlled by +multisignature smart contracts. As a result, we did not change any +Michelson instruction and no smart contracts will break. Moreover, the +consensus key is a regular implicit account with its own balance. In +addition to signing consensus messages, it can at any time do anything on +chain that any other account can do, including calling smart contrats. + +## Security considerations + +`Update_consensus_key` is not taking effect immediately, but `PRESERVED_CYCLES + 1` later, which mitigates risks of accidental usage or being tricked into running the operation. This delay applies to both baking rights as well as the usage of `Drain_delegate`. + +The Ledger app should be modified to recognize the `Update_consensus_key` and print the action on-screen in plain English, rather than blind signing. -- GitLab From 05f15d8f72fe15252da969770bd80862b0c894f3 Mon Sep 17 00:00:00 2001 From: "G.B. Fefe" Date: Sat, 23 Apr 2022 10:15:57 +0200 Subject: [PATCH 16/21] Some rewordings --- drafts/current/draft-consensus-key.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 69dfd64..1a77a99 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -25,8 +25,8 @@ Separating keys allows separation of human responsibilities, which may alter the ### A new consensus key table in the context We propose to extend the context with two new tables: -- one main table storing the active consensus key of a delegate, -- and a second table storing pending consensus-key updates for a delegate and at which cycle the key must be activated. +- one main table storing the active consensus key of a baker, +- and a second table indexed by baker and cycle and storing pending consensus-key updates. At the end of each cycle, the table of pending updates is traversed: consensus keys that must be activated in the next cycle are removed from the pending consensus-key table and inserted into the active consensus-key table. @@ -38,7 +38,7 @@ We propose to add two new operations: This operation must be signed by the manager key of a delegate. - It will record the pending update in the pending consensus-key table. The current implementation requires that `` is equal to the current cycle plus `PRESERVED_CYCLES + 1`. + It will record the update in the pending consensus-key table. The current implementation requires that `` is equal to the current cycle plus `PRESERVED_CYCLES + 1`. At any time, a consensus key can only be used by a single baker, the operation fails otherwise. @@ -50,7 +50,7 @@ We propose to add two new operations: This operation fails if the governance toggle `--drain-toggle-vote` is set to **Off**, see next section. - This operation fails if the implicit account associated with the consensus key is not initialized. + This operation is a regular `Manager_operation`. Thus, it fails if the implicit account associated with the consensus key is not initialized, and if it cannot pay for the associated fees. ### A new toggle vote `--drain-toggle-vote` -- GitLab From 9964f98d4b0301b740a93a45ef63f6d48fec1ce2 Mon Sep 17 00:00:00 2001 From: "G.B. Fefe" Date: Sat, 23 Apr 2022 10:16:24 +0200 Subject: [PATCH 17/21] typo --- drafts/current/draft-consensus-key.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 1a77a99..8b8b372 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -116,7 +116,7 @@ tezos-client register key as delegate with consensus key The drain operation might be sent with: ```shell -tezos-client drain delegate to +tezos-client drain delegate to ``` ### A new flag to the baker -- GitLab From ce49a6db4e06bc605922dd93ff63f16a1bf5d1f1 Mon Sep 17 00:00:00 2001 From: "G.B. Fefe" Date: Sat, 23 Apr 2022 10:16:44 +0200 Subject: [PATCH 18/21] delegate -> baker, when possible --- drafts/current/draft-consensus-key.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 8b8b372..01d1d04 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -36,7 +36,7 @@ We propose to add two new operations: - `Update_consensus_key (, )` - This operation must be signed by the manager key of a delegate. + This operation must be signed by the manager key of a baker. It will record the update in the pending consensus-key table. The current implementation requires that `` is equal to the current cycle plus `PRESERVED_CYCLES + 1`. @@ -44,7 +44,7 @@ We propose to add two new operations: - `Drain_delegate ` - This operation must be signed by the active consensus key of a delegate. + This operation must be signed by the active consensus key of baker. This operation immediately transfers all the free balance of the manager implicit account into the consensus implicit account. It has no effect on the frozen balance. @@ -86,7 +86,7 @@ In each block, the EMA is updated as follows: ### Protocol migration The proposed amendment needs to initialize the new consensus key table. -It will iterate on all registered delegates (around ~2500) and set +It will iterate on all registered bakers (around ~2500) and set the consensus key to be equal to the manager key. The migration also sets the initial EMA of the toggle vote to zero. @@ -242,7 +242,7 @@ The motivation of the `Drain_delegate` operation is twofold. #### As a deterrent against handing over the key to a third party -When there is one key, whoever has access to it has full control over the baker. When there are two keys, the possibility emerges of each of these keys being controlled by different people or entities. For example, the delegate key would likely be in physical custody of the baker, while the consensus key could be handed to, or created by: +When there is one key, whoever has access to it has full control over the baker. When there are two keys, the possibility emerges of each of these keys being controlled by different people or entities. For example, the manager key would likely be in physical custody of the baker, while the consensus key could be handed to, or created by: * a cloud platform, or * a contractor or baking-as-a-service provider taking care of the baking operations on behalf of the baker. @@ -254,7 +254,7 @@ This constitues a centralization risk: At any time, if over one third of the stake goes offline, the chain can not move forward. Decentralization is key to avoiding this. -The drain operation acts as an deterrent against centralization and ensures that the consensus keys ultimately has the same control over the balance than the delegate's key. +The drain operation acts as an deterrent against centralization and ensures that the consensus keys ultimately has the same control over the balance than the manaker key. #### As a recovery mechanism from baker's key loss @@ -292,7 +292,7 @@ In this proposal, the ultimate authority indeed rests on the parent key which ca As a private baker, it is possible to put 90% of the funds in cold storage, in an account that delegates to the baker. This is however an imperfect substitute to this proposal, given that it still leaves 10% of the funds in the baker's account. It is also not doable for a public baker who may have 100% of their balance frozen. #### Why is the drain operation necessary? Isn't giving away your consensus key risky, even in the absence of a drain operation? -Indeed, anyone with access to the consensus key has the ability to double sign, which can result in the delegate being slashed. Shall the attacker have baking rights, they may inject the denunciation operation in their own block, stealing half of the frozen balance, while the other half is burned. +Indeed, anyone with access to the consensus key has the ability to double sign, which can result in the baker being slashed. Shall the attacker have baking rights, they may inject the denunciation operation in their own block, stealing half of the frozen balance, while the other half is burned. Therefore, a rigorous baker will keep their consensus key secure and will not hand it off to an untrusted party. @@ -300,13 +300,13 @@ But the drain operation makes the risk of doing so more evident: when the drain #### How to bake using the consensus key? -In your baker's command, replace the delegate's key alias with the consenus key alias: +In your baker's command, replace the delegate's manager key alias with the consenus key alias: ``` tezos-baker-0XX-Psxxxxxx run with local node ~/.tezos-node ``` -While transitioning from the delegate's key, it is possible to pass the alias for both delegate's key and consensus key. The baker will seamlessly keep baking when the transition happens: +While transitioning from the delegate's manager key, it is possible to pass the alias for both delegate's manager key and consensus key. The baker will seamlessly keep baking when the transition happens: ``` tezos-baker-0XX-Psxxxxxx run with local node ~/.tezos-node ``` -- GitLab From c8bdde7652bf31563d16b02e02146f35ee0cb532 Mon Sep 17 00:00:00 2001 From: Nicolas Ochem Date: Sun, 24 Apr 2022 22:59:36 -0700 Subject: [PATCH 19/21] phrasing --- drafts/current/draft-consensus-key.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 01d1d04..85cfbc4 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -14,7 +14,7 @@ This TZIP describes a proposed protocol-amendment that would allow bakers to des ## Abstract -In the current version of the Tezos protocol (Ithaca), a baker is identified by a public key hash, e.g. a `tz1...` address. Like any public key hash in Tezos, this hash, or address, identifies an implicit account, i.e. a balance and the corresponding keypair allowed to withdraw funds. If for any reason a baker want to change the keypair used for signing consensus operations, they have to have all their delegator accounts manually redelegate to the hash of their new public key. This TZIP aims to ease this process and to avoid any explicit redelegations. +In the current version of the Tezos protocol (Ithaca), a baker is identified by a public key hash, e.g. a `tz...` address. Like any public key hash in Tezos, this hash, or address, identifies an implicit account, i.e. a balance and the corresponding keypair allowed to withdraw funds. If for any reason a baker want to change the keypair used for signing consensus operations, they have to have all their delegator accounts manually redelegate to the hash of their new public key. This TZIP aims to ease this process and to avoid any explicit redelegations. For this purpose, we propose to associate a second keypair to registered bakers, called the consensus key or the child key. By default this key is equal to the regular key of the baker (a.k.a. the manager key or the parent key). A baker may change the consensus key by calling the newly introduced `Update_consensus_key` operation, thus transfering to it all the block-signing rights and (pre)endorsements-signing rights after a delay of `PRESERVED_CYCLES + 1`. @@ -145,7 +145,7 @@ baker now requires the flag `--drain-toggle-vote [on|off|pass]`. - GET `/chains/main/blocks/head/metadata` - The block metadata are extended with the active consensus key of the baker and proposer. The field `proposer` and `baker` still hold the respective public key hash of the manager keys of the proposer and baker. The block metadata also export the current value of the drain toggle ema. + The block metadata is extended with the active consensus key of the baker and proposer. The field `proposer` and `baker` still holds the respective public key hash of the manager keys of the proposer and baker. The block metadata also exports the current value of the drain toggle EMA. ``` "proposer_consensus_key": "[PUBLIC_KEY_HASH]", @@ -155,7 +155,7 @@ baker now requires the flag `--drain-toggle-vote [on|off|pass]`. - `GET /chains/main/blocks/head/context/delegates/[PUBLIC_KEY_HASH]` - The delegate data are extended with active and pending consensus keys. + The delegate data is extended with active and pending consensus keys. ``` { "full_balance": "4000000000000", @@ -177,7 +177,7 @@ baker now requires the flag `--drain-toggle-vote [on|off|pass]`. - `GET /chains/main/blocks/head/helpers/baking_rights` - The baking rights RPC now returns both the manager key, required to identify the rewarded delegate, and the active consensus key required to sign block. The RPC also accepts a new parameter `consensus_key=` to filter the result by active consensus key. + The baking rights RPC now returns both the manager key, required to identify the rewarded delegate, and the active consensus key required to sign a block. The RPC also accepts a new parameter `consensus_key=` to filter the result by active consensus key. ``` [ { "level": 2, "delegate": "[PUBLIC_KEY_HASH]", -- GitLab From 31e14bd11a4c896ed8e4a121201031add21ba41d Mon Sep 17 00:00:00 2001 From: "G.B. Fefe" Date: Sun, 8 May 2022 22:36:45 +0200 Subject: [PATCH 20/21] Update drain description --- drafts/current/draft-consensus-key.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 85cfbc4..46d8e12 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -4,8 +4,8 @@ status: Draft author: G.B. Fefe , Nicolas Ochem type: Interface created: 2022-04-06 -date: 2022-04-06 -version: 0 +date: 2022-05-08 +version: 1 --- ## Summary @@ -42,15 +42,17 @@ We propose to add two new operations: At any time, a consensus key can only be used by a single baker, the operation fails otherwise. -- `Drain_delegate ` +- `Drain_delegate ()` - This operation must be signed by the active consensus key of baker. + This operation must be signed by the active consensus key `consensus_pkh` of the baker `baker_pkh`. - This operation immediately transfers all the free balance of the manager implicit account into the consensus implicit account. It has no effect on the frozen balance. + This operation immediately transfers all the free balance of the `baker_pkh` implicit account into the `destination_pkh` implicit account. It has no effect on the frozen balance. This operation fails if the governance toggle `--drain-toggle-vote` is set to **Off**, see next section. - This operation is a regular `Manager_operation`. Thus, it fails if the implicit account associated with the consensus key is not initialized, and if it cannot pay for the associated fees. + This operation is included in pass 2, together with `Seed_nonce_revelation`,`Double_*_evidence` and `Activate_account`. So they don't compete with regular manager operation in gas and block size quota, and they will always be applied before regular manager operation, e.g. a transfer operation from the baker. + + As an incentive for bakers to include `Drain_delegate` operation, a small fixed fraction of the baker free balance is transfered as fees to baker that includes the operation, i.e. the smallest amount between 1tz or 1% of the free balance. ### A new toggle vote `--drain-toggle-vote` -- GitLab From 2fde2b33b786c172907f48722fc68752e41809e8 Mon Sep 17 00:00:00 2001 From: Daniel JEAN Date: Mon, 18 Jul 2022 10:18:19 +0000 Subject: [PATCH 21/21] fixed little typo --- drafts/current/draft-consensus-key.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drafts/current/draft-consensus-key.md b/drafts/current/draft-consensus-key.md index 46d8e12..8383873 100644 --- a/drafts/current/draft-consensus-key.md +++ b/drafts/current/draft-consensus-key.md @@ -123,7 +123,7 @@ tezos-client drain delegate to ### A new flag to the baker -Like the mandatory flag `--liquidity-baking-togle-vote [on|off|pass]`, the +Like the mandatory flag `--liquidity-baking-toggle-vote [on|off|pass]`, the baker now requires the flag `--drain-toggle-vote [on|off|pass]`. -- GitLab