Skip to main content

GRT $0.01972 up 1.06% Market cap $217.6M

Minimum Curation Amount for Indexing Rewards Eligibility

GGP-0011 · Council vote #12 on The Graph

Overview

Updated

Approved

Voting ended
May 26, 2022
Opened May 19, 2022
Submitted
May 19, 2022
May 19, 13:46 UTC
Members voted
6
One vote each, on Snapshot

GGP-0011 was also put to a vote as #11.

Put to the Council by 0xd201c9…22aa

Votes

  • Yes 6 votes
  • No 0 votes

How BitBasic reads the result

  • Approved when more Council members chose Yes than No.
  • Each member has one vote, and Snapshot keeps a member's last.

Description

GGP: 0011 Scope: RewardsManager contract Created: 2022-05-07 GIPs-Repo-Latest-Commit: 7f427b25a84391032e15193e323997e37967eb75

GIPs

GIP: 0030 Title: Minimum Curation Amount for Indexing Rewards Eligibility Authors: Ricky Esclapon ricky@edgeandnode.com, Craig Tutterow craig@edgeandnode.com Created: 2022-04-19 Stage: Candidate Discussions-To: https://forum.thegraph.com/t/gip-0030-minimum-curation-amount-for-indexing-rewards-eligibility/3290

Abstract

To mitigate economic security risks to the protocol, we propose initializing a new protocol parameter: minimum_signal, to an amount of 500 GRT in order for a subgraph to become eligible for receiving indexing rewards. We present a sensitivity analysis that indicates that a minimum curation parameter will make the proof of indexing spoofing attack identified in the protocol’s OpenZeppelin security audit unprofitable under specified economic conditions.

Motivation

The OpenZeppelin audit identified an economic attack vector (C02) wherein a dishonest Indexer could:

  • Minimize self-staking to reduce value at risk of slashing.
  • Maximize self-delegation, which is eligible for receiving indexing rewards without slashing risk.
  • Forego infrastructure and labor costs of indexing by spoofing PoIs, thereby taking on slashing risk while claiming indexing rewards.

Prysm Group, a team of economists specializing in mechanism design and game theory, received a grant from The Graph Foundation to develop a model and conduct an analysis of the viability of this strategy, as well as develop recommendations for mitigating the risk of such an attack. Edge & Node data scientists subsequently performed a numerical and sensitivity analysis to extend the Prysm models and identify values for protocol parameters that are capable of preventing this attack under different economic circumstances.

References

  • The OpenZeppelin Audit (Issue C02) provided a qualitative description of the proof of indexing spoofing attack.
  • Prysm Group was contracted to develop a formal model and design a mechanism to protect against such an attack: Initial Analysis of PoI Spoofing Attack Viability, PoI Spoofing Profitability Model and Analysis.
  • Development work for implementing the minimum curation signal protocol parameter was completed in December and subsequently audited, but establishing a value that would prevent the attack required further analysis based on the Prysm Group models. See: Github PR for graphprotocol/contracts.
  • Edge & Node Data Science did a parameter search based on the Prysm analysis. This was presented in slides on the March 31 Core Dev call and code for the analysis can be found in the notebook here.
  • Implementations: https://github.com/graphprotocol/contracts/pull/528/

Graph Governance Proposal-0011

This proposal is to upgrade The Graph's protocol smart contracts running on Ethereum mainnet with the changes described in Graph Improvement Proposal (GIP) 0030, including the motivation and scope of the changes described in this proposal.

The code deployed that implements GIP-0030 must correspond to the commit hash included in the front matter of this governance proposal.

Following a successful "yes" vote, the protocol upgrade should be carried out at the earliest convenience using The Graph Council's Gnosis Multisig. Following the upgrade, the Council should subsequently set the minimum_signal parameter to 500 GRT, as proposed in the GIP.

How the Council voted

In the order they voted. Snapshot knows members by address only, so BitBasic doesn't name them.

Member Vote When
0xd201c9…22aa Yes May 19, 13:47 UTC
0x38fa68…4da8 Yes May 19, 18:54 UTC
0xb02ce5…80b0 Yes May 20, 07:10 UTC
0x17118d…2c21 Yes May 25, 05:52 UTC
0x37bc95…b391 Yes May 25, 21:05 UTC
0xfe46c8…4dc2 Yes May 25, 22:54 UTC