GRTiQ Podcast: 148 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:00:18):

But I think with Horizon, I’m more confident than ever that we’re actually going to change the world with this thing as long as we actually execute and stay true to the values that we have espoused in permissionless and decentralization.

Nick (00:01:03):

Welcome to the GRTiQ Podcast. Today I’m speaking with Zac Burns, Principal System Architect at Edge & Node, one of the core dev teams working on The Graph.

(00:01:13):

Long-time listeners of the podcast will likely recognize Zac from a comprehensive interview we conducted during episode nine back in May 2021. In this episode, we welcome Zac back for a fascinating conversation with our focus squarely on Graph Horizon, an intriguing new initiative outlined in The Graph’s new roadmap called New Era. While Graph Horizon has quietly made its way into the community discussion, as Zac has made several presentations on the topic, today is a special opportunity for us to take a closer look into Horizon’s origins, its visionary purpose, and the far-reaching implications it holds for The Graph protocol and the many contributors within the ecosystem.

(00:01:54):

I started today’s discussion by welcoming Zac back to the podcast and asking him to reintroduce himself to listeners.

Zac Burns (00:02:03):

Yeah, sure. Nick, it’s a pleasure to be here. My name is Zac Burns. I am a system architect at Edge & Node and I’ve been with The Graph for a little over four years now working on a variety of things like I created the proof of indexing, created the Agora cost modeling language, have worked on some protocol design stuff and a mishmash of a bunch of problems, which is kind of the fun of being a system architect, I guess.

Nick (00:02:32):

Well, as I mentioned, you’ve done one full-length interview before and I’m welcoming you back for a very special reason today that we’re about to talk about, but I do want to encourage listeners to want to learn more about your background to go back and listen to that first episode. I’ll put a link to it in the show notes.

(00:02:47):

As I mentioned though you’re back for a very special reason, which is this discussion that started within The Graph community around this initiative called Horizon, and very careful readers of the New Era roadmap that was recently released, probably saw Horizon in there, and there’s been some mention of Horizon in The Graph Forum. And Zac, you are one of the thought leaders behind Horizon, so we’re going to dedicate today’s episode to talking about the ideas behind Horizon and some of the vision of how it could impact the protocol.

(00:03:18):

Before we get there though, can you just describe in simple terms what Horizon is?

Zac Burns (00:03:24):

Yes. So, Horizon is really a bunch of ideas that have come together as a result of learning a lot about the problem that we’re trying to solve with The Graph, what is The Graph as a decentralized protocol for querying blockchain data, and we released the first version of The Graph maybe three years ago, and even with that, a lot of the ideas had come from earlier on, and at that time, and even now we’re really doing something new, which is this decentralized incentivized layer for querying verifiable data. And so there was really no model to copy back then. I think we could look at knowing blockchain technology as an example, but blockchain isn’t actually what we’re trying to build. This is actually a different thing and the differences are important. So a lot of the ideas that we first had maybe didn’t really pan out in the way that we anticipated.

(00:04:26):

We’ve learned a lot about mechanism design. We’ve also learned about the needs of our customers. We’ve learned just a lot over these past few years, and all of those ideas are coming together in an interesting way and we call that Graph Horizon. You can think of it almost as a new era for The Graph.

Nick (00:04:46):

When I first heard about Horizon, I was super excited about it because you sometimes have to build upon that beachhead strategy and evolve and grow, and I’m glad to see that in this particular case, there’s this vision of how The Graph can be improved. Is that the right way to kind of think about this? I mean, is Graph Horizon kind of a V2 of The Graph?

Zac Burns (00:05:07):

Yeah, that’s how I think about it as a V2 we’re really revising a lot of earlier ideas that didn’t pan out. I think something interesting about our history here is that we were able to find good product market fit with subgraphs by identifying a problem, then releasing initial ideas, but then going through several iterations of responding to customer feedback, making improvements over years. And there was really, I think the subgraphs that today and even Substreams, which are perhaps even an evolution beyond that are the result of iteration. And I think we looked at the product market fit that we had found for subgraphs and maybe had the assumption that if we created a protocol for this which would enable people to access subgraph, that the success of that protocol would be somewhat a given that the product market fit would transfer.

(00:06:05):

But I don’t think that’s actually the right framing. I think that the protocol itself is also a collection of products and services and that those also need to find product market fit. And so we need to look at the protocol right now with a very iterative mindset and being able to respond to demand and what’s working and what’s not working and feedback and all this. So yeah, I do think of it as an iteration or even a V2, if you want to use that terminology.

Nick (00:06:38):

Really an answer. And again, any careful reader of the new roadmap called New Era will note that there are a lot of data services coming to The Graph and eventually, it’ll encompass all data needs in the web3 ecosystem and throughout the world. I want to take listeners kind of behind the scenes now a little bit Zac, and you talked in your introduction about your role at Edge & Node and some of the things you’ve been working on, but where did the seeds of this Horizon initiative begin? Can you take us back in time into some of those early thoughts or impressions that kind led up to where we are presently?

Zac Burns (00:07:11):

Sure. So I started working on Horizon in earnest, let’s say in about March of this year. At the time, I was looking at a lot of protocol mechanisms and leveraging a lot of criticism internally about things that I thought were working or not working. I just had been bothered for a long time that I felt like a lot of things that we were doing working, but what kind of killed me inside was just I thought there could be a version that does work and I really wanted to deliver on our mission. And so I was talking about this with Giannis and he gave me the green flag to go design something.

(00:07:50):

So I spent two weeks back in March. Starting with the first version of Horizon was just let me list out all the problems that I see and what if I go fix those problems individually and then where do we end up with a second iteration of Horizon? Then took that and tied together a common theme of what the different data services are going to need in the future, which is sort of response to the world of data services. And then yet a third iteration was adding something which is the modularity of the protocol, and that’s really when I think what people think of when we talk about Horizon really took shape as sort of a pluralistic design for The Graph where you can build up new data services out of different building blocks, like different payment systems, different verifiability mechanisms or different needs for security. You can take all these things because all the data services have actually different needs. They do differ in these respects, but have a common core protocol that serves the needs of those multiple data services. And so that’s kind of how Horizon came to be.

Nick (00:09:06):

As you’re discussing and describing that, it sounds like it starts with some observations of ways that the protocol can be improved. Onesie-twosie type of things eventually evolves into this kind of V2 type of framing. When did you have that epiphany of like, oh boy, maybe I bit off more than I can chew here. I mean this is a whole new revamp of the protocol, or did that happen?

Zac Burns (00:09:27):

There were definitely some moments where I wouldn’t say that I thought that I bit off more than I could chew, but there were some moments where I became very excited about the prospects of this protocol and almost uncontainably so where I would want to talk to people about it, but it was an interesting time. But we couldn’t just go to the community straight with this information. We had to start by figuring out how to talk about it, which the process for doing that was to talk to a small circle of people who I speak to frequently, and so we have a more of a common understanding in testing the ideas and in doing that, you can see how they respond in conversation and figure out how the communication needs to be improved, what ideas need to change, where might I have gone wrong, kind of test things in a smaller circle and then go out into larger and larger circles once you’ve sort of figured out how to talk about the thing.

(00:10:22):

I don’t know if you’ve had this experience, but I think it’s a common problem for founders to figure out their elevator pitch. You have to give the same story five or six times before you actually even know what it is that you want to say because it starts in someone’s head as just a myriad of details, but you can’t really take all that context and put it in someone’s head. It was like a process that you go through figuring out how to communicate. So that was the next part. That was a very exciting time. And I think what you’re alluding to of a moment of knowing that this was big was just how that communication got out of control. I had wanted to talk to a small circle and then a slightly bigger circle and then a slightly bigger circle.

(00:11:08):

I’d shared documents, and then the next thing I know, 40 people across different core devs had read these documents and were commenting on them and even before I had quite nailed how to talk about it, and so that was also exciting, but more of the feeling that I may have bitten off more than I can chew at that moment when people were really responding and it was no longer in my control. It was more of a product of the core devs as a whole.

Nick (00:11:34):

I love the backstory there. And like I said, there have been snippets here and there that I’ve caught and there’s a couple posts on the forum where you can kind of see Horizon and you were kind enough to do an index or office hours recently where you explored Horizon, so there’s been different points of contact with the community and exposure to this great initiative. When you think about it holistically, Zac, do you think about it as an initiative that’s going back and kind of fixing some of the V1 if you will, issues or problems that you identified or is it actually an initiative that’s designed to accommodate or facilitate this new era of The Graph and all these new data services?

Zac Burns (00:12:14):

It’s thankfully both of those things at once. I’ll quote someone that I admire is Shigeru Miyamoto is a game developer who came up with Mario, Zelda, Pikmin and other people’s sort of prominent figure in the Nintendo space. He says that a good solution is not something that solves one problem but solves multiple problems simultaneously. And that’s true not just in game design, but I think also in business and protocol mechanics and other areas. And so we’re definitely addressing very narrow and specific problems. So for example, The Graph has Oracles today. And those Oracles you can almost think of as a permission to use The Graph Network. So it’s not like permissionless entirely. If for example, with curation, we have a subgraph availability Oracle and that availability Oracle makes sure that there’s data availability for a subgraph so that you can’t create something called a rewards-withholding attack where an Indexer could write their own subgraph but then never publish it and enter the network and collect indexing rewards just like free writing, not actually providing any valuable service.

(00:13:38):

So the subgraph availability, Oracle is meant to address that by making sure that all Indexers would be able to find the subgraph and then compete for indexing rewards. But you can think of that another way as a permission to use the network because if a consumer wants to incentivize indexing of their subgraph, let’s say I have a subgraph, I want Indexers to index it, they need to be paid somehow. If the subgraph availability Oracle doesn’t approve of your subgraph, then there won’t be any rewards distributed to that, and so then you won’t have a way to incentivize Indexers for indexing and you have a permission to use the protocol, right? That’s unintentional kind of permission, but it’s a permission that does exist. And so we are looking at issues like those and narrowly addressing them by making sure that the mechanisms that exist in Horizon don’t require on the same kind of governance that the existing mechanisms do.

(00:14:41):

And we are also responding to our much broader vision of The Graph, which includes a world of data services, and I can give a specific example in that area as well. Right now, all of the core devs are working on their own data services and … Sorry, I don’t remember exactly which ones are on the roadmap or all of them or what, so I’m not going to go list them all and spoil anything, but there are, let’s just say a number of interesting data services in the works, and it’s been difficult for us to progress as separate organizations because the protocol right now operates on consensus and in order to make a change, everyone has to agree to it. That means that the protocol is moving in one common direction and that there’s a lot of communication overhead about what each other are doing. That’s actually just added friction.

(00:15:41):

And so Horizon takes a much more modular approach so that we can really unlock the power of these core developers by allowing them to operate independently and be able to deploy their own data services according to the needs of those data services without really looking for consensus from the broader group, which may disagree based on the differences between these actual data services, and so then it can be difficult to move forward for that reason. So those are different kinds of things like narrow problems of the past, plus looking forward to new models of how The Graph should evolve.

Nick (00:16:24):

I now want to explore this concept of permissionlessness and its relationship to Horizon, and I know that in some of the public settings where you’ve discussed this, permissionlessness comes up time and time again in the context of Horizon. Can you provide just a little bit of contextualization as to how Horizon relates to this concept enhanced?

Zac Burns (00:16:47):

Yeah. First, it might be useful to take a step back and even and say why permissionlessness is important to what we’re trying to achieve with the protocol. First, I think decentralization is in part a response to what happens when you have monopolies or at least artificial monopolies that are based on things like permissions to operate in a market that may be bestowed from a governance mechanism based on reasons which may be corrupt or otherwise. When those kind of artificial monopolies exist, they create a lot of inefficiencies in markets. So that means that the customer may be paying a premium for services just due to the fact that there is imperfect competition. That’s one reason we care about permissionlessness is to enable perfect competition so that we can drive down prices so we can have more efficiency in the market.

(00:17:50):

Another reason that I think about for permissionlessness is just this idea of equality, that if you can do the work, if you can provide the service, if you can do the best job regardless of your race, your gender, your country, your background, whatever reason, what matters here is can you do the job and can you win the market on your merits. Permissionlessness enables that. I don’t even know a lot of the people that I work with, I wouldn’t have the chance to discriminate against them if I even wanted to just because of the nature of how we operate now and this permissionless marketplace enables that.

(00:18:34):

Another reason that we care about permissionlessness is the censorship-resistant aspect. If there is a body that is granting permission to use the network, then it’s not necessarily true that the network could continue forever because if for whatever reason that body is compromised, then there wouldn’t be continued entry of participants into the market. So once different people leave the market for whatever reason, we know that the market can sustain right now. Well, if it’s permissionless because new entrants could replace them, but if there is a need for permission to enter the market, then that can’t be the case.

(00:19:20):

And so there are a variety of reasons why we care about permissionlessness, and I think the other aspect of your question is where are ways that we can improve on Permissionlessness right now. I can give a few examples. One is with gateways, we’ve just recently made that permissionless such that I’m not actually … There’s a GIP for it and there’s definitely code for it. I don’t remember if at this moment as we record that it has been deployed to main net on the protocol, but it is near the end of that path. So that’s one area where we weren’t permissionless and we’re able to make changes to the protocol to minimize the consequences of various economic attacks that could occur if anyone could pay the market. We had to do that before making that permissionless. But there are, with the present protocol design, a lot of reasons why it’s difficult to make it fully permissionless because there are various governance parameters, like how much should we burn tokens for query fees? How much should we distribute to Curators? What should the Delegator tax be? What should the Delegator sign period be? There are lots of these parameters and all of these parameters exist for a reason usually to circumvent some sort of economic attack that would exist otherwise. But those economic attacks, actually, the reason they exist is because of other sort of complexities in the protocol that aren’t solving the problems in the way that we intended to. So with this simpler version of the protocol, those economic attacks don’t exist in the first place, and so we don’t need governance parameters to patch over those or to mitigate those, and so that form of governance goes away.

(00:21:08):

So right now, can anyone extend and augment The Graph protocol? If you wanted to release a new data service using The Graph, could you do that or do you need permission to do it? And the way that the protocol is sort of a monolith right now necessitates that we have to have it be permissioned because if anyone could change it, they could just as easily break things for other people, but with a modular system, you don’t need that permission anymore. There’s a few other examples. I think that right now we are as permissionless as we practically could be. That’s something we’ve been striving for at every moment, but this will allow us to go a lot further than we’re able to in the context of the current protocol.

Nick (00:21:55):

Do you feel like Horizon is the mechanism by which The Graph really can become fully evolved and realize its complete potential in web3?

Zac Burns (00:22:07):

Yes, absolutely. I think subgraphs, while they have found product market fit and while they are the backbone of web3 right now are really just the tip of the iceberg in the applicability of a protocol for incentivized query for data. There’s many kinds of data that exist beyond what subgraphs can address. I mean, data really powers modern life, so having a decentralized layer to access that data is imperative and just has applications I think far beyond what Subgraphs can provide right now. And so we definitely want to bring all those applications into the addressable market for the protocol.

Nick (00:23:56):

Zac, I want to make sure that listeners are comfortable and kind of tracking with this and as they will learn and as people explore more and more, Horizon can be complicated. I mean The Graph is a little bit of a complicated protocol, but web3 for non-technical people in its entirety can be complicated. So it’s important for people to keep track and have entry points so that they can understand. And I want to ask a question that kind of does that for people that are still trying to grasp the potential of what Horizon is. So if you don’t mind, can you just kind of list two or three things that are currently this way, but under Horizon, they’re different or changed?

Zac Burns (00:24:34):

Yeah, so I’ll give a pretty meaty example. One is the mechanism for curation in the protocol today. What curation is meant to be like a prediction market for query fees so that there’s this idea that there would be a role of a Curator who is bridging the gap between business and running infrastructure. So what I mean by that is that Indexers, they really want to automate running their infrastructure. They should choose based on information on chain what subgraphs they want to index, which ones present the biggest business opportunity for them. It’s not necessarily in the scope of that role to go out and understand the market. They just want to stand up the hardware and let it do its thing, right? If you’re going to mind Bitcoin or something that would be relatively, you stand it up and you let it do its thing, you can just kind of walk away.

(00:25:37):

That’s what they want to do. But there’s this problem of identifying among tens of thousands or right now or maybe even many more subgraphs, which ones are the real business opportunities. And so curation by being a prediction market for query fees was supposed to provide a signal to Indexers about which ones were the biggest profits opportunities, right? This mechanism hasn’t worked out in practice. There are very few people who actually participate in the curation market. It’s relatively risky. There’s bots that would rug pull participants. There are other incentives in the market that compete for GRT like delegation. Right now a Delegator probably stands to gain more then a Curator does. And so if you have to choose where you’re going to put your GRT, you might interact with delegation instead. That’s yet another problem that Curators see.

(00:26:39):

And in practice, what we actually have is that there are authors of subgraphs, which are dapp developers who want to bootstrap their subgraph in The Graph protocol.

(00:26:52):

And so that’s actually their goal isn’t to try and predict query fees. Their goal is just to get to an end state where some set of Indexers with a certain amount of performance and the ability to serve queries are indexing their subgraph. And so there’s this mismatch between how that protocol and the roles that it was meant to address exist and how our existing customers actually need to interact with the market. They just want to use it to get that job done. How do I index my subgraph? And when they look at curation, they see something that’s actually very complex as compared to their problem statement.

(00:27:35):

I think they would love to just be able to pay Indexers to Indexer subgraph, not like participate in a prediction market, which sadly isn’t even paying Indexers in an indirect sense because the amount of indexing rewards that are distributed to Indexers is fixed and no matter how many consumers come, and no matter how much GRT they put down in the curation or how they would pay Indexers in an indirect way through that mechanism, it doesn’t actually increase the amount that’s paid out to Indexers. So it’s not scaling with that side of the market. Literally, they want to pay and they can’t.

(00:28:19):

And so with Horizon, one of the products that we’re offering in order to incentivize indexing is just, it’s kind of like as simple as the problem statement itself. People want to pay for indexing, so we just give them a mechanism to pay for indexing. It’s called indexing fees, and there’s a GIP that’s on the forums. So that would be different in Horizon is now that there’s this mechanism that consumers can interact with the protocol in a very straightforward way. It doesn’t have to be, interestingly, the only way for people to incentivize indexing. If people think that there are other ways, they also can build those ways in Horizon and then those methods can even compete or coexist depending on the needs of the market of the users of that system.

(00:29:13):

So a tagline that I’d like to use here is that if we don’t enable competition within The Graph protocol, then we force competition against The Graph protocol. And so right now, if you look at our competitors, which would be centralized services, they offer things like being able to pay them to index a subgraph based on a subscription service or whatnot. That’s a product offering that they have that we don’t. But by enabling a protocol that has competition within it, we’ll be able to match those products and services in a way that doesn’t necessarily have to upset the whole community because I don’t think that the whole community wants exactly that mechanism. There are others who may want to use different mechanisms, and that’s fine. We can have both simultaneously.

Nick (00:30:00):

I appreciate that overview and that makes sense to me. And of course I’ve done a lot of interviews with Curators and kind of watched that stakeholder role develop. Is it fair to say based on what you said there, Zac that in a Horizon environment the role of Curator goes away?

Zac Burns (00:30:16):

I think that definitely the existing implementation of curation probably should go away when replaced with a superior mechanism for accomplishing the goal of having the ability for dapp developers to incentivize the indexing of subgraphs. And I don’t think that there are a lot of people who are actually going to be disappointed by that because there are right now very few Curators or so few that I think know all of them by name. There’s maybe three or something that’s due to when we launched curation that Curators experienced a lot of problems with the mechanism. I mean they got rug pulled, they weren’t seeing a lot of profit from query fees. There’s not going to be a lot of people who are to say interacting with this and are going to be disappointed that that’s going away.

(00:31:15):

I do think though that some of the ideas of curation need to live on and that in the future, we should design more mechanisms which may be meet the needs of that. So one idea of curation was that you’re going to be able to have this idea of a foundation or a large deposit that would enable a subgraph to be incentivized and indexed in perpetuity. I think that’s an interesting idea. In the unstoppable dapps space, you can think of a Filecoin version of curation if you will. Now that feature isn’t going away because I wouldn’t go so far as to say that the implementation of curation even met that goal, but it was one of the goals that the designers of curation had in mind. And so there’s that. There’s also the ability for many different people to sort of incentivize indexing instead of just one payment. There’s ideas of how do we automate the selections of Indexers and what role can the protocol play in that.

(00:32:24):

I think that those ideas deserve ongoing discussion and maybe mechanisms can also be put in place in Horizon which actually meet those goals. But we haven’t yet gone through the effort of designing those mechanisms because the real and present problems that we’re facing are really about how do we migrate traffic from the hosted service onto the network. And I think to do that, the protocol needs to meet the needs of those users. And so tackling those other problems I think will be for the future.

Nick (00:32:56):

And that transition from hosted to decentralized network is in full process. We’ve seen recent announcements related to upgrade Indexer. We’ve seen the deployment of Sunrise of Decentralized Data. So a lot happening on that front. I want to kind of continue Zac through the stakeholder roles and as I’ve said a couple times, Horizon’s far more complicated than just a couple punchy bullet points, but if you don’t mind if we can just kind of scan over some of the other stakeholder roles and get a sense for how they’re impacted in the Horizon environment, starting with Delegators. You’ve mentioned them a couple of times, how is life or interacting with the protocol different for Delegators?

Zac Burns (00:33:34):

There’s a few differences and again, nothing I say can necessarily be 100% true indicative of the future because this is just my view. Horizon has a simple core upon which I’m sort of extrapolating what I think to be simple systems, but what ends up winning in the market could be different. But when I was a Delegator, I definitely experienced some problems. The way that I wanted to interact with delegation was to find Indexers who were mission-aligned, delegate to them, and then just kind of walk away for a while and have it be operating as say, an investment in those Indexers. But in practice, what I had to do because of the way that the protocol works was to monitor the performance of those Indexers frequently and say if one flatlined for whatever reason, then redistribute that capital. When I did try to say move delegation from one Indexer to another, I would have to undelegate and then there’s a 28-day line period redelegated again and then get hit with a delegation tax.

(00:34:48):

And so it’s very easy I think to forget if you undelegate to come back 28 days later and then to go delegate to another Indexer. So one thing I was worried about was will I just leave some of these delegations here and forget about them. I’d rather for the mechanism to efficiently allocate that capital across Indexers without me having to actually come back all the time and worry … I worry every time that I do any on-chain transaction, it’s just like a small panic attack every time, no matter the amount, right? I even have a burner wallet with $100 with of ETH in it and I can’t bring myself to make transactions sometime, even though I know that that wouldn’t be a life-changing problem. Just the idea that there’s risk involved in these transactions is off-putting.

(00:35:44):

So I want to set it, forget it, let my capital work for me, come back later, maybe withdraw, but not have to be active like an active, I want to be a passive investor, not an active investor. And so one way to approach delegation would be to have it be like a lending pool where you could deposit an amount of GRT in a lending pool and allow many Indexers to access it according to their needs. So right now I have to look at Indexers and maybe predict how good each of them will be in accomplishing quality of service. Let’s say that one of them has an outage for a couple of days. It’s not like unheard of and running distributed software is hard. Now thankfully with a permissionless network, other Indexers can come in and fill the gap, but I don’t have a way to efficiently allocate my capital over that one-day outage. That’s just a loss to me because that capital is still being used by that Indexer.

(00:36:48):

But if the capital was in a lending pool where after the amount of quality of service that each Indexer has performed is known that Indexers can then borrow from that pool, then that allocation is in effect distributed perfectly as if I had perfect knowledge of what was going to happen in the market. And so I can white list a bunch of Indexers that I agree with, even if one of them stops performing, I don’t have to come back. And then it’s just much easier to enter into the system that way. So that’s one thing I like about delegation.

(00:37:26):

There’s one thing that I want to be forthcoming about to Delegators, I think we haven’t talked about it yet, may be some of the strongest resistance against Horizon may come from the Delegator community for the reason that delegation will likely be slashable in Horizon, whereas it is not today. There’s just no way around that I think if you want for the mechanisms to make sense.

(00:37:51):

What I mean by that is in order for delegation to make sense, we have to have a productive use of capital. And so let me expand on what I mean by that. We say that one of the purposes of delegation is to secure The Graph Network, but what secures The Graph Network is the threat of slashing of capital. It’s that if an Indexer serves an incorrect response, then they stand to lose more than they would gain from serving that incorrect query. They collect a trivial amount of payment, but then they lose a hundred or a thousand times more from that. That’s what incentivizes good behavior in the system is this threat of slashing.

(00:38:35):

But when people delegate to Indexers, it gives them access to unslashable capital, which then lowers the risk of interacting with the system and thereby actually works against the security of the system. It’s a sort of internal contradiction. And so to just put an analogy on it today, imagine if you had a lemonade stand and I wanted to invest in your lemonade stand so that you could grow and serve more customers because I believe in your lemonade stand, well, I took my cash and I stuffed it under my mattress and then point it at your lemonade stand and say, I support that lemonade stand. It shouldn’t really actually entitle me to any of your revenue from the lemonade stand because I haven’t actually contributed to the lemonade stand in a meaningful way because you have no way to put that capital to productive use.

(00:39:31):

And so I think that necessarily in Horizon, delegation has to be slashable in order for Delegators to actually participate in the network in a meaningful way, in a way which entitles them to some revenue from the use of that capital. I think that’s true in … I don’t mean some difference between Horizon and the old protocol makes that true.

(00:39:55):

I think that the current protocol is just broken in this regard and so that going forward we’re going to have to make delegation slashable and that’s probably the way that it’s going to be implemented in Horizon. So that’s one thing that I want to just be very forthcoming about to the delegated community.

Nick (00:40:12):

And then if we turn our attention to the Indexer community, how is life different for an Indexer in a Horizon environment?

Zac Burns (00:40:20):

Well, I think Indexers and consumers are going to really reap the most benefits from here, which indirectly also impacts everyone else in the network because if things are good for Indexers and consumers, things are also good for Delegators. If it’s good for Indexers and consumers, that increases the addressable market for The Graph, which means that the Delegators’ capital can be put to productive use, which means more revenue. It means more of that share of revenue goes to Delegators, right? There’s a symbiotic relationship between these two things.

(00:40:52):

The main benefit to Indexers and consumers is that things are a lot more efficient and a lot more simple. So right now there are a variety of mechanisms … Just take one example, like burning query fees. There’s both a tax on query fees and a rebate mechanism, which isn’t intended to incentivize that Indexers hold stake. It doesn’t quite work very well, but I’ll just say that’s what it’s for. And that mechanism burns query fees. If the ratio of stake that you have isn’t what it thinks it should be, that doesn’t lead to efficient transactions between consumers and Indexers. So we can lower friction there, which would mean either lower prices for consumers or more profit or Indexers or some combination of the two. It’s hard to predict in advance when you increase the efficiency of transactions where the surplus will go, but it’s one of those two places and because of that, it means that The Graph will be able to address much more of the long tail of the market and be able to be competitive against say, centralized providers that don’t have these same kind of mechanisms.

(00:42:15):

To give just an analogy that I also used in Indexer office hours, imagine you have a bridge and that bridge represents The Graph protocol and on one side of the bridge you have a consumer, they want to buy apples and they want to buy apples, and on the other side of the bridge, you have a fruit market and they have apples there for sale. It’s analogous to our situation in that the consumer needs to use bridge to access this fruit market, right? It’s like the means by which they access the apples. Say that the cost of producing an apple is $1, and so their price is like $1.1 Or whatever. It’s like some markup over there and the consumer, they want to buy them, but if they cross the bridge, there’s going to be like this troll that takes 90% of their money, and then whatever they’re left with, that’s what they can spend at the fruit market.

(00:43:10):

So if the consumer wants to buy the $1 apple, they have to carry $10 across the bridge, then the troll steals nine and they buy the $1 apple. If that’s the only way that they can get apples, well, then maybe they’re willing to pay $10 for a $1 apple, but if there’s another fruit stand across a different bridge that doesn’t have a troll on it, they’re going to prefer to use that one.

(00:43:40):

And so that really is what will make The Graph competitive or not against alternatives that have popped up trying to steal some of our thunder, if you will, looking forward in the future, is that we need to make a lot of these mechanisms more efficient, more simple.

Nick (00:43:57):

I appreciate the overview of those three roles, and it’s no surprise that in any emerging industry competition enters the market more and more, and I think that’s true for The Graph and probably every other web3 protocol that there are new entrants seeking to compete in this new environment. How has that competition evolved during your time working on the protocol and what’s your kind of opinion of where that sits now and maybe how Horizon figures in?

Zac Burns (00:44:24):

Sure. Analysis of business is a little bit outside of my domain, but I can give my personal take on things which won’t be as comprehensive or correct as someone who actually works on analyzing competition say. But from my perspective, when we launched the protocol, people saw that there was a market cap here in excess of a billion dollars if you just look at the market cap of GRT. And immediately, some organizations announced that they had competitors to The Graph. Now at that stage, that competition was basically… They had literally ripped off our documentation that took copy-pasted stuff from our website. They hadn’t developed any technology. They were just really trying to ride the wave or to incite investment into their competition to enter into that market. But it’s been three years now since The Graph protocol launched. They’ve had time to build solutions. They have thought about ways that they might differentiate their products and now there do exist. SaaS competitors there exist competing protocols.

(00:45:35):

I think that we are going to win out against these competitors in the long term for a couple of reasons. One is against the SaaS competitors, they’re not … If you buy into this idea of web3, I think you got to really buy into it the whole way. If you claim to be a dapp, but the only way that your dapp actually functions is for this one organization to pay exactly one other organization, then it’s not permissionless, it’s not censorship-resistant, it’s not any of the things that we think are going to enable market competition and be effective.

(00:46:16):

So I think that in the long run, we have a unique value proposition and we also are going to be able to have the lowest prices for the best quality of service in the market if we really lean into the permissionlessness and what makes the market efficient, and that’s what’s going to really upend those kind of centralized competitors because they won’t have anything to offer at that point. If they’re not decentralized and they’ve got higher prices, well, why would someone prefer them? I don’t know.

(00:46:48):

But in a way, it’s actually good. I think that this competition exists right now because we can learn from the things that they are trying to do to steal our market and incorporate those. So for example, I’ve looked at SaaS competitors that have products like indexing fees, which is just a way for consumers to be able to pay or indexing, and we have this curation thing which isn’t meeting the needs, but now you can really … I’ve been saying that for a while, but now you can actually point and say, look, X number of customers are going to that competitor for this reason. Let’s match that in The Graph and let’s create a better version of that. It really, I think makes sort of the story that I’ve been trying to tell a lot more real and a lot more pressing and something that we need to respond to. So it’s definitely pressure for us to deliver, which I think is a good thing.

Nick (00:48:17):

When I first interviewed you for interview number one, again, there’s links in the show notes for anyone that wants to go back and listen to that. You talked about when you first had the opportunity to join Edge & Note and go to work on The Graph, and you said these people … And I’m paraphrasing, these people are either super crazy or they’re on something that’ll change the world. How has your perspective of The Graph and that mission, that initial like this is either crazy or this is something that’ll change the world, how has your perspective on that changed over the years?

Zac Burns (00:48:45):

I think what’s changed the most is that I now see a more clear road on how to actually execute on the vision. There was definitely a lot to digest, and in that time, a lot of the information that I had to digest was anchored in the existing protocol, which is if I’m being frank, overly complicated and inefficient and due to permissions issues, doesn’t really execute fully on the vision of a permissionless decentralized system. It’s like maybe it was the best that we could come up with at the time, but at that time, I had to deal with the cognitive dissonance between wanting to see this very efficient and big version of the future and what we actually had plus actually learn how all of those things worked in depth, which was a lot to chew through.

(00:49:39):

But I think with Horizon, I’m more confident than ever that we’re actually going to change the world with this thing as long as we actually execute and stay true to the values that we have espoused in permissionlessness and decentralization.

Nick (00:49:56):

You’ve done a phenomenal job here. In other places, like we’ve referenced Indexer office hours and explaining and providing an overview of Horizon. One question I’d like to ask outside of the technical components is this role of community in feedback on something like Horizon. So as you lay out your vision, how do you account for that aspect of it?

Zac Burns (00:50:19):

Community feedback is absolutely one of the most important pieces of this initiative. Different people have different skill sets, and so one of my skill sets is sort of an engineer problem solver type. If an engineer problem solver type goes to work by themselves, they won’t really work on all the right problems. And so you need to have involvement with a community to actually understand that the problems that they’re experiencing in order to provide solutions for those problems. And we have looked at a lot of feedback from the community, both Indexers, Curators customers in designing a lot of the mechanisms or Horizon, although I’ve been a little bit critical about some of the processes that we have in The Graph community. This is just my opinion about getting feedback. So the GIP process for example, I don’t think that that’s the right mechanism for getting feedback, and I don’t know that it has given us an abundance of actionable feedback.

(00:51:27):

There are a lot of other mechanisms that we use, especially for things outside of the protocol that have been a lot more effective. So for subscriptions, for example, which is a new feature of the Edge & Node Gateway. We go out, we talk to customers, we experience their problems, we design solutions, and then we communicate those solutions in a way that talks about how they’re going to solve the problems and kind of see how they respond. Does this actually solve your problem? A lot of those interactions have been healthy and a lot of the interactions about say, GIPs, which aren’t happening at the level of problem, they’re more happening about the level of in the weeds of technical details, have been a lot harder to have those conversations due to the information asymmetry and the difference of skill sets. So like a customer that understands the problem doesn’t always necessarily understand how or why an implemented solution may address their problem.

(00:52:29):

If they go try to dig into a mechanism that has been delivered by say, PhD economists, they won’t necessarily see the connection between that and their problem, and they may read it and not understand parts or try to revise the mechanism itself. That’s not as productive as a conversation about where these two things meet in the middle. And just like an evidence of that is with indexing fees, we talked about it twice. Once was in a GIP that we posted on the forum, which largely talked about the mechanics of indexing fees. And I don’t think that the response to it there was very positive from the Indexer community. They had problems with some of the mechanism design. They weren’t necessarily seeing how this connected to problems that they have in acquiring customers.

(00:53:22):

We talked about the exact same thing in Indexer office hours in a different way just by having a real conversation between people rather than a technical document. And the response was completely different. I think there was overwhelming support from the Indexer community in that setting. There were like emojis and people were saying how happy they were, but it’s the exact same. We were talking about the exact same thing, but the medium is the message. If you just give them a technical white paper versus have a conversation about the problems that they’re having and talk about how a solution would address those problems without getting into technical details, you get a totally different response. And so I think we need to not only just evolve the protocol, but also evolve the ways that we’re interacting with each other in order to get the most actionable feedback in order to foster more of a sense of community and not interact in more combative ways, which I think that the GIP process historically has had a problem with.

(00:54:32):

So I think we need to iterate in all areas, not just mechanisms of the protocol.

Nick (00:54:39):

When you think about timeline, and we’ve already mentioned there’s a lot of things going on within The Graph right now. You’ve got the launch of the new roadmap, you’ve got the launch of Sunrise of Decentralized Data, which again falls in that new roadmap. We’ve got the release of upgrade Indexer, the move to L2. There’s a lot of things in motion. Without saying this is exactly what’s going to happen, what’s the vision for a rollout of something like Horizon?

Zac Burns (00:55:03):

Yeah, this is a complicated question. So rather than say what the timeline is, I’ll talk about some of the considerations that would go into that question. One is I think that migrating traffic off of the hosted service like Sunrise, that’s the priority right now. It’s something that we promised that we were going to deliver to the community, and we need to do that. That task is made a lot more difficult by the fact that we don’t have Horizon because with curation, for example, hey, if customers don’t understand it, they don’t have a way to pay Indexers to pay them for indexing. How are they going to migrate to the protocol? That presents itself a challenge for Sunrise, and because we can’t deliver Horizon necessarily, but as early as we would like in order to enable this migration, we have to then create ways of mitigating the problems of the protocol in order to enable that migration.

(00:56:00):

So you mentioned the upgrade Indexer. I think the existence of the upgrade Indexer is in part due to this problem, right? If consumers can’t use curation to index their subgraph and they have a really bumpy road and would get disruptions and quality of service by migrating to the protocol the way that it is today, well, then we can smoothly over that process by having an Indexer that doesn’t base its decisions based on what’s happening in the curation market, but rather bases its decisions on what we know from the demand for traffic coming off of the hosted service or bases decisions on enabling a smooth experience regardless of whether or not the incentives of the protocol reward that behavior. And so for the long-term for this to be a competitive permissionless market, we can’t rely on things like the upgrade Indexer. That’s not sustainable because we can’t just prop up the network indefinitely as Edge & Node, but we need that to exist right now to enable this transition while Horizon doesn’t exist.

(00:57:05):

And so then once the Sunrise occurs, then Horizon really gets into gear because it’s the next highest priority. And because we’re in an unsustainable situation where we’re still subsidizing the network through this upgrade Indexer, we don’t want to pay for that. We also are not putting ourself in a position where we’re going to take revenue from Indexers that sends the wrong message. So we want to give Indexers the opportunity to compete in the market and not burn however much money we are burning on that thing.

(00:57:45):

And so that means Horizon has to be executed on quickly. There isn’t one timeline because Horizon is a vision of The Graph in the future, and it’s a set of new products and services that are being deployed to address the needs of the protocol. And those won’t be released altogether at one point in time. We’re going to be iterating and releasing them one at a time.

(00:58:12):

So you might see the lending or the new delegation protocol come in at one point in time. You might see indexing fees come in at another point in time or moving the query market to Horizon at a specific point in time. There are dependencies between these things. Like for indexing fees and query fees, those both need the staking mechanism for Horizon. So there’s a dependency graph, but then it’s when you resource-tasking that dependency graph that you actually get a timeline. And not only has that not been decided yet, but that kind of stuff always changes after. Horizon will be rolled out progressively even as we imagine it today. Ideally, a very substantial portion of Horizon should be rolled out. I think, actually, I’m not even going to say because I don’t want to just to even be interpreted as a commitment, but even when a lot of our vision for now is rolled out, well, there’s always going to be the next thing that we want to do, and that’s going to be built on Horizon and a part of the Horizon ecosystem. So Horizon is never even done, really.

Nick (00:59:20):

Zac, you’ve been generous in doing this podcast, as we’ve said you did in index or office hours. People can go on to YouTube and watch that or just look in the show notes. How do you envision the community and people that want to learn more about Horizon? How do you envision them learning more and more about it as the days and months go on?

Zac Burns (00:59:38):

We’re exploring having a lot of ways to interact with the community. I think we’re planning a blog post on Horizon that’s coming out next. For each of these products that exist in Horizon, I think there’s going to be independent communication strategies for all of them. So we’re going to be wanting to talk about indexing fees across a variety of channels to different participants. We’ll be sending, I imagine emails to customers on the hosted service. We’ll be writing blog posts, we’ll be talking about that and Indexer office hours, there’s going to be, I anticipate a glut of information across a variety of channels because this is really about the foundation for the groundwork.

Nick (01:00:21):

The first time you joined me for an interview, I didn’t have the GRTiQ 10, but now it’s here. And I’m so grateful for the opportunity, especially with someone like yourself to go back and revisit these 10 questions. And so Zac, now my pleasure to ask you the GRTiQ 10. These are 10 questions I ask each guest of the podcast every week, and I do it in hopes that first listeners can get to know you a little bit better, learn some of your personal interests and things that you like, but also I think it helps listeners learn something new, hopefully try something different. And of course, they can achieve more in their own life. So, Zac Burns, are you ready for the GRTiQ 10?

Zac Burns (01:00:57):

I am ready.

Nick (01:01:09):

What book or article has had the most impact on your life?

Zac Burns (01:01:13):

One thing that I would encourage a lot of people to read is a book called Enlightenment Now by Steven Pinker that talks a lot about the story of human progress, how things have gotten better and why they’ve gotten better. And I think that a lot of the principles of the Enlightenment are especially relevant today in the information age where some of the first principles thinking is really under attack. And we could really learn a lot from that book. And it helps people, I think, draw the connection between thought and outcomes. I think that what you think is actually very important and will end up impacting your life in very substantial ways. And it actually matters whether what you think or believe is true, and that really think is something that we need to understand better as a society today. So I definitely recommend that book.

Nick (01:02:13):

Is there a movie or a TV show that you would recommend everybody should watch?

Zac Burns (01:02:17):

I don’t watch movies or TV shows very often, almost at all. So, sorry.

Nick (01:02:23):

How about this, if you could only listen to one music album for the rest of your life, which one would you choose?

Zac Burns (01:02:29):

Oh, boy. I enjoyed a Coldplay album. I think it’s called Everyday Life. And it’s hard to say this is the only one, but because you have to listen to it from front to back, it’s more like a musical journey that you have to pay attention to. And it’s not something I listen to while I’m working, but I enjoy that one a lot.

Nick (01:02:53):

What’s one thing you’ve learned in your life that you don’t think most other people know or have learned quite yet?

Zac Burns (01:03:00):

One thing that really strikes me often having a history in programming is that high performance software is not actually difficult as it sounds to do. I think that even among the programmer community, it’s not understood that you can have very simple software that runs very fast, and it’s usually things that people do to the code that make it more complicated, that actually make it slower. I think what is actually preventing fast software isn’t the difficulty in making it. It’s a mythology that exists in the programming community that believes incorrectly. That high-performance code must also be complicated and difficult. It’s actually usually simpler and easier to change code that ends up being high performance. I think that actually is true in a lot of systems. It’s hard to simplify things, but when you do, it often ends up just gaining other good properties like high performance, more efficiency.

(01:04:07):

Simplicity is king. And it’s weird because it seems like simplicity is something that an architect would think of as important, but would not actually bring benefits to consumers if they were just focused on the problem of creating and not actually the problems that consumers have. But simplicity, weirdly, is often aligned with the needs of solving the problem. Yeah, that’s been important to me and I think not reflected in conversations that I have with a lot of people.

Nick (01:04:47):

And how about this one, what’s the best life hack you’ve discovered for yourself?

Zac Burns (01:04:52):

I guess get rid of the phone. Just keep your phone away from you. Phone is bad like that. The magic rectangle that can answer all questions, but that also seems to draw your attention when you don’t want it to. Or you can habituate this idea of needing to check social media, needing to check email, needing to check whatever, needing to go read some stupid thing on the internet and not be present. And at the end of the day, feel unfulfilled by those things and feel like you missed out on important parts of life. And then do that again the next day because your decision-making isn’t really rooted necessarily in what your experience of what is the most fulfilling thing. It’s like based on this sort of addictive dopamine response to turning on the magic rectangle. I think the way that you can experience your life in a more fulfilling way is to put the magic rectangle out of reach.

Nick (01:05:48):

Based on your own life observations and experiences, what’s the one habit or characteristic that you think best explains how people find success in their own life?

Zac Burns (01:06:02):

I don’t have anything very insightful here, but it’s working hard persistently, working on the right problems and working with other people who are similar and able to work hard and on the right problems that bring a unique perspective to what you’re working on. And also, a bunch of luck. The world is way more complicated than anyone can digest. So let’s say that I would’ve fully really anticipated the success of The Graph, by way of example, would just be totally wrong. I mean, there was always uncertainty there, even though everyone believes in what they’re doing. I’ve worked on a lot of things that didn’t work out and I couldn’t go back and tell you that I was sure that this one was going to work out more than the other things I worked on. So there is luck, but you also kind of make your own luck and that I worked hard across lots of different projects before one of them became successful. So there’s that.

Nick (01:07:05):

And then the final three questions, Zac, are complete the sentence type questions. So the first one is complete the sentence. “The thing that most excites me about web3 is … “

Zac Burns (01:07:13):

I’m going to give, I think what might be a surprising answer is the bring your own algorithm. So for example, if I use Twitter and Twitter has a mechanism that controls what goes in my feed, and I don’t always like the way that their algorithm works, but if Twitter separated the front end and the query and data from the front end from the data which web3 actually does in a way because we’re operating on this permissionless data set, then you can create your own view on that data in a way that is actually best for you rather than best for Twitter. Because the way that they’re creating their view is attempting to make a addictive product that maximizes their advertising revenue. But that’s not actually aligned with my interest because the way that Twitter is creating their view is attempting to make a product that maximizes their advertising revenue is attempting to make a, this addictive product is often by emphasizing controversy, emphasizing fear, and a variety of other techniques.

(01:08:25):

Whereas I want my feed to be informative and to enable me to make decisions. So there’s a interest misalignment there, that something like bring your own algorithm. If I could control how the process of selection for what tweets were in my feed, I would absolutely take advantage of that. And that’s something that web3 can bring us and we can also, not only would I take advantage of that, but I’d probably share it with people and let other people … and yet others would contribute and have their own ways. And we don’t all have to agree on the same way. So I’m very excited about anything that enables bring your own algorithm.

Nick (01:09:07):

And how about this one, if you’re on X formerly Twitter, then you should be following …

Zac Burns (01:09:14):

I’m about to leave Twitter, so.

Nick (01:09:17):

And the last question, complete this sentence, “I’m happiest when … “

Zac Burns (01:09:21):

I’m happiest when, but find a satisfying answer to a problem. It is euphoric. I don’t know how to describe it. There’s something that if you work on a problem for a long time, and then if you see the answer, there’s this thing where sometimes the problem is complex and you think it’s the right answer, but then you start to remember parts of the problem in check, does this work, does this work, does it work? And when the answer is yes over and over and over again, then you kind of like, no, that this is the right answer. That can be a great feeling at that moment.

Nick (01:10:05):

Zac Burns, thank you so much for coming back and joining the GRTiQ Podcast for a very important episode, an overview of Horizon and a lot of important work, and an incredibly inspiring vision for the future of The Graph. Listeners won’t know this, but we’ve had the opportunity to spend a little bit of time together in person, and I greatly admire you and have always appreciated your kindness and your contributions to The Graph. It’s been incredible to watch from that first episode to present, and I’ll be excited to watch you continue to contribute. If listeners want to follow you, stay in touch, track some of the things that you’re working on, what’s the best way for them to stay in touch?

Zac Burns (01:10:42):

Oh, that’s a good question. I just said I’m about to leave Twitter and that was actually the way, and I don’t have a replacement right now, so I’m sorry.