Consensus Keys : toogle vote drain_delegate

Consensus Keys : toogle vote drain_delegate

Dear Tezos Community,

I’m here on behalf of Exaion company, a subsidiary of EDF Group specialized in cloud infrastructures, web3 services and also corporate baker since 2020. Over the past year, we have worked on many projects on Tezos blockchain and also on Tezos integration inside our RPC node services Exaion Node as well as supporting other companies partners to become a corporate baker.

More and more users are turning to external providers to host their nodes, whether for performance, storage, availability, security or technical skills concerns. In order for this service to be provided in an increasingly secure manner, the current bakers and future bakers need to be able to delegate validation functionality to a key different from the private key holding the funds.

Today this feature seem to be partially implemented in the Tezos protocol but to be fully operational it needs to disable “drain_delegate” feature.

We believe that adding this feature can positively impact the network as well as these users on different points:

  • Onboarding and adoptions :

    The validation key would make adoption easier for new bakers by limiting the risk during installation and maintenance of the validation node, but also allow new to join the project via solutions of baking as service. But this is only possible if the key used cannot spend the funds of the initial key.

  • Security of funds :

    Being able to share a key that does not have power over the funds with a cloud provider or quite simply on a machine connected to the Internet makes it possible to segment the responsibility in the event of mishandling or in the event of its leakage. The end user always retains sole responsibility for the funds, and the power to revoke the validation key he has shared.

  • Network security :

    Increasing the number of validators and baking service providers would undeniably have a positive impact on network security and decentralization. Although predominant players could emerge and offer this type of service, this would give a wider choice to the user, who could either run the validation operations himself or call on experts while retaining ownership of his funds.

It seems that the people behind the “consensus key” feature intended for the community to have a say in the “drain_delegate” feature (Proto: allow bakers to set a consensus key (part 3/4 : toggle vote) (!5457) · Merge requests · Tezos / tezos · GitLab) however the MR was closed a few months ago.

Following the consensus key announcement article, we would like to express our interest in the integration of the toggle vote --drain-toggle-vote in order to give the possibility to the validators to express themselves through the onchain vote on this point. We therefore plan to make a “proposal” in order to integrate this feature.

We would need core development entities expert in ocaml programming to review MR 5457 so that a “proposal” integrating it can be voted on by the community.

15 Likes

Thank you for the proposal. We are stakefish and would love to see this as well. You have our support!

4 Likes

The Drain operation allows the consensus key to transfer the free balance of the baker. Under adaptive inflation as I understand it, the entirety of the baker’s balance will be bonded at all times and there would be no free balance to speak of. Therefore the drain operation would have no effect and could potentially be removed.

With this in mind, I think we should focus our energy on building adaptive inflation and putting it to a toggle vote instead of this.

4 Likes

We approve the proposal because it is a good decision for Lugh and the future of baking on Tezos.
You have our support too !

2 Likes

The question is, is someone implementing adaptive inflation right now?
Because if this is not the case then the consensus key makes sense actually.

And depending of the implementation it can take a couple of months. Without in protocol staking for non block producers, it could be ready for protocol N with a push(if its voted in). With in protocol staking it might be doable for O but it would have to take the focus away from things like latency. Thats from Arthur.

Overall the whole point of drain delegate is to force decentralization by making it harder to outsource baking. The fact that it’s annoying unfortunately means it does what is supposed to do.

That said, I second what Nicolas said here. This is all moot if and when Tezos moves to an adaptive inflation design which is IMO the right approach, and one I now wish I had adopted from the start.

3 Likes

Very interesting proposal as we are using consensus key and the security matter was a big question! So we are in favour of this proposal. Thanks!

Exaion has also our support.

At this point, we definitely cannot say “it does what it is supposed to do”(not only bakers stats), as the ecosystem is turning to providers like AWS KMS, GCP KMS, and AZURE KMS. Solutions to deal with this issue are already available like Signatory.
However, this strategy has the perverse effect of pushing bakers into the arms of major cloud providers to the detriment of many small players. In fact, only small providers, individuals with fewer financial resources, peoples with limited technical knowledge or those who do not want to deal with cloud providers are affected.
If we look at Tzkt stats, this feature should be the norm, but it remains untapped.

We also support the Exaion proposal to vote to remove “drain_delegate” operation.

1 Like

You have our support too.