Tx/state-change inspection in evidence module

We have generally two kinds of security related to state machine control 1: consensus fault detection and punishment 2: manipulated tx & state-change attempt detection and punishment We have controlling mechanism for the risk of 1. Also, cross-chain validation(aka shared security) can enhance such security But, we don’t have any mechanism to protect the blockchain from risk of 2. i think the ones who search and submit such evidence of 2 are defined as “fisherman” in polkadot. i agree that stand-alone fisherman is not a sustainable incentive design because there exists high probability that he/she might not find any evidence for a long time, resulting in zero rewards. but, i think dedicated validators with good reputation will be willing to run such “fisherman” binary to provide additional security for the security of the network and users. so, i expect some good validators will operate this. also, fisherman does not need very high quality security setup, so it should not be so expensive to additionally operate this node. this utility is much more necessary in smaller, newer network with less collaterized security(less staked assets), less decentralization. and…

Excerpt (1197 of 1701 characters). Read the whole post on the forum ↗

Regarding ‘manipulated tx & state-change attempt detection and punishment,’ is there a simple explanation of how such an attack could be carried out? What would need to happen on the Cosmos Hub, for example, in order a successful attack? I’m fairly inexperienced with the fisherman scheme.

Imagine a cartel in Cosmos. They decided to make a malicious transaction which sends all assets in a whale’s account into a new account, with a wrong signature(not from the account owner) Then they hack the gaiad binary so that all cartel members agree to vote on any proposal containing the malicious transaction created above. In current design, the state machine cannot defend itself from this attack, cartelling. The only possible solution after this attack is only hard fork, which we already experienced in Game of Stake But imagine when the cartel fails to commit this malicious transaction. Don’t you think such attempt should be well monitored and punished? But guess what? There is no methodology on our state machine to strongly punish these cartels, nor even we might don’t know the existence of the attack! So what I am suggesting here is an expansion of evidence module so that anyone can submit an evidence of such malicious attempts into the state machine so that we can kick their asses. In order to operate this kind of nodes, we also need a custom made binary to professionally monitor and submit reports for any existing malicious attempts like this. Someone who…

Excerpt (1197 of 1475 characters). Read the whole post on the forum ↗

My general thoughts about Fishermen is that you want to mostly likely combine LazyLedger with my proof of watch ideas.

NightShade (was: Whale Fishing): a new NEAR sharding design

One idea I have to incentivizing fisherman liveness. Require the fishermen to generate claim rewards if (VRF(block execution transcript hash)) is below some threshold. This would incentivize fishermen to actually execute blocks to claim the reward...

LazyLedger so you have strong guarantees that the state transition is available.

Proof of Watch so you have probabilistic guarantees that someone is actually monitoring the state transitions.

Zaki, I couldn’t fully understand LazyLedger nor Proof of Watch.
Would be nice if more context and detail explanation is provided.

Thank you for sharing thoughts!

For preventing spams from fishermen, I think significantly expensive deposit works enough for that purpose. If the evidence is wrong, the deposit will be burnt. I am not sure why we need other complicated mechanism on this?

Below are comments from Ethan Buchman and Ethan Frey about this topic on telegram channel

Ethan Buchman : Invalid txs in a block isn’t a big problem. Iltheyll just return errors but have no impact on state. Sdk could punish those proposers pretty easily, no need for fisherman. Right now validators don’t run block or check txs before voting so we can’t punish them for voting on block with bad txs unless we want to make them do those checks first and then possibly slow things down...

Ethan Frey : We do assume an honest proposer ran checktx before submitting them. Which doesn't mean they should succeed even. Just that they can be parsed, are properly signed, and have tokens to cover the fees

related historical discussions : https://github.com/tendermint/tendermint/issues/2384

I hope everyone to understand what I want to prevent in this topic.
What I want to prevent is “attempts to cartel with bad txs” by slashing those attempts.
It is basically not about spam prevention or other objectives.
Successful cartel cannot be prevented, but we can still slash failed cartel attempts.