V1 change: `IEvidence.submitEvidence()` when sender is not a party or a contract

[jaybuidl]

Context

V1 Behaviour

IEvidence.submitEvidence() is implemented directly by the arbitrable contract. It also emits the Evidence event with:

• _party = 0x00 when the sender is not a party according to ERC-1497 Evidence standard.
• _party = msg.sender for some arbitrable protocol event (e.g. item submission/challenge).

Sources:

• Curate v1 sets _party to the caller of the submit/challenge item function.
• Same for PoH V1
• IEvidence v1
• ⚠️ There seems to be no actual example of Arbitrable contract emitting Evidence with _party = 0x00.

V2 Behaviour

IEvidence.submitEvidence() is implemented by a separate EvidenceModule which does not allow specifying _party to avoid impersonation and instead sets it to msg.sender.

Sources:

• Curate v2 contract set as the _party submitting evidence
  • ⚠️ This is a bit wrong, it should be arbitrable caller rather than the arbitrable contract.
• EvidenceModule

Questions

• What is the impact?
• Is this change acceptable?
• If not, are we happy to allow submittingEvidence() on behalf of someone else? Or alternatively submitEvidenceNotFromParty()?

[jaybuidl]

Decision

In the spirit of ERC-1497, the Evidence event is intended for end-users only, not for protocols.

When used as intended, the Evidence._party parameter is emitted by the EvidenceModule with the correct value.

Therefore the arbitrable contracts should stop interacting with the EvidenceModule.

If an arbitrable protocol really does need to expose any relevant information for a dispute it should:

1. Use a dedicated event, for example ChallengeRequest in Curate, rather than Evidence
2. Use the data mapping to retrieve the event with an abi/event or subgraph action, and display the relevant information as part of the dispute template's description field.

So far both V1 and V2 have attempted to support both the end-user and protocol scenarios through a single submitEvidence() workflow but the requirements for both scenarios have become irreconcilable in V2. The function needs to be specialized for either of the scenarios.

Impact

The Curate V2 arbitrable contract should be adapted accordingly: kleros/curate-v2#85

Impact 2

The Evidence event will NEVER be emitted before the dispute is created because the user only calls submitEvidence() for an existing dispute. So this tricky edge case doesn't need to be supported anymore like in V1.