GIP-0041: Store Dispute status on Resolution

Governance & GIPs Graph Improvement Proposals (GIP)
1

Abstract

The Dispute Manager contract allows fisherman to police Indexer activity by submitting disputes for invalid indexing or query responses. Right now, disputes are deleted on resolution instead of being marked as accepted, rejected, or drawn. This prevents other smart contracts from tracking the status of disputes and past Indexer slashing events. Rather than delete disputes, this proposal suggests that the Dispute Manager contract should permanently store disputes alongside their status.

Motivation

Soulbound Labs is building a Subgraph Bridge designed to offload prohibitively expensive computations from the EVM to The Graph.

Our goal is to prevent query responses from Indexers from being certified on-chain if that response is tied to either an active or valid dispute.

We consider this is a great addition to the core functionality of the Dispute Manager that will help transform subgraphs into read-oriented rollups.

Specification

Modify the Dispute struct in IDisputeManager.sol to include the current status of the dispute.

   struct Dispute {
        address indexer;
        address fisherman;
        uint256 deposit;
        bytes32 relatedDisputeID;
        DisputeType disputeType;
        DisputeStatus disputeStatus; /* New disputeStatus enum */
    }
    
     enum DisputeStatus {
        Pending,
        Drawn,
        Accepted,
        Rejected
    }

Modify the _resolveDispute and _resolveDisputeInConflict methods in DisputeManager.sol to accept and set a DisputeStatus value on a Dispute.

Modify acceptDispute, rejectDispute, and drawDispute methods to call the updated _resolveDispute and _resolveDisputeInConflict calls with the appropriate status. Note that acceptDispute will set the valid disputeā€™s status to Accepted and the invalid disputeā€™s status to Rejected.

Modify _createIndexingDisputeWithAllocation and _createQueryDisputeWithAttestation methods to create new disputes with a Pending status.

Implementation

This proposal doesnā€™t have an implementation yet.

Backwards Compatibility

This proposal is fully backward compatible.

Validation

Audits
The implementation has not yet been audited.

Testnet

The implementation has not yet been deployed to Testnet.

Copyright Waiver

Copyright and related rights waived via CC0.

6 Likes
2

The Subgraph Bridge work that Soulbound Labs is undertaking is a major leap forward for Subgraphs as read oriented rollups. I think we should support this work by implementing some variation of the suggested changes.

5 Likes
3

Hey @Jordan_Soulbound great to see contributions to the protocol. I can see why this idea might be helpful.

Do you think the Soulbound team can work on a candidate implementation? The delta seems small and Iā€™d like to see code from other teams eventually getting to Mainnet. Edge & Node can then help with reviewing the implementation.

3 Likes
4

Can do! Goose and I will submit a PR this week.

3 Likes
5

Hey there I am the primary developer for the subgraph bridge. I just submitted a PR to the graph-contracts repo. The change is quite minor, only a single line. Let me know if you have any questions or feedback.