Minor spelling error:
Make shorter allocations slashable for a smaller amount that longer allocations for indexing disputes
that → than
1 Like
Attestation that is only correct with respect to the previous official version of the Indexer software
I think the language should account for the possibility that multiple previous versions of the software may have been sunset during the grace period and that any of them would be valid. There is other language to be modified to this effect in the same paragraph.
2 Likes
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.
I’m realizing now after having read my previous post on this a second time when linking someone to this discussion that I failed to mention what this should be changed to.
Instead, the same mechanism should be used to query the PoI for the same block as though the subgraph had not entered into a deterministic failure state. The way that the PoI is written it will continue to be updated and provide security.
This simplifies the indexer-agent as well as the logic as to how an Indexer should behave. The Indexer can continue to open and close allocations, and serve queries, as if nothing has happened. Historical queries would give results and queries after the failed block would give attestable errors.
1 Like
Hi @That3Percent could you rephrase this?
In the form of “If this happened → then you should do: step 1, step 2, step 3”
Because for now, I understood this in the wrong way (I think), like:
If Subgraph has a bug (like mStable or like Enzyme?) do this:
- Don’t worry and close allocations without any additional actions (with the usual generated POI, not 0x0).
- Keep working with this subgraph.
- Order Lambo.
1 Like
I think you understand this in the correct way.
If a subgraph has a deterministic failure, continue as normal by eventually closing the allocation with the usual non-zero PoI. If there is still curation on the failed subgraph, consider opening another allocation.
3 Likes
Hello,
I generally agree with the charter and glad we have the discussion here and about the fact we have fantastic arbitration team. The rules are very good thought through and I think indexers are generally happy about the level of clarify at this stage. There is a clear evidence for presumption of innocence both in the charter and in the approach used by arbitrators and broader Graph team and the community, which is great!
Although i am generally happy with how things are, I would like to share my view on few points which I believe worth to consider.
- 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.
- I would like to highlight my observation regarding the recent update of the chapter 9
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.
So the exception to the rule not penalise indexers for the subgraph failure is perfectly fine, but without clarity for how long backwards the last valid PoI should count it created the opposite -the incentive to stay on the failed subgraph for as long as possible.
What is even more worrying, then if such behaviour is supported we may have more precedents and some indexers may even deploy their own subgraphs which they know will fail at some point and signal on them to basically create the exclusive environment for them to enjoy rewards on the subgraph which only they are allowed to submit valid poi as the only allocated before the failure…
Regards,
vict | grassets.tech
3 Likes
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.
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.
2 Likes
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.
2 Likes
We still need to clarify the question(I believe it was good enough clarified in the charter, but people still discussing it):
- 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:
- 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.
- 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.
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.
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.
1 Like
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.
4 Likes
Another funny part of Opyn allocations:
It seems like more than 28 epochs, but allocations are still open.
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.
1 Like
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?
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?
1 Like
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.
1 Like
Hi @mindstyle_p-ops! Would be great to understand your objections in more detail?
The proposed text is here: GIP-0009: Arbitration Charter - HackMD
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?
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).