Request for information about disputes #GDR-9

Governance & GIPs Arbitration
1

The arbitrators are contacting indexer address 0x4fedde33607cfda2c82a999accb427d1170987d9 (oraclegen) 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:

Dispute (0xbd7a4f1161630edbe505f8df605e4c60e73256687cf5de144f037da6ea614273)
├─ Type: Indexing
├─ Status: Undecided (2.45 days ago)
├─ Indexer: oraclegen (0x4fedde33607cfda2c82a999accb427d1170987d9)
├─ Fisherman: 0xb25813a23c3cb8852133416ba6adc30552880dc3
├─ SubgraphDeployment
│  └─ id: 0xe5dcb1e44a93ed102fc85a44fa43f9495ad2d0c9ec6146eaf03361d7477de640 (QmdowFoTBBCd5t6PXAtTVBPY5BFgJxMhCbN9gwuKT4REb9)
├─ Allocation
│  ├─ id: 0xdd7b735a064b2fcafa9bda6641bfcc965e639dfd
│  ├─ createdAtEpoch: 216
│  ├─ createdAtBlock: 0xe73e101fba5d9290d46edb381988b6c4c4e407507716237b90ec3631cceb160c
│  ├─ closedAtEpoch
│  │  ├─ id: 243
│  │  └─ startBlock: 0x7a8f423cc53b06e9ca8e7275ececad4a79b3bead291864a84358aca671aa3d48 (#13061746)
│  └─ closedAtBlock: 0xf3480247f823f5e363f74969caed8c1cdad6e0e4d57c95ba360ad84a5b25c53e (#13068107)
└─ POI
   ├─ submitted: 0x83f27fa1cecd3d074346288855c3abe85882cb7952b096484617f6b4ec78f13a

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

Hi @ari ,

The following links include the requested information above:

  • Graph Node version: v0.23.1
  • ETH versions: Geth archival v1.10.8 and OpenEth archival v3.3.0-rc.7
  • Config info found here
  • Table of POIs and call cache zip download

Subgraph: QmdowFoTBBCd5t6PXAtTVBPY5BFgJxMhCbN9gwuKT4REb9

Block used for POI (Epoch-equivalent block): 10768876
Hash: 0x27e40f55ad191b23cde6fdcb42a878ddf53285472968c7b357083c7494aef8ea
POI: 0x83f27fa1cecd3d074346288855c3abe85882cb7952b096484617f6b4ec78f13a

Last block prior to subgraph failure: 10773149
Hash: 0xe1dba4b161ba614aded6309b726506738eb3cb60c4ca77a729fe06eaf36dbebe
POI: 0x63a61a4bf6d11aee1028a0c12d2d9cdc64673a1b7ebc90f811f7726ade83250e

Part 1

I’m assuming the reason for this dispute by FIsherman 0xb25813a23c3cb8852133416ba6adc30552880dc3 is related to clarity surrounding closing out an allocation with a non-zero POI on a broken subgraph, in this case the first version of the Synthetix - Mainnet Mega subgraph.

The allocation in question was opened by me on July 23rd at 19:17 UTC. Some days later Leo confirmed in the chats the subgraph was in fact broken with the Synthetix team on the 26th at 12:38 UTC. I was able to confirm the same about 2-3 days later. Fast forward to August 2nd and the subgraph was updated to the new and current version QmZLFFChgZu6j4q8twaJn8xF74WgGgZ1WKEG6Cigesr49R . After the subgraph was updated I decided to do research into what to do with regards to closing my allocation and was eventually informed of the Radicle updates regarding broken valid subgraphs and closed out my allocation on August 21st - 19 days after the old subgraph’s curation migrated to the new one, rendering my allocation rewardless for 19 days.

Just recently, Ariel confirmed that we are allowed to close allocations with a non-zero POI on a broken subgraph in a post on GDR-5 which can be found here .

The Synthetix subgraph in question was:

  • Valid
  • Had many curators
  • Was providing a service to the network

Due to the reasoning above, I do not believe I should be slashed for closing this allocation with a non-zero POI because I was acting in good faith, was within the rules, and fully synced the subgraph to the failed block and produced a good epoch-equivalent POI.

Part 2

While following the discussions here in similar disputes regarding Opyn, there was something that stood out to me particularly in GDR-8 where @Fattox mentions:

There is quite a sensitive balance of power when it comes to disputes. The role of an Indexer involves attempting to cover every consideration that a Fisherman has, in order to avoid getting disputed, and then some. But the risk presented to the Fisherman is rather low compared to that presented by the stake of most Indexers.

For this reason, i feel that Fishermen should be held to the absolute highest standard. Not only because of the risk:reward often being slanted in their favour, but because any invalid disputes present ‘noise’, and demand a lot of time and effort for the Indexer and the Arbitration Council. I feel without having high expectations of our Fisherman, we could attract opportunists.

The last part is spot-on in that many of these disputes the Fishermen themselves are playing pin-the-donkey with little to no expectation of taking a Loss, and in some cases aren’t even arguing their case, for example on GDR-5 which looks to have been ruled a Draw. This does in fact lead to the indexers’ time being consumed on top of the Charter’s where individuals in the Charter’s time is very valuable.

Naturally, I completely understand the reasoning behind declaring a Draw on things where there’s a miscommunication of rule updates and such, which is more than fair. However, this led me to do some digging after noticing that I was disputed for the same reasons as these Opyn-related disputes.

Interestingly enough after simple chain analysis, the Fisherman in this dispute is @inflex decisionbasis-inflex 0x040a8ae130b5fbac973074aa1bd2c69773c5fbc2 and/or decisionbasis-bestake 0x81dd719fd7efb19d12740b8057c0e363bee35b4a. Here are the tying addresses:

inflex:

  • origin: 0x040a8ae130b5fbac973074aa1bd2c69773c5fbc2 (inflex vesting)
    • sent to: 0x2c452073377ec65b4b8c7dfa995624d60028cd53 (inflex rewards address)
      • sent to: 0x673b6e9fe607f6ddf4a4f25b386b846c5c82995e (pre-migration fake sub publisher)
      • sent to: 0xde28fA99375CC746995061d872DC148b1F6b9121 (Binance deposit address)

bestake:

  • origin: 0x81dd719fd7efb19d12740b8057c0e363bee35b4a (bestake vesting)
    • sent to: 0x09ccaA023d2B2dAF3C23273ABDdE64ceC3a01781 (withdraw surplus)
      • funded by: 0x2c452073377ec65b4b8c7dfa995624d60028cd53 (inflex rewards address)

Fisherman:

  • origin: 0xb25813a23c3cb8852133416ba6adc30552880dc3
    • sent to: 0xde28fA99375CC746995061d872DC148b1F6b9121 (Binance deposit address)

You can see above how there are related addresses connecting the indexer(s) above to the Fisherman, most notably the Binance deposit address.

Ironically enough this person/group also submitted disputes against themselves for the following three indexer addresses with regards to Opyn:

0x81dd719fd7efb19d12740b8057c0e363bee35b4a - bestake
0x63c560997b8338f2b033f3ffdcc0f7c680feec45 - inflex 2
0x040a8ae130b5fbac973074aa1bd2c69773c5fbc2 - inflex 1

As was mentioned above via the quote from @ari regarding GDR-5, the Fisherman of that dispute (inflex) wasn’t found to be in the Loss column because it was assumed that the Fisherman was accidentally acting on outdated/unclear information when clearly based on @inflex’s defending argument in the dispute, he was fully aware of the current rules before that dispute was created, meaning the dispute should be categorized as a Loss resulting in his own recommendation of:

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

and from GDR-8:

I think slashing person ought to be competent and be aware of the latest version of the charter. Thus, you shall be punished for your dispute and lose 10 grand.

Having said that and given the circumstances surrounding the Fisherman of my case being fully aware of the updated rules, I do think that they should have each of their 4 disputes ruled as a Loss instead of a Draw, as he himself personally recommended.

Lastly, I would like to hear from the Charter regarding disputing yourself. It’s clearly a bit iffy, but at the same time there’s truly no way to enforce it unless you have a situation like this above where the chain data can be easily connected. As for the “risk:reward” @Fattox mentioned, I’d imagine there will be discussions going forward about how to find a better balance between indexer and Fisherman risk.

3 Likes
3

I would say we should differ between Opyn (GDR-5,6,8) and Synthetix (GDR-4,9) in terms of “broken subgraphs”.

Opyn became broken during the active indexing phase, on a new block. Subgraph had curators and was serving queries, a situation is clearly described by the arbitration charter.

Synthetix’s failure block is timed August 2020, even before The Graph protocol was launched. Opening an allocation towards such subgraph and using POI from almost a year ago doesn’t seem as straightforward as Opyn situation. According to the Charters, both recent version and outdated, POI shall be calculated for the first block of the epoch, which is impossible to determine. Also, I highly doubt you served any queries (some logs could be appreciated).

On the other hand, there are similarities between these two situations: presence of curation signal, and POI’s are not some bogus random numbers, but correctly generated taking failing block into account.

Eventually, it’s up to Arb’s Council to decide the outcome.

As for ruling the situation in a loss for fisherman, I would say that dispute tx was sent before Ariel ruled out GDR-5, thus the decision should be consistent in case of justification of indexer’s actions.

4

How is the epoch-equivalent block calculated to get to 10768876 ? I’m wondering because there were no epochs at that block. Are you calculating epoch slots from protocol genesis back?

Block used for POI (Epoch-equivalent block): `10768876`
Hash: `0x27e40f55ad191b23cde6fdcb42a878ddf53285472968c7b357083c7494aef8ea`
POI: `0x83f27fa1cecd3d074346288855c3abe85882cb7952b096484617f6b4ec78f13a`
5

Correct - counting backwards by 6646 blocks until arriving to the “epoch-equivalent” block prior to the failed block.

6

Previous Notes:

Related to broken subgraph indexing related to the Opyn subgraph discussion, which was determined to be allowed.

Along with statute of limitations, this dispute has been settled as a draw by the Arbiters: