Application Specific Evidence

[cmwaters]

I'm opening this discussion board to discuss the needs surrounding application specific evidence that was stirred up by the recent RFC on ABCI++ (see #254).

To provide further context:

Tendermint has its own class of evidence which currently is DuplicateVoteEvidence and LightClientAttackEvidence. Only these types of evidence can be gossiped between nodes and committed on block. However, applications themselves might have a need to create their own evidence (due to fraud on another chain or some other observed malevolent behavior). I believe there are two categories for application specific evidence:

• On-chain via transactions, in which case the application business logic should be equipped to handle it in a deterministic manner
• Off-chain, in which network participants should submit txs that can prove the off-chain misbehavior.

AFAIC, in both cases this can be handled in a way that has the same properties as Tendermint's native evidence process: Broadcasting amongst peers, consensus amongst validators, on-chain records, firing of the event system and deterministic state transitions (well the last part is also up to the application).

The only divergence in attributes is that Tendermint prioritises evidence above txs. Perhaps applications also want to have this attribute in which case I would think a priority based mempool should be sufficient.

What do other people think? Are there cases that I have missed or requests for properties about application specific evidence that haven't been covered?

[alexanderbez]

Thanks for starting a discussion @cmwaters!

I believe there are two categories for application specific evidence: ...

I'm having difficulty distinguishing between these two...both are submitted via transactions, no? Ultimately, that is what matters.

I believe a priority-based application-based mempool might be able to deal with needing to handle evidence above all other txs. Another approach I can think of is via ABCI. Similar to how we submit txs to Tendermint via the broadcast RPC method, we can broadcast evidence via an RPC method (I think this is already possible?) and then Tendermint would ask the application if that evidence is valid. If so, it then follows the standard process of Tendermint native evidence (e.g. DuplicateVoteEvidence).

[alexanderbez]

if the application had said that the evidence was valid, would the Tendermint node then start gossiping this evidence around the network?

Yes, at this point, the evidence follows the same flow as Tendermint-native evidence and it makes no distinction.

When a node received application evidence from another node would it also call the same ABCI call to verify it?

The originating node that broadcasted the evidence will run the ABCI method to validate it and if valid, will gossip it. At this point, it's included in some future block and is treated no differently from Tendermint-native evidence.

These are just high-level thoughts. It would need to be examined more closely, but I see no reason why this shouldn't work.

[cmwaters]

Right and so you would have CheckEvidence the same as we have with CheckTx. I think this is also a possible approach but without diving to deep into both options I think I would prefer just having a prioritised mempool and treating application evidence as a high priority transaction.

[ValarDragon]

Currently, Tendermint does treat consensus-evidence specially within the header. It includes a separate evidence hash within the header https://github.com/tendermint/tendermint/blob/master/types/block.go#L357. AFAIU this is due to needing the block hash to depend on evidence and this being the simplest way to do it.

I think we will propogating lots of confusion if "EvidenceHash" only refers to Tendermint specific evidence. To avoid this, I think theres two options.

(1) Make Tendermint-specific evidence get passed into the application using txs as well. These txs could be forced to be at the beginning of the block. Tendermint Evidence could still have its own p2p channel, but it ultimately gets combined into the block tx data. We also remove the "MaxEvidenceBytes" portion of a block. Then application-specific evidence is indeed just normal txs that ought to be prioritized highly, and as far as the state machine is concerned all evidence is treated the same. (Though perhaps tendermint evidence is wire-formatted differently than state machine txs)

(2) We make the notion of evidence within Tendermint abstract over both application specific and tendermint specific evidence. Then application specific evidence can get passed over the Evidence channel, and we have a CheckEvidence ABCI method.

I prefer (1)

[tac0turtle]

I prefer 1 as well. I already had the intention of combining evidence into the block.Data field. The part that is unclear to me is merging it into the block tx data you mention. Do you mean within the Txs field with in data or the Data struct?

[cmwaters]

Make Tendermint-specific evidence get passed into the application using txs as well

Can you explain this proposal in more detail. How is tendermint evidence being passed to the application? I don't think there should be any interaction until after it is committed and is sent in BeginBlock.

I'm also a bit wary of whether the confusion you mention with naming a field in the tendermint header EvidenceHash really warrants making a change