[MRC-7] Declare unsecure validator-as-a-service (VaaS) as unwelcome

Proposals MRC (Mars Request for Comment)
1

Authored by Jacob Gadikian (@gadikian), larry.stars (@larry0x), and _gabrielShapir0 (@lex_node) with helpful inputs from PFC (@PFC_Validator) and PUPMØS (@pupmos)

This proposal aims to seek the community’s agreement that entities providing validator-as-a-service (VaaS) with unsecure practices and their customers (a.k.a. “white label” validators) are unwelcome on Mars Hub.

Context

For the purpose of this proposal, we focus on the following unsecure practice: the VaaS provider, rather than assisting the customer (i.e. the validator) with their own secure key generation and management, generates key(s) on the customer’s behalf, or else requires the customer to share the key(s) after they are generated.

While white label validators take a full share of the staking reward in the same way as other validators do, they do not provide the same level of security; rather, they obscure the network’s true level of security. Two vital properties of a blockchain, namely liveness and censorship resistance, rely on blocks being proposed and validated by many independent actors located in diverse geographical locations and jurisdictions. The inclusion of white label validators into the active set obscures the levels of these properties, because what may appear as multiple independent validators can potentially have their keys held by a single entity (i.e. the VaaS provider).

In fact, they may reduce the security if non-white label validators are forced out of the active set. In the case that a single VaaS provider controls a large percentage of the network’s consensus voting power (as is the case for the LUNC chain, for example), this provider may have the ability to severely undermine the network’s security by forcing a chain halt (which requires 1/3 of total voting power) or forging fraudulent blocks (requires 2/3).

Despite some VaaS providers claim they have deleted the keys shared with them by their customers, there is no credible evidence that they have indeed done so. While it is easy for someone to prove they possess a certain key (simply by producing a signature with the key), it is extremely difficult, if possible at all, to prove that they do NOT possess a key. Once a key has been known by any party other than the validator themself, it should be considered permanently compromised.

Motion

We suggest that the community approve the following signaling proposal:

  • Validators with a compromised (as defined above) operator key AND/OR consensus key (whether due to key generation by a VaaS, key sharing with a VaaS, or otherwise), are not welcome on Mars Hub;
  • VaaS providers must publish strong evidence of secure key practices that do not leave their customers with compromised keys AT ANY POINT, otherwise they are not welcome to operate their VaaS business or operate as a validator on Mars Hub;
  • The community asks that any validators with compromised keys withdraw from the active set, and that their VaaS providers cease providing the VaaS in this unsecure manner.

Note that this proposal does not indicate any enforceable action against VaaS providers or their customers, which may be decided in a separate proposal if the community deems it necessary.

7 Likes
2

To help inform everyone, I think the proposal should list known VaaS providers with the mention that they are known at the time of writing the proposal. Things change over time of course, but this information can be helpful when looking at sites that show all the nodes on the network, their host and location.

Some hosts show up differently than their advertised name as well. Vultr for example shows as an old name not in use anymore, Choopa LLC. Finding out those, where applicable, to correspond with the known VaaS hosts would also be helpful.

Totally in full support of this.

3 Likes
3

We will support this proposal because it doesn’t impose any enforceable measures on VaaS providers or their clients. We believe and agree that before taking any action, it’s important to inform Mars Hub’s stakers about the current situation with All Nodes. This proposal is a positive step for the Hub, demonstrating concern for both delegators and validators while also proving transparency.
By being posted and cast on-chain we hope that this proposal will reach as many Martians as possible, allowing them to make up their mind.

2 Likes
4

For this particular proposal, we don’t want to name or shame anyone. Just raise the community’s awareness on the white label issue and try to reach consensus on that such validators are unwelcome.

2 Likes
5

agree here, would be good to know who they are referring to

6

I think its a bad stance in a decentralised world to have a “someone is not welcome” stance.

If it a VaaS and it does not contribute to the ecosystem it is better to simply get the kicked by not staking to them/ getting them off the active set.

having a stance where someone is not welcome creates an extremely slippery slope where you can start banning validators.

It is an issue of creating a precedent, first you banned VaaS, then it was US based validators, then it was validators from the hood lol.

7

I think the whole point of a decentralized world is saying that centralized solutions are not welcome. Is this not right in lines with the DeFi ethos to make a point to say that moving towards a more centralized method of validating proof of stake chains would be a possibly very risky thing to do?

8

I don’t think this contradicts the idea of decentralization.

I think of Mars community as a group of people bound together by social contract. They have the full right to set rules among themselves - such as who is welcome or not welcome to join, and who the protocol will or will not serve.

Decentralization manifests in the fact that if anyone does not consent to the rules that the community has set forth, they have the total freedom to 1) not join the community, 2) leave if already joined, and 3) fork the protocol to compete in the free market.

1 Like
9

In any way, the VaaS provider (the effective operator) will need to own and non-disclose the consensus key.
A validator is the combination of the wallet and the consensus key.
the “customer” can be in full possession of the operator key, without the consensus key, he cannot do anything.

10

True, although there can be workarounds, e.g.

  1. The customer runs a signer program that remotely connects to a full node operated by the VaaS provider; the full node receives proposed blocks, sends it to the customer to sign, then gossip the signature.

  2. The customer generates the consensus key, split it into multiple shards using threshold signature scheme, and give them to multiple VaaS providers. Each provider signs blocks with their shard, and aggregate into a full signature.

Of course, no VaaS providers currently operate in such ways.

1 Like
11

1/ The VaaS customer is not a technical people, running tmKms is very often out of his capacity.
Even if he is in capacity, the security of the signer need to be strong.
How do you garanty any SLA?

2/ Horcrux between multiple VaaS provider… you will never be able to garanty any SLA.
In case of consensus issue, all the providers will need to agree…
I will never open my Horcrux signer to the internet for security reasons.

12

I’m for this proposal

As I see it, white label validators are extractive. Because they control their users’ consensus key, they provide less censorship resistance / liveness per unit of staking rewards received. In cases where they acquire significant stakes (as with LUNC), they can undermine security via chain halts (>33%) or by creating fraudulent blocks (>66%)

To be clear, to me this is just a signalling proposal. I’m firmly opposed to any form of social slashing as this is a very slippery slope imo.

2 Likes
13

So what would be the biggest difference of a VaaS vs validators that use Hetzner ?

Or whats the difference from a VaaS to a validator that runs 30+ validators?

At least a VaaS has decent setups no?

Again, I dont support VaaS, but I think they should have the same rights as anyone else, the moment you start censoring its a slippery slope.

15

The issue raised here is about a “potential” control of the goverance/consensus by a VaaS.
VaaS provider should not have any implication in the governance vote of the customers.
but the VaaS provider can, in case of problem (security breach, server crash…) shut down a full range of the consensus actors and stop the chain.

this last issue is the exact same problem than a concentration of validator nodes on a same provider like Hetzner.
If Hetzner shut down a DC or shutdown all the server running Cosmos stuffs (easy to detect with port 26656), the chain can stop.

About infrastructure, many validators should take some training with VaaS provider to learn how to protect their nodes. I cannot count the number of validators nodes totally open to the outside.

16

I don’t support VaaS but I oppose even more to a governance process that targets and singles out groups of participants

In my personal opinion this is a dangerous slippery slope that is heading towards the direction of proof of authority where the end-scenario could very likely be a chain where validators are “elected”, and I say “elected” because they are based on some factors external to the code. First insecure VaaS are being targeted. Next, are “secure” VaaS targeted next (since who judges what exactly are insecure or secure practices)? What about “insecure” cloud providers that have suffered hacks or security breaches? What about centralization of cloud providers? The list can go on and the reasons for “unwelcoming” them all sound very similar.

Already there are severe problems with this proposal where guidelines and rules are arbitrarily defined:

VaaS providers must publish strong evidence of secure key practices
“strong evidence” - who defines such a threshold and how/when is it crossed?
“secure key practices” - who defines what exactly are secure key practices?

Also the fact remains there is ABSOLUTELY not a 100% guaranteed way to tell or verify if a node is operating under a VaaS (unless you count admissions, screenshots)

This then opens up the floor to fingers pointing, accusations, hurling suspicions among node operators. It is possible that we have an outcome where smaller VaaS operators and nodes are “under the radar” and remain undiscovered who continue to operate while the community starts to witch-hunt bigger VaaS? Absolutely.