hi
i can understand why this discussion is important,
what makes me doubtful is why so much diverse opinions there among validators.
to me it’s quite simple:
we can get a non-subjective proof that nothing was malicious → NO
we can’t - whatever the reason of that “neglicence” → YES
i really hope the YES wins.
otherwise Hub security standing is… marred.
we can get a non-subjective proof that nothing was malicious → Yes, we can and we have
I was on the fence yesterday, but I’ve changed my personal vote to a solid YES on 818.
It is true that accidental double signs don’t really cause any damage, and this was obviously accidental. One can imagine a lot of different ways to reduce punishments for accidental double signs, for instance quadratic slashing, but that is not the intention of governance-gating ICS slashes.
The intention of governance-gating ICS slashes is to avoid a scenario where a malfunctioning or malicious consumer chain generates completely bogus slash packets, and that is not what happened here.
While it may not have been intentional, the validators involved did sign two blocks at the same height. Legitimate slash packets were sent correctly from the consumer chain and were received by the Hub. Without governance-gating, they would have been slashed right away.
Furthermore, this governance-gating is a temporary feature. Work is currently underway on code that will slash validators automatically on the Hub by cryptographically verifying equivocation evidence. This new code would also have slashed the validators in 818 automatically.
From a theoretical perspective, blocking these particular slashes would not affect security. But from a social perspective, changing the social contract of PoS on the spur of the moment is a bad idea, and could negatively affect the public perception of ICS and the Hub’s security.
Can you point me to somewhere I can read more about this? Thank you!
Marty, @serejandmyself made a very good twitter thread on this topic:
https://twitter.com/cosmos_voice/status/1689667475451887616?s=20
Here’s another one on the anti-slash point of view:
https://twitter.com/0xSpaydh/status/1690372872731086848?s=20
Personally, I am pro-slash, but I want to temper these words a bit. @serejandmyself is a great contributor to the ecosystem. I hate voting to slash them. I don’t think that it is as they say “just following orders” though. I think that the right choice here is to follow the way the software is written. This is not the kind of slash that we added the governance slashing to prevent.
I could come up with only one reason not to slash @pupmos and @serejandmyself.
Here it is:
“Slashing updates in replicated security” introduction:
“We received feedback from some validators and community members that it would be too risky to slash based solely on information transmitted from the consumer chain. The concern is that some malicious code on a consumer chain could send fake slash packets and slash a validator that had not committed any infractions.”
Did malicious code send fake slash packets? - no, packets are valid, it was validator mistake.
Is this mistake related to any ICS innovation? - no, deleteting priv_val_state during halted chain is a common (and well known) validator mistake. There is no difference in upgrading procedure on consumer chain or independed chain.
Was “Slashing in RS” created to forgive HUB validators for their mistakes? Ok, but where the line is?
no, it wasn’t.
You are correct.
I feel this is an exercise of social consensus when the automated slashing is intendedly not implemented at this stage, and the validator community and proposers of 818 is making an example out of Pupmos and Citizen Cosmos.
I’m still dissatisfied with the rather short post-mortem tweet by Citizen Cosmos and Pupmos tweet was definitely lackluster, a 5% slashing is minimal and is a slap in the hand. A tombstone is not acceptable, but it should be if it happens again (employ a 3-strikes rule)
At this stage, this proposal is novelty at best, and serves as a reminder that we should strive for operational excellence and do our best to adhere to avoid double signing at all cost.
Having multiple keys in multiple nodes for the sake of near 100% operator uptime is not acceptable. I’d rather see individual node operators miss a few blocks, happening gradually across all node operators to implement hard fork upgrades, in order to maintain 100% network uptime (maintaining 2/3 majority consensus), rather than near 100% operator uptime with potential double signing missteps.
Being quick to act to help with a network upgrade shouldn’t take priority over operational excellence. Due to that we will vote YES on this proposal, against all odds of this proposal passing.
Validators should get slashed (appropriate + sm amount) and simply learn from it, no?
Yeah absolutely.
The reason that we eventually vetoed this proposal is that it’s technically flawed. That doesn’t mean that we disagree with the intent of the proposal and in fact notional supports slashing in cases of equivocation and does not wish to see that change.