abci: remove Evidence#TotalVotingPower

[melekes]

tendermint/abci/example/kvstore/persistent_kvstore.go

Line 134 in c05b2f2

Power: ev.TotalVotingPower - 1,

by not using VotingPower of byzantine validator (and using total voting power of entire validator set), we're essentially increasing byzantine validator voting power => promoting it (instead of punishing).

[melekes]

Why do we need total_voting_power anyway?

[melekes]

cc @ebuchman

[ebuchman]

Very good question. I can't seem to find a good answer. I suspect it had something to do with letting the app know what percentage of the voting power was byzantine in case they weren't maintaining their own historical validator set or something, but I'm not totally sure and unfortunately I can't find a reference. From what I can tell Cosmos-SDK is not using it, but probably because it keeps historical validators ... not sure if other apps are.

Here's the PR on the abci repo where it was introduced: tendermint/abci#245 but I can't find any supporting justification for why.

It could be related to issues like cosmos/cosmos-sdk#1348 ? Maybe @cwgoes knows/remembers.

Without it, you'd have to pull up the old validator set to know how much to slash, since the offending validator might be gone by now. But I can't really tell if this is actually solving for something since I'd expect any app doing slashing to maintain historical validator sets probably anyways.

Would be good to find out if anyone else is using this field ...

[cwgoes]

The SDK cannot currently calculate past voting power of individual validators or past total voting power, so if we were to implement cosmos/gaia#30 (moved from cosmos/cosmos-sdk#1348) we would need this. This is in the category of proof-of-stake issues that I think would be nice to implement if we want a rigorous formal model with exact penalties, but probably don't make too much difference in most practical use-cases.

I do not know if any non-Cosmos-SDK users are using this field.

Without it, you'd have to pull up the old validator set to know how much to slash, since the offending validator might be gone by now. But I can't really tell if this is actually solving for something since I'd expect any app doing slashing to maintain historical validator sets probably anyways.

I'm not sure about this - it's fairly expensive to keep all of this information in state (twice, if Tendermint is already storing it), at least for individual validators, although I suppose it wouldn't be so bad to just store the total voting power for each of the past blocks within the unbonding period. Recalculating it is possible in principle but problematic because it is likely to require iteration over user-controlled fields (e.g. delegations), which opens up DoS vectors.

Arguably, unless Tendermint needs this information, it should be stored by the application instead though, and if the application doesn't need it perhaps it shouldn't be stored at all.

[melekes]

The SDK cannot currently calculate past voting power of individual validators or past total voting power, so if we were to implement cosmos/gaia#30 (moved from cosmos/cosmos-sdk#1348) we would need this.

Sounds like we should leave it then. @ebuchman and @cwgoes thanks for your input 🙏