An Arbitration Charter to clarify Arbitrator behavior

[ari]

@That3Percent

If a subgraph has a deterministic failure, continue as normal by eventually closing the allocation with the usual non-zero PoI.

About subgraph failure I agree with this point from Zac, as long as it was a deterministic failure because of a bug from the subgraph developer it makes sense for the network to keep indexing it because it can still provide query results, even if not until the latest block, there is value in that. It would be interesting to consider an addendum to the charter with this condition.

@grassets-tech

• I would like to agree with @KonstantinRM on the point of slashing based on the indexer’s own stake. My argument is while current mechanism sounds perfectly when it comes to slashing for incorrect query service because of the economical security metrics etc. The indexing rewards does not really depend on the indexer’s self stake and thus it would make more sense to apply slashing on the indexing rewards rather than tie to the % of the stake.

Slashing could be a function of the allocated tokens and allocation duration to not overly penalize indexers that rotate allocations more frequently, today they are exposed to more risk than slow rotating indexers. We would need to calculate that the allocation security bond is enough to cover what an indexer gets from rewards to avoid any potential exploit.

[Brandon]

Update: I have updated clause 9 of the arbitration charter based on the feedback above, and have pushed the changes to Radicle (commit # 7b9cfa81242697b86ca87f9d09e5d1fabe87399c).

I accept Zac’s point above that it could be useful to historically query a broken subgraph, or even know that a subgraph is broken, and what the error is, which is only possible if Indexers are online to report on it’s broken state.

Also, philosophically, it makes sense to me that it is the Curators who signaled on the subgraph that should determine when they no longer wish a broken subgraph to be indexed by migrating their signal. There is no need for the protocol to make this decision on their behalf.

I disagree with @KonstantinRM’s suggestion to only make indexing rewards slashable and not Indexer’s principal stake. Such a change would make the expected profit positive for a whole class of economic attacks, because there would essentially be no downside to attempting such attacks other than the opportunity cost of capital involved in the attack, which is a near-zero interest rate environment is relatively low.

I agree, however, w/ Ariel’s point about possibly only making allocated stake slashable, as opposed to an Indexer’s entire stake. This is actually already listed under “Future Work” in the GIP because this requires a code change and thus goes beyond the narrow norm-setting capabilities of the Arbitration Charter.

[KonstantinRM]

We still need to clarify the question(I believe it was good enough clarified in the charter, but people still discussing it):

1. If the subgraph failed, is it ok to start allocating on it after it’s failed or not? Because for now, we have a situation, when Indexers can keep allocation open for failed Indexer if they already there, but can’t open allocation for an already failed subgraph.

Speaking about “allocated stake” it looks much better than the current state. Because for now Indexer can create a new Indexer with 1M self stake → delegate 16M to itself and do everything they want. Why:

1. Nobody will create disputes for him, because of too low ratio: Fisherman’s bid vs 1.25% slashable body. Plus up to 56 epochs of waiting, freezing fisherman’s tokens.
2. Potential rewards from 17M allocated malicious way will be much higher than 2.5% slashing for his 1M self-stake. Especially with reallocating once per 28 epochs.

[juanmardefago]

Potential rewards from 17M allocated malicious way will be much higher than 2.5% slashing for his 1M self-stake. Especially with reallocating once per 28 epochs.

Regarding slashing allocated stake instead of own stake, the issue here is that you are adding slashing to delegators basically, which is a new risk that wasn’t there before.

[indexer_payne]

You can slash percentage of the owned stake based on allocated stake. So it’s not that bad.

So say you have 100M own stake and 500M total allocated, and you only allocated 50M on a subgraph, then the slashing is considered on the 10% of your own stake (equivalent to the allocation basically).

So slash on 10M by 2.5% in today’s slash percent.

Sorry if my math is off but you get the idea.

[cryptovestor]

Indexers are starting to allocate to Opyn again. Any Indexer with a small stake can jump on this with low likelihood of disputes due to lack of incentive as the numbers are too low to warrant one. GRT earned per million allocated is something like 3000GRT per day with current numbers. They will likely eventually close allocations with the last good PoI. OR any poi that works, because they are less concerned about getting slashed at such an high rate of indexer rewards.

Maybe this is less of a problem once we have a lot more signal, but its for sure a strange/unique situation right now. No pressing incentive (for now) for the signaller to move that Opyn signal until they upgrade their sub. Signal I agree, per @Brandon s thoughts, is ideally how these dynamics become irrelevant in the future.

[KonstantinRM]

Another funny part of Opyn allocations:

It seems like more than 28 epochs, but allocations are still open.

[adamfuller]

Re-opening this thread to share some proposed updates to the Arbitration Charter:

• Updating the allocation expectations given the introduction of the Block Oracle
• Adding a clarification on Experimental features and the expected Arbitrator behaviour

This is also in the interest of moving towards ratification of the Charter by the Council, so inviting community feedback & review here, based on observed behaviour and performance of the Charter “in action” on the network.

The full proposed text is linked here, and the salient changes are extracted below:

9. Valid Proofs of Indexing for a given epoch.

When closing an allocation during an epoch, an Indexer must submit a valid PoI as of the first block of that epoch.

Prior to the introduction of the Data Edge & Epoch Block Oracle (GIP-0038), epoch blocks are defined by the EpochManager contract. After the introduction of the Data Edge & Epoch Block Oracle, the Epoch Block subgraph becomes the source of truth for Epoch Blocks across networks.

In a dispute, if the discrepancy is found to be the result of a bug in the Data Edge, or Epoch Block oracle, then the Arbitrator should settle the dispute as a Draw.

In a dispute, if a PoI is invalid for the epoch in which the allocation was closed, but valid as of the first block of the preceding epoch, then the Arbitrator should settle the dispute as a Draw.

Experimental features

Subgraph API Versioning and Feature Support (GIP-0008) describes the introduction of new subgraph features, including “experimental” features. These may be known to require further development to achieve determinism, in which case they will not be eligible for rewards and therefore disputes. But in some cases, features may be expected to be deterministic, but might require observation in a production environment in order to achieve full confidence. An example might be the introduction of a new Ethereum network. In these cases, features might be marked as eligible for rewards, but in the event of a dispute, indexers who cooperate with the Arbitrator can expect a higher likelihood of a draw, given the contribution towards a better understanding the behaviour of the experimental feature.

[cryptovestor]

@adamfuller

In a dispute, if a PoI is invalid for the epoch in which the allocation was closed, but valid as of the first block of the preceding epoch, then the Arbitrator should settle the dispute as a Draw.

If I understand the above correctly, then asking this question will make sense: Will the graph node and agent behave as above when trying to close an allocation in this situation? Or will an indexer still need to manually go back and compute the PoI from the previous Epoch’ start block and manually close the allocation via actions queue or otherwise?

[mindstyle_p-ops]

god i hope not, this whole charter thing is pretty messed up (imo) as is

also a question, does this charter plan to be released/published somewhere where its actually accessible please?

[indexer_payne]

This is because the transactions might be stuck for x hours and within those x hours, the epoch advances. It’s the current behaviour of the arbitration charter as well, if I recall correctly.

[adamfuller]

Hi @mindstyle_p-ops! Would be great to understand your objections in more detail?

The proposed text is here: GIP-0009: Arbitration Charter - HackMD

[adamfuller]

As @indexer_payne says this is the current behaviour of the charter, to allow for situations where an allocation is closed as a new epoch ticks over.

@cryptovestor I think your question is maybe more about failed subgraphs, where the manual process you described is currently required? @Ford I think this is something which could be handled automagically by the agent for failed subgraphs?

[mindstyle_p-ops]

Regarding the charter itself, it has been discussed a bit in recent disputes. Its quite unclear what is wrong or right, or what is dispute worthy and what not, especially given the cases that already happened (vast majority ends up in a draw). This leads me to believe its not clear enough for either the fishermen or indexers. Unfortunately i guess we need to stick with it until its no longer needed at all (which i hope its soon).

As far as the other point goes, just wanted to say that people have a hard time accessing in it Radicle, so something more publicly available would be great (and sorry if it already is, didnt see any news on that).

[inflex]

Putting some non-existent future GIP-XXXX into the current version of Arbitration Charter ruling out the disputes? What a mess. I hope you haven’t changed it on Radicle.
I was actualy the first person who leveraged that Radicle text for personal gains. And am now too lazy to go there and actually check if changes are there. Demonstrates how useless it is, huh?

[adamfuller]

Hi @inflex - thanks, good spot, that should have had a link to GIP-0038: GIP-0038: Epoch Block Oracle, I will update.

It sounds like you have other reservations about the charter, are there specific areas you would change?

[JB273]

Good that we have this charter and make it clear and workable for everybody involved.
Currently it doesn’t work really imo, I will keep the example only to the opened dispute against our indexer, but I think it also counts for all disputes currently running (or actually shouldn’t be running anymore).
The arbitration charter describes the handling of disputes in a timely fashion, it states here, and I quote “The Arbitrator should seek to settle all disputes within one week of a dispute
being submitted.”
It’s really important that we keep an eye of what we think is normal usage and behavior within The Graph protocol by indexers, but having disputes open or unsettled for over 2 months obviously is not the way to go and will be impossible to follow up in later stages.
So in the current form it’s all just (extra) paperwork and nothing else if you ask me!

Curious how others look at this process and how we run it currently!