This is the second part of a two part post exploring the design of The Graph Network. You can read part one here.
In the first post we gave an overview of what The Graph Network is and how it works at a high level.
In this post we’ll be going deeper on several key concepts, including how Graph Tokens are used for indexer staking, curation, and indexer inflation rewards. I’ll also introduce the decentralized Graph Explorer—a dApp for interacting with The Graph Network—and describe our payments and verification layers.
The Graph adopts a work token model, where Indexers must stake Graph Tokens in order to sell their services in the query market. This serves two primary functions.
It provides economic security, as the staked GRT can be slashed if Indexers perform their work maliciously. Once GRT is staked, it may only be withdrawn subject to a thawing period, which provides ample opportunity for verification and dispute resolution.
It provides a Sybil resistance mechanism. Having fake or low quality Indexers on a given subgraph makes it slower to find quality service providers. For this reason we only want Indexers who have skin in the game to be discoverable.
In order for the above mechanisms to function correctly, it’s important that Indexers are incentivized to hold GRT roughly in proportion to the amount of useful work they’re doing in the network.
A naive approach would be to try to make it so that each GRT staked entitles an Indexer to perform a specified amount of work on the network. There are two problems with this: first, it sets an arbitrary upper bound on the amount of work the network can perform; and second, it is nearly impossible to enforce in a way that is scalable, since it would require that all work be centrally coordinated on-chain.
A better approach has been pioneered by the team at 0x, and it involves collecting a protocol fee on all transactions in the protocol, and then rebating those fees to participants as a function of their proportional stake and proportional fees collected for the network, using the Cobb-Douglas production function.
In our construction, the rebate Yi an Indexer i receives during a time period is
I recommend reading the paper — but what’s interesting for our purpose is that in equilibrium a rational decision maker would be expected to budget a stable proportion of their spending between the two inputs to the production function. In our case, that would be the cost of renting or owning GRT and the operating expenses related to running a Graph Node which allows an Indexer to perform more work, and by extension collect more protocol fees.
Because we would expect all rational Indexers to make an equivalent budgeting decision, in equilibrium, we should expect Indexers to stake a proportion of total GRT staked, equal to the proportion of work they have performed for the network.
The beauty is that this distribution of stake doesn’t need to be enforced in the protocol, but rather, it arises naturally from Indexers making decisions in their own economic best interest.
For a consumer to query a subgraph, the subgraph must first be indexed—a process which can take hours or even days. If Indexers had to blindly guess which subgraphs they should index on the off-chance that they would earn query fees, the market would not be very efficient.
Curator signaling is the process of depositing GRT into a bonding curve for a subgraph to indicate to Indexers that the subgraph should be indexed.
Indexers can trust the signal because when curators deposit GRT into the bonding curve, they mint curation signal for the respective subgraph, entitling them to a portion of future query fees collected on that subgraph. A rationally self-interested curator should signal GRT toward subgraphs that they predict will generate fees for the network.
Using bonding curves—a type of algorithmic market maker where price is determined by a function—means that the more curation signal are minted, the higher the exchange rate between GRT and curation signal becomes. Thus, successful curators could take profits immediately if they feel that the value of future curation fees has been correctly priced in. Similarly, they should withdraw their GRT if they feel that the market has priced the value of curation signal too high.
This dynamic means that the amount of GRT signaled toward a subgraph should provide an ongoing and valuable market signal as to the market’s prediction for future query volume on a subgraph.
Another mechanism we employ related to indexer staking and curator signaling is the indexer inflation reward.
This reward is intended to incentivize Indexers to index subgraphs that don’t yet have significant query volume. This helps to solve the bootstrapping problem for new subgraphs, which may not have pre-existing demand to attract Indexers.
The way it works is that each subgraph in the network is allotted a portion of the total network inflation reward, based on the proportional amount of total curation signal that subgraph has. That amount, in turn, is divided between all the Indexers staked on that subgraph proportional to their amount of contributed stake.
More formally, the indexer inflation reward for Indexer i is
Setting the inflation rate dynamically in a way that is optimal is an area of ongoing research, but suffice to say that it will be low, most likely single digit.
This mechanism provides an additional incentive for Indexers to be responsive to the signal provided by curators, making curation an even more useful activity to engage in.
In the long term, we would expect rational Indexers to stake GRT on subgraphs where they will earn inflation rewards and earn query fees. During the early days of the network, however, there is an incentive for Indexers to stake but not actually do the work of indexing and serving queries on any subgraphs.
For that reason, during a bootstrapping phase, there will be an indexer monitoring service which is set via protocol governance. This service has the authority to add Indexers to a blacklist if they are found to be unavailable for serving queries on the subgraphs they are staked on.
Because there are benign reasons for becoming unavailable, the only penalty for ending up on a blacklist is that you are disqualified from earning inflation rewards until you are removed. Being blacklisted will not result in slashing.
Curating subgraphs for Indexers is only half of the story when it comes to surfacing valuable subgraphs. We also want to surface valuable subgraphs for developers.
This is one of the core value propositions of The Graph—to help developers find useful data to build on and make it effortless to incorporate data from a variety of underlying protocols and decentralized data sources into a single application.
Currently, developers accomplish this by navigating to Graph Explorer:
In The Graph Network, Graph Explorer will be a dApp, built on top of a subgraph that indexes the Graph Protocol smart contracts (meta, I know!)—including the Graph Name Service (GNS), an on-chain registry of subgraphs.
A subgraph is defined by a subgraph manifest, which is immutable and stored on IPFS. The immutability is important for having deterministic and reproducible queries for verification and dispute resolution. The GNS performs a much needed role by allowing teams to attach a name to a subgraph, which can then be used to point to consecutive immutable subgraph “versions.”
These human readable names, along with other metadata stored in the GNS, allows users of Graph Explorer to get a better sense for the purpose and possible utility of a subgraph in a way that a random string of alphanumeric characters and compiled WASM byte code does not.
In The Graph Network, discovering useful subgraphs will be even more important, as we will be shipping subgraph composition. Rather than simply letting dApps build on multiple separate subgraphs, subgraph composition will allow brand new subgraphs to be built that directly reference entities from existing subgraphs.
This reuse of the same subgraphs across many dApps and other subgraphs is one of the core efficiencies that The Graph unlocks. Compare this approach to the current state of the world where each new application deploys their own database and API servers, which often go underutilized.
Our payments layer is designed to minimize trust between the consumer and the Indexer. Payment channels is a technology that has been developed for scalable, off-chain, trust-minimized payments. It involves two parties locking funds on-chain in an escrow where the funds may only be used to exchange funds off-chain between them until a transaction is submitted on-chain to withdraw funds from the escrow.
Traditionally, payment channel designs have emphasized securely sending a micropayment off-chain without regard for whether or not the service or good being paid for was actually received.
There has been some work, however, toward atomic swaps of micropayments for some digital good or outsourced computation, which we build on here. We call our construction WAVE Locks. WAVE stands for work, attestation, verification, expiration, and the general design is as follows:
Work. A consumer sends a locked micropayment with a description of the work to be performed. This specification of the work acts as the lock on the micropayment.
Attestation. A service provider responds with the digital good or service being requested along with a signed attestation that the work was performed correctly.
Verification. The attestation is verified using some method of verification. There may be penalties, such as slashing, for attesting to work which was incorrectly performed.
Expiration. The service provider must either receive a confirmation of receipt from the consumer or submit their attestation on-chain to receive their micropayment before the locked micropayment expires.
Using locks with payment channels is not new. Both Lightning and Raiden papers discuss using a hash preimage to unlock a micropayment. This is particularly useful for multi-hop micropayments where each “hop” is locked with the same hash and can be unlocked by a value, the preimage, that produces that hash when input to a specified hashing function.
While we could roll our own payment channel solution, which is purpose-built with this new locking mechanism, a more pragmatic solution is to use state channels.
We can think of state channels being to payment channels, what smart contract blockchains like Ethereum are to Bitcoin. They can handle the simple payments use case, but they can also codify more complex state transitions while keeping the same scalability and security properties as a payment channel.
What payment and state channels have in common, however, is that in their most basic form they are a means of exchanging value or state updates between two participants, which are known ahead of time. As alluded to above with the multi-hop micropayments, sending between any two participants requires being able to form a chain of payment channels across multiple other participants, which connects the two original participants.
There are a variety of clever projects working on different forms of graph traversal to facilitate these micropayments between any two arbitrary participants. For simplicity, The Graph Network will initially use a hub and spoke topology.
This means that in order to use The Graph a consumer will need to have a state channel open on-chain with the state channel hub, which is loaded with their preferred stable token or ETH. The Indexers, meanwhile, will also need to have a state channel open with the hub where they can receive GRT.
The state channel hub will be collateralized with GRT and be responsible for setting the exchange rate between the payment denomination and GRT so that all micropayments are settled in the same unit of account.
In order for the WAVE Locks construction and indexer staking to be meaningful, there must be an effective verification mechanism that is capable of reproducing the work performed by an Indexer, identifying faults and slashing offending Indexers.
In the first phase of The Graph Network, this is handled through an on-chain dispute resolution process, which is decided through arbitration.
Fishermen submit disputes along with a bond, as well as an attestation signed by an Indexer. If the Indexer is found to have attested to an incorrect query response, the fisherman receives a portion of the slashed amount as a reward. Conversely, the fisherman’s bond is forfeit if the dispute is unsuccessful.
Importantly, the fisherman’s reward must be less than the slashed amount. Otherwise, malicious Indexers could simply slash themselves to get around thawing periods or avoid slashing by someone else.
In the long run, as the network becomes more reliable, we would expect the reward to active fishermen to dwindle to near zero. Thus, even though there is a fisherman’s reward, we consider this actor to be motivated by altruistic incentives.
For that reason, initially, there will be a fisherman service where consumers may post attestations, and we will take on the responsibility of verifying query responses and submitting disputes on-chain. Of course, anyone who wishes may also perform this role.
Additionally, in the early days of the network, there will be an arbitration service set via protocol governance, which will act as the sole arbitrator in the dispute resolution. This allows us to exercise judgment when incorrect queries may arise as a result of bugs in the software, Indexers missing events from the blockchain, or other accidental factors that could lead to a slashable offense.
Eventually, as the software matures, Indexers will be expected to develop the operational know-how to avoid these sorts of errors.
Future work on The Graph Network involves exploring new market mechanisms and parameterization of existing mechanisms, which will make the query market more dynamic and efficient. The latter will involve running agent-based and dynamic simulations on the existing mechanism design, as well as analyzing the network after launch.
The contracts will be upgradeable so the protocol can continue to be improved after launch.
In the longer term, we would like to eliminate the roles of fisherman and arbitrator altogether, by relying on authenticated data structures, consensus and cryptographic proofs. Doing this performantly has been an area of ongoing research for our team and something we’ll be writing more about in the near future.
Thanks for reading! I hope this illuminates the rationale behind the choices we made while designing the network and explains what to expect from our team in the next year and beyond.
If you have any questions, or want to get started building a subgraph today, join our Discord. You can find me in #research.