Event `DisputeRequest` can lead to implementation issues

[greenlucid]

kleros-v2/contracts/src/arbitration/interfaces/IArbitrableV2.sol

Line 19 in 7f8be8e

event DisputeRequest(

When the _templateId or _templateUri is emitted on the Arbitrable, it creates a dependency that

These are the errors this could lead to:

• Arbitrable could emit it before calling createDispute, leading to indexing issues if indexing solutions (e.g. The Graph) create the data sources before the event can be listened to
• Arbitrator frontends could have issues listening to the event, or extra complexity, that they could have avoided by listening to a similar event internally
• Arbitrators should absorb most of the complexity related to dispute resolution. The least complexity is leaked into the Arbitrable developers, the more scalable and practical of a solution the Arbitrator is.

Not sure what the best approach is, but an alternative could be to change

function createDispute(
    uint256 _numberOfChoices,
    bytes calldata _extraData,
    IERC20 _feeToken,
    uint256 _feeAmount
) external returns (uint256 disputeID);

to:

function createDispute(
    uint256 _numberOfChoices,
    bytes calldata _extraData,
    uint256 _templateId,
    string _templateUri,
    IERC20 _feeToken,
    uint256 _feeAmount
) external returns (uint256 disputeID);

(same consideration for the native token entry function)

or something to that effect, so that there is an stronger connection to the required dispute context, to the dispute itself. This would remove reliance on the event, and the templateId / templateUri could be propagated to the Arbitrator to handle it internally, cross-chain if necessary.

Note this continues to require the Arbitrable to store data internally, related to the relayed _templateId or _templateUri, and it would be less gas efficient

[jaybuidl]

Arbitrable could emit it before calling createDispute

We can't prevent anyone from writing/deploying/running a buggy arbitrable which emits events at the wrong time without respecting the protocol. As long as it doesn't impact the arbitrator it's fine.

Arbitrator frontends could have issues listening to the event

This problem is already solved by the current court implementation

Arbitrators should absorb most of the complexity related to dispute resolution. The least complexity is leaked into the Arbitrable developers, the more scalable and practical of a solution the Arbitrator is.

I agree, that's the intention with the current design.