--- GIP: 0005 Title: Gas costing for handlers Authors: Leonardo Yvens<leo@edgeandnode.com> and Zac Burns <zac@edgeandnode.com> Created: 2021-05-04 Updated: 2021-05-24 Stage: Candidate Implementations: https://github.com/graphprotocol/graph-node/pull/2414 --- # GIP-0005: Gas costing for handlers ## Abstract This GIP proposes that the computational cost of a handler be measured in units of gas and limited to a maximum cost. If a handler attempts to consume more gas than the maximum, the subgraph will fail with a deterministic error. This is necessary so that it is possible to prove that a subgraph cannot be indexed past the block which triggers such a handler. ## Motivation Subgraph handlers that run for too long are an issue for operators, since they excessively consume resources, and also a issue for protocol security since they make the subgraph impossible to sync in a reasonable time, if it can be synced at all. Graph Node currently implements a timeout for handlers, which is useful to prevent excessive resource consumption, however timeouts are not deterministic. For protocol security, it is necessary to deterministically measure the cost of a handler. This GIP proposes gas costing for handlers, similar to the gas costing for transactions that exists in blockchain protocols. ## Detailed Specification Gas is defined as the unit of execution cost. As a reference, one unit of gas should correspond to 0.1ns of execution time, making for 10 billion gas in a second. Close correlation with execution time is not a primary goal of gas costing, at least not in this first iteration. Still gas needs to have some correlation to execution time in order to be useful. The maximum gas cost for a handler should be sufficient for any reasonable subgraph, and be limited by the cost a Fisherman or Arbitrator would be willing to incur in order to check an attestation. The proposed limit is 1000 seconds of execution time, which corresponds to 10 trillion gas. The costs incurred by executing a handler can be categorized as either WASM execution costs or host function execution costs. WASM execution costs must be measured by injecting a callback at the block, see the documentation for this technique in the [pwasm-utils crate](https://docs.rs/pwasm-utils/0.17.1/pwasm_utils/fn.inject_gas_counter.html). For the gas costing of individual WASM instructions, refer to the implementation in [this commit](https://github.com/graphprotocol/graph-node/blob/30720a8f1fb074b71fe76729d4e0dc4ba3c3e955/runtime/wasm/src/gas_rules.rs). The cost of most host functions is calculated as a base cost added to a cost per byte of input. To account for host functions that have non-linear complexity, the input bytes are first combined through a complexity function and then multiplied by the cost per byte. To calculate the size of the input bytes, a `gas_size_of` function exists for each data type that is an input to a host function, see implementations of `GasSizeOf` in the reference implementation for details. Note that `gas_size_of` is an approximation of the true in-memory size of the data, the actual size may vary between platforms and implementations but still this approximation should be sufficient for gas costing purposes. #### Constants This section specifies the constants used for applying a cost to host functions. ##### Table 1: | Constant | Value (in gas) | Description | | ---------------------- | ------------------------------------ | ------------------------------------------------------------ | | GAS_PER_SECOND | 10_000_000_000 | Relates time and gas units. | | MAX_GAS_PER_HANDLER | 3600 * GAS_PER_SECOND | The limit is one hour worth of gas. | | HOST_EXPORT_GAS | 10_000 | Cost of the callback that measures gas. | | DEFAULT_BASE_COST | 100_000 | Base cost of most host functions. | | DEFAULT_GAS_PER_BYTE | 1_000 | Equivalent to 10MB/s, so 10GB in the 1000 seconds limit. | | BIG_MATH_GAS_PER_BYTE | 100 | Equivalent to 100MB/s. | | ETHEREUM_CALL | 25_000_000_000 | Gas cost of a contract call. Allows for 400 contract calls. | | CREATE_DATA_SOURCE | MAX_GAS_PER_HANDLER / 100_000 | Cost of `dataSource.create`. | | LOG_GAS | MAX_GAS_PER_HANDLER / 100_000 | Base cost of `log.log`. | | STORE_SET_BASE_COST | MAX_GAS_PER_HANDLER / 250_000 | Base cost of `store.set`. | | STORE_SET_GAS_PER_BYTE | MAX_GAS_PER_HANDLER / 1_000_000_000 | Allows 1GB of entity data for `store.set`. | | STORE_GET_BASE_COST | MAX_GAS_PER_HANDLER / 10_000_000 | Base cost of `store.get`. | | STORE_GET_GAS_PER_BYTE | MAX_GAS_PER_HANDLER / 1_000_000_000 | Allows 10GB of entity data for `store.get`. | #### Costs for host functions This section specifies the costs attributed to each host function. Most host functions have linear complexity on a single parameter `N` and are costed as: ```` DEFAULT_BASE_COST + gas_size_of(N)*DEFAULT_GAS_PER_BYTE ```` Host functions that differ from this are listed in the table below: | Host function | Cost | | --------------------------- | ------------------------------------------------------------ | | abort | DEFAULT_BASE_COST | | store.set(key, data) | STORE_SET_BASE_COST + STORE_SET_GAS_PER_BYTE * (gas_size_of(key) + gas_size_of(data)) | | store.remove(key) | STORE_SET_BASE_COST + STORE_SET_GAS_PER_BYTE * gas_size_of(key) | | store.get(key) -> data | STORE_GET_BASE_COST + STORE_GET_GAS_PER_BYTE * (gas_size_of(key) + gas_size_of(data)) | | ethereum.call | ETHEREUM_CALL | | dataSource.create | CREATE_DATA_SOURCE | | log.log(m) | LOG_GAS + DEFAULT_GAS_PER_BYTE * gas_size_of(m) | | bigInt.plus(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * max(gas_size_of(x), gas_size_of(y)) | | bigInt.minus(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * max(gas_size_of(x), gas_size_of(y)) | | bigInt.times(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * gas_size_of(x) * gas_size_of(y) | | bigInt.divided_by(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * gas_size_of(x) * gas_size_of(y) | | bigInt.mod(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * gas_size_of(x) * gas_size_of(y) | | bigInt.pow(x, exp) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * gas_size_of(x) ^ exp | | bigInt.bit_or(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * max(gas_size_of(x), gas_size_of(y)) | | bigInt.bit_and(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * min(gas_size_of(x), gas_size_of(y)) | | bigDecimal.plus(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * (gas_size_of(x) + gas_size_of(y)) | | bigDecimal.minus(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * (gas_size_of(x) + gas_size_of(y)) | | bigDecimal.times(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * gas_size_of(x) * gas_size_of(y) | | bigDecimal.divided_by(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * gas_size_of(x) * gas_size_of(y) | | bigDecimal.equals(x, y) | DEFAULT_BASE_COST + BIG_MATH_GAS_PER_BYTE * min(gas_size_of(x), gas_size_of(y)) |
Last changed by  
 
Brandon Ramirez
334

Read more

GIP XXXX - Reduce Curation Tax

Abstract This GIP proposes reducing the Curation Tax parameter in the protocol from 2.5% to 1%. The proposal evaluates this change in the context of a previously undisclosed attack we refer to as a Subgraph Withholding Attack. Motivation As production subgraphs migrate to The Graph's decentralized network, we have collected more data and feedback on the total costs of using the network as a subgraph developer. As many subgraph developers initially signaled ~100K GRT initially when using the network, the cost of upgrading a subgraph currently sits around 2.5K GRT. This cost is in addition to the opportunity cost of locking up the signal as well as the cost of actually paying for query fees. Note This ignores the curation tax costs associated with signal delegation, which will be addressed in a separate GIP. See Future Work.

1/18/2023
GIP-0009: Arbitration Charter

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. This section contains the body of the arbitration charter. Later sections elaborate on the context and motivation for the design. Arbitration Charter 1. Role of the Arbitrator. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network. They fulfill this purpose by looking at the Proofs of Indexing (PoIs) or query Attestations associated with a dispute and checking if they correspond to the results that the Arbitrator produced when reproducing the work themselves. They decide the outcome of the dispute according to the norms laid out in this charter and based on whether the PoI or Attestation was produced correctly.

6/4/2021
GIP-0007: Separate slashing percentages for query and indexing disputes

Abstract This proposal introduces two different slashing percentages, one for indexing disputes and another for query disputes. This change allows slashing percentages to be set in such a way that accounts for the different risks of producing slashable faults while indexing and querying. Motivation One of the security mechanisms in The Graph relies on filing disputes whenever an Indexer presents a wrong Proof of Indexing (PoI) or if it returns a query with inaccurate data. After any participant files a dispute, the Arbitrators will decide if the dispute is valid according to norms established via protocol governance. If the Arbitrator accepts the dispute, the offending Indexer's stake is slashed according to a governance parameter called slashingPercentage. The issue with having a single slashingPercentage parameter for both indexing and query disputes is that an Indexer, in the regular day-to-day operation, will return a disproportionately higher amount of queries than PoIs. As a result, servicing queries is a higher-risk activity than indexing.

6/4/2021
GIP-0008: Subgraph API Versioning and Feature Support

Abstract This proposal defines a process for defining the canonical behavior of the subgraph API in the protocol as well as establishing the matrix of subgraph API features and their corresponding supported protocol features. Motivation A core value proposition of The Graph, as a decentralized protocol for indexing and querying public data is that a Consumer can trust the integrity of the work performed by the network, with minimal or zero trust in any individual Indexer. There are a number of techniques for achieving this with varying degrees of trust minimization. These include off-chain reputation systems as well as mechanisms that may be combined with slashing such as arbitration, refereed games and cryptographic fraud or validity proofs. In general, the more trustless the mechanism, the greater the research and engineering effort required to implement it. This proposal therefore describes a support matrix comprising which subgraph API features can be used in conjunction with which features of the protocol, as determined by the strength of the techniques available for guaranteeing the integrity of said features. Having this granular support matrix allows new subgraph API features to be continuously and immediately added to the protocol with additional protocol features supported for those features in later stages--all while driving query volume for these features to the decentralized network, as opposed to any centralized services that might be used to expose these features. Additionally, all the mentioned techniques with the notable exception of reputation systems, require that the work that Indexer perform be defined deterministically. Therefore, this proposal also describes how a canonical version of the subgraph API may be established via decentralized governance. This is a hard requirement for supporting protocol features such as disputing and slashing Indexers for invalid indexing or query work.

6/4/2021
Read more from Brandon Ramirez
Published on HackMD