GIP-0041: Store Dispute status on Resolution

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.

7 Likes

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

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

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

3 Likes

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.

For anyone following this topic, the PR linked by @goose_soulbound above will be going for audit soon.
We’ll then support the Soulbound Labs team to get this through some testing, and ask the Council to vote on it, so any feedback from the community on this would be welcome at this time.

Curious why it takes 8 months to move this proposal through…

1 Like

8 months is very long indeed. There are several reasons:

  • This GIP required contracts changes and therefore requires an audit. Audits tend to be planned with some time, and audit slots are limited, so it’s hard to fit community contributions into an audit slot. Unless someone else wants to set up an audit, we need to fit it into the pipeline with other projects.
  • We had some review iterations with @goose_soulbound on GitHub after the initial PR was posted, to get it ready for audit. This naturally took some time which was not visible here.
  • The current GIP process doesn’t have a clear way for GIPs to be prioritized, or to gauge community interest/urgency in a GIP (other than a community snapshot, and it’s unclear when a GIP should move to a community snapshot)

There is some ongoing work to improve this, e.g. setting up a better process to get GIPs in front of the Council, have more visibility into which GIPs are important to the community, improve how audit slots are prioritized, document the process for contract changes better, etc. so hopefully we can make the process easier and faster going forward, but it will take some time.

3 Likes

Thanks for explanation. I look forward to see streamlined processes in the future.

1 Like

Hi all, the audit for this GIP has been completed and we will be asking the Council to vote on its deployment soon, meanwhile we’ll be testing it on testnet.

1 Like