To improve the security and ease of public baking operations, we are kindly asking protocol developers to consider introducing the concept of a Reward Account designated by a baker. The protocol deposits all rewards (baking, endorsing etc) into this account, instead of the baker’s account.
Motivation
A public baker must distribute rewards to its delegators. This is done outside of the protocol, by regular transfers typically performed by reward distribution software.
It is common for public bakers to first send some amount of tez to an intermediate “payout account” that a payout engine has private keys for. There are drawbacks:
- with a Ledger, the operation is necessarily manual, requiring opening the wallet app and confirming on-screen,
- the baker has to strike a balance between frequency of transfers, either doing transfers at every cycle which is time consuming, or doing it less frequently with bigger amounts, putting more funds at risk in a hot wallet,
- if the baker forgets or is unable to transfer funds to the payout account, the payouts are not going through, which leads to a poorer experience for delegators.
This proposal simplifies this flow: at the bakers discretion, the protocol directly deposits rewards to a payout account. This alters the operation of the payout engine: it distributes rewards to delegators, and the remainder goes to the baker’s account, potentially increasing its stake and deposits limit.
It also simplifies readability of rewards: for every cycle, it is expected that the balance of the reward account will be zero after the reward distribution has completed. This gives bakers and delegators more confidence that the reward distribution has completed and has been done fairly.
A simpler and more reliable public baking experience potentially increases the number of public bakers and delegators, which is good for decentralization.
Spec
New Operation
The rewards key is stored in a new column of the tables in the context storing current and pending consensus keys as of Lima protocol.
- one main table storing the active rewards key of a baker,
- and a second table indexed by baker and cycle and storing pending reward-key updates.
At the end of each cycle, the table of pending updates is traversed: reward keys that must be activated in the next cycle are removed from the pending reward-key table and inserted into the active reward-key table.
A new operation Update_rewards_key(<public_key>, <cycle>) with the same semantics than Update_consensus_key(<public_key>, <cycle>), lets a delegate record the public key hash of an implicit account. It will record the update in the pending reward-key table. It must be signed by the manager key of a baker.
At any time, a reward key can only be used by a single baker, the operation fails otherwise.
All rewards (baking, endorsing, nonce reveal, drain, slash, etc…) go to the currently active reward key.
If the reward key is empty, the burn fee is taken from the reward. Any kind of possible reward is above the burn fee so there is no edge case.
Migration
The proposed amendment needs to initialize the new column in the key table. It will iterate on all registered bakers (around ~2500) and set the reward key to be equal to the manager key.
The stake snapshots for the next PRESERVED_CYCLES are also reallocated. They now snapshot the consensus public key, the reward public key and the manager public key hash. Yet, the baking and endorsing rights are unchanged.
CLI Changes
New commands in tezos-client
A reward key can be changed at any point. This may be done with the command:
tezos-client set reward key for <mgr> to <key>
The current registration command still works:
tezos-client register key <mgr> as delegate
It is also possible to register as a delegate and immediately set the reward key:
tezos-client register key <mgr> as delegate with reward key <key>
Or even set the reward and consensus keys altogether:
tezos-client register key <mgr> as delegate with consensus key <ckey> and reward key <rkey>
The above commands send the Update_reward_key operation batched with the other operations.
RPC Changes
- GET
/chains/main/blocks/head/metadataThe block metadata is extended with the active rewards key of the baker and proposer. The fieldproposerandbakerstill holds the respective public key hash of the manager keys of the proposer and baker.
"proposer_reward_key": "[PUBLIC_KEY_HASH]",
"baker_reward_key": "[PUBLIC_KEY_HASH]",
-
GET /chains/main/blocks/head/context/delegates/[PUBLIC_KEY_HASH]The delegate data is 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]"}
],
"active_reward_key": "[PUBLIC_KEY_HASH]",
"pending_reward_keys": [
{ "cycle": 7, "pkh": "[PUBLIC_KEY_HASH]"},
{ "cycle": 9, "pkh": "[PUBLIC_KEY_HASH]"}
]
}
Protocol migration
The proposed amendment needs to initialize the new colum in the key table. It will iterate on all registered bakers (around ~2500) and set the rewards key to be equal to the manager key.
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.
)
