GIP-0043: Activate indexing rewards in The Graph Network on Arbitrum One

Governance & GIPs Graph Improvement Proposals (GIP)
1 
GIP: 0043
Title: Activate indexing rewards in The Graph Network on Arbitrum One
Authors: Pablo Carranza Vélez <pablo@edgeandnode.com>, Ariel Barmat <ariel@edgeandnode.com>, Tomás Migone <tomas@edgeandnode.com>
Created: 2023-02-01
Updated: 2023-02-01
Stage: Candidate
Category: "Protocol Logic", "Protocol Interfaces", "Economic Parameters"
Depends-On: GIP-0037

Abstract

In this GIP we propose to upgrade the protocol contracts to support indexing rewards on the L2 as described in GIP-0037. That GIP proposed changing indexer rewards issuance to follow a linear function instead of the current exponential / compound interest formula, with the GRT for rewards minted natively in L1 and L2. In addition, we propose activating indexing rewards in Arbitrum One using a small initial step of 5% to 10% of the total issuance rate.

Motivation

The Graph Protocol contracts have been deployed to Arbitrum One in block 42,449,166 as proposed in GIP-0040 and approved by the Council in GGP-0017. Since then, all the participants can run indexers and subgraphs on Arbitrum One. However, indexers don’t have any additional incentive to query fees collected from consumers. This GIP proposes to activate indexing rewards on Arbitrum One using a small initial step of 5% to 10% of issuance to increase the supply of indexers on the L2 deployment of The Graph Network.

High-Level Description

Enabling indexing rewards in Arbitrum One involves several steps that we can divide into three parts:

Part One: Upgrade

  • Upgrade the Rewards Manager in Ethereum Mainnet (L1) to use the new linear issuance mechanism.

  • Upgrade the L1GraphTokenGateway in Ethereum Mainnet (L1) to add extra protections for minted tokens coming from L2.

  • Upgrade the Rewards Manager in Arbitrum One (L2) to use the new linear issuance mechanism.

  • Council calls RewardsManager.updateAccRewardsPerSignal() in L1 to storage all pending accrual.

  • Set indexing rewards configuration in terms of issuance speed instead of a percentage of the total token supply on Ethereum Mainnet (L1). We can calculate the current total issuance rate as speed in GRT per block:

totalIssuancePerBlock = totalSupply \times issuanceRatePerYear \div blocksPerYear
totalSupply = 10,576,000,000
issuanceRatePerYear = 0.03
ethBlockTime = 12 \text{sec}\
blocksPerYear = secondsPerYear / ethBlockTime
10,576,000,000 \times 0.03 / (60 \times 60 \times 24 \times 365 \div 12) = 120.73 \text{GRT/block}\
  • Finally, check that everything is properly configured and update relevant monitoring that tracks indexing rewards issuance.

Part Two: Activate indexing rewards in Arbitrum One

  • After reviewing that the upgrade is working correctly, the Graph Council will send one transaction to reduce the per-block issuance speed on Ethereum Mainnet (L1) and another one to increase it on Arbitrum One (L2).

  • The Council must ensure that the transactions to L1 and L2 get mined as close as possible to avoid a gap in the issuance rate.

  • Considering that total issuance speed is now the combined speed of L1 and L2:

totalIssuancePerBlock = issuancePerBlockL_1 + issuancePerBlockL_2

To set the rewards distribution in Arbitrum One to be 10% of the global issuance, the Council should set the issuance speed this way to keep the global issuance at the same rate:

issuancePerBlockL_1 = 0.9 \times totalIssuancePerBlock
issuancePerBlockL_2 = 0.1 \times totalIssuancePerBlock

Part Three: Set L2 Bridge enhanced protections

One of the features introduced by GIP-0037 implementation is a “Mint Allowance Protection” as an extra line of defense against uncontrolled minting of L1 GRT after a large withdrawal from the L2.

  • The Council must set this value to follow the issuance speed on L2 using RewardsManager.updateL2MintAllowance() to match the configuration used in Part Two.

Additional Considerations

  • After the Council upgrades the contracts to use a linear reward distribution, it will lead to less issuance over a very long period. The Council might consider reviewing the issuance per block parameter to match a desired target inflation to total supply.

  • This GIP kickstarts the activation of indexing rewards in Arbitrum One. However, the Graph Council will need to decide on future updates in the distribution parameters to migrate most and eventually all of the reward issuance to L2.

Related Work

For additional details, please read the related work in the following GIPs:

  • GIP-0037: The Graph Arbitrum deployment with linear rewards minted in L2
  • GIP-0040: L2 Bridge and Protocol Deployment

The feature is implemented in PR-700

Risks and Security Considerations

Please read GIP-0037 for a detailed description.

Validation

  • The code was audited by OpenZeppelin and the audit report can be found here: OpenZeppelin Audit

  • Edge & Node team is running the test and deployment plan that involves simulating the upgrade, activating the rewards and checking that the issuance is correct.

Copyright Waiver

Copyright and related rights waived via CC0.

8 Likes
2

I am strongly in favor of diverting some portion (5%) of indexing rewards to L2, even before it is considered production ready, as having some real incentives enabled is crucial to the testing process.

5 Likes
3

Agreed, and would add a nod towards 5% (or up to 10%) to draw in early interest.

3 Likes
4

I think this is an important step in the journey to L2. I think we should err on the side of caution with respect to the proportion distributed on L2 to begin with, so I would be in favour of 5% or less, and ramp that up as key milestones are met.

3 Likes
5

Thanks for sharing this GIP, Ariel. There may be benefits to waiting on activating L2 indexing rewards (or at least keeping them as low as possible).

  1. Indexing rewards may be unnecessary. As indexers can be more efficient on Arbitrum (e.g. due to greatly reduced gas costs) and developers are expected to migrate there (again due to reduced costs), indexers may migrate without any indexing rewards. This is because reduced costs can increase indexer profitability from query fees.
  2. We may see lower and more stable query prices without indexing rewards. Without a subsidy, indexers that migrate are more inclined to streamline/optimize their operations and discover costs for serving queries than if they are insensitive to such matters (e.g. today many indexers on L1 use default query cost models).
  3. Activating indexing rewards on L2 now may complicate (if not block) a transition to curation v2. As the mechanisms for curation v1.x and indexing rewards are tied together, it may be least disruptive to users’ experiences if we first update curation and then turn on indexing rewards.

Lastly, if we are ultimately interested in helping developers get their queries served, I find it worth noting that I am not aware of any incentive provided by indexing rewards to motivate indexers to serve queries.

3 Likes
6
  1. indexers may migrate without any indexing rewards. This is because reduced costs can increase indexer profitability from query fees.

This is an idealistic scenario that will never happen imo. The query fees of the last 3 months are ~900k GRT which translates to less than $50k for the entire network at the current market price. Whereas the indexing rewards are ~800k GRT per day.

  1. We may see lower and more stable query prices without indexing rewards.

This means even lower revenue for indexers, reading the above stats. Lower query prices doesn’t translate to more queries. You need projects to migrate, to generate the queries, first and foremost, and only then, figure out ways to reduce the query prices.

  1. I am not aware of any incentive provided by indexing rewards to motivate indexers to serve queries.

While there are no incentives to serve queries there are incentives to keep running your infrastructure. There are 431 indexers on the network today (data coming from the explorer). Imagine if all those 431 indexers would be paid equally - that’s $116 per indexer at the current GRT price. If you can host your graph infrastructure and archive nodes within that budget, let me know, cus I’m looking to find a better provider than Hetzner (that already has a concentration of 60-80% of the indexers today).

7 Likes
7

Agree here, but I think @howard is onto something on expanding our thinking on how serving queries themselves might be incentivised. Maybe a topic for a different thread though.

2 Likes
8

Howard makes some good points. I also understand the reasoning by indexer_payne. While it is idealistic, delaying indexing rewards can at least test Howard’s hypothesis at relatively little cost (as long as the delay is sufficiently short). Furthermore, even if one indexer migrates (and thus some customers follow), we might gather some insight as to how indexers can optimize their behavior in absence of indexing rewards and provide better guidance to indexers in the future when query fees dwarf indexing rewards.

In short, it is unlikely all indexers will migrate without indexing rewards, but running an experiment to see even if one indexer migrates does have its benefits. Of course, this has to be weighed against the benefit of a timely migration to L2.

3 Likes
9

We already have a couple indexers migrating, but I would argue their behavior at this time will tell us little about the future when query fees dwarf rewards. I imagine they’re testing the waters and setting up their operations in anticipation of rewards starting to flow in, so I doubt they’ll be optimizing for queries at this time (we can ask them I guess? but Payne’s comment is probably a good indicator).

Slowing down the rewards rollout means slowing down a larger number of indexers going to L2, which in turn makes L2 less attractive to subgraph developers (as there’s less capacity to handle larger projects), which in turn means less query fees, which makes the whole idea of slowing down the rewards rollout even less effective imho…

As far as I know, one of the initial purposes of having indexing rewards was “bootstrapping the network”, and they seem to have worked for that in mainnet. Now that we have a new network in L2 I think bootstrapping it is just as important. Especially if curation v2 is at least a few months away (considering implementation, audit and testing times), keeping L2 without rewards throughout this time would surely slow down the migration significantly.

As to incentivizing serving queries, I think the current setup is kinda like paying an incentive for running the first 20 miles in a marathon; if you also get a medal if you finish the full thing (query fees), I think most people would try to finish to get both. So it’s an indirect incentive, but I think mainnet proves it’s at least somewhat effective.

(Edit: Just to clarify, I would still support ideas for incentivizing serving queries more directly, e.g. finding ways to slash indexers that collect rewards but don’t respond to queries, or providing rewards for verifiably serving queries somehow)

5 Likes
10

Hi all, the Council has voted for deploying this GIP with a 5% initial rewards value for L2: Snapshot

We’re getting ready to deploy the updates and enable L2 rewards this week, will post back here when it’s done.

Update (April 10th): The upgrade has now been deployed and signed by the Council, so 5% of indexing rewards (6.0365 GRT per block) are now issued on L2 (with mainnet having 95% i.e. 114.6935 GRT per block).

4 Likes