Request for information about disputes #GDR-5

Governance & GIPs Arbitration
1

The arbitrators are contacting indexer address 0x63c560997b8338f2b033f3ffdcc0f7c680feec45 (decisionbasis-inflex) about disputes filed in the protocol.

To make the investigation as brief as possible, please provide the following information and any other relevant records about the open disputes:

  • Version of graph-node used.
  • Graph-node configuration in full.
  • Type and version of Ethereum node.
  • Table of PoIs generated by the affected subgraphs.
  • A dump of the call cache data from the database for the affected subgraphs.
  • Entity values as of the divergent block once identified.

This is not an all-inclusive list. Request for additional information may be made if considered necessary.

How to Get Relevant Data

You can use the following queries to extract information from the indexer software to be used in the evaluation.

# Get subgraphs schema
SELECT name FROM public.deployment_schemas where subgraph = 'QmTj6fHgHjuKKm43YL3Sm2hMvMci4AkFzx22Mdo9W3dyn8';

# Move to the subgraphs schema
SET SEARCH_PATH TO <RESULT_FROM_ABOVE>;

# Dump PoI TABLE - (from outside of psql console but on server)
pg_dump --dbname="<YOUR_DB_NAME" --host=<DB_HOST> --port=5432 --username=<USERNAME>  --table='<SUBGRAPH_SCHEMA>."poi2$"' --file='<FILE_TO_SAVE_TO>'

# Dump call cache (on some setups this table may be in a different schema, check it with `select * from public.chains`)
pg_dump --dbname="<YOUR_DB_NAME" --host=<DB_HOST> --port=5432 --username=<USERNAME>  --table='public.eth_call_cache"' --file='<FILE_TO_SAVE_TO>'

Once a divergent block is identified:

# loop through all entity tables and get changes for that block
# for each entity table in subgraph deployment schema:
select * from <entity_table> where lower(<DIVERGENT_BLOCK>);

Purpose of the Requirement

This requirement is related to the following disputes:

└─ 0xd7fd2fa916c7690bbed5b7029e5ee0c9f2775acce5481175314df1d0f279adb4
   ├─ Type: Indexing
   ├─ Status: Undecided (0.12 days ago)
   ├─ Indexer: 0x63c560997b8338f2b033f3ffdcc0f7c680feec45
   ├─ Fisherman: 0xb25813a23c3cb8852133416ba6adc30552880dc3
   ├─ SubgraphDeployment
   │  └─ id: 0x014e8a3184d5fad198123419a7b54d5f7c9f8a981116462591fbb1a922c39811 (QmNRkaVUwUQAwPwWgdQHYvw53A5gh3CP3giWnWQZdA2BTE)
   ├─ Allocation
   │  ├─ id: 0x803371de0fce2d6d3691e0467886e8ff71460dad
   │  ├─ createdAtEpoch: 201
   │  ├─ createdAtBlock: 0x3c8fe439e77aa8af58a1dcd1165326fb603e7434399f517c56db3c18398c9d19
   │  ├─ closedAtEpoch: 226
   │  └─ closedAtBlock: 0x1ffe36600e884c1b87cb46d3ac03b609922a4e8da6ed2f0d84ff917901a1f383 (#12951561)
   └─ POI
      └─ submitted: 0xe401efac0e849d7478b01a3c632b6d4ac8bb9ca16d7648d09b66464fcf85ad41

About the Procedure

The Arbitration Charter regulates the arbitration process. You can find it in Radicle project ID rad:git:hnrkrhnth6afcc6mnmtokbp4h9575fgrhzbay

For communications, please use this forum. Additionally, please monitor Graph Protocol’s Discord #arbitration (https://discord.gg/9gg7XvfggW ) for any arbitrator reaching out for more information.

2

is there any update to this? im curious as this is not a case where a lot of tech data is needed, but whether its against the rules or malicious to index a broken subgraph

would appreciate a public conclusion here as soon as there is one

2 Likes
3

Same here.
It is long standing issue with tonnes of discussion.
Can hardly wait the final decision.
What is the deadline for dispute responce and wrap up decision?

I am also not sure that here is any tech data needed, as it is mostly charter complience issue.

Best regards,

4

Hey, I created the request for information post including the dispute information and the default data I typically ask after someone submits a new dispute. It doesn’t necessarily mean that the issue is about a divergent PoI. A disputed indexer can use the opportunity to share some words with the community and the arbitrators for evaluation before the resolution.

5

yeah i know, thats why i asked if theres any development here, because its just about charter compliance

6

Hi,

First, sorry for being absent for a long time.

Second, I think all the frustration comes from misunderstanding. Many people refer to some “notion.so” link with arbitration charter, which is utterly outdated. You can see that each dispute request has a valid radicle repo ID in the end, pointing to the current version of the charter. I would expect that each indexer is able to sync the latest version before arguing, or, what’s even worse, opening disputes, taking valuable time from the team, and putting money on the table.

For those, who are unable, I want to point out the commit 7b9cfa81242697b86ca87f9d09e5d1fabe87399c submitted by Brandon at the beginning of July (sometime after Open got broken). In that commit, line 86 was replaced from

If the Indexer is unable to produce a valid PoI for whatever reason, then they must close the allocation with a so-called "zero PoI," which is a PoI comprising all zeros. For example, if a subgraph has a bug that prevents indexing up until the current epoch, then a zero PoI should be submitted and indexing rewards must not be collected for that subgraph. An exception to this rule is if the allocation being closed was opened before the subgraph bug occurred. In this case, the Indexer may submit the last valid PoI they produced for the subgraph and collect indexing rewards for the allocation.

To

If a subgraph encounters an error that prevents it from being synced up to a the first block of the epoch, then an Indexer should submit the last valid PoI for the block before the error occured. Indexers may continue to collect indexing rewards on a broken subgraph until the market indicates it is no longer useful to index that subgraph and removes all signal from the subgraph.

As soon as I saw this, I decided to open allocation towards Opyn, as this exact situation is now clarified in the Arbitration charter.

For market indication I take the active signal on the subgraph and, what’s more important, queries on the subgraph. All of my allocations in Opyn have a stable flow of queries. I’m not sure whether these are artificially generated by the team, or actual queries by the subgraph users, but I still see this as indication that subgraph should be indexed by someone.

So, please, rule the dispute in my favor, and take 10k from the slashing entities without return.

P.S.: I’m ready to present all the technical information, including POI tables and query logs. However, I’ve cross-checked the POIs with indexers who closed the allocation immediately after the subgraph got broken, and am sure that my POIs are correct.

2 Likes
7

While this is strange (and the fact opyn didnt fix the issue yet after so long), i think i agree - signal is there and queries are being served.

While i was 100% against this behaviour before i can now see it is still important to do it and serve queries aligned with the curation signal, which is high.

Im expecting this is resolved shortly @Ford @ari , since its just an arbitration charter question, not a technical one.

1 Like
8

After reviewing the data and the statements from the fisherman and disputed indexer we’ve found that the behavior around the disputed allocations aligns with the guidelines outlined in the latest version of the Arbitration Charter. Additionally, the indexed subgraph is valid, has many curators, and is confirmed to provide a service to the network.

According to the newest version of the Charter in Radicle:
Project ID: rad:git:hnrkrhnth6afcc6mnmtokbp4h9575fgrhzbay
Commit # 7b9cfa81242697b86ca87f9d09e5d1fabe87399c

“If a subgraph encounters an error that prevents it from being synced up to a the first block of the epoch, then an Indexer should submit the last valid PoI for the block before the error occured. Indexers may continue to collect indexing rewards on a broken subgraph until the market indicates it is no longer useful to index that subgraph and removes all signal from the subgraph.”

We also consider that the fisherman should not be slashed in this instance as we found there was some lack of clarity around this particular rule. The recommendation is to resolve the dispute as a draw.

2 Likes
9

Hi, Ariel.

Thank you for the update.
Since community may experience some issue accessing this Arbitration Charter via Radicle App, may I kindly ask you to dump current version, date it and socialize through Discord Indexer Announcement.

If you have not done so :wink:

Regards,

10

It’s several pages long, mate. :slightly_smiling_face: Better a hackmd or github/gist

11

I think accessible link shared in Discord to any of those you mentioned would work :slight_smile:

12

There was a version in hackmd that is not currently updated, I heard that Radicle is working on an http gateway so anyone can access projects easier than using the local client. That would also make it easier to provide a link.

13

Hm.
Are you talking about this one? (HackMD version is notoriously well known (GIP-0009: Arbitration Charter - HackMD)).
Would not it be worthwhile to post link to updated HackMD a least here?

Regards,

14

Thanks, Ariel. Could you share any ETA, when the final decision by this Dispute will be in blockchain?

15

The transaction is already initiated in the multisig but waiting the 48 hours period time described in the Charter to execute.

# 12. Publishing information about decision.

The Arbitrator must post a decision in the dispute’s forum thread that briefly describes what outcome was chosen for a dispute, why it was chosen, and what factors were considered. This should be posted at least 48 hours before the dispute is settled on-chain, assuming the offending Indexer doesn’t have any unbonding stake that will become available to withdraw during that time period. If any new mitigating circumstances are presented in that window, the Arbitrator may revise their decision.

1 Like