|
1 | 1 | # Graph Protocol Solidity Smart Contracts
|
2 | 2 |
|
| 3 | + |
3 | 4 | 
|
4 | 5 | 
|
5 | 6 | [](https://codecov.io/gh/graphprotocol/contracts)
|
6 | 7 |
|
7 |
| -## Contracts |
| 8 | +# The Graph Protocol Contracts |
8 | 9 |
|
9 |
| -This repository contains The Graph Protocol solidity contracts. It is based on the |
10 |
| -[PRD outlined here](https://www.notion.so/thegraph/Public-Network-Contracts-PRD-5eb8466aa4b44a1da7f16a28acd6674f), |
11 |
| -There are many other smaller, more detailed PRDs that these contracts implement, that can also be |
12 |
| -found on notion. |
| 10 | +[The Graph](https://thegraph.com/) is an indexing protocol for querying networks like Ethereum, IPFS, Polygon, and other blockchains. Anyone can build and Publish open APIs, called subgraphs, making data easily accessible. |
13 | 11 |
|
14 |
| -The contracts enable a staking protocol build on top of Ethereum, using The Graph Network Token |
15 |
| -(GRT). The network enables a decentralized network of Graph Nodes |
16 |
| -to index and serve queries for subgraphs. |
17 |
| -[Graph node's repository can be found here](https://github.com/graphprotocol/graph-node). |
| 12 | +The Graph Protocol Smart Contracts are a set of Solidity contracts that exist on the Ethereum Blockchain. The contracts enable an open and permissionless decentralized network that coordinates [Graph Nodes](https://github.com/graphprotocol/graph-node) to Index any subgraph that is added to the network. Graph Nodes then provide queries to users for those Subgraphs. Users pay for queries with the Graph Token (GRT). |
18 | 13 |
|
19 |
| -The Graph Network enables smart contract development to happen alongside subgraph development. |
20 |
| -It is a new and improved way to develop dapps. It allows developers to move some logic into the |
21 |
| -subgraph for resolving data based on events, or past storage data on Ethereum. Therefore, |
22 |
| -the contracts and the subgraph rely on each other, to show to end users the current data and state |
23 |
| -of The Graph Network. |
| 14 | +The protocol allows Indexers to Stake, Delegators to Delegate, and Curators to Signal on Subgraphs. The Signal informs Indexers which Subgraphs they should index. |
24 | 15 |
|
25 |
| -### Contracts Testing |
| 16 | +You can learn more by heading to [the documentation](https://thegraph.com/docs/about/introduction), or checking out some of the [blog posts on the protocol](https://thegraph.com/blog/the-graph-network-in-depth-part-1). |
| 17 | + |
| 18 | +# Contracts |
| 19 | + |
| 20 | +The contracts are upgradable, following the [Open Zeppelin Proxy Upgrade Pattern](https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies). Each contract will be explained in brief detail below. |
| 21 | + |
| 22 | +**_Curation_** |
| 23 | + |
| 24 | +Allows Curators to Signal GRT towards a Subgraph Deployment they want indexed on The Graph. Curators are often Subgraph Developers, but anyone can participate. Curators also receive a portion of the query fees that are earned on the Subgraph. Signaled GRT goes into a bonding curve, which returns a Graph Curation Share (GCS) to the Curator. |
| 25 | + |
| 26 | +**_Graph Name Service (GNS)_** |
| 27 | + |
| 28 | +Wraps around the Curation contract to provide pooling of Curator Signaled tokens towards a single Subgraph. This allows an owner to deploy a Subgraph, and upgrade their Subgraph to a new version. The upgrade will move all Curator tokens to a new Subgraph Deployment with a new bonding curve. |
| 29 | + |
| 30 | +**_Service Registry_** |
| 31 | + |
| 32 | +Allows Indexers to tell the network the location of their node. This allows end users to choose a node close to themselves, lowering the latency for queries. |
| 33 | + |
| 34 | +**_Dispute Manager_** |
| 35 | + |
| 36 | +Provides a way for Indexers to be slashed or incorrect or malicious behaviour. There are two types of disputes: _Query Disputes_ and _Indexing Disputes_. |
| 37 | + |
| 38 | +**_Epoch Manager_** |
| 39 | + |
| 40 | +Keeps track of protocol Epochs. Epochs are configured to be a certain block length, which is configurable by The Governor. |
| 41 | + |
| 42 | +**_Controller_** |
| 43 | + |
| 44 | +The Controller is a contract that has a registry of all protocol contract addresses. It also is the owner of all the contracts. The owner of the Controller is The Governor, which makes The Governor the address that can configure the whole protocol. The Governor is [The Graph Council](https://thegraph.com/blog/introducing-the-graph-council). |
| 45 | + |
| 46 | +**_Rewards Manager_** |
| 47 | + |
| 48 | +Tracks how inflationary GRT rewards should be handed out. It relies on the Curation contract and the Staking contract. Signaled GRT in Curation determine what percentage of inflationary tokens go towards each subgraph. Each Subgraph can have multiple Indexers Staked on it. Thus, the total rewards for the Subgraph are split up for each Indexer based on much they have Staked on that Subgraph. |
| 49 | + |
| 50 | +**_Staking_** |
| 51 | + |
| 52 | +The Staking contract allows Indexers to Stake on Subgraphs. Indexers Stake by creating Allocations on a Subgraph. It also allows Delegators to Delegate towards an Indexer. The contract also contains the slashing functionality. |
| 53 | + |
| 54 | +**_Graph Token_** |
| 55 | + |
| 56 | +An ERC-20 token (GRT) that is used as a work token to power the network incentives. The token is inflationary. |
| 57 | + |
| 58 | +# NPM package |
| 59 | + |
| 60 | +The [NPM package](https://www.npmjs.com/package/@graphprotocol/contracts) contains contract interfaces and addresses for the testnet and mainnet. It also contains [typechain](https://github.com/ethereum-ts/TypeChain) generated objects to easily interact with the contracts. This allows for anyone to install the package in their repository and interact with the protocol. It is updated and released whenever a change to the contracts occurs. |
| 61 | + |
| 62 | +``` |
| 63 | +yarn add @graphprotocol/contracts |
| 64 | +``` |
| 65 | + |
| 66 | +# Contract Addresses |
| 67 | + |
| 68 | +The testnet runs on Rinkeby, while mainnet is on Ethereum Mainnet. The addresses for both of these can be found in `./addresses.json`. |
| 69 | + |
| 70 | +# Local Setup |
| 71 | + |
| 72 | +To setup the contracts locally, checkout the `dev` branch, then run: |
| 73 | + |
| 74 | +```bash |
| 75 | +yarn |
| 76 | +yarn build |
| 77 | +``` |
| 78 | + |
| 79 | +# Testing |
26 | 80 |
|
27 | 81 | Testing is done with the following stack:
|
28 | 82 |
|
29 |
| -- Waffle |
30 |
| -- Hardhat |
31 |
| -- Typescript |
32 |
| -- Ethers |
| 83 | +- [Waffle](https://getwaffle.io/) |
| 84 | +- [Hardhat](https://hardhat.org/) |
| 85 | +- [Typescript](https://www.typescriptlang.org/) |
| 86 | +- [Ethers](https://docs.ethers.io/v5/) |
33 | 87 |
|
34 | 88 | To test all files, use `yarn test`. To test a single file run:
|
35 |
| -`npx hardhat test test/<FILE_NAME>.ts`. |
36 | 89 |
|
37 |
| -### Contract addresses |
| 90 | +```bash |
| 91 | +npx hardhat test test/<FILE_NAME>.ts |
| 92 | +``` |
| 93 | + |
| 94 | +# Interacting with the contracts |
| 95 | + |
| 96 | +There are three ways to interact with the contracts through this repo: |
| 97 | + |
| 98 | +**Hardhat** |
38 | 99 |
|
39 |
| -Currently we are running our testnet on Rinkeby. Contract addresses can be found in this repository at |
40 |
| -`./addresses.json`. However, addresses should be obtained from the NPM Package. |
| 100 | +The most straightforward way to interact with the contracts is through the hardhat console. We have extended the hardhat runtime environment to include all of the contracts. This makes it easy to run the console with autocomplete for all contracts and all functions. It is a quick and easy way to read and write to the contracts. |
41 | 101 |
|
42 |
| -### Deploying Contracts |
| 102 | +``` |
| 103 | +# A console to interact with testnet contracts |
| 104 | +npx hardhat console --network rinkeby |
| 105 | +``` |
43 | 106 |
|
44 |
| -In order to run deployments, see `./DEPLOYMENT.md`. We use a custom deployment script, which |
45 |
| -allowed us to completely remove `truffle` as a dependency. |
| 107 | +**Hardhat Tasks** |
46 | 108 |
|
47 |
| -## Subgraph |
| 109 | +There are hardhat tasks under the `/tasks` folder. Most tasks are for complex queries to get back data from the protocol. |
48 | 110 |
|
49 |
| -The subgraph repository can be [found here](https://github.com/graphprotocol/graph-network-subgraph). |
| 111 | +**cli** |
50 | 112 |
|
51 |
| -Great care must be taken to ensure all the code and data the subgraph refers to is in sync with |
52 |
| -the current contracts on the correct network. For tracking all of this, we have an NPM package. |
| 113 | +There is a cli that can be used to read or write to the contracts. It includes scripts to help with deployment. |
53 | 114 |
|
54 |
| -The addresses |
55 |
| -for the subgraph need to be the most up to date. This includes grabbing the latest ABIs and |
56 |
| -typechain bindings, as well as pointing the addresses in the subgraph manifest to the latest |
57 |
| -addresses. You can find the latest subgraph addresses in `addresses.json`, and they are also |
58 |
| -in the NPM package. |
| 115 | +# Deploying Contracts |
59 | 116 |
|
60 |
| -Currently the contracts are being tested on Rinkeby. We test on ganache as well. We used to use |
61 |
| -Kovan, but it is somewhat deprecated. |
| 117 | +In order to run deployments, see [`./DEPLOYMENT.md`](./DEPLOYMENT.md). |
62 | 118 |
|
63 |
| -## NPM package |
| 119 | +# Contributing |
64 | 120 |
|
65 |
| -The NPM package will be release in versions, and the version will be coordinated to be the same |
66 |
| -version as the contracts and the subgraph. Anyone wanting to tie into the graph network contracts |
67 |
| -or subgraph should install the npm package into their repository, and refer to the same version |
68 |
| -number for the contracts and subgraph. |
| 121 | +Contributions are welcomed and encouraged! You can do so by: |
69 | 122 |
|
70 |
| -**New development work on the contracts and subgraph will be merged to master. Thus, when developing** |
71 |
| -**on the network, you should not rely on the master code as it might break between the subgraph repo** |
72 |
| -**and the contracts repo. Please use a version that is tagged.** |
| 123 | +- Creating an issue |
| 124 | +- Opening a PR |
73 | 125 |
|
74 |
| -The NPM package will contain the following files/information: |
| 126 | +If you are opening a PR, it is a good idea to first go to [The Graph Discord](https://discord.com/invite/vtvv7FP) or [The Graph Forum](https://forum.thegraph.com/) and discuss your idea! Discussions on the forum or Discord are another great way to contribute. |
75 | 127 |
|
76 |
| -- The contracts |
77 |
| -- The ABIs for those contracts |
78 |
| -- The typechain autogenerated functions. These are typescript functions that are created based off |
79 |
| - the ABIs, and are very useful for their type checking and the fact they are tied to a version |
80 |
| -- The deployed addresses for each network, the date of deployment, and the commit hash. |
81 |
| -- Metadata JSON objects for Graph Account and Subgraph metadata |
82 |
| - **This is the only place you should grab contract addresses from.** |
| 128 | +# Security Disclosure |
83 | 129 |
|
84 |
| -We will also release versions for specific releases, such as `@graphprotocol/contracts@beta`. |
| 130 | +If you have found a bug / security issue, please go through the official channel, [The Graph Security Bounties on Immunefi](https://immunefi.com/bounty/thegraph/). Responsible disclosure procedures must be followed to receive bounties. |
85 | 131 |
|
86 | 132 | # Copyright
|
87 | 133 |
|
88 |
| -Copyright © 2020 The Graph Foundation |
| 134 | +Copyright © 2021 The Graph Foundation |
89 | 135 |
|
90 | 136 | Licensed under [MIT license](LICENSE).
|
0 commit comments