mpoke
commented
1 year ago In QueueSlashPacket, a calculation needs to be run to determine the validator's position in the set. If the validator is not in the top x% of the set by power, the function should return early.
That's not that easy as the consumer CCV module doesn't keep track of valsets in previous blocks. As a result, the following scenario may occur:
- a validator
valmisbehaves at heighth1 valis removed from the active consumer valset at heighth2 > h1- evidence of
val's misbehavior on the consumer is submitted at heighth3 > h2 - as a result, the consumer CCV module has no info of
val's relative voting power at heighth1
Protocol Change Proposal
Summary
This specifies a modification to the protocol which allows the bottom x% of the validator set by power to opt out of validating consumer chains without being jailed or otherwise punished for it. Implemented with entirely consumer-side code.
Problem Definition
This mechanism will alleviate a lot of the concerns about RS not being profitable enough for small validators to be able to run many consumer chains, without changing any core assumptions of RS.
Some quick napkin math:
The smallest validator in the Hub active set currently has 36,459 atoms delegated to it. At a 5% commission rate, this validator may make 414 Atoms per year in commission. At $12 per atom, that’s around $5000 per year, or $416 per month. With Cosmos nodes having typical operating expenses of $200-$600 per month, running only one consumer chain could make this small validator unprofitable.
The smallest validator in the top 80% has 1,126,938 atoms staked, for an estimated $155,517.44 in annual commissions, or $12,959.78 per month. Running extra consumer chain nodes with this budget is a very different calculation.
Proposal
In QueueSlashPacket, a calculation needs to be run to determine the validator's position in the set. If the validator is not in the top x% of the set by power, the function should return early.
We also need to add the power threshold (called "x%" above) to the consumer chain params and proposal.
This will result in no downtime jailing packet being sent for small validators. QueueSlashPacket will be run again every block though. We need to establish whether this is a performance concern. If it is, we will need to do something to make it run less often.
Effects
It is important to note that the small validators who are not being slashed will still be present in the validator set of the consumer chain. In other words, we are sacrificing liveness, not safety. The economic security of the consumer chain is the same, but it may be more likely to halt.
If x is set to 10%, and every validator who doesn't have to run the consumer doesn't run it, then it will only take downtime of 23% of the remaining set to halt the chain. This is very likely still OK, but it may manifest in slightly longer downtime during upgrades.
For Admin Use