serai-dex / serai

Other
265 stars 49 forks source link

Select Serai validators as the top 150 validators from all external networks, not from their own set #395

Open kayabaNerve opened 1 year ago

kayabaNerve commented 1 year ago

The Serai validator set is distinct as it doesn't have any explicit stake requirements. Instead it's:

1) Whatever's needed to prevent censorship 2) Whatever's needed to prevent equivocation, which would halt the chain 3) MEV considerations

Accordingly, we're left to hand-wave out how much of emissions should go it (instead of validators for external networks) and coax some percentage of stake we believe ideal to it that way.

Alternatively, we can select the Serai validator set from the validators of all external networks. This would minimally increase their hardware requirements, since they're already expected to run nodes (and no, they cannot run light nodes). This may change if we adopt #94, as that may involve Serai validators running a Tributary...

This idea would remove our need for an additional slice of pie to give the Serai validators dedicated emissions.

It'd also potentially increase SRI behind the Serai validators, as now no one needs to distinctly provide SRI to the validator set (which may be much less prioritized).

It definitively increases our capacity for external coins, as now the SRI which would've been used for Serai remains used for external networks. With this however, the SRI used to secure external networks is overloaded. If a validator set turns malicious, they're expected to be slashed, yet now a validator may turn malicious re: an external network AND re: Serai, creating two reasons to slash them.

Fortunately, while slashed SRI is expected to be reused to re-acquire coins regarding external networks, there's no expectation of reuse regarding Serai itself. If a Bitcoin + Serai validator turns malicious and gets fully slashed from both, the SRI can be safely prioritized to Bitcoin. The only concern is how after getting slashed in one location, they create a nothing at stake problem in the other.

We'd effectively have to assume that a validator set failing is infrequent, and not allow any validator set to control more than 33% of the Serai validator set (as then if the validator set fails, they could subvert Serai itself). This isn't achievable at launch due to only having three validator sets, forcing at least one to have at least 34%.

On the flip side, we'd have to assume a Serai validator getting fully slashed (which happens on equivocation or explicitly malicious behavior) is unexpected, and we'd have to make it so no Serai validator has 34+% control of any external network.

There's trade offs here. We have to add a few invariants if we do select Serai validators from the external networks' validators, which is a bit fragile for my taste, yet they can be made far more robust as we expand and add more networks.

kayabaNerve commented 1 year ago

I'd like to kick this to a post-launch potential improvement as the nothing at stake issue causing the collapse of Serai's consensus upon a single validator set failing isn't acceptable IMO.

kayabaNerve commented 11 months ago

The main benefit to this how a malicious coin + a malicious Serai set can really bludgeon our economic security models via a series of censorship attacks to manipulate the price oracle.