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.
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.
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.
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.
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.
I would like to signal support for removing the drain operation.
Under adaptive issuance we still need to keep ~ 20% of funds liquid which can be a significant amount.
A compromised consensus key that starts double attesting could be detected early and with adaptive slashing all liquid funds would not be lost.
I find the whole drain operation a bit paternalistic. It is a fantastic feature for bakers to be able to have a HSM in the cloud do fast attestations while keeping funds safe in a cold wallet. With block times speeding up, a ledger on a local machine is no longer enough to get all attestations signed in time. Also, a HSM in AWS would cost as little as $10/month which should not hurt decentralization in any significant way imho.
After some discussions on tezos-dev slack I would like to add a bit more context.
Even with adaptive slashing an attacker could perform many double attestations in a single block and could still theoretically drain all staked tez quickly with a compromised consensus key. But, unlike the DRAIN operation the attacker cannot simply transfer the tez to any address. I order for there to be incetives to do this, the attacker needs to be a baker an perform the double attestations when they are about to bake a block.
So currently a consensus key is vulnerable to attacks both on the staked tez (above) and the liquid tez (DRAIN).
Imho it still makes lots of sense to remove the DRAIN operation since it such a clear target for attacks with high incentives to try and do it. Even if there is other potential attack vectors for consensus keys that is imho not an argument in favor of keeping an obvious one.
Consensus keys is a great idea; this is how Algorand validators work too. But there seems to be no point to consensus keys with the current drain delegate vulnerability.
