GGP: 0014 Scope: Arbitration charter Created: 2022-11-07

GIPs

GIP: 0009 Title: Arbitration Charter Authors: Brandon Ramirez, Adam Fuller Created: 2021-04-09 Updated: 2022-11-01 Stage: Candidate Discussions-To: https://forum.thegraph.com/t/an-arbitration-charter-to-clarify-arbitrator-behavior/ Category: Protocol Charters Depends-On: GIP-0005, GIP-0007, GIP-0008

Abstract

The Graph has a protocol role called an Arbitrator who is assigned through decentralized governance. The Arbitrator is an Ethereum Account that has the ability to decide the outcome of disputes in the protocol. The purpose of the Arbitration Charter are to establish norms that constrain the Arbitrator’s actions beyond what is expressible or currently expressed in smart contract code. We propose that any Arbitrator that does not comply with the norms laid out in this charter be replaced via decentralized governance.

Contents

The full text of the arbitration charter as of version 2022-11-01 is stored in IPFS under CID QmaENLieqnQ9ronsPexUzNbHysWDrhDgKvydZQCbLB16kw.

Motivation

The Arbitrator is a protocol role that is assigned via decentralized governance, and as such there are certain parts of its behavior that are not specified in smart contract code running on-chain. Having a protocol charter for this actor's behavior creates clarity for the ecosystem in how the role of the Arbitrator will be executed and establishes a standard for measuring the effectiveness of an Arbitrator, which can be referenced in protocol governance discussions around the appointment of an Arbitrator.

The substance of the Arbitration charter is intended to ensure that the Arbitrator is fulfilling their role of supporting a healthy and functioning network where Indexers perform their work correctly, while minimizing the risk to honest Indexers of being economically penalized while interacting with the protocol in good faith.

The next section elaborates on the specific rationale behind select parts of the charter and how they help accomplish said goals.

Rationale and Alternatives

Indexing and query faults due to software malfunctions

Allowing the Arbitrator to exercise discretion in the event of determinism bugs removes possible disincentives and barriers for participation for Indexers. The alternative would require Indexers to become experts on the Graph Node software, which is written in Rust and under active development, or else assume the risk of having their stake slashed for software malfunctions that are outside their direct control.

Double Jeopardy

This is a form of replay protection which prevents an Indexer from being slashed an indefinite number of times for a single fault. Allowing for such an outcome would be a massive disincentive to Indexers participating in the protocol.

A drawback of the current approach is that given the current Attestation structure, an Indexer actually could give the same incorrect response to multiple Consumers and those Attestations would be indistinguishable from one another and could result in at most one instance of the Indexer being slashed.

An alternate approach would be to alter the Attestation structure such that the replay protection only applied to incorrect query responses provided to a specific Consumer.

Furthermore, it might be preferable for the protocol smart contracts to store a record of past disputes in order to enforce the double jeopardy rule, rather than leaving it up to the Arbitrator, which might be prone to error.

Both of the above alternative designs would be far heavier to implement, however, as they require changes to the protocol software and additional on-chain bookkeeping. These may be explored in future GIPs.

Statute of Limitations

There are several reasons for placing a statute of limitations on the faults for which an Indexer can be slashed:

1. The alternative, allowing Indexers to be slashed for faults that occurred an indefinite amount of time in the past, would punish Indexers that participate in the protocol for a long period of time and thus have a far greater number of instances where they might be slashed due to software malfunctions or operational errors.
2. Without this clause, Indexers might periodically exit and re-enter the protocol under new identities, to manage their risk of slashing due to possible accumulated faults. This lack of continuity between Indexer identities would create noise in the protocol and would possibly obstruct useful Indexer reputation systems being built around The Graph.
3. A malicious Indexer attacking the protocol can unstake their GRT immediately after an attack and thus would not be slashable after a thawing period. It would be unfair to make the stake of honest Indexers slashable for a period substantially longer than that of a malicious Indexer.

An alternate design that addresses the above issues would be to enforce the statute of limitations in the protocol smart contracts. A drawback of this approach, as before, is that it requires software changes and so is a heavier change. This approach may be explored in a future GIP.

Data Availability

An Arbitrator can only perform their job if they are able to reproduce the work of an Indexer. This requires access to data such as subgraph manifests or the body of a query, both of which are too large to store on-chain. A Fisherman should have a built-in incentive to make sure this data is available so they can be awarded for a successful dispute.

The proposed charter requires settling disputes where data is unavailable as a Draw. An alternative design would be to punish the Fisherman for submitting a dispute without making the data available. A drawback of this approach is that discovering files through the IPFS distributed hash table (DHT) is not 100% reliable and could introduce undue risk to the Fisherman. This might be mitigated by requiring the Fisherman to pin all necessary files to a specific IPFS node, but this feels overly centralized and brittle.

Another alternative could be to require the necessary files to be pinned to a storage chain such as Arweave or Filecoin, and only allow a dispute to created if all necessary files are available. This may be explored in a future GIP.

Maximum allowable slashing for query disputes

By capping the amount that an Indexer can be slashed for queries in a given time period, the charter addresses an important asymmetry between indexing and querying in the protocol: specifically, the fact that Indexers only submit one PoI per allocation and thus can be slashed a maximum of once per allocation for indexing faults, but Indexers may respond to an unbounded number of queries during an allocation and thus might expose themselves to a similarly unbounded level of risk due to slashing, capped only by their total stake, from software malfunctions or other operational errors. Without the cap specified in this clause, an Indexer could theoretically have all their stake slashed in a single allocation.

An alternative design would be to implement this cap in the protocol smart contracts. This is a heavier change as it requires an upgrade to the protocol smart contracts. This may be explored in a future GIP.

Valid Proofs of Indexing for a given epoch.

Currently, the protocol smart contracts do not let you specify as of which epoch you would like to close an allocation; rather, this is inferred from the current epoch as of when the transaction gets mined that closes the allocation. This leaves open the possibility that an Indexer may submit a PoI in a transaction that is intended to close an allocation in one epoch, but the transaction might not actually get mined until the following epoch. Given the unpredictability of gas costs and interacting with the blockchain, it would be undesirable to punish Indexers for such a situation.

An alternative design would be to allow Indexers to specify an epoch number when closing an allocation. This is a heavier change as it requires an upgrade to the protocol smart contracts. This may be explored in a future GIP.

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.

Dependencies

This GIP depends on two other GIPs:

• GIP-0005 (TBD) - Makes timeouts in subgraph fully deterministic using WASM gas metering. This is necessary for the Arbitrator to reproduce the work of Indexers in a way that is completely deterministic.
• GIP-0008 - Specifies the process for making upgrades to the Subgraph API and Indexer software. This is necessary for defining the canonical version of the protocol software that the Arbitrator should run in reproducing the work of Indexers.
• GIP XXXX (TBD) - Allows the protocol to set separate slashing percentages for indexing and query faults. This is necessary because this charter proposes allowing Indexers to be slashed once per epoch for query faults, which with current network parameters of 2.5% slashing and 28 epochs max allocation duration, equates to up to 70% possible slashing from query faults for a single allocation. This is disproportionately high compared to the 2.5% maximum slashing per allocation that currently exists for indexing faults.

Risks and Security Considerations

As this GIP is a protocol charter, it does not introduce any new technical risks or security considerations that do not already exist in the protocol today.

A possible non-technical risk is that this charter provides a false sense of security to Indexers participating in the protocol that it is impossible to be slashed while interacting with the protocol in good faith, but then are slashed due to the Arbitrator executing their duties incorrectly.

Future work

Delayed dispute decision finalization

It was suggested in the review of this GIP that there could be a protocol-enforced window before the decision of a dispute can be finalized in order to provide ample time for appealing to the community and The Graph Council. This may be explored in a future GIP.

Enforcing conventions in this charter at the protocol level

While most of the Arbitration charter describes conventions for behavior that are difficult to specify on-chain, some clauses could be enforced at the smart contract layer. This may be explored in future GIPs.

Only make allocated stake slashable

Currently, all of an Indexer's stake may be slashed for a fault that occurred involving a single allocation. A possible change would be to allow Indexers to limit their risk by only having the allocated stake associated with a fault be slashable. This also removes a disincentive for Indexers to create many simultaneous allocations. This would require a change to the smart contracts and may be explored in a future GIP.

Make shorter allocations slashable for a smaller amount that longer allocations for indexing disputes

Currently, an Indexer is punished for closing their allocations more frequently, as they submit more PoIs in this process, which creates more opportunities to be slashed. An alternate design would be to set a slashing percentage per epoch of indexing, such that longer allocations may be slashed for a greater percentage than shorter allocations. This would require a smart contract upgrade and may be explored in a future GIP.

---

Graph Governance Proposal 0014

Through this proposal, the Council ratifies the Arbitration Charter with IPFS CID QmaENLieqnQ9ronsPexUzNbHysWDrhDgKvydZQCbLB16kw, which is currently used to inform arbitration decisions, and has been updated for the introduction of the Epoch Block Oracle.