ZKPodcast: Mapping the Web3 stack with The Graph

Transcript

welcome to zero knowledge a podcast where we explore the latest in blockchain technology and the decentralized web the show is hosted by me Anna and me Fredrik in this week's episode I sit down with Brandon Ramirez from the graph to learn about what they're working on the fast-evolving layer 1 layer 2 paradigm and the emergence of service protocols [Music] before we start I have a quick favor to ask in order to make this show as good

as it can be it would help us to get some feedback from you our listeners I added a link in the show notes this week to a short questionnaire if you're a long-standing listener or even if you're really new to the show we would really like to hear from you of course you can also stay in touch with us on telegram on Twitter and through our YouTube channel so to the new listeners who recently joined us hi be sure to subscribe where you get your podcast we share a new episode every week so looking forward to hearing from you and now here's our interview with Brandon from the graph so today I'm sitting with Brandon Ramirez from the graph he's the co-founder and research lead of the

project and today what we're gonna be talking about is the concept of layer 2 layer 1 what that is exactly and also where the graph fits into this so welcome to the show Brandon hey Ana good to be here I have a question for you kind of like to give us some context of who you are kind of give us a little bit of a sense of your background and maybe try to pinpoint the moment that you got really excited about blockchain or about sort of the origin ideas for the graph yes so first my background my academic background was in electrical engineering but came up through school in LA and wasn't really interested in working for like many of the defense companies out

there which was the primary kind of funnel for electrical engineers so I went into the software world worked for about five or six years as a product manager of various enterprise companies startups and then switched and worked as a software engineer for several years well so my first familiarity with crypto is we briefly stayed in a start-up house and Austin back in like I want to say it was 2013 2014 and these guys were going to why nominate her to start like one of the first like Bitcoin exchanges and they were sort of these like to like prototypical like techno libertarian technically anarchists and at the time I was kind of my interest was piqued but I didn't feel passionate about like the

vision that was sort of exciting them it was really I think when I heard about aetherium and kind of came to the idea of like programmable incentives and the implications of having a fully decentralized Internet application stack applications that never die that can outlive their creators that idea really fascinated me and and I think was sort of what drew me into the space what was your first I'd like was the graph your first project in blockchain or have you done something else with like etherium yes so this is getting actually to the origin story of the company a little bit Yaniv Yanis and i were working on a developer tools startup for i guess they were working on it for about a year i kind of joined for the last few months doing some software engineering and we

were kind of finding over lunches that like instead of talking about our business which is what we should have been talking about we were just like talking about crypto every single lunch talking about the implications trying to understand new projects that were you know publishing papers at the time this was you know in 2017 a lot you know all the white papers are dropping and and we knew we wanted to get closer to the space and like so we actually shut down the start-up we were working on at the time and we just started a full stack web agency and decided that that would be the best way to kind of get our feet wet pivot with our current experience of doing application engineering but then also start targeting our services towards blockchain companies and that

was kind of we had a six-month period where we were sort of getting our feet wet that way before we started the graph were you still over in LA at this time no I yeah I move all over the place so I did school in LA but I've lived in Seattle Austin and at this point I was in San Francisco I believe here maybe the East Bay so you had this web development agency where where's that pivot moment where you decide you're gonna like start a business or start a project yourself yeah so it was kind of a long drawn-out process to be on so I think you Nev had the initial vision for the graph towards the end of 2017 maybe even before we started the agency and it was kind of it was more of the the 5-10 year vision of the graph

right he kind of had this vision of all these data sets that are public that are you know operating on block chains or kind of public storage layers and and are completely interoperable right so this is one of the things that really fascinated us early on was this idea of block chains as this interoperability layer in contrast to today where api's are sort of the interoperability layer so we started having these conversations and I didn't see an obvious like a - you know a twosie path and like how to get there and then I was through the course of doing some of our consulting work we realized that there was a you know a real short-term problem that projects were facing which was actually how do you build an application directly on top of the blockchain and what I mean by

that is the blockchain provides like a pretty low-level interface for getting data out of it and so what projects were having to do is they were having to do like what's called ETL to put their data into like a database and then that's what would drive their applications what is ETL so ETL stands for extract transform load okay and it can be done in batch it can be done in like streaming jobs but it's typically how you get like data from multiple disparate sources or you know sources that aren't fit to your domain into like another data warehouse or database on it so you are seeing these sort of individual projects having to create that themselves or do it themselves correct and and so we run a project early on it there was a number of teams

on the project at number of different consulting teams I think three or four so we were responsible for building like a dashboard based on like a graph QL API there was an entire other team that you know their entire job was basically just taking data out of ethereum and putting it into like a Postgres database yeah so when we saw that you know these projects that are trying to build applications on top of the theorem were you know willing to spend you know fire estimates you know one to two hundred thousand dollars if not more on just putting data into a database that was kind of when we develop conviction that like hey there might be a real business here there might be a path to get to this longer-term vision that you know you Nev have started talking about you know towards the end

of 2017 interesting so it was actually over the the holidays I think that yaniv in Yanis started working on a prototype I came back from like the Christmas break and they had this like really simple like working example of like a graph QL server that was I was written and go and was basically listening to events on the blockchain putting him into I can't remember if it was a database or even just like a local cache and then letting you query the data through like a graph QL API so in early 2018 we decided that we want to dedicate some time to pursue the idea of full time we took a few months break from our consulting work you can even Yanis continued working on the demo I wrote the first version of our white paper and in I believe March or April we

raised a venture capital to work on the graph that's cool actually is that something I wanted to talk to you about in general which is like the funding of some of these projects but I want to hold that because I want to first better understand the graph and and kind of what it's used for you just mentioned this graph QL server you like this this is this is my question actually about the graph is there like in the general kind of web to stack or computer it's like just general computer science are there concepts like the graph and is this trying to take those equivalents and turn it into like a web 3 product this is something I've always sort of assumed about the graph but I'm not entirely clear if that's the case yeah the answer is yes and no so in a in a

traditional web to stack you would have an API server traditionally for a long time that was like a REST API and in the last few years a technology called graph QL has kind of gained prominence for a whole host of reasons that we can talk about later when you're building a traditional application and web 2 usually already have a database so you know it could be a no sequel database commonly it's you know a sequel database like Postgres and so you're writing your application data into that database and then that database is taking care of things like indexing and making sure that that data is efficient to query through your API layer so there is an analogue for the graph today in the sense that you know web 2 applications have an API layer but blockchain by its nature has created a

whole set of other requirements which is like now we need to go to index this data that's on this decentralized layer where block reorg can happen arbitrarily and now we have chance that have finality but you know for most applications building on aetherium today like that's a concern that didn't exist for web - hmm when you say so like the whole concept of the graph is it built for aetherium specifically is it built for any smart contract platform is it built for eighth - what what's it actually meant for so our goals for the graph are to be multi blockchain I mean we wanted it to be wherever top developers are so we started with East one auto because that's where we felt

the most developer traction was for decentralized applications but we think in the future there's gonna be a lot more interoperability between block chains both at the layer one and kind of at the service layer where we exist hmm do you see the graph then being like is it cooling is it cooling for taps is it one of these like necessary components for any sort of application to run on these smart contract platforms so these layer one platforms is that is that kind of your thinking around the project I think it's a combination right there's definitely a developer tools component to it you know we're giving you know we have clients that that developers can run CLI is to like help their workflow to write a subgraph and deploy it but

primarily the graph is you know this service layer so it's the you know the decentralized infrastructure that developers can deploy their sub graphs to and query where typically I would think of developer tools as being something that's more like local - like a developer's machine but maybe doesn't have a you know a running infrastructure and is it I mean what is it built out of like is this a standalone software stack or is it a I I'm trying to figure out is it a smart contract project like what where what is it yes so today the primary part of the graph is the graph node which is a indexing server that's built in rust and

so it listens to events on the blockchain and it puts them into a store which today for us is Postgres in the decentralized Network which were planning on launching next year the graph application logic for the protocol rules will be implemented as smart contracts but then there will still be these nodes that are the graph nodes that are that speak the language of the protocol and will be running as a separate service layer and those would then be decentralized and those will be decentralized what is it right now there's like when you said there's a node built and rust is it like just within the project itself there's a few people running these nodes they're not it's not actually a it's not spread out there's no incentive for anyone to run

these nodes outside of it right yeah so this is some good I guess history on kind of how we approached our product development roadmap yeah so the first thing that we wanted to do was build a node and just open source it to solve this problem for developers so we did that I believe in July of 2018 and it was like maybe a month before eath Berlin and so we just got a lot of really great feedback on just like hey here's this tool we think it's useful you can run it yourself and it solves this set of problems towards the end of 2018 which what we were realizing was that even though it made it you know orders of magnitude easier to solve this problem it still required you to kind of run a database it required you to like have some knowledge around docker it

still wasn't a trivial set up to you know set up this indexing server and graph QL API in early 2019 earlier this year we launched the hosted service which is a centralized service where were operating graph nodes on developers behalves many of our developers have chosen to switch over to this just to reduce their operational you know overhead but you can still you know go to github you know download the graph node software today and just run it for yourself in your own infrastructure what we don't have yet is a decentralized network where anyone can participate in running a graph node and an end user can query any graph node based on what's

going to provide the highest quality of service to them and that's what we're working on launching dear what like okay so that first the first iteration you did actually imagine like other participants running nodes who would those participants have been in that case are they like the app the doctor developers is it like who run who would have run them yes so so in the first iteration where we just open sourced the the indexing server it would just be projects running it for themselves and their own environments it's a chain operators is it like the actual layer one chain or would it be the layer two that operators who would actually use something like this or would they all yes that's a good question so when we launched the open-source version of the graph node we

were primarily targeting it at app developers that wanted to run this infrastructure for themselves and their own centralized part of their application stack so this is maybe good background unlike what developers were doing before the graph there were basically like one of two kind of major options like one you could have these applications index the data locally on the user's machine so you could efficiently query you know data in the application once the users machine is like synced and so I believe apps like augur and Aragon took this approach the benefit is that the app stays fully decentralized but the downside is obviously degraded user experience the

other approach is the one that like crypto kitties took for example where the core application logic is running on the blockchain and it is decentralized but they run these centralized indexing servers where they're you know loading the data into their own database and then all the user experiences that people are interacting with are actually interacting with their centralized infrastructure hello and so when we launched the graph node we were basically trying to make that second pattern easier for people although you could still you could still run it locally on the user's machine if you wanted but the reason that we're you know pushing forward to this decentralized network is that we still think that pattern is suboptimal right like I wouldn't even call that a layer

you know quote unquote in the decentralized application stack because it's really just centralized services operating you adjacent to the decentralized application stack got it and so originally you started sort of open source anyone could have a node then you decide then you all started to offer hosted services which centralizes it but that's not where you're stopping I mean have you had any pushback for actually even creating a hosted version you know we did early on and I believe I think it was you know more towards like I guess when some of the fervor of 2017 still hadn't like worn off I think there was a lot of like residual like optimism and and I think part of it was supported by

the the marketing around these projects that like web 3 was something that was just gonna happen tomorrow that it was like a few weeks away of just like really hardcore development and that the entire application stack was gonna just be decentralized and then I think what you saw in 2018 is that 2018 was a tough year for a lot of investors and a lot a lot of teams as well and I think it was kind of a reality check that like hey if we want to build something that's gonna be useful to users today we need to be pragmatic I think a lot of you know what we focus on now is kind of being very vocal about our commitment to pushing forward to the fully decentralized network but that in the short term we want to offer developers and end-users you know a consumer-grade user

experience and give them the ability to build performant web applications we've touched on that that idea of like the trade-off between decentralization and maybe like performance or speed of development we've talked we've definitely talked about that quite a bit and I I find it fascinating because I think the dream I think the idea of decentralization is so beautiful but at the same time in practice you see some of the complications and there is this this thinking that you need to you do have to sometimes be pragmatic and decide like well we want to get from point A to point B but like how are we gonna do that most effectively and it may not be starting decentralized yeah I think there's a few different dimensions of it right when people talk about

centralization and decentralization so there's you know architectural decentralization which comes with trade-offs right you know right now for layer 1 block chains for example that means a lot of redundancy it means you know not the kind of performance that you would expect from like a consumer-grade application and then there's like organizational and and you know political decentralization where there's no obvious shelling point of like a clear leader that's you know dictating a strategy top-down and kind of moving a organization in lockstep towards a specific goal you know I think at different stages in a project I think both can be appropriate but I think it's just a matter of timing I think it's understanding like what

stage you're at I think very early in a project life its advantageous to be able to move quickly and sort of you know be aligned instead of having to like for every change to the protocol or project submit a proposal get buy-in from the community you know talk about it on Twitter I think that's something that's more appropriate as a project's hit a certain level of maturity yeah so you mentioned sort of these two dimensions and you've just sort of talked about the trade-offs in the second one the social one but what about the trade-offs in that architectural one what does that look like yes so I think this is actually you know we're starting to get into like the distinction between the category of projects that the graph fits in versus for example a you know layer one blockchain I think for a layer one

because it is the foundational platform upon which many other services and applications are being built people have a much higher bar set early on to kind of wait decentralization and trustless nests over for example performance in these service protocols the security model is a little bit different right and it's unique to each project although there's commonalities so take the graph for example we're indexing data that's on the layer one blockchain and we're presenting that to users in a way that's efficient we're not the source of truth for any data we are not the source of truth for any state transitions on the underlying blockchain so we can wait

things like performance a little bit higher than decentralization in the early days of our protocol without degrading the core utility of what we're offering to end users and developers cool I think what we should do right now is define the layers and reason I want to do that is you know a lot of what I want to speak about in the next section of this podcast is layer 1 layer 2 how they interact what the landscape looked like what it looks like now this is something I don't feel that we've really properly covered over on the podcast so I'm really happy to have you walk me through this this is really cool and then I want to go back to these trade offs that we just outlined because

I think that would be really cool to see it in that context but let's talk about the layers in blockchain I had we had Dan brownie on recently and he actually defined four layers of the blockchain and I'm gonna share those with you I don't know if you agree with them um it's just sort of one perspective but he saw layer 1 as consensus he put layer 1.5 as computation slash EVM layer 2 was the dap or applications like stable coins like the mechanisms of stable coins and then he had layer 3 which was the user facing wallets and sort of actually a lot of the user facing stuff so in that I mean I don't know what you think of that layering um

does that make some sense to you or yeah I mean the layers make sense I think a lot of different people are gonna have different opinions on like what should be called you know at the bottom of the stack like one like 0.5 seems somewhat arbitrary called it layer 1.5 but he put it between layer 1 and layer 2 yeah I can say that colloquially when people generally talk about layer 1 and layer 2 usually they're talking about layer 1 as a blockchain sometimes that also extends to include storage layers like ipfs and then layer 2 is usually a scalability solution that is somewhat general-purpose and extends the capabilities of the layer 1 so you can

think of like state channels plasma side channels roll-up solutions those would all kind of fit into the category of layer 2 when people are speaking cool cooler like this is you know if you're talking to someone at a conference or like oh yeah this is a layer 2 solution for X Y Z in terms of the actual you know tech go layers without like advocating a specific numbering yeah I would say maybe I think of you know the bottom layer as being like p2p networking maybe a layer above that I would say is things like dhts and like content address storage right so this is like what ipfs uses but it's also what aetherium uses above that I would put consensus which enables like the smart contract

execution and then I would put the layer to scaling solutions and then somewhere above there you have these service protocols which is the category that the graph fits into these kind of trust minimized services and further up the stack you get the actual decentralized applications hmm where would you put something like a stable coin then where does that live I don't know if stable coin in my mind occupies its own layer and the stack to me that's like an application that's running on this application stack that we're building right so if you take something like take something like you know die for example you know there's it's composed of many of these different layers right so you

have smart contracts that are running at the consensus later that are running on the blockchain but then you also have you know off chain services maybe that are supporting you know that are submitting transactions to the blockchain there's you know very clearly a need for auxilary services in order to make this useful for users at the presentational layer so I just wouldn't think of it as being I think of those as being the types of applications that we are trying to support by building this this layered infrastructure thank you so much by the way for just like also sharing that colloquial definition but I do hear it i I've always heard layer two thrown around just to define kind of anything that isn't the consensus level

two I've just sort of heard like I don't think else is layer two I totally do the same thing right like that's that's certainly another valid colloquialism like yeah people will say the graph is a layer two you know protocol for querying blockchain data but yeah I would say that's very cool cool rather than trying to be you know precise like is layer one and layer two maybe an outdated term actually are the way that we use it colloquially is it is it sort of not really representative anymore yeah that's a good question I mean so when people talk about later in a lot of times they're inspired by like the OSI model which is I kind of you know the way that yeah the kind of song works yeah well it's the it so the internet internet application stack right like

you know so you have all these networking protocols that's sit upon other protocols and the idea is that each layer in the protocol is only aware of the layer below it and that the layer below it abstracts away any other layers below it right so if I'm at like the transport later and in the protocol stack like I don't know anything about like the physical like link layer right like there's several layers in between that sort of sort of abstract that away from me now in blockchain and like web 3 we don't really mean that in this same exact way right like so if you're building on a layer 2 solution like let's say you're building on top of

you know state channels you're building on top of you know plasma that doesn't preclude you from also interacting directly with the layer 1 blockchain so you know that makes it kind of hard to example for example to call something that sits on top of lit plasma a layer 3 because unlike the old model that would mean okay it's only interacting with the layer below it below it but it isn't it's actually gonna be interacting with like multiple parts of those two layers and exactly and if you think of like the decentralized storage layers also being its own layer you know oftentimes you might be interacting with the blockchain but also the decentralized storage layer so yeah you're kind of always interacting at different levels in the

stack I mean I guess eventually we're gonna have to retire those terms anyway I mean there can't only be - right right I mean or you just start getting into the fives and sixes but I have a feeling like no one wants to build themselves as like a layer six solution yeah somehow it just doesn't have that same ring well you know crypt those kind of a space built on memes so maybe layer one and layer two will just be you know really powerful memes that carry forward so maybe maybe let's talk a little bit about what these service protocols are and how they connect to all of these layers what's the service protocol exactly I know you've mentioned in the past maybe we can talk a little bit more about it yes so a good analog if you're familiar

with web to space is like kind of like micro services right so there was this trend in web 2 or originally we were building software as these giant monoliths and we started decomposing software into kind of more purpose specific services called micro services that you know could be unbundled from the larger application and so service protocols in the web 3 space are sort of an analogue of that so there's there are these more domain-specific building blocks that kind of sits atop the you know more generalized foundation that's provided by like blockchain layer 1 and layer 2 solutions you kind of mentioned ipfs is living still on sort of the layer 1 so that would you put that under

the category of service protocol I wouldn't put I P FS there because it's this very general platform that we're building on right so I can web to you know your building you know even though you're building with micro services you're always using some combination of compute and storage right and so in the web 3 space I think of your compute as being you know the blockchain or smart contracts and then your storage being something like ipfs ok so it's so core for the entire mechanism you wouldn't necessarily call it a service protocol right and it's extremely general right so you know you get into a service protocol like the graph and I we're far more specific in what we're doing right we're helping you with a specific type

of computation which is doing the job of indexing and then efficiently querying the data that we've indexed from the chain another protocol that fits into this category is live peer so they're you know doing a very domain-specific task which is the transcoding of video right so it's not a general-purpose computation that they're doing it's you know fit for a particular application domain who else would you put in that category what other groups so I'd put projects like new cipher into this category keep projects like Gollum and where Gollum even though they were you know kind of initially targeting this generalize compute where they've started as this you know domain-specific problem of you know I believe graphics

rendering I think is their first use case do you have sort of a specific domain that you are also focused on or is it more of a generalized solution with the graph because the graph sounds like quite usual by lots of things it's quite general it's certainly quite general in the sense that a broad broad set of applications and services need or it can get benefit out of the services provided by the graph I guess when I say that it's more specific I mean in the nature of the computation right like we're not a generalized compute platform we are a platform that helps you with a very specific set of problems and tasks that you're trying to solve

got it do you think I mean in the in sort of the multi chain universe where you see like all these different platforms and and block chains operating together I've heard this idea of having different chains be focused on specific services like for example a hosting only blockchain which I think we're gonna also see emerge with something like file coin but like having you know hosting having I forget what the other computation having like all these different ones could you imagine the graph then living alone I know and not that you're constructing it that way now but could you imagine that concept being a standalone blockchain eventually this

is something we're watching pretty closely I'm not sure I have like a dogmatic position on how the future will play out I think even a world in a world of multi blockchain or multiple shards I think there's it's clear that there's network effects around some things being on the same chain and the security model for Mugen stuff between chains is still not as strong as if something is just on the same chain right like if you're relying on a bridge or some other way of moving an asset between chains and another you know challenge I guess for projects that want to launch their own chain is that regardless of whether they go a proof of stake route or work route they need to secure that chain and that can be difficult to do for like a nascent project so this is space we're watching closely but for now we're kind

of focused on yeah the area and supporting multiple block chains but our our smart contract logic would run on it a chain like aetherium great back to the service protocols I'm trying to figure out how they actually fit in with these other layers or with the stack like what I have would I run like say you know right now you mentioned you're kind of hosting for other projects but like in that first iteration where everyone would run a node would I then run a node for each one of the service protocols like how would how would each project have to participate in these service protocols in order to use them this is sort of unclear to me so that's a great question and this sort of gets to our vision for web 3 or at least the part of the vision that excites us which is this new model

of users interacting up with applications where they're paying for their incremental use of the services they rely on for those applications and so what I mean by that is instead of you know today we're like you know a user pays a centralized company and then a company kind of indirectly pays for all these services and then the services provide utility to the user the user in the future will just directly interact and exchange value with these services in exchange for getting utility now what the DAP developer does in this model is they deploy logic to these services that the user can then depend on and with this and the services would be running like it wouldn't it wouldn't be that

everyone in deploying would need to run their own node the nodes are basically deployed and it is an existing thing that you can tap into and the security or the the mechanism is already taken care of by this decentralized network it's not that like I'm thinking of it like a building block you have to download and incorporate which I realize not in any way the way it works but I'm trying to sort of figure out how they interact a good way to think about these protocols may be in contrast to like layer one is that these were designing like markets right and so so there's these decentralized you know networks of node providers that are competing in a marketplace and the end users do need to be able to interact with that marketplace but they don't need to be

able to run the entire node software themselves so the model is much more akin to like a light client model and like traditional like later one block chains where you know if you're a in the in the future if you're interacting with the graph you will need to have a client on the end-users machine that can speak the language of the protocol at least to interact and exchange value and data with people in the decentralized market but it could be very light it could be a light client not a full client yes it can be our goal is for these things to be very light and actually a good way to think about it in an or protocol and I think this applies generally to at least a handful of protocols in the spaces you can almost

think of like the end user and the service providers and in the market both having like their own kind of algorithmic trading engines that are interacting with each other in real time to like kind of do price discovery and figure out what service providers to interact with and at what price and you know what parameters and that's like a big part of the design space here as well to make this a reality for end-users obviously there's things that need to develop an ecosystem as well so we need you know the proliferation of state channel wallets we need better UX for signing transactions and for State Channel wallets like this wouldn't work if every time the you know automated negotiator or trading engine wanted to make a transaction that you need to

prompt the user for you like to click a button so in the interim you know we launched the network or you know as we're planning to do next year we will have actually like a gateway that abstract some of this from end users so that they can hit the gateway instead of having to have this you know state channel wallet and client running locally on the end-users machine from there like you sort of mentioned this marketplace I what is that like can you can you tell me a little bit more about like what that really looks like so a big challenge for protocol designers that are working in this space you know specifically what these service protocols is designing a efficient marketplace so this is actually something that I'm working with other

folks in a service protocols working group you know folks from a new site for a live PR so on to kind of discuss these you know shared challenges that you know each project in the space has but there's a handful of commonalities here so one is you know it's discovery layer and how do you handle service discovery so that's like a core function of a marketplace is it even though it's decentralized there needs to be some logical logically centralized place where you know to go and find service providers yeah assuming that there's many many service providers you need to figure out ways to narrow down the set to the ones that can provide the highest quality of service to you or that you want to interact with there could be things like you know rating the

performance or you know having like local reputation for these service providers that you know like hey if this one's done well for me in the past I interact with it again in the future you need things like price discovery so you need you know it's not enough to have many participants in the market you need information to flow in such a way that like prices actually reach an equilibrium that you know that's efficient another shared concern that we're actually talking about in an upcoming session is you know how do you subsidize useful work on the network how do you define useful work in a way that you know can't be spoofed we're discussing things like how do you you know use the work token to get civil resistance and economic security in a model where work is coordinated almost

completely off chain but that I mean that leads to another question I had which was about like what is a token in this context where does it like I actually it's not entirely clear for me how payments or how the utility tokens of these service protocols work in tandem like a hat like because I just don't I don't know do you imagine every death having these tokens as well like how does that like this is super interesting to me because this is exactly this gets to the core of how I don't fully understand how some of these projects actually fund themselves or plan on running themselves or how there's a market exactly and like how other actors are supposed to interact with them yes you mentioned utility

tokens that's the one model that a lot of projects and like DAPs raised on early on where the idea was that if the you know the token was useful to do something in the DAP it would be used as kind of a medium of exchange and that was sort of accrue value to the token and to the network this approach has fallen somewhat out of favor in in recent years for many reasons not the least of which is that it imposes undue friction on end-users if they have to hold you know a token of some other project especially given the amount of volatility that we've seen in token prices where you know now we're imposing this kind of quote quote balance sheet risk on on end-users so the approach that many

projects including the graph of move to is called the work token model and the idea here is that only the service providers need to interact with the token so service providers stake a deposit of graph tokens or you know the native token for you know the respective protocol and that entitles them to do work in the network and so these things accrue value according to like the present value calculation it's very similar to how taxicab medallions accrued value in regulated taxi markets in cities like New York and elsewhere mm-hmm I actually don't know how those works yes so that's that's a okay I can talk about that yes so let's see what I

could do from memory so at some point regulators in New York City this is going back several decades decided that I believe the the impetus was that there were too many cars and taxis on the road in general and they wanted to limit that and so they came up with a model of tradable licenses called taxicab medallions and this is pretty unique when you can think of business licenses and other businesses right like if you become a lawyer or if you become a hairstylist you know that's something that's kind of assigned to you but you don't think of being able to trade that mm-hmm but in the taxicab market you could actually trade these licenses called medallions and so you sort of had a a not fully competitive marketplace so

the profits that could be earned in the taxicab markets by cab drivers were what we would call an economic supernormal profits right like there were profits above and beyond what we would expect in a fully competitive efficient market now the question is like if you have all these cab drivers that are earning these you know extra you know profits on top of like what we would expect what does that do to the value of the taxi cab medallion and the answer is that those profits are capitalized into the value of the medallions according to like a discounted cash flow analysis or like present value calculation and those medallions actually become capital assets that have value of their own do they increase in value as this market progresses yet so

they increased dramatically in value over the years partly due to speculation but also you know partly due to like the the intrinsic value of the medallions and so do you have the idea then of taking this model and putting it into the service protocol world or these marketplaces correct yes exactly so these service protocols many of them if not all of them kind of adopt this model into you know into the crypto economic space where you know similar to the tradable licenses that you had with the taxi cab medallions now service providers can stake a deposit of tokens and that gives them permission to do work in the network now what becomes

challenging for a lot of protocols like the graph is that for reasons of efficiency and performance the coordination of work happens off chain in a sort of organic self-organizing manner right like there's no top-down controller that says hey you have this many tokens so you get to do this much work actually early versions of some of these protocols like live peer they did work this way as like sort of their first proof of concept because there were so few service providers in the network that they could just have work allocated on chain but since we're moving for performance and scalability reasons we're moving all this work to be coordinated off chain now we have to come up with new techniques to still

have the tokens have this same fundamental property of like permitting to do work in the network but without just top-down control and when you say the service providers themselves would stake it like going back to like that interaction with adapts did they have to have some connection to the tokens on the service protocol like levels like do they have to own them do they have to work with them do they have to is there any interaction there or is it all happening within this like self-defined place is separate from anything else right and in this one the same way that you pay for a cab you know with US dollars despite the cab driver having to own a taxi medallion you know we would expect that for most of these protocols

including the graph you would pay in your sort of medium of exchange token of choice whether it's die or eat and then only the service providers need to interact with graph tokens got it is there any reflection here in like the way that the mkr holders like half do all the governance and voting and stuff like that and it's separate from died or do you think that that's a completely different metaphor different construction no I think that's or I think that's a reasonable metaphor and there's definitely similarities to maker in the sense that you know you have this token that's kind of more designed for sophisticated you know operators of the protocol and then you have a separate token that's more designed for you know the average user to use right you saw it

the same thing with like the Lieber Association where they had you know the Libra investment token but then they also had the Libra currency which is what would be you know has the properties that you would expect from something that's been interacted with by all end-users you know namely like stability for protocols like the graph you know we have our work token which is designed for the service providers in the network and you could imagine as having a separate token for exchange and you have seen some projects do something similar but for us we just see you know value in kind of adopting the currencies that people are already using in in the ecosystem like die like eath so this definitely brings me to another question I had a little earlier and I didn't get a chance to ask which is like does the

graph have a token which I assume now is yes yes so the graph will have a token padlock when we launched the decentralized network and it will be a work token got it is there also in this work token like is are there any governance components to it could you actually vote on the way the protocol is developed in any way using the stuff or is it not at all in that category yeah this is a great question it starts to get into into pretty philosophical territory you know obviously you know there's a lot of analogs here between like the debates that we've had at layer one like on chain governance versus off chain governance do you you know do in protocol upgrades or do you upgrade through hard Forks and I think this isn't something where I would expect

every project in our category is going to come up with the same answer so I can offer you sort of my opinion which is that I think in the first few years of these protocols it's very likely that in protocol upgrades through governance will be necessary and that the work token will play a role in that process one of my goals as a protocol designer is to to minimize the surface area of governance as you know quickly as possible and eventually maybe even be able to throw away the key altogether and that's a lot easier said than done because you know when we're designing these systems you know we kind of have these qualitative designs which are like what are the Vino various incentives for the different roles how do these things

these different building blocks flow together how does information flow in the system but then there's also a lot of quantitative design decisions right like what the specific inflation rate that you set what is the percent cut that a curator gets you know first for rewards what is the slope of your bonding curve right and it's very difficult to imagine that prior to launching the network you're going to set all these things in an optimal way so like one of our future goals as a research team is to model and simulate the dynamics of our system and the dynamics of the protocol design but then also after we launch to kind of you know figure out how well do those models track reality and like where are areas

where we think we would maybe one day be able to relegate the setting of a parameter to maybe an algorithmic decision rather than something that is set through governance you just mentioned this term roles what our roles in the graph the way that we've kind of approached the protocol design process is first to define the technical system design and so this is very akin to how you would design like a traditional web 2 system right like what are all the building blocks that need to function in order for the thing to do the job that we've set out to do there's that sort of binary right like it either works doesn't work now once you have that technical system design there's we can't

think of these things as all being controlled by a centralized actor anymore so we need to think about who's gonna do all these different functions and those kind of map to roles in our protocol and so in the graph the primary roles are the indexers so these are the ones that are indexing the data and respond to queries and the end users the ones that are issuing the queries via the gaps that they're using and then also the developers the ones that define how the indexing jobs take place that the indexers do now often what will happen is when you define these first role sets of roles and then sets of incentives you realize that you need secondary roles to kind of support the mechanisms of the primary roles right so

do you almost need like you need somebody to check in on the indexers or check in on the end-user or something like that make sure it's all happening correctly exactly exactly and so that's where we end up with these secondary roles and so like when the network launches next year we'll have a role of like a fisherman for example which is doing exactly what you described checking in on the work that's performed by the indexers which shows early on to use like a market mechanism for like efficiently matching end users with indexers but in support of having an efficient market where there's you know good market discovery we also have a curator role and so that's like a

secondary role that I think of as supporting the primary roles in the network this this these roles and everything that you've defined here I'm imagining there's like a very complex incentives structure I don't know if we can go into it in big depth here on the podcast because maybe it's better to like write this out on a blackboard or see it do you have actually a resource where people can really see how these roles are defined and like what the incentives are for each of them yes so we actually just published a blog post a couple of weeks ago perfect yeah it provides a very readable version of this we previously had some of this in like previous white papers and like a spec but the blog post is probably like the

most approachable way to kind of get up to speed on the current version of our protocol decisions as well including the roles in our talk so far we've sort of heard about the origin story of the graph and we've heard about the current state of the graph we've heard about the service protocol group and some of the the plans but what is the future for the graph what's your what's your next step yeah so there's a few things coming up in the next year that we're really excited about obviously as you mentioned we're launching the decentralized network which is gonna be the first version of the protocol where anyone can come in and operate a graph node and participate in compete in the market to you know provide the service of indexing

and querying data there's a couple things we're actually working on ahead of that that I think make that even more impactful so one of those is we're adding multi blockchain support and the other one that I want to talk about a little bit is we're also adding support for what's called sub graph composition and what this means is that you'll actually be able to build sub graphs that can reference other sub graphs in their data model and so this is starting to get and it's like what we saw as being you know that sort of master vision for the graph you know back when we started was really getting to the point where blockchains and web 3 was acting as like a data interoperability layer so the way that we see users building apps in the future is that

it'll be much more of a remix culture you know than it is today where we like you you know rebuild everything from scratch from the you know the top to the bottom you might see that hey there's a couple protocols out there already that do a little bit of what I need and there here's some sub graphs for them that kind of you know referenced one another and maybe all I need to do is build a new sub graph that references the first two sub graphs and covers this little you know bit of functionality that's described on Shane and a new smart contract and so I think that combination of having this you know composition on a public decentralized protocol is really powerful cool are there any specific change that you're like already thinking of working with or when you say multi-chain

compatibility in order to do that do you actually have to change anything do you to work with those teams how does that work yes so there's definitely a bunch of projects were looking at talking to you know cosmos polka dot taste those others are on our radar things were looking for our traction with gaps you know in terms of defining you know what change we aim to support first and then also of course you know grants you know which some projects have approached us about you know so that they can have a you know this has utility to their ecosystem as well you know especially when you talk about like block explore like scenarios where you know to support a good block Explorer you need to be able to index the data on like the underline they are one chain and

presented to users in a way that's that's useful well listen I want to wish you a lot of luck with the with the coming work and the coming launch and everything but before we sign off I do want to ask you a question about your logo and your designer because you have some of the most beautiful swag t-shirts out there and it seems like there's a reference in a lot of your graphics to what was it called Monument Valley that video game or assure paintings or something like that I don't know you're probably looking even deeper than I am so when we did the mood board for for the design which was done by Carl who's our brilliant designer on the team the

initial impetus was space Aztec and that's just sort of just evolved over the last couple years and as sort of the you know various designs and characters and landscapes that you see in our you know the product and like blog posts today well it's really beautiful the way that sort of comes across yeah so thanks again for helping me navigate this sort of layer question I think if there's a takeaway for me like one big takeaway from this it's to rethink the way we think of those landscapes and just to realize like there's certain projects that won't necessarily fit into these layers but are still incredibly important and needed in the ecosystem yeah the stuff is still evolving I'm

still kind of relearning right alongside the rest of the community cool and happy to be on and talk about this with you guys yeah so anyway I guess thanks again for coming to our listeners thanks for listening [Music]