GRTiQ Podcast: 09 Zac Burns

The following podcast is for informational purposes only. The contents of this podcast do not constitute tax, legal, or investment advice. Take responsibility for your own decisions, consult with the proper professionals, and do your own research.

Zac Burns (00:22):

When I first joined The Graph, I honestly had no idea what was going on. I’d never used Ethereum. I didn’t know what a smart contract or a dapp was, but I could tell one thing, and that was that either of these guys were crazy or that they were onto something that was going to be really big.

Nick (01:11):

Welcome to the GRTiQ Podcast. Today I’m speaking with Zach Burns, a software engineer at Edge & Node. Our conversation covers a variety of interesting topics, including a detailed discussion of the recent Scalar announcements, how Delegators actually secure the network, the most common misunderstandings Zach hears when speaking with members of The Graph community, and a new topic not yet covered in any previous podcast, the role of fishermen in The Graph. I started the conversation with Zach asking how he first came to be involved with The Graph.

Zac Burns (01:49):

When I first joined The Graph, I honestly had no idea what was going on. I’d never used Ethereum. I didn’t know what a smart contract or a dapp was. But I could tell one thing, and that was that either of these guys were crazy or that they were on something that was going to be really big. And I’d be able to figure out within the first six months, and if they were crazy, I’d just jump ship. So that’s probably not the best state of mind getting into this, but when you see that there’s a once-in-a-lifetime opportunity that only comes up once in a lifetime by definition, so if you’re not able to take a small risk and find out what that is, then that opportunity might pass you by.

(02:35):

Fortunately, during the interview I got to share with Yaniv Tal my philosophy about how the story of human progress is one of increased efficiency over time. You can track the wellbeing of civilizations with questions like, how much effort does it take to have light in the evening for one hour? Once upon a time, we chopped wood for heat and light, and that took a lot of effort. Things moved on to candles and eventually light bulbs and cheaper and more efficient light bulbs with more efficient sources of power. These innovations have real impact on real people.

(03:16):

I wanted to be working on those pivotal moments in history that bring light to civilization. So thankfully Yaniv understood that we had an alignment that I thought might be there, but I didn’t really fully grasp yet. So if you had asked me now what would’ve brought me to The Graph, knowing what I do now, I would say that a big part of having an efficient civilization is creating incentivized systems that coordinate independent actors to engage in pro-social behaviors and bring value to their community. And so that to me is what The Graph is all about. It’s about creating tokenomics that bring people together to solve problems, reward the value that those people contribute, and keep the bad actors from taking advantage of that system. It’s basic when you boil it down like that, but it’s also very exciting.

Nick (04:11):

So what was it about the project that made you think, “Either everybody’s crazy or this could be something big.”?

Zac Burns (04:17):

What The Graph does presupposes that you understand blockchain and that problem space. So it’s a lot for someone to figure out in a short amount of time about whether or not they’re really solving a real problem. It turns out that they are. In fact, one of the first things that I noticed when joining the company that really validated this decision is that people were knocking over the door trying to get in and try to deploy subgraphs. And because everyone in blockchain actually has this problem, but until you understand blockchain, then a lot of that can be foreign.

Nick (05:03):

Can you describe what it is you do at Edge & Node?

Zac Burns (05:06):

My official title at Edge & Node is software engineer. At Edge & Node, all the software engineers wear a variety of hats though. So if you were to try and choose one area that I focused on, what makes me different than other engineers at Edge & Node, I would say that my focus has been on decentralizing the network. There’s a lot of aspects to that. Decentralization requires security, right? So I’ve developed the proof of indexing to make sure that Indexers create a shared artifact that makes sure that all of them are indexing all of the data in the same way. Also for security, I developed the fisherman service, which verifies queries are being served correctly by Indexers, and if not, raises a dispute on the chain.

(05:54):

Decentralization also requires there to be query fees. So I created Agora, which is a programming language that allows Indexers to express the price of a query. Also for query fees, I developed Scalar which enables high throughput micro-transactions at the scale that’s necessary to support the queries in the network. Decentralization requires choice, so I implemented our Indexer selection algorithm which collects statistics about Indexers. And when a query is received from a consumer, it looks at the consumer’s preferences, whether those be for speed or economic security or price or data freshness or whatever, and matches that query to the best Indexer for the consumer to help provide the network participants with the best choices.

(06:45):

I’m also working with Semiotic AI who received a grant from The Graph Foundation to optimize interactions between many independently interacting agents. I’ve only been with this team for a little over a year, and those are just some of the highlights. So you can see that Edge & Node keeps software developers pretty busy. In fact, I’d say that there are so many different opportunities surrounding the network, but I find that a part of my job is turning down lots of those opportunities just to make sure that we’re focusing on what’s going to be the highest value opportunity right now.

Nick (07:19):

It’s remarkable all the different things you’ve been involved with. I want to talk a little about Scalar. That made a lot of news when it was announced. I’m curious if we can approach that question in two ways: a technical way and a non-technical way. So from a non-technical perspective, what can you tell us about what made Scalar so important?

Zac Burns (07:39):

Scalar makes the network work. If you want to have paid queries, well, there’s nothing else that will actually get it to work without Scalar. You either wait a really long time for getting your response back, or it’s going to be insecure, or it’s going to be prohibitively expensive, or these other problems. If you have those problems, no one wants to use The Graph.

Nick (08:01):

All right, that makes a lot of sense. So can you answer this question in a more detailed or technical way: what made Scalar so important for The Graph?

Zac Burns (08:11):

Scalar was a collaboration between The Graph Foundation, Edge & Node, and Connect. What Scalar enables is routing query fees via micro-transactions from consumers to Indexers with low latency, which means that happens very fast, and at scale, which means that you can have a lot of them. To describe how this solution benefits the network, I need to get a little bit technical unfortunately because this is a technical solution to a technical problem, but I’ll try to tie the technical analysis to benefits that are accrued by each participant in the network.

(08:48):

So first, the problem that Scalar intends to solve. Part of the network security model is that micro-transactions support queries from consumers to Indexers. Doing this on a Layer 1 chain like Ethereum is a non-starter. Doing anything on Ethereum cost gas, which is pretty expensive right now compared to history. So using that for a micro-transaction is going to be very inefficient, which is an understatement actually. Another problem is that Ethereum takes about 13 seconds to mine a block, and that’s the only confirmation that an Indexer would get that a transaction has taken place. So if a micro-transaction in an Ethereum block is a dependency of your serving a webpage with some data that you got from an Indexer, that at 13 seconds is an eternity to wait and see your data. No one’s going to stay on a webpage for that long.

(09:48):

The traditional way to solve these problems is with something called state channels. Basic state channels let two parties make many micro-transactions between themselves and then settle the final balance on-chain periodically. It sounds perfect for the problem that we have, but it’s not quite, at least not in the forms that have been explored before Scalar. In fact, it took almost two years of research with some of the world’s leading experts to reach a state channel design that could accommodate the needs of The Graph.

(10:23):

The scale of The Graph tends to take technologies and just push them to their limits, and in some cases pass their breaking point, as was the case with state channels. The basic idea behind state channels is this: I hand you a signed message that says, “If you serve me a query, you can have a small fraction of a GRT.” You then serve the query back in that message, sign it, and hand me that message back. This process is repeated. You pass the message back and forth until you’re done interacting, and you know that at the end you will get your fractions of a GRT because that signed message is backed on-chain by, say, 10 GRT, which would account for the many queries that have taken place over a period of time.

(11:14):

So here is the first problem that exists for our network when taking that basic state channels design and applying it. Let’s say that a gateway has a query. It produces a signed message and hands it off to the Indexer. Now, the same gateway receives another query but wants to sign off on a new micro-transaction. But the Indexer now is holding onto that signed message. It’s their turn to update it and send it back, so you need another signed message. This is bad because creating and maintaining that signed message that’s backed on-chain with real GRT is really expensive in this context. There’s a setup process involved, which involves communication between both parties. And while you’re setting one up and collateralizing the message with GRT, the user is all this time just waiting for their page to load.

(12:11):

Furthermore, the gateway has to back up that message with some GRT. Even though they already have another message that the Indexer is holding onto that has GRT backing it, now they just need another one with the traditional state channels design. This is really wasteful for the gateway from a capital utilization standpoint to have their liquidity partitioned into many different signed messages being held by these different participants like different Indexers. That waste and the liquidity that’s just being locked up in these messages has a real cost that can be calculated and would then have to be passed on to the consumer. So state channels, if you just take the basic design and apply it, is going to be slow and expensive. Actually, it gets worse from there. I’m not going to try to get into too many details, but there are questions like, “What happens if you send the Indexer a message and it just doesn’t come back? Now what?” It is a distributed system which is going to be susceptible to all kinds of networking and system failures. So if they don’t send one back, do you need to make another message and figuring out what happened there has overhead of its own and do you lose that 10 GRT that’s backing the message?

(13:34):

When you’re talking about hundreds or thousands of participants interacting at scale, this breaks down. The way that Scalar approaches the problem is actually very simple at its basic. I’m going to oversimplify a few things, but the basic idea is that when you set up that first signed message, instead of having one signed message, you’re basically getting an infinite number of state channels that are held in a pool that all share the same collateral on-chain. They’re all backed by the same, say, 10 GRT that they can draw from. And that has a lot of second order of effects for the efficiency of the system. So that problem where I had sent you a signed message and the Indexer was holding onto it and I get a new query, now what I can do is I can just draw from my near infinite supply of messages and send you that one. And then these two signed messages can be updated in parallel without having any additional setup cost.

(14:43):

Now furthermore, if maybe the Indexer drops a message or you’re not really sure what state it’s in because it’s a distributed system and maybe the gateway sent it over and the Indexer didn’t find it or maybe the Indexer sends it back and it’s just lost, these signed messages because they don’t have any collateral tied to them specifically, but they all share the same collateral, they’re disposable. You can just drop one and grab a new one whenever you want. And then whatever happened there about who dropped the ball, you don’t need to figure it out. What happens is just that the latest state ends up being resolved into the final state. So the Indexer will collect the latest version of all the signed messages that they have and collect all the query fees that way. So it just kicks the problem down the road.

(15:36):

There’s a lot more benefits that come from how Scalar interacts with Vector in that when we have a lot of participants in the network, it means that a lot of these interactions will happen through a router so that an Indexer, even if they have collected query fees from many different participants, which are backed by different amounts of collateral on-chain, will actually be able to submit only one final message to the chain that withdraws all of those query fees that they’ve accumulated from many different participants onto just one single transaction. And that’s very efficient, which is important for saving those gas costs for the Indexer so we don’t have to pass those gas costs off to the user. There’s a lot of more benefits and a lot more technical analysis, but I’d encourage you to read the blog post, which will be in the show notes, if you have the time.

Nick (16:35):

So before we move to the next topic, maybe we can quickly summarize what the benefits of Scalar are in more simple terms.

Zac Burns (16:43):

The essence of what we did with Scalar is that if you want the network to be secure, you have to have paid queries. If you want to have paid queries that are fast and not prohibitively expensive, then you need something like Scalar or the network just doesn’t work, because if it costs $10 in Ethereum gas fees to serve a query for a webpage, no one is going to be visiting that webpage. Or if you can’t serve queries securely where the Indexer isn’t going to have guaranteed payment, then that Indexer isn’t going to serve queries because it would end up losing money. There would be no incentive later for the consumer to pay them if they don’t have to. So you also need webpages to be served very quickly or The Graph is irrelevant in the context of the web. So you really need all of these things, and Scalar is what enables that.

Nick (17:46):

You bring up gas fees, which is always a going concern in the Delegator community and I’m sure the larger ecosystem. I’m curious how you think about gas fees.

Zac Burns (17:57):

The gas price in Ethereum has risen a great deal over just the last year. This is explainable with basic economic, right? There’s a limited supply of something. In this case, it’s a limited supply of the number and complexity of transactions that can fit into a single block in Ethereum. There’s also at the same time an increase in demand for those transactions in a block that’s driven by an increased interest in decentralized applications. Increasing price is the mechanism by which a free market ensures that the limited supply of transactions is utilized efficiently by the users who need them the most. In some sense, this is a good thing, right? The price increase is a strong signal from the market of the demand for Ethereum transactions. It’s a measurable, observable effect of the adoption of decentralized applications, and this is good. But on the other hand, the higher prices drive out many legitimate uses for blockchain. High prices affect the network because the long tail of smaller Delegators are often among the casualties who are driven out by people who are making other kinds of transactions.

(19:18):

So there is an EIP in Ethereum called EIP 1559, and that’s supposed to help with this problem. And I think that it will help a little, and that’s going to come fairly soon, I think it’s in the next [inaudible 00:19:32], which is called London. But it’s really a bandaid on the actual underlying problem. The real problem is that there’s not enough supply or Ethereum transactions to meet demand, and the only way to solve gas fees to enable the widest variety of decentralized applications is to scale out supply of transactions. There are many kinds of scaling solutions, lots of people working on this. Ethereum 2.0 is one. LazyLedger is something that I learned about recently and is also very interesting. So help is on the way for gas prices, and I hope that we can increase the supply of transactions soon.

Nick (21:02):

The goal here is to engage listeners and create a more informed community by hearing the stories and insights of those helping to build The Graph. As a listener, you can make important contributions. Please take a moment and leave a review wherever you listen to the GRTiQ Podcast. And be sure to click the Subscribe button. These two simple actions can make a significant difference in helping to grow the listening audience. If you’d like to learn more about how you can support this podcast, visit grtiq.com/podcast.

Nick (21:45):

I’d like to ask you a question I’ve always been curious about, it’s this idea of how Delegators secure the network. What is meant by that? How do Delegators secure the network?

Zac Burns (21:56):

None of my opinions are necessarily reflective of Edge & Node. I’m just one member of Edge & Node, there can be many correct answers to this question. When a gateway receives a query, it needs to select an Indexer to serve the query to on behalf of the end user. One of the factors that our gateway considers is the amount of delegation that Indexer has. So when you delegate to an Indexer, you send an important signal to the network and any gateway that’s operated by the community that this Indexer is worthy of receiving a higher query volume. So that signal is central because a Delegator can consider many factors that are not necessarily visible on-chain when deciding whom to put their capital behind. For example, a Delegator may see that an Indexer created a great tool for the community. This observation informs the Delegator that the Indexer has the technical capability to index well and that the dedication to the network required to provide an excellent service on a long time horizon.

(23:06):

But none of that is visible on-chain, that observation was made by the Delegator. Or maybe a Delegator may value diversity and they may vote that Indexers come from a diverse set of backgrounds, or whatever is important to the Delegator. They may see for some reason that an Indexer is motivated to serve correct responses, and that would add to the security. What’s important here is that it’s the wisdom of the crowds that’s going to shape the network into what they want it to be. We can already see evidence on-chain and off that Indexers are responding to this market signal because they want to get that delegation. Their response raises the bar of what it means to be a great Indexer in the network, not just for security, but across all metrics that the community cares about.

Nick (24:02):

I appreciate that answer. What advice do you have for Delegators when it comes to selecting an Indexer?

Zac Burns (24:09):

I can tell you how I approach delegation personally, but I think it’s important that each Delegator come at the problem from a diverse set of angles. But first, I have a minimum bar for delegation. Any Indexer that I delegate to must have both submitted a proof of indexing and collected at least one GRT from query fees. It’s not much, but there’s an enormous amount of work going from zero to one, to set up the infrastructure, learn the protocol, stake on-chain, fully index a subgraph, and finally serve that first query. It’s a whole lot less work to go from one to 100 GRT than it is to go from zero to one. That’s my minimum bar.

(24:57):

But from there, what I’ve tried to do is to pick a different reason for selecting each Indexer that I’ve delegated to. For one Indexer, it was performing well in the testnet. For another, it was that they built a useful tool. When subgraphs started migrating over to mainnet, I paid attention to see who responded to that in the first 24 hours. I’ve looked at the Indexer profiles in The Graph portal and picked one that had a profile that resonated with me and my beliefs. Once I looked at who was collecting the most query fees because I know how the Indexer selection algorithm works, I know what it means to be selected, and that’s a difficult thing to do is to rise to the top to be good across the many metrics that Indexer selection bases its decision on. So I know that they must be doing multiple things right if they had the most query fees.

(25:58):

There was one case where I delegated where someone was asking questions about developing subgraphs on the Discord. At first I just thought that this person was hopeless. They were going back with these questions, we didn’t seem to be getting anywhere, and over time, and I was wrong, I saw that over the course of a few months that this individual they kept at it and they grew until eventually they became a very competent Indexer. And seeing that transformation left an impression on me, and I’m interested to see what this person does in the future, and I decided to delegate to them. So the answer seems all over the place, but I try to look for something outstanding in every Indexer that I delegate to knowing that each one of them is going to be bringing their own unique value to the network.

Nick (26:53):

Are you concerned then that many Delegators make the selection of an Indexer based on projected or estimated APY?

Zac Burns (27:02):

That is somewhat concerning, but it’s very temporary. I think that if people think about it a little bit more that they’ll realize that that’s not necessarily even a good strategy anyway. Because if everyone looks at an Indexer’s APY and they pick the one that is the highest at the moment, well, your delegation is also going to get piled on and someone else is going to pick that Indexer as well until the APY between different Indexers is just balanced. It goes to this equilibrium. So by following this strategy, you didn’t even necessarily get an advantage, you just balanced of the APY of the pool. Over time, that doesn’t work.

(27:51):

I think that the reason that people are looking at APY right now is because the network is early and it’s really honestly hard to make good decisions about who a good Indexer is until very recently as subgraphs are now being migrated over to mainnet for real. That’s going to provide a lot more interesting data points or a lot more things that an Indexer can look at and research when they decide who to delegate to.

Nick (28:20):

So with all the recent migrations and the many more that we are expecting, would you advise Delegators who made the decision of which Indexer to work with primarily on APY to reevaluate their decision?

Zac Burns (28:34):

That depends. I’m fairly confident in the decisions that I made when delegating, but if someone has made the decision to just follow APY, I would consider reevaluating that for sure, because there’s so much more information now that will be available to you then when you made that decision. That’s one of the fundamental parts of making decisions is that over time new information becomes available and you need to adjust course based on that.

Nick (29:05):

It’s going to be a tough thing for a lot of Delegators because it seems like many of the community dashboards point to APY as the primary driver of which Indexer to select. What advice do you have for Delegators in this regard?

Zac Burns (29:21):

I think it’s important to consider that the APY that you see on a dashboard is not necessarily in indicative of any actual expected returns that you would be getting by delegating to an Indexer. For one, it only takes into account the so-called indexing rewards from submitting a proof of indexing. There’s nothing in that dashboard that can tell you how much that an Indexer is actually going to collect in query fees. And really, the whole point of the network is query fees. I don’t think that that’s going to be the primary source of gain that a Delegator could accrue, so if you’re just looking at that, then you’re not only not contributing to the network in the best possible way, but you’re also probably making the wrong decision financially.

Nick (30:16):

As such an informed Delegator, I’d be curious to hear your opinion about if it’s a red flag if an Indexer doesn’t close their rewards allocation within a 28-day period.

Zac Burns (30:28):

I think that would be a red flag. I would wonder why that was happening, because the Indexer should be incentivized to close the allocation after 28 days. There’s no reasonable reason. I mean, there can be problems that the Indexer is experiencing which may prevent them from closing the allocation, like if they don’t have any ETH on hand and are having difficulty having capital to run the Indexer, that would be a red flag to me because I wouldn’t want to vote and say, “Serve queries to this Indexer which has very low capital and can’t afford to run their infrastructure.” That would not be securing the network, in my opinion. So if that happens, try to find out what’s up. I know that a lot of Indexers, you can contact them. On our Discord, we have a Indexers and Delegators’ communication channel where you can find them and you can ask them any questions and you can ask them specifically why they didn’t close that allocation and see if you were satisfied with that answer.

Nick (31:31):

I want to ask the converse of that question, which is, is it then more favorable to work with Indexers that close their allocations frequently, maybe even daily?

Zac Burns (31:43):

Not necessarily. In fact, I would think that closing allocations too often is a sign of them not necessarily operating efficiently because there is no reason to do that. It just seems like burning money to me. The reason that we allow allocations to stay open for so long is so that you don’t have to close them, so that you don’t have to spend money to close that allocation in ETH. So I don’t think that it’s going to be very typical.

(32:13):

Now, what I would want to see when looking at an Indexer is that their closing and opening allocations that are responding to market conditions about subgraph. If a new subgraph is deployed and they need some of their stake back, I would like to see them close an allocation and open two with one with that new subgraph in it and one with the previous subgraph that they had each with an appropriate amount of stake. So the closing and opening of allocation should let them balance their signal for receiving queries on different subgraphs in response to changes that are happening in the real world. And if there’s no need to balance, then I would like them to hold their allocation open for as long as possible.

Nick (33:00):

What do you say to Delegators who worry that their rewards or GRT might get slashed if they partner with a bad Indexer?

Zac Burns (33:07):

This is a misunderstanding that I see comes up quite a lot actually, so it’d be, I think, useful to clarify. There are a few risks that are associated with being a Delegator, but being slashed is not one of those risks. As a Delegator, if an Indexer behaves maliciously and say they serve an incorrect response to a query, you will not be slashed. You will not be held accountable for that. The risks that are there are more in terms of opportunity costs. So there is a delegation tax where when you delegate, I believe exactly half a percent of your GRT is burned, and then the rest goes to the delegation. Once you want to delegate, then you are subject to a 28-day fine period. So your main risk is that maybe you never get that half a percent back and you need to keep your liquidity locked up in the contract for 28 days. But as far as risks go, that’s really low risk. I mean, it’s capped. After that half a percent, you don’t stand to lose any more GRT.

Nick (34:28):

I’d also like to hear your thoughts about the 28-day thought period. You’re so informed about the network and you’re also a Delegator, so how do you think through that issue?

Zac Burns (34:37):

This is a little bit of a difficult question. I mean, so the 28 following day period is there for a reason, and I’ll just explain what that reason is. There is an economic attack that we call Delegator front-running. And what that is that because of the way that the contracts are implemented on the chain, in order to make things efficient, when a Indexer closes an allocation, we don’t look at how long that Delegator was delegated when that allocation is closed in determining the rewards. All of those Delegators are rewarded equally. So that the Delegator front-running attack goes, “I see that an Indexer has held an allocation open for a long time. So right before they close it, maybe after 27 days, I’m going to submit my delegation, wait for them to close it, and then delegate to another Indexer and then just kind of loop around and try to collect rewards at a much more accelerated rate than would be reasonable if they were participating in the network as intended.”

(35:48):

And so what the 28-day thought period does is to prevent an Indexer from being able to switch allocations any more often than that maximum allocation length, which means that they have every incentive to actually to just secure the network instead of play silly games. That being said, ideally that 28-day though period is a response to a problem and not something that’s necessarily desirable in itself. It’s not making the network more efficient. You could argue that if we are going to secure the network, it would be good for an Indexer to be able to respond quickly to changes that are happening. If I see that an Indexer is behaving poorly and I want to switch to another one, maybe being able to do that quickly is actually advantageous for the security of the network. Maybe not, because if you are seeing that that Indexer is behaving poorly, then when you delegate, they are immediately losing that delegation, right? So maybe it’s not important that Delegator who made a poor choice be able to make another one quickly again. Maybe it provides an incentive for a Delegator to actually do some research before committing that amount for an amount of time.

(37:14):

I think that there are arguments on both sides, but we have graph improvement proposals, and we have a forum where people can debate about these topics a lot, and we take these issues very seriously. By we, I mean the whole community, takes these issues very seriously and is trying to make the best network that we can know given the realities of the situation.

Nick (38:06):

With the migrations of subgraphs to the mainnet, is it reasonable for Delegators to expect their rewards earnings to be more based on query fees and less on Indexer rewards?

Zac Burns (38:18):

Yes, absolutely. It’s important to understand the phase that the network is in right now and what the function of indexing rewards is. So as the network is bootstrapping, right now there’s only a select handful of subgraphs that are migrating, but we know based on what’s on the hosted service that there’s potential for a lot more of these subgraphs to migrate over and for there to be a lot of credit fees, but at the very beginning, you have this kind of chicken and egg problem where no one is using the network because there’s no Indexers and no Indexers want to index and serve query fees because there’s no users.

(39:02):

So in order to bootstrap that, the indexing reward is added to get Indexers to be able to have a source of income before the volume of queries scales in the network. So the plan has always been that this is more or less temporary in terms of it being the dominant source of income but that over time that proportion of income is going to be shifting toward query fees. Indexing rewards are never actually going to go away because they still do provide their own value, which is that Indexers can crosscheck that they are doing the indexing correctly by comparing their proofs of indexing. And that ends up securing the network because later as we have provable query responses from taking a proof of indexing and a response, you can show eventually that the response that you got is the correct response by comparing these two things.

(40:06):

Once you have that, then even just providing a proof of indexing is going to help secure the network because the more of them that you have, the more sort of stamps of approval you have on all the queries that have been served from these proof of indexing values. But really, the point of the network is queries. I think that revenue is going to be shifting heavily in that direction over time.

Nick (40:34):

I’d like to ask you some questions and have you define some terms or concepts that Delegators may not fully understand. So let’s start with GraphQL, how should we think about what GraphQL is?

Zac Burns (40:49):

So QL and GraphQL stands for query language, and it’s just a standard for making queries where a consumer can ask for some subset of the data that may exist on the server. They may ask for an entity and some particular fields on that entity. They don’t want to know everything about it, but they only want to view some subset of the data. Having that kind of a query language makes things more efficient because it means that less information may have to be transmitted over the wire, so it comes to you faster and would be read from the database more quickly, and all of this by enabling you to just ask for specifically what you need, instead of saying, “Give me all of the information.” It was invented by Facebook. It’s an open standard now, and it’s used across a wide variety of web APIs.

Nick (41:46):

I’d like to hear how you define or think about what a subgraph is.

Zac Burns (41:52):

A subgraph takes information from the blockchain which is arranged over time because that’s how a blockchain is structured, processes the data that it’s receiving over time into some other data that is more like the information that you actually want to get out of the system. That sounds jargony, but example, if we were to take CryptoKitties as our information layer, it’s a Ethereum phenomenon that happen where you can trade CryptoKitties and people make these different trades and kitties have different attributes. Some might be red or some… I don’t really know much that much about it. Let’s say that some are red kitties and some are big kitties or small kitty, I don’t know. So you take all of that information or the subgraph receives all of that information over time, and maybe you have some question for every user based on how long that they’ve held a particular CryptoKitty, what color was their favorite over time. And that information is not actually available on-chain, but you could take all of the data on-chain, process it down, just filter out the information that’s relevant to you, and then store it in a different way so that you can answer that question very quickly in a way that would be relevant to a web application.

Nick (43:22):

Can an Indexer index more than one subgraph, and can a subgraph be indexed by more than one Indexer?

Zac Burns (43:29):

Okay. So the first question is, can an Indexer index more than one subgraph, and can a subgraph be indexed by more than one Indexer? And both are absolutely true. With the case of a subgraph being indexed by multiple Indexers, this is essential to decentralization and essential to the reliability of the network, that if one Indexer disappears for whatever reason, they decided they’re not interested anymore or it’s not been profitable for them because they haven’t made the right business decisions about how to run their infrastructure or an earthquake destroys their facility, whatever reason an Indexer disappears, well, there are going to be other Indexers that are all already set up where query traffic coming from consumers can be routed to those many other Indexers. That’s really one of the primary benefits of decentralization is reliability.

(44:31):

Another benefit of decentralization is consumer choice. You don’t have to be locked into using one specific Indexer who then could, if they form a monopoly around a subgraph, then they wouldn’t necessarily be incentivized to have the best service. But the way that the network works is that the consumer sends a query to a gateway and they have preferences about what they value, and they send those preferences over to the gateway. So for example, a consumer may say that, “I really need this query to be served quickly. I’m serving a webpage, that’s really important.” Or they might say, “I really need this query to be served at the lowest price because I’m doing analytics and I need to make a lot of queries and it’s going to be expensive, so I need you to find me the cheapest Indexer. It doesn’t matter if they’re really fast or anything else.” You might have an Indexer who is doing financial analysis and they may say, “I need an Indexer that is going to give me great economic security so that they have every incentive to make sure that their response is correct and up to date.”

(45:42):

You may have a consumer that says, “I need the very latest response on-chain because I’m making a game, and that’s important to my users to be able to see changes that are happening in that game right away and not stale data, which would make the game look incoherent if things are changing.” But maybe another consumer doesn’t care about that. So they’ve all these different needs, and they send those needs with their query to the gateway. And then the gateway has been interacting with all of those different Indexers. It’s looking at, “I sent you this query query a few minutes ago. How long did that take to come back?” I’m looking at what kind of stake do you have on-chain? That’s where your economic security is coming from. If you stand a lot to lose, if you’re slashed, then we say that you have a lot of economic security.

(46:34):

We’re looking at, is the Indexer reliable? Do they drop queries sometimes which is going to create problems for your users? We’re looking at lots of factors, actually. Yeah, the delegation is something that we’ve talked about as well, which tries to roll in many factors that we can’t necessarily observe programmatically in our gateway. So we’re taking all of these factors into consideration with hundreds of different Indexers across that may be indexing the same subgraph and choosing the best Indexer, the best service for that consumer. And that’s really the primary function of the gateway.

Nick (47:13):

How do you think about the role of Curators in The Graph?

Zac Burns (47:16):

A Curator is kind of like what a Delegator is to Indexers, a Curator is for subgraphs. Personally, I think curation is one of the most difficult roles in the network. That just might be because of my particular skillset, other people might find that it’s the best for them. But what you’re doing when you are curating is signaling to Indexers that a subgraph is worth indexing. And so this needs to take into account a lot of different information from a variety of sources. For example, a subgraph may be worth indexing if you expect it to have a lot of queries, a lot of consumers that care about the information that that subgraph is producing. So you would need to have market knowledge of what is happening in the greater crypto space. What are the important projects? Where is the demand for this data going to come from? Which subgraphs make the most use of that data from those important projects?

(48:22):

You also need to have maybe technical and coding skills to be able to take a look at the subgraph, like how it’s actually implemented, and make sure that it doesn’t have any conditions or any kind of bugs where it’s going to serve wrong data or maybe go into a failure mode, that it’s not recoverable and not be able to serve consumers in the future. So you need to evaluate not just the broad crypto space, but also the technical implementation of the subgraph. Again, it’s really all fitting into this model of adding security and value by providing market signals. This time, the market signal is for Indexers because it cost them a lot of real-world resources like computing hardware and being able to pay for a Ethereum data and all of this in order to index the subgraphs. So they need a signal that says, “You should do this, and if you do, you’ll be rewarded and not hit with some terrible condition like no one cares about the data or you won’t be able to serve the data after you’ve spent all of this work.” That’s a different skillset than what the Indexer actually may have, which is to actually run the infrastructure. So these are another of just two complimentary roles in the network.

Nick (49:47):

So this is a GRTiQ Podcast first. Earlier you referenced the role of fisherman in The Graph. What is a fisherman?

Zac Burns (49:56):

A fisherman is an altruistic role that helps to secure the network. The basic idea is that it tries to catch Indexers in the act of serving incorrect responses to queries. Edge & Node operates one fisherman, but anyone from Delegators to competitive Indexers can participate as well. If you make the same query to two different Indexers and get different responses, someone is lying, and you can bring the evidence on-chain for a dispute. Once we determine who that is, then an Indexer will be slashed. So if say that you want to add some kind of probabilistic security to the network as a consumer or a Delegator, you could say, “One in 100 of my queries I’m going to perform again with different selection criteria, hopefully get a different Indexer, compare them and submit a dispute if I need to.” And then you are acting as a fisherman and helping to secure the network at a very low cost to you if you’re only doing it say one in 100 times.

(51:00):

But with those probabilities of something happening one in 100 times over many, many queries over time, the chances would be really high for an Indexer who was behaving maliciously to get caught and then to have a penalty for that.

Nick (51:16):

Can a Delegator be a fisherman?

Zac Burns (51:19):

Yes. Any role in the network is complimentary to any other role. And if you feel that you would do great in both roles, by all means. Anything that you learn in one role is actually going to increase your competency in the other roles as well, so I’d encourage people to participate in as many roles as they’re interested in.

Nick (51:39):

For the final question, I’d like to know if there are any common misunderstandings that you come across as you’re talking to other members of The Graph community either in the Discord or the Telegram group.

Zac Burns (51:50):

The Graph is complicated and is technical, and so it’s not surprising sometimes that I’ll be reading things and I find some misunderstandings. It’s great to have the opportunity to be able to clear some of these up.

(52:04):

One misunderstanding that I see come up quite often is that the network is not going to be viable because the price of GRT right now may be like a, I’m just going to make up a number, a dollar, and that’s way more than the value of a query. So how is it ever going to be that consumers are going to pay a whole dollar for their queries? This network can’t possibly work. And so the answer to that is that like any ERC-20 token, that unit, when we say one GRT, it’s actually divisible into many small pieces. In fact, it’s divisible to 18 decimal places. So you can pay for a query down to the low price of 0.0000 18 times, and then a one at the end of that, and that’s a 0.00000, many zeros and then $1, say, is a very small amount of money. So that doesn’t actually pose any real problem for consumers when they’re paying for queries. They can pay various small amounts of money for a query regardless of the conversion rate for GRT.

(53:19):

In fact, when a consumer makes a query at the gateway, the Indexer when they’re sending over their prices can take into account that conversion rate. So everything is dynamically adjusting to market conditions all of the time. And so that’s not really a problem that we run into. Another misconception that comes up that I see a lot is just the question about slashing. Indexers ask this, Delegators ask this, “Can I do X, Y, or Z? Will I get slashed?” Every time that I’ve heard that question, the answer has been, “No, you will not get slashed.” I think the reason that that comes up a lot is that in a lot of networks you have to be very sensitive for security reasons, that even something as simple as inaction can become a security vulnerability in some scenarios. So those kind of networks apply slashing very liberally to make sure that none of these potential security vulnerabilities exist.

(54:22):

Those kind of questions don’t exist in The Graph Network. We’re really on the other side of that where if you’re going to get slashed, you were acting very maliciously. The two reasons that this can happen, and again, there’s only two, an Indexer provides an incorrect proof of indexing or an Indexer provides an incorrect response to a query. And even if that does happen, safeguards are in place to protect Indexers in case that that happened not maliciously but say because of a bug in the graft software. So there’s arbitration that happens on-chain, and that will allow us to be able to dig into what actually happened to see if an Indexer was acting with malicious intent. So really, slashing is not something to be concerned about unless you are criminally negligent or malicious. Again, that’s never been the case whenever I hear someone asking about slashing.