Graph Protocol Core Devs, 31 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: The Graph - Core Devs Meeting #12

Description

The Graph’s Core Devs Meeting #12

This video was recorded: Thursday, March 31 @ 8am PST, 2021.

The Graph's Media:
Twitter: https://twitter.com/graphprotocol?s=20
Instagram: https://instagram.com/graphprotocol
LinkedIn: https://www.linkedin.com/company/theg...
Website: https://thegraph.com

A

Hey everyone welcome to our 12th court r d, call if you're new here some context we're having these calls with core contributors every month. The purposes of these calls are for core contributors to present what they've been working on leverage the cross functionality uh introduced by different working groups and branch storm on ideas, new research tracks and also get community feedback on some of these work streams, they're always recorded and uploaded to youtube. So I do invite you to check our channel if you've missed the last ones.

A

I'll paste in the chat in show notes the link to the graphs ecosystem calendar, so it can be subscribed to future ones and the more general as we call it uh community talks so to continue. I do have some worthy updates. The foundation might want to share um you've, probably seen this blog post, where we've uh presented the d roadmap.

A

uh I can link this as well, but I also invite you to listen to the recorded twitter space to hear from the different core contributors on how this was a coordinated effort and understand what the main priorities are really and to conclude. Brandon, co-founder of the graph and head of research and product and engine node, uh he also did a great ama on reddit and there's some interesting takes there. So I'll share all of this in in the show notes and on this chat as well all right, we do have a packed agenda.

A

So uh we'll start off with data and api's working rule with toyota from the guild showing us the recent work on the graph client, I believe, dota, I believe, yeah. I believe that will also do a demo showcasing exciting features such as the client side, subrav, current position, which is pretty cool and then we'll go deep into protocol econ hearing from multiple core contributors on the recent work that will uh to some degree, have an impact on different network participants. So it's good to uh discuss those things here.

A

We'll start we'll start with prism group, I'm not sure if you've heard from prism before they're a long time bringing in their expertise in neoclassical economic modeling, we have yuji on the call uh and so he'll share more about their work. Focusing on specifically this recent analysis on on uh uh of the outcomes of a of an open, zap and security audit, they saw that it will be open sourced by the time we publish uh prism's papers, their recommendations and the related gip.

A

That's in the works as an outcome of this working working group uh I'll refer to brandon in a bit to introduce this.

A

This topic and walk us through the context, context and relevancy here really, and I will go over uh mechanisms impacting mainly subgraph developers and curators, specifically the proposed uh principal protected, bonding curves and related work on decaying creation, curation tax and the signal renting, which is fairly new and finally, directly impacting indexers indexer economics we'll do a quick intro on um stale allocations, take rebate and subsidize query settlement branded can walk us through here, still early work with more analysis to follow soon but worth taking a call to have a preview and understand the motivation behind all of these.

A

So it's a packed agenda. I just hope we do have enough time for all of this. um Okay, so enough for me, uh I think we can get started.. I'm gonna stop sharing my screen and if you're ready, you can take it off.

A

B

Yeah perfect now I can unmute myself thanks um cool. So uh while I'm sharing.

C

My screen, I will.

B

Just say that I plan two hours demo uh just kidding, but don't worry pedro uh only ten.

C

B

Yeah, it's packed so I'll, try to squeeze as much as possible, so I'll start with a quick overview of what we did. So we at the guild started working with the graph and we looked into how we can improve the developer experience of depths and improve the way that the right graphql and the way that they query uh the graph.

B

So uh this was our initial inspiration that we did a few uh meetings with apps developers and we tried to find all the pain points and the actual issues um and we tried to pack all of these into one graphql client we're calling it the graph client tools. I'll explain a bit on that. We have a packed list of features and we're able to integrate with basically everything in the graphql ecosystem today.

B

But I would start with just like the general architecture first and then I'll do a quick demo. So, basically, the graph client is a package containing uh tools that improves the developer, experience um and improves uh type safety and the way that you execute graphql.

B

um It comes with a lot of cool features like client-side composition, which I'll demo in a minute, and a few more, it's important for me to mention that this was an amazing journey, because we developed graphql mesh, which is an open source that basically combines and transforms anything into graphql and there we had a layer that knows how to compose different layers, different graphql endpoints, which is basically subgraphs, as we know it from the graph.

B

So our idea was to take these tools and leverage open source in order to make something new uh for the graph and improve uh the way that we're occurring. So we had two modes uh and today I'll show only the standalone modes but uh mode. But it's important to me to say that there are two modes: you can either do standalone mode where you just use the graph client directly, and this gives you all the orchestration and query planning and you can query as much as subgraphs as you want.

B

You don't really need any infrastructure, you don't even need a front-end project or a node project. You can just use graphical out of the box. I'll show it in a second and uh besides that we have an integration layer that provides a compatibility layer for all the popular graphical uh clients around. uh If it's a polar client oracle, you can just do fetch directly. Anything you want. So this is like another option to use a graphclient. It just wraps everything that we're doing in the standalone mode.

B

That makes it easy to integrate so I'll start a bit with just a demo for the client-side composition, there is a complete, like a whole list of features that we have here. uh Maybe I'll have a few more minutes to go over this uh after the demo. So uh for the demo, what I uh prepared is basically a very simple example of taking a sub graph and merging it with another sub graph.

B

So our entry point is basically, let's say I'll start with the node project and I have a yaml file that defines basically everything that I need in order to fetch the data here I can define like all my sources, if I'm using multiple indexers that are distributed, um I can use it if I have an indexer that I'm not fully trust, and maybe I want to fall back to the hosted service on the same subgraph. I can even do that, um so you can see that I can really control on.

B

I have full control on the um the network aspect and the execution aspect of graphql. So for this example, here I have um two subgraphs one is uniswap and the other one is compound, and basically this example takes uh both of them defines um like the actual sources where the subgraph is deployed.

B

uh Here I just did one that doesn't really work or doesn't really exist and the other one is a fallback to show how I can just fall back to the hosted service- and I have another one here, and this is like a very naive way of merging two subgraphs. So this is all that I need in order to have this client side, composition and client actually running. I don't really even need a whole project set up.

B

I have here a script that only does graph client serve dev and, basically, all that it does.

B

I can just do yarn graphical and basically behind the scenes. I get these two subgraphs um introspected um and the definition.

D

B

Network structure that I define here to do like a fallback. This is actually running even now. It's not only a runtime thing. It's everything you define here is both both for uh development purposes, and you can also reuse that configuration for your actual runtime of your deck. So um what happens here behind the scenes? We're introspecting these two and then merging them in a supernatural way, um since there are no real conflicts between these two subgraphs. Everything is just fine, so I just did yarn graphical, and this is what I got.

B

This is the graphical. This is the new graphical. You can also see that now we have tabs. uh This is a really cool effort done by the guild in order to take graphical into the next level. So what we did here uh first, we got these two subgraphs and, as you can see here, they're both merged into one graphql schema right.

B

I have these two sub graphs and all of their types are defined here together and just for the purpose of the demo, I'm going to query these two subgraphs in one query and behind the scenes I have here a query planner. That knows how to how and where to execute each subgraph. So.

D

B

Is done by schema, stitching and graphql mesh under the hood, so I'm just squaring and as you can see, I got one single response for both subgraphs under the hood on the network layer. If I'll take a look here, um yeah you can just see one query being executed, because I have this tool running in development.

B

That knows how to orchestrate all the code, but if I'll integrate that into my uh depth or from the application, I would see four http calls here actually because I have a fallback here, so this one is failing because of bad dns property and then this one is actually working same here and each part of the query is executed across uh the actual subgraph.

B

D

This is really cool but, as I said, this is a very naive.

B

Example, so I prepared another cool example: arda from the guild helped me, and he is the mastermind behind everything here with the client side composition.

B

So the more advanced example and by the way arda is here on the chat. So if someone has questions feel free to ask on the chat, uh it can help very quickly.

B

So the other example that I made here is a bit more advanced, so we're taking two subgraphs and we're doing some transformations and some cool uh stuff that I'll mention a bit uh like the technical aspect. So I'm taking here, um one is like nfts and the other one is uni swap, and what I'm trying to do here, I'm using a concept that is called type merging. Basically, I'm taking two graphql schemas, two sub graphs and I'm taking two different types. um Each type is defined in a separate uh subgraph and I'm merging it together.

B

um So from the point of view of the query, the graphical query, I don't even need to worry about these two types or syncing mechanism, or even, if I'm using apollo, client or urkel. I don't need to worry about caching, because the caching is now unified, because there is just one graphical schema, so I'm taking these two endpoints, these two sub graphs and then doing some manipulation. I go I'll go over it in a second I'll, just want to show you how it works.

B

So basically what happens here um we have this graphical again, and this query that I have here is far more sophisticated, because what happens here is that I'm taking? um Let me just try to find the type user here, as you can see here, type is actually a combination of type and the count two different graphql types, two different entities that are merged together and everything is happening locally right. It's not really happening on graph node or the indexer just happening here locally and distributed across the two sources in a separate way.

B

So this example here, I'm just running sure this works. Basically, it takes two types of merging together and the way that we're doing it is like uh only in a declarative way. We didn't really even write a single line of code here in order to do this uh kind of merging. So basically, we can define again like the handler, um the sub graph, the endpoint that we're using and then the transformations is the coolest thing here. um First, we want to prefix everything coming from the nft.

B

The source named nft, so we're just doing nft underscore, and what happens here is that the graphql schema that is deployed on the subgraph is actually the same. But what we did here, we just renamed it for just here locally.

B

There are a few more configurations here, but basically we're adding a prefix we're renaming the nft account into a type called user and then we're doing type merging and type merging is basically merging a type from one schema into a type from another schema. And then, when I'm querying it, I can just ask for fields across two subgraphs. So what happened here? I got one type called user that is merged with another type called user, and now, when I'm querying it, you can see that I can.

B

I can ask for uh from the source called nft. I can ask for some data, but here, as you can see it's composed with another subgraph, because liquidity positions is actually coming from uniswap, so I can just play around with these two subgraphs and control the way that they are being merged.

B

So this is a super powerful feature under the hood. It's called schema stitching. We call it client-side composition, because we can very easily take two subgraphs and merge them together here locally. So this is just client-side composition. uh I want to show more, but I think I don't have a lot more.

D

B

D

Mentioned a bit of fetch.

B

Strategies which is the way that you can control and orchestrate calls across multiple indexers in distributed network.

B

We I mentioned a bit integrations and in the repository we have tons of examples how to use it with next ges, how to use it with just node.js or how to use it, as is without any client, and integrations with all the popular graphql flags and.

D

If you're using typescript.

B

You get support out of the box, we're using a concept called type document node, so we basically type um the actual uh operation and when you use the graphql query to execute you get a typed response, so everything is fully typed, so you're not going to have like any runtime issues um so yeah. This is 10 minutes on the graph client yeah.

A

B

A

Wrap it up here.

B

Yeah we're collecting.

A

B

So if you haven't.

D

B

Thank you, yeah.

A

Yeah just try it try it. Try it out reach out on discord. I see slim chances also asking questions. Maybe you can take these uh in the chat time while we move forward, but I can see an opportunity here where you can uh probably take some more time and uh leverage. You know what slim chance has been doing on um uh on on these uh questions or more of the developer focused uh calls and go deep into into this client with some of the uh some rough uh developers.

A

So, let's move forward with the uh agenda uh brandon. Do you want to take it away and introduce this research work that prism has been working on so that eugene can then also follow up.

D

Sure yeah, I'm just uh teaming this one up so I'll, make it quick. But uh about a year ago, before the network launched, uh there was an audit by open zeppelin, uh which is you know, part of our kind of you know due diligence in launching the protocol.

D

There were a couple uh items in there that were left outstanding uh going. You know beyond the protocol launch that open zeppelin, given that it was a technical audit, they were sort of unwilling to um say for sure that that these things were mitigated, because the mitigations were economic in nature and required economic assumptions rather than technical, uh technical assumptions and so about.

D

I don't know. Eight to nine months ago now uh the foundation uh issued a grant to the prison group team to take a look at some of these uh economic issues and see if we could get sort of the seal of approval on these two items.

D

So one of them uh was what's called delegation front running it's this idea that a delegator could come in try and uh delegate to an indexer right before they claim indexing rewards to try and front run the delegators that are already on it um and the other was this idea that they called poi spoofing, which was um this notion that an indexer might delegate to themselves collect indexing rewards get slashed, but that the index and rewards that they uh send to themselves via the delegation mechanism might exceed uh the slashed amount.

D

So you can kind of see how like it's, whether or not this is profitable is really about the economics of the system. So uh this turned into a multi-month uh research effort with prism and a lot of really great work came out of it and uh I guess I'll. Let youtube take it from here.

C

C

B

C

To be our uh first, uh this is our first time participating in the core, damn call, um so I guess to folks that who are not familiar with us. I just want to give a very quick introduction, so we are an economic, consulting firm that specializes on blockchain technology. We have uh extensive collaboration on both education, every research front, with a lot of the leading economic, academic and government uh institutions.

C

um I know that the term classical economics floats around uh the community quite a bit. um It could be. It could mean very different things to different people, so I would like to clarify um that the approach that we use and the tools that um we have are actually are actually way beyond what is naturally defined as classical economics, for example, um our two founding economists. They were both training harvard and then they have deep, deep expertise in designing contracts uh and market structures, and this is something that we take to to.

C

This is what we use to apply to work. We don't we do with the graph and beyond. um So this is the current thing that this is the current project thing that is working with the graph. uh We we combine experiences in both economic academic policy, research and also uh business and management decision making um before moving on to the the attack itself. um So um I guess to give a background of what we are doing here.

C

uh So when we started engaging with uh the graph, um we did um a step-by-step economic mapping of every transaction on the graph network, just to highlight, which ones are, might have economic significance, which are the open design, questions um that needs to be addressed or optimized. So we've it. It's been, I think, 9 10 months, it's very exciting, to see a lot of improvement happening in comparison to what we mapped back then, and then we are working on a few different fronts.

C

So this is the first effort that that is translating uh into a gip, and then we think we, we might have um a few others coming forth force coming depending on um how our collaboration works, with uh both the graph team and also some of the other teams in the ecosystem, like semiotic and the block science.

C

So um so, just to reiterate what the attack is really about and to to pinpoint uh what are um the key parameters that decide the profitability of the attack. So uh we have someone who's trying to basically get indexing, rewards for free uh and then in order to do that, this attacker would open an allocation and self-delegate um typically up to the maximal delegation ratio and they want they want. They would want to do that because they want to minimize um the the proportion of their capital.

C

That's subject uh to slashing, um of course, when they self-delegate they need, they still need to pay a delegation tax, but the under most scenarios. The the delegation tax is uh it's reasonable to expect that to be lower than uh the the slashing risks, uh and then this attacker will submit an invalid poi.

C

um This is something that they, this could just be something that they make up without actually doing the work of syncing, the subgraphs uh and then uh right after that they will claim the reward and divert the film so that uh the reward itself uh is also not subject to to with uh to withdraw or or slashing the only the only cost that they make. The only um like numerical cost that they might they might be worried about is the part of the the allocation that's subject to flashing.

C

uh So so to translate that into an objective or payoff function for the attacker, we have uh as a benchmark the honest uh indexers who are assumed to be financially motivated. We know a lot of folks um in the in the community are altruistic, but this is just to help us pin down what the economic environment is of for um attacker to potentially come in and then reap some reward, and then the the spoofer or the attacker.

C

Has some a priority incentive to to engage in this attack because uh to in order to produce a valid poi? You need to do some hard work and then the attacker might want to get the reward without incurring that cost. So we call that cost uh the operational cost.

C

This is something an honest: indexer will have to pay, whereas the attacker can avoid and then, for example, this could be the cost of running an ethereum archive node and also all of the associated software uh to to support indexing and, by the same time, um attacking is not for free, as we've mentioned that uh the honest indexes they don't need to worry about uh being slashed as long as everything works uh as they're intended, um but the the attacker uh faces its a probability of being found out, um and then this is the parameter that um we can manipulate and then um ricky and craig will talk more about that.

C

So I'm here just I'm just setting up the the analytic framework here, um so they face uh a slashing risk and then, as as I'll, show in a few later, slides that that would translate into a higher uh risk-adjusted cost of capital um and then thing for or the design problem for us is to figure out the optimal combination of uh policy parameters that makes uh such an attack um not only unprofitable but robustly unprofitable, while not introducing additional too much additional distortion to the network.

C

So this is the design question um and giving the time constraint.

C

I don't think I would want to explain uh the profit function and how we derive this uh in detail, but the rough idea is that um the attacker needs to decide how much to allocating total and then for that, for that sum they they additionally need to decide how much to uh self-stake, how much the stake uh as an index and how much to self-allocate itself to how much to self-delegate and that part would can help them to can show, can shield them from slashing and then there's also this fixed cost.

C

As long as the attacker wants to interact with the graph network, they still need to guess something: they still need to set up some infrastructure, and then that would be costly, and this cost is borne by both an honest or an honest indexer and an attacker.

C

In order to characterize um the condition under which um the attack is unprofitable, basically, we uh compare the problem the to the profit for, on the same side, on the same sub-graph, the same economic condition. um What um an individual indexer would get as an honest attacker versus what how much they will get uh as an uh as an attack as a as an attacker, and we want the profit for the honest indexer to be higher, um and then that gives us uh this inequality.

C

uh The key parameter here is this um risk and tax adjusted cost of capital r? So, for the honest, indexer, there's an opportunity cost if they're, locking up their capital for indexing they're, foregoing some other ways that they could also earn a return, and that's supposed to capture that. But on top of that we also have um a more complex, complicated term that captures the the trade-off for um the attacker between self-delegating and staking.

C

And to describe and to understand why we derive that, basically the once the assume that we fix the total allocation amount.

C

Then the attacker is solving a linear, optimization problem where, if they allocate their funds to a self-delegation, they pay um a delegation text of tau d, and if they um put funds to uh to stake to themselves, then there's um then they they have. They faced an expected cost of flashing, which is the probability of being detected times. The portion of the slashing portion and one of the the two parameters is, um I guess, harder for us to control. Where is uh the second one?

C

The slashing percentage is something that we can tune on the network, but we see these two things as complementary to each other, so we sort of just multiply them and then treat them as one object.

C

And then the decision here comes down to the comparison between slashing risk, uh sigma psi and the delegation tax tau. uh If slashing risk is really low, then of course the the attacker would want to put all of the capital and uh to self-stake and then, conversely, if flashing risk is high, then the attacker would want to put as much money into a self-delegation and that's when um they would want to push all the way until they hit the delegation, the max allegation ratio.

C

So these two slides they defined they defined how we derived this equation are, and then we've done some preliminary numerical analysis and then in order to fully characterize our our choices and then determine what's the best thing to recommend in a git um the the fantastic data science team at edge. I know they're doing a much broader parameter, sweep and the sensitivity, analysis and I'll refer to them on their work and the uh visualization of the results.

D

While they hop on I'll just note that these are papers that that usually just walk through they'll be published to the forums shortly, so you can walk through them in detail. Now that we're uh now that we're publishing this.

A

Let me know if you guys can uh share your screen or if you need some help, I can do it for you. If you just send me the right link.

A

Oh, you can't unmute. Okay, I see uh we see your screen, but there's no audio coming through as a fallback. Do we want ricky or brandon to take over while you try to maybe restart zoom correct.

D

I think it's just uh does it need to be given permissions on you.

A

Now you should be.

E

There we go. Can you hear me? uh Okay, now, I'm good yeah cool perfectly hey. uh My name is craig: I'm the data science lead at edge of node, and uh today I'm going to be presenting uh the work of my colleague, ricky escapon.

E

um He's done some awesome work following up on uh prism's model um and uh yeah, let's get into it um yeah. So uh I think ug gave a good explanation, but you know what we're trying to solve for here is um the attack identified in the open, zeppelin audit, where so, where an indexer minimizes their self-stake, which is the value at risk of slashing and maximizes self-delegation from another wallet and then spoofs pois such that they don't have to incur the cost that an honest indexer does in terms of index and sub-graphs serving queries, etc.

E

So the goal is to identify new protocol parameters that uh make this attack vector unprofitable under reasonable economic uh assumptions and um yeah, and uh do that in a minimally invest invasive way.

E

So these are the uh parameter, the main parameters that the prism's prism model defines and the first five are in our control. Those are protocol parameters that we can move around.

E

The last two are cost parameters for honest and dishonest indexers, and I think one of the one of the main findings from our analysis is that that this is like the primary factor that determines uh the attack: profitability, the the cost difference, obviously between the honest and dishonest indexers. So um so the values that you need to give in the protocol parameters to prevent against such an attack is, you know, extremely sensitive to the cost profile.

E

um So so that's the main thing we focused on so far um but yeah uh and in particular, we're focusing on the minimum curation signal, which also affects the uh the indexing rewards on a given subgraph.

E

So the pathway through which that impacts uh the the the uh profitability of this attack is that when you increase curation signal, you also increase the indexing rewards which incentivizes uh more competition on a subgraph from other indexers um that reduces the profitability of uh of an attacker.

E

But yeah like, like I said, the um the profitability is mainly determined by the difference. uh The difference in the cost profile of an honest and dis dishonest indexer, and we can kind of see this in the uh the equations that the prison group defined so on the left.

E

You have a no sufficient condition for no profit attack for no profitability, so, on the left hand, side of equation 17 there in the first line you have the the profit profit function for honest indexers, and you can see at the end there that both ci and c0 are subtracted.

E

So the honest indexer incurs both of those costs, whereas the dishonest indexer only incurs ci um and uh yeah.

E

One of the things you know we really focused on was reaching out to the community getting like uh leaning on their domain, knowledge of the cost functions for for indexers, and then also you know, what's the minimum uh required for for a poi spoofing, so um yeah so so like initially, these were defined as like having an indexing node versus the operational costs that uh that vary in the number of queries served, but that doesn't exactly match up to like how this attack would be operationalized and also you know what what the cost profile of an honest indexer is.

E

So I mean, if you just take the formula formula literally uh your the honest, indexer ci is actually the cost that both honest and dishonest indexers uh face uh to submit pois, collect indexing, rewards uh and c0 is the cost that only in on an honest indexer faces and this uh understanding it.

E

This way actually puts us in a pretty good car uh spot right now to prevent this attack, especially under a high gas cost regime, uh because both honest and dishonest index or space gas costs and uh at least qualitatively what we hear from indexers is that you know this is kind of like the dominant factor in determining how many subgraphs that they're going to index.

E

um But the hardware um you know hardware would allow for them to index many subgraphs and since since this is cost per per subgraph, the more sub graphs that uh that indexers are are serving on the same hardware. That brings down the the on a specific indexer cost um and such that, like the gas cost, is actually you know much larger.

E

um Obviously, that won't be the case uh in the long term, uh but but that does put us in a very good uh spot for preventing the attack now with without extreme values, uh for for a minimum curation signal yep, so the the initial um yeah, the initial uh estimates were much higher than than we found when we discussed with with indexers. um So you know it, it sounds like the minute.

E

You know the the most competitive pricing uh for cloud uh hardware uh for recommended setup or even higher than the recommended setup is around 600 a month in infra cost, and you could easily index 10 sub graphs on that, bringing us down to a cost of about 60 per month per subgraph and in reality you know there. There are people that index over 30 on on such a setup, 30 subgraphs, uh the lighter weight ones so um so yeah we can bring that cost down. Quite a bit uh for the honest indexers.

E

Yep so ricky did yeah. He created some awesome tools uh for us to do grid, search uh basically with different. You know moving around different parameters.

E

He also made some notebooks to replicate the formulas uh and you know in in latex as well, so that we could, you know, cross check in and replicate the analysis um and yeah. This is.

E

This is all very tentative, but uh when we produce a heat map with uh with the likelihood of being detect of spoofing being detected on the y-axis and the slash rate on the x-axis, if we look at the current 0.025 or two and a half percent slash rate, uh if we assume you know very conservatively that there's a 20 percent chance of of poi spoofing detection, which we think it's actually much higher than that, that gives us a minimum curation parameter of 290 grp to prevent against this attack and satisfy the zero profit condition, uh so that actually works out quite well yeah.

E

I think there's some old language on the last slide, but you know it's actually, you know quite good, I think um only 13.9 of sub graphs with more than 10 grt. So we have a lot that are like zero that were kind of like trials subgraphs, uh but those above 10grt only 39.9 of subgraphs would be affected uh that are currently on the network, um so we're going to do some sensitivity, analysis, robustness, checks uh and other stuff.

E

So this is all very tentative, uh but we'll produce a gip uh proposal uh for changing that parameter, um definitely interested in hearing the uh the community's feedback on that idea uh and other ideas that you might have some other things that we thought about, or just like anything that increases the cost of submitting a spoofed poi um or just any poi, such as, like minimum hardware requirements. You know like that, basically can't forego that cost.

E

If, uh if that, if the telemetry is broadcast- or you know, there's some sort of proof of work task that we're not seriously considering these, but this is just kind of like brainstorming other ways um that that would prevent against such an attack, um yeah and uh yeah, and also decreasing gas costs could actually have a positive effect. If it's going to bring down that cost of honest indexing.

E

You know such that you know people take the 200 of you, know gas cost per subgraph that we're spending opening and closing allocations, and they just use that, to you know, index more sub graphs on the same same hardware, uh that's going to bring down the honest index or cost per sub graph.

E

You know- uh and you know we'll actually could actually work in our favor there, um so yeah so we're gonna do some sensitivity, analysis for exogenous, economic factors, uh opportunity costs, uh interest rates, grt prices, gas costs, etc, um and then we'll we'll uh give a proposal uh and put that out soon. Thank you.

D

Thanks craig thanks uh thanks eugene yeah, so just to put a pin in that uh the minimum signal parameter that is actually a new parameter, so ariel has done the smart contract development for that already, that's already been audited, so you know, as craig mentioned. Next steps are really just to do.

D

The sensitivity analysis find the right value to set that parameter to, and- and you know essentially at that point we'd consider this- you know a really hardened, um really hardened analysis with respect to you know how viable that type of attack is the positive impact to the ecosystem. Is that finally lets us publish the original uh open, zeppelin audits because it allows us to disclose.

D

You know these two attacks that you know, we've been spending basically months doing this kind of analysis to try and you know really make sure that we've, uh you know dotted our uh dotted our eyes crossed our t's and that's a precursor to actually a lot of um d5 integrations with the graph. So uh having that audit out there will allow the graph to interact to interoperate and integrate with a lot more protocols in the dfi ecosystem.

D

So that's another positive outcome of us being able to uh to publish these uh uh these audits um cool pedro. Do you want me to just jump right into the next sections.

A

Yeah, I think so. I think we can we've wrapped up uh thanks for the context and motivation, so yeah we're, I think it's clear. So we have 15 minutes. You have two segments might as well yeah.

D

That's going to be.

A

You're leading it so.

D

Yeah, that's going to be tough, but I'll I'll do my best. Can you guys see my screen? Yeah we go cool, so I basically want to give the community an update on a bunch of gips that are coming through the forums I'm not going to have nearly enough time here to do them justice. So please check these out would be my my main call to action. The first bucket of gips are really focused on subgraph developer improvements um and the big one here is principal protected, bonding curves.

D

This was an idea proposed by a member of our community juan from graphops, and the motivation here is twofold: one: it's recognizing that within the curator role, there's actually two personas, there's like the financially motivated curator and the sub graph developer and the subgraph developer is really just trying to get utility out of the network they're not trying to get like financial upside in the curation mechanism. They don't need, like the volatility of like having their signal, you know potentially lose or gain value.

D

um Meanwhile, on the on the financially motivated curator side, we're also seeing mev style activity um in the subgraph deployment, bonding curves things like ap and things like run, runs on the bank, things like sandwich attacks, and so this uh aims to mitigate both of those sets of problems um and specifically on the mbb side. It's at the subgraph deployment level. So just to do a quick recap.

D

um Most people may not might not be aware of this, but the curation market in the graph actually uses a nested bonding curve architecture. So you have inner bonding curves, which are the subgraph deployment bonding curves. These tend to be short-lived because they only basically live. You know until the next subgraph upgrade, so it could be on the order of you know weeks, you know, or even days in some cases, um and then we have the outer bonding curve, which represents the sort of long-term identity of the subgraph right.

D

So, like the things that you browse in the graph explorer, these are like the stable subgraph identities, these bonding curves last a long time, but because of the frequency that with which these ones are replaced, they're really sensitive to like the entry and exit conditions of of bonding curves, and so that's part of what this this proposal aims to mitigate so principal protected, bonding curves.

D

What they do in a nutshell is that they preserve the incentives to be early when it comes to signaling, so you still use the bonding curve to decide how many shares to mint you still use the bank or formula so being early gets you more shares and more shares means more share of uh curation royalties. You know more query fees, however, when you unsignal, what you actually get back is your cost basis, so the amount that you initially put into the curve, plus any accumulated curation royalties. So what that effectively does?

D

Is it eliminates capital gains, but it also eliminates balance sheet risk when it comes to signaling on a sub graph?

D

um Another implication of this and that I'll get to, I think in the next slide, is that uh transferring shares in that bonding curve um shares become less fungible in the sense that, with each balance of shares, we're also tracking a cost basis that determines uh you know what balance you you get back when you unsignal.

D

um So yeah, so, as I mentioned, this is going to include cost basis tracking.

D

It requires a change to the payout logic uh in the subgraph deployment bonding curves, because we can no longer deposit directly into the resource of the curves, which is how the protocol works today and there's a lot of sort of things that are both enabled and required at the gns level, and all this stuff is laid out in the gip, but the gns basically needs to be cost basis aware uh it needs to be aware of the non-fungibility of those shares um it needs to pass through principal protection for the subgraph owner.

D

That's like a big you know. Benefit of this proposal is that now the subgraph owner, no longer, you know, has to risk their their uh capital. When using the network, um we can now remove some protections from the gns level that existed before, so things like upgrade protections um and slippage protections um just because uh the principal protected subgraph deployment curves are no longer uh susceptible to those kinds of uh attacks um and there's some things that are uniquely enabled by this proposal and that's kind of where these new these uh next two proposals dovetail.

D

So first one uh that's enabled by this is decaying curation tanks, and this is just a one slide summary. So this will be quick, but basically the motivation for the curation taxes that exist today is that indexers must be upgraded from frequent upgrades.

D

This is less of an issue in the high gas cost environment, but it you know it was. It will be when we moved to l2- and you know it was when we were first designing the network and the gas environment back then, but uh effectively. If, if a subgraph owner upgrades their subgraph too frequently they're essentially hurting indexers, because now indexers don't either um you know they don't get to earn rewards for.

D

You know a certain period of time after uh incurring the cost of syncing the subgraph, fully um or potentially opening an allocation right like for indexers, it's better. If an allocation can can last the full 28 days, otherwise, they're incurring you know, uh multiples on on the gas cost.

D

The downside of the curation tax is that it's a blunt instrument so, whether you upgrade frequently or infrequently, you still pay the same tax and it's charged on deposit. So it's basically charged when you signal into the curve, not when you unsignal, and that was because we didn't want to tax curation royalties.

D

We just wanted to tax the deposit.

D

The nice thing about the previous proposal is that it's actually decoupled the way that we track um on signaling and and the rewards that you get when you unsignal, and so now we actually have the capacity to tax on withdrawal from the bonding curve, uh which means that we can actually decrease that curation tax to zero uh over time. So as an example, it could be.

D

You know linearly, let's say over two months: you know, so you could say that if you've left the subgraph signaled for at least a month, then you uh you know, then you only pay half the curation tax would be how that works.

D

um This also uh involves new tracking uh and and another dimension of sort of non-fungibility in the curation shares. uh So the previous proposal introduces cost basis tracking. This proposal introduces cost-weighted um time basis uh tracking to to track the time signaled. So um it's not that shares are completely non-fungible now they're still erc 20 compliant. It's just that.

D

There's these additional metadata you could think of as being tracked, along with the balances that that you could interpret as like a degree of non-functionability, but this should reduce costs to subgraph developers, which has been a big. uh You know a big pain point in general of using the network, um so the last one, that's that's really enabled, uh uniquely by principal, protected curves, is signal renting.

D

So, as I mentioned, you know today signaling the protocol, because we we bundled together the subgraph owner and the financially motivated curators. It carries principal risk. It carries balance sheet risk um that makes it difficult to do things like um you know, rent signal to uh to sub-graph developers, because there would be a chance of losing the principle of that. You know amount of signal, um but renting is something that's actually.

D

You know quite valuable to the developer experience and the the ux of being a sub graph developer in the network, because today a sub graph developer when they come to the network. You know the first one of the first things they have to do is outlay. All this capital up front right.

D

They have to signal in a bonding curve and sometimes on the order of thousands of grt right all before they kind of receive any value in return from the network, that's really um unfamiliar to developers that are used to like more of a sas like billing experience where you're you're, you know, sort of charged monthly um and so signal renting is exactly that.

D

It's it's giving us the ability to say you know, pay x, amount of grt a month to rent y signal as a subgraph developer, subgraph owner, um and we can do that in a fully automated. You know fashion, where, like the liquidity, for you know, renting signal is, you know, is: is provisioned in like a liquidity pool in these um rental agreements are sort of automatically automatically issued.

D

So this is something that howard one of the new researchers, that uh edunode will actually be working on a gip for, and, as I said, this, this also depends highly on the gns exposing principal protected endpoints, so that these smart contracts that implement implement the signal renting can lock down uh what endpoints can be called to only the principal uh principal protected ones.

D

Okay, so the next bucket of gips and again I I know we're uh we're short on time, so I'll try to move through this five minutes. I have left these are index or economics improvements, um these all uh change the profitability of different index or behavioral profiles in in different ways that we think promotes uh more pro-social and um rewards active and honest indexers in in the network better. So the first bucket here is force closing scale allocations.

D

um Basically, you know stale allocations. uh You know by quote-unquote lazy whales, they they hurt and deter active indexers from joining a subgraph. uh This is because they're, basically not claiming indexing, rewards and they're, also preventing other active indexers from claiming indexing rewards. So, as an example, you know, the network issuance rate of uh grt for indexing awards is three percent. In 2021 we only had 2.7 issued, which uh amounts to about 30 million uh grt, that you know active indexers in the protocol didn't earn because of these kind of lazy whale profiles.

D

um We already have a mechanism today where delegators can force close and allocation.

D

um The gip, that's uh that sam from semiotic and ariel from metro node have been working on, is to allow anyone to force close an allocation, um and we expect that this will just divert more indexing, rewards to active indexers and, by extension, improve quality of service on subgraphs, because, as we've seen from uh some of the other analyses that that uh prism and symbiotic have done that more indexing rewards in the subgraph leads to better, uh more more distinct indexers and by extension, quality of service.

D

um And one note here is that we we're making an exception for so-called zero allocation so that an indexer that wants to like not collect indexing, rewards but still announce themselves through serving query fees. They can do so and they can let those those um allocations run run long next.

D

Next bucket, here is what we call subsidized furry settlement.

D

So the the challenge that we're trying to overcome here is that oftentimes there's not an incentive to settle query fees because the gas costs of settling query fees uh exceeds the the you know the micropayments that have accumulated in the state channel. um So that's why you know if you look at like the graph explorer today, you'll see a lot of epochs that have like zero query fees.

D

It's not that there were zero query fees, it's that uh is that it wasn't economically viable to to settle them, and so uh indexing rewards were always intended to sort of subsidize indexers, not just indexing, but like serving queries on a subgraph.

D

So the solution here is that basically, indexing rewards would be tied to the additional transactions required for collecting query fees and claiming rebates from the rebate pool and it basically um all other things being equal. It should make you know, indexers, indifferent between uh settling query fees and not selling query fees. You know put differently if positive. If query fees are positive, uh then they the incentive should be to settle them for any none.

D

uh You know for any amount, that's above zero, so this will allow us to see a lot more query fees going through the network.

D

It also going back to the analysis that craig did it. It decreases that difference between that c. I c c, o term. So, basically, uh it diminishes the delta between like an honest index or an attacking or lazy indexer.

D

um This will give us a more dynamic query market, but the effect is that it's also going to lead to higher fixed costs of indexing, a subgraph in general because now to collect indexing, rewards on the subgraph you're, not just submitting the pli but you're also submitting to collect and the claim uh transactions as part of that and the last one here is stake. Rebates. uh This gip is in progress still, so so keep an eye out for this in the forum. Soon, um this goes back to how the cobb douglas rebate uh formula works.

D

um Just to recap there, the cobb douglas rebates, like really essential to the work token model that the graph adopts um in equilibrium it incentivizes uh that indexers stake and serve query fees in equal proportion.

D

um So, if you serve, you know x percent of query fees, then you, the optimal behavior, is to stake x percent of the network state. um However, even though that's the long-term equilibrium, uh when the network is out of equilibrium, the current mechanism actually benefits active indexers at the expense of lazy, quote-unquote, lazy whales, uh which here I'm just defining as indexers that uh either serve zero query fees uh or far less query fees than than their share of stake in the network.

D

um And so the solution here is what I'm calling stake rebates because today the rebate mechanism only comprises query fee rebates um and actually I'll show you just the functional forms to have some background.

D

um So this is the rebate function today, where you basically have this kind of weighted geometric mean uh you know, based on the this left term, is the indexer's uh share of uh fees, and this is their share of stake, um and this is all the stake that or all the fees rather that have been collected into the rebate pool, um and you can see that the net rebates that people receive actually are sort of centered around zero.

D

So a bunch of indexers actually receive a positive net rebate in those mechanisms uh in the current mechanism, and all of those indexers happen to be ones that are sort of doing less work than their share of stake would imply and active indexers. The ones that are doing more work than their share of stake would entail. Are the ones that end up with negative rebates. We've heard from indexers that this dynamic is really harmful.

D

It's led to some indexers timing, their allocation closures to avoid closing their allocations in the same epoch as like a lazy whale, because the the effect is that pernicious.

D

What we're proposing moving to is a net rebate that both includes a query fee rebate component. So that's the term on the left here and then a stake rebate component, and so that's the term on the right here and basically, I you can kind of think of both of these.

D

Both of these components of the the formula is almost being symmetric to one another. So like an indexer that would have been positive under the query. Fee rebate will be negative under the stake rebate and vice versa, and what that effectively does? Is it caps the net rebates at zero? So there will be no indexers that are sort of have positive net rebates. The optimal behavior will still be to stake and serve queries in equal proportion. That's how you basically get to the zero net rebate.

D

Point which is optimal, but importantly, all active indexers are improved under this new mechanism. So, while lazy whales are incurring a new cost um and that's what actually gets rid of these, these sort of positive rebates to the right of the zero there, um uh some of that is distributed in this mechanism. You can think of it as going to active indexers, so indexers that are serving query fees. uh You know proportional amount of currencies in the protocol today will be made better off uh by this mechanism.

D

um There's a observable notebook that will also be linked in the gip. That kind of does a a numerical analysis here.

D

So if you want to see how these histograms were were generated, um so the next steps here, because these uh all three sort of impacting index or economics, we think it makes sense to evaluate them as a bundle.

D

um You know we think on net, like stake, rebates will benefit some indexers quite a bit while, while harming or adding costs to to sort of inactive- or you know, less active indexers um stale allocations is a net win again for active indexers, because it's going to you know, increase the amount of index and rewards going around, whereas subsidized query settlement will introduce a higher fixed cost for all indexers that are collecting indexing rewards on subgraphs.

D

So um we think there's some give and take here with respect to the you know the impact to indexers, we think on net. This will be positive for for active, indexers and positive. For you know the protocol as a whole um so stay tuned for some analysis as well that kind of uh kind of explores. You know the predicted effects of all three of these great and I don't think we actually have any time for q a but uh feel free to post. Those questions in the forum.

A

Yeah kai just asked one so kai might uh might be best to just yeah as one dimension just post it on the forum and you can analyze this thing.

A

D

A

Good thanks guys, thank you all for joining. uh This was great I'll, see you on the 28th of april. Again, that's the one we have scheduled if you want to follow up with the next ones. Again, just go on to the graph dot foundation. You'll see an ecosystem calendar link, just click on it, you'll get access to the calendar, subscribe and yeah so that you don't miss any of these upcoming ones.

A

Thanks all that's, it have a good day, bye.

A