Intro to Graphanomics [graph-uh-nom-iks]

In today’s workshop, we learned the fundamentals of how pricing is accomplished in The Graph protocol. Because this is a decentralized world, price is not fixed by a central API provider. Instead, pricing is achieved via a dialogue between the customer and provider (side-note: David Bohm’s On Dialogue is an excellent read).

💬 Cost Model is the Language

The two main components are a Cost Model and State Channel.

A Cost Model is used by both the customer (data consumer) and indexer (data provider) to establish a “common language” for communicating costs. The indexer sets the Cost Model for each subgraph they wish to index, and this information is made available to customers via a public API. The customer then uses this model, along with their desired query, to construct a bid.

Now the customer is ready to query the subgraph. When a query is sent, the customer includes the bid. If the indexer accepts the bid the query data is returned. If the customer and indexer are speaking the same Cost Model language, then this process will go smoothly.

💶 State Channel is the Settlement Layer

So far this common pricing language has been established completely off-chain, using standard web APIs. The second major component, the State Channel, is used to process the bids and convert these to real payments using GRT tokens.

The beauty of this system is that the bid creation process can be almost completely de-coupled from the State Channel. As long as the bid matches the indexer expectations, e.g. adheres to the Cost Model, then the indexer will always submit bids to the State Channel. The State Channel doesn’t know (or really care) about the Cost Model. Blockchain can just do blockchain things.

Cost Models in Practice

The rest of this post is mostly for Indexers participating in the testnet, but feel free to keep reading!

When setting up a new subgraph to provide, here are the basic steps you might take:

Set a default cost model (subgraphs cannot be indexed without a Cost Model)
Start gathering some real-life query data.
Craft a cost-model based on this data.

We will also be provided soon with the 🛠 Query Evaluation Tool. This tool is designed to help write a model effectively, and test hypothesis. At most it will provide us with results from a “best-guess” scenario, before using the model with live traffic. Here’s a basic glimpse at this tool:

New Infrastructure

A few updates have been made to our Agent and Service infrastructure.

Indexer Agent (Internal)

The Indexer Maganement CLI now includes some new Read commands:

graph indexer cost get all [--output=<table|json|yaml>]
graph indexer cost get <deployment>

graph indexer cost get model all
graph indexer cost get model <deployment>

graph indexer cost get variables all
graph indexer cost get variables <deployment>

As well as some new Write commands:

graph indexer cost set model <deployment> <filename>
graph indexer cost set variables <deployment> <json-object-string>

Here is a screencap of Jannis using these new commands via his Emacs presentation (now I have to learn how to use this Emacs org-mode thingy).

Two options for setting a Cost Model defaults can be used:

(available now) Set a Global Variables to be used when a specific deployment doesn’t have a cost model.
(coming soon) Set a Fallback for each deployment.

Indexer Service (External)

The Indexer Service, which is public-facing, now includes Cost API, for clients to discover your pricing. Also added is the Cost Model integrated in the actual queries themselves

What to Expect Next

Sanitized query logs will be made available soon. This will give an accurate reflection of real-life data, so we can refine our Cost Model thinking and strategy.

Good luck Indexers. May your Cost Models bring you much profits! 💰💰