The Graph Core Developers Call 30: Cross-Chain Subgraphs and Protocol Updates

[00:00:00][Music] so I wanted to give I think it's useful to give a small update on the things we've been brewing and things that have stem up from substreams and give it a little bit of a primer communicate better with the community there so uh I don't know if you've gotten read the report in the Forum there's a few things first of all I think you've seen the the merging from go ethereum they took out we had a collaboration with the guys from go ethereum and they brought up the technology that was the fire hose technology and bolted that into what they call the live Tracer so it was collaboration with them and us and it merged and it was shipped in gu 1.14 which means that the fire hose now will disseminate to all the GU derivatives we only need a small shim now so it can be maintained Upstream with greater ease so they really you know adopted or seen the value that the fire hose brought to people who needed indexing so that's cool it's been released last month we've shipped a few new things also in subgraph I don't know if you're aware but we've improved the performance of the subgraph engine on the server size that you won't see and so to reduce the the cost and increase the speed uh that's a few weeks ago by adding layers of caching between each substreams modules so if you have something that you know produces some data and something else comes and consumes it later it's not going to open the Big Blocks anymore it's going to consume just the output of their previously cached module which reduced dramatically you know the the CPU power needed the transfers and especially the bytes that were charged to the end user and so what we've done also is created what we call foundational modules for the different chains that mostly ethereum right now but we're rolling out for some other stuff Solana also has a one for no votes it purged of all the no votes cash so when you want to use that well you're not you're not opening Big Blocks and we're having some for log events on ethereum just reduces the block to log events if you want to only that you won't need to pay for opening Big Blocks just the log events and now the LA latest thing we've released this past week uh in a 1.6.0 release of substreams is what we call block indexes it's a new type of module the module you get in you get in whatever input modules they could be from logs or from large blocks and over there you basically output tags it's like tagging blocks like saying oh there's a Unis swap swap in here or it touches this contract address or there's an erc20 transfer from this address or to this address or whatever you just tag it they're strings and so you tag blocks after that's processed on the whole chain we have an index of what is in which blocks and you can consume that with this new tag called block filter there's a small language there with NS and ores that you can use to say I want to consume that module but only the blocks that have certain tags and in that case the substreams engine is able to skip huge chunks of of blocks processing because it reads only the indexes which are very tiny for like we pack them by thousand blocks so we read those and there's a roaring bit map there so database technology to allow us to know which blocks you know contain the tags and skip it if there's none so uh so uh from fire hose so this is what fire hose did already but in a general purpose manner anyone can write those modules and they can consume them it's basically what fire hose did with transforms but just on ethereum and it means that it it works across all chains now now graph node will leverage that by going through substreams and as as we're going more and more graph node consumes from substreams directly and this quarter streaming fast is working hard on having you know bringing substreams into the mappings of graph node the Ed and no had made some great work on bringing substreams so that it triggers mappers written in assembly script in version 035 I think and so we're working hard on that so that we're giving give more examples and um people are going to rather use substreams than directly the fire hose and they can compose a lot more stuff bring things together we're working on a lot of no code tools also so you can give it a spkg and craft it in some shapes and form and then without run writing rust code dump it into a subgraph and write your assembly scripts and in assembly script you have the first line there it receives in one big payload btes and there's a bite that decodes protuff and then you're all typed in assembly script and you can have complex object structures they're not events or or logs they don't need graph node to understand it's protuff right into the heart of your mapping so um yes shout out to Philipe for those things so that's good and um so we're we're been working and we're continuing to improve substreams dodev over there that's where we want to have the tools land and so what we've done there to get to no code I don't know if you try the substreams in it you can start scaffold the package we're basically making a conversational UI that will work both on the web and through the command line so we do substreams in it you're actually conversing with a server that's going to be able to generate the spkg and compile the rust code for you it's going to ask question maybe ask for an ABI fetch the ABI from time to time that's on in Solana but the framework will work on all chains and you can have a conversation that eventually many people can write so code generators that also build and so you download perhaps the source code package in the end a zip file you can unpack and compile yourself but then you need to install cargo and all the tools here and there buff and the protuff stuff but we avoid that if you can use this the the the generated code and you get the spkg directly you could upload it to the registry and then you could use that conversation that you can imagine on substreams in it on the web eventually a small chat box answers questions and then boom you get the spkg which you can stream directly or load into your subgraph so you don't need to write rusts okay that's a lot of new things that are coming that's not shipped yet one thing that is shipped I don't want to shut it too loud because it's still sort of beta and hidden it's gohost support in substreams so modules can now be written with tiny go and there's a new like I haven't publicized that I I just do that in a small context with you guys here so if you have feedback you want to try it you're curious you want to I don't know tell me you like it or you don't like it uh but it's deployed on all our endpoints you can ship those little tiny go things there's an example in the Forum post you can yeah I know I know so but I don't want to announce it too loud if it's um because I don't want to start right away until I see this traction so that's why it's a small to to start writing documentation you know that we have rough documentation then go documentation so it's small it's in a corner try it if you're really a goof fan and we'll see where that leads I'm not sure okay and is there anything else I wanted to to tell you yes you want important thing so we've been bringing to the network the traffic that we've been acing through acre you know we've been selling and trying to to figure out pricing models for substreams and fire hose and we bring brought that to the network so last week we've sent query fees for all the the customers that have processed fire hose and substream workload CL with us through the chain so it's the first time these services are getting onto the network and for that we're building what we're calling the payment Gateway beta sort of our thing I call it the the graph payment Gateway beta sort of thing we're building streaming fast and it's going to live and the goal there is to have some a Federated identity and a way for substreams dodev to consume what you're paying for on the payment Gateway and eventually I know some the The Guild guys are working on sub on U web hooks that they could have their web hooks. dev or whatever but they can still build on the payment Gateway sort of a sort of unified payment an authentication place but with a list of services that can pay outside index so we're we're testing that we've been testing that with PX and volume Gathering usage of people who are honoring those authentication tokens is based on jot so there's also information on on the Forum post yeah I think it's pretty cool I think it can solve a lot of the um so we're trying that we'll see where that leads uh but we're going to be pushing if you have ideas send them over happy I have one minute and a half for questions so you send them over here quickly so someone any go devs around yes I don't there's Mew when folks I didn't mention I didn't mention initially because Alex had to jump straight into but yeah we do have time for Q&A you have the chat open if you want to talk just let me know and I'll make sure you can unmute yourself for each topic we'll have a couple minutes here Pablo the trust assumption between the payment Gateway and the indexer right now is a quite High trust the goal of that place is to increase trust so that you know people can have a purchasing experience that is sort of flawless so there's definitely you know a trusting relationship we want the platform wants to increase trust for the end users but right now it's sent you know once a month it's a crappy thing we just started we sent a lumpsum after seeing the usage for for our indexer and then we're going to do that with PX and some other folks who want to par participate please message me but eventually we'll have you know more more uh payments that are sent uh more U let's say with scaler tap okay and stuff like that now there's still a trust assumption that the market is going to charge you know because it's sending usage metric and for substreams we have no choice really because we're billing bites that are red right the service reads bit from their storage that's what it's built to the end user and so there's a already for the end user a trust relationship with the service provider that they're they're trusting they're going to charge them the right amount and we're going to increase the estimators like and improve the estimators so we can know how much approxim is it going to cost we've been doing some work on that you don't have a front end but uh there's the back end if you're curious to know you know how many bites will that cost or on that Network for that chain segment um I don't know if that answers the question but there's a there's a a trust relationship there for the front end of the Gateway there PA does that answer the question yes thanks um let's my my suggestion would be let's spend some Cycles chatting about how we can reduce those trans assumptions for post MVP so right so you know one of the thing that can be exposed to the gate the payment Gateway there because it's really a distinction between the current Gateway which is two things right now at Edge and nodes it's a route Gateway and the payment Gateway so I want to detach the payment section and so to be able to have routing gateways and that in that case we're bringing down to the Assumption of know the Gateway yeah we're honoring traffic but all the indexers behind there it's the same verifiability protocol as what we have today and with Horizon these can all also be things that are you know negotiated with the end user and they can abide by some so we can lower the trust barriers there we can incorporate in it's just an experience for payment here and authorization so we can corporate a lot of things going forward I think down there so that's all the time I have for you guys if you want to follow up in private don't hesitate Discord or some some whatever okay cheers happy to be here with you sure thanks Alex thanks for taking the time and jumping in um I didn't mention initially but folks I highly recommend you also to check up our Forum there is a category where core Dev teams like streaming fast um that's the company Alex proj works for each team has been sharing some updates there so I highly encourage you to follow those as well everything is out in the open we do want your feedback um so yeah thanks Alex thanks for joining we'll continue that conversation happy very curious to see how this will evolve and now let me just go quickly through the agenda we're 15 minutes in so I think we still have time to go through everything we'll start with Maran Maran I see you coming online Marian is uh Business Development from Ed noes team we're going to go through the sunrise update we're going to start with a status update on the this big initiative I'm I'm sure most of you are well aware of by now and yeah we Maran will walk us through the current status review timelines and everything so as always we have time for Q&A after each topic so feel free to use the chat and if you want to talk just uh let me know in the chat and I'll unmute you so let's start with Marian yeah perfect we can see your screen welcome I think this is your first time here right yeah it is my first time so uh pleasure to meet you all uh I'm Mar Walter doing Partnerships for et node and I'm happy to give you an update on the overall view of Sunrise initiative all right yeah just a quick reminder uh this is all part of a of of the sunrise of decentralized data so with Sunray we uh got all hosted service chains uh that were supported on the hosted service now also supported by the decentralized network we we built the easy upgrade flow that coming in really handy now that we're seeing the upgrades did the new uh 100K free query plan U built the upgrade indexer and all of this was completed by March 26 and then we made the big Sunbeam announcement on April 11th uh starting the 60-day upgrade window which really is what we at ETA not on the BD side BD team are now really hustling on informing uh all of our users on the hosted service about the upgrade window and the need for them to upgrade from the hosted service to the decentralized network by June 12th which will complete the sunrise right I already mentioned uh zooming out there's a lot of work that that's going into the sunrise to make this a success from different parts of the team and of course from the overall ecosystem as well I've already mentioned that we streamlined billing um the ability or opportunity to pay either in GRT but also just with credit card was a feature that was very much requested by a lot of our users and we are really happy to have this ready uh for product for the sunrise this comes with uh the new transparent pricing of40 us per million series above the sorry sorry sorry sorry guys this is like um private things you know this is not scripted yeah someone is picking up a um whatever so and uh there's 100K monthly queries for free um the what comes really handy is the seamless upgrade flow uh that we've built super streamlined and uh We've also created like nuggets that uh show how easy it is to do the upgrade it it really takes from 1 minute to 5 minutes this is what I've seen so far and on the other side we've also improved the network uh n uh improvements on latency in the past five months which is also very important now uh that we move people to the to the decentralized network here I really got some numbers for you this is what what we in BD are working on day in day out so since the 60-day upgrade window was announced on April 12th we have crossed the 1,000 Mark of subgraphs that upgrade from the hosted service that was two days ago uh we are at almost 200 subgraphs that had more than 100K queries traffic on the hosted service and each day we have about one and a half uh million billable Network queries from upgraded subgraphs the next big thing is the sunrise upgrade program which we launched in May on May 2nd briefly what it is it's a six week campaign for individuals of the graph community and especially Community newcomers consisting of weekly missions where people can earn rewards for completing missions this will run until June 20th and there is a like high level view there is the web3 builders track and the have three Visionary track the Builder track is really targeted at technical people those that are running subgraphs or that just want to get into it this is all about upgrading subgraphs curating the network building queries and doing uh interesting things with the data and then on the Visionary track this is all about Community especially about education creating memes writing educational content but also creating uh poems music videos and so on and yeah we made the announcement there is uh 4 million GRT allocated to this program and the idea behind that just taking a step back is that um while we or I personally in my work often focus on the projects for them to upgrade uh this the the the sunrise is larger than that this is a unique opportunity to get uh interest and buy in from the whole community so this program is especially targeted at individuals so it's for the People by other people what we are aiming here is to create Buzz uh and especially for people those that are new to web three uh to have a chance to get into this because um the idea of it is that no matter where you are uh if you're just starting out this is really the ideal place to start because you're not doing it alone it's uh we are there's a whole community on Discord about this uh program where you can uh meet with other people create like work on the missions together and uh solving it together and earning rewards for that in the process so it's all about empowerment and uh it encourages the upgrading and using of the network uh for the devs but also for the wider audience to to use the network to learn the network to to really be on boarded to the decentralized network and yeah over the past week and a half two weeks by now we've seen a lot of Engagement there already just uh included some of the the memes that were created but if you check out on the uh social on social media you find a lot of uh assets being created by the Community which is great to see and one other very important thing is support uh the Ed and note team has a team of a head count of five people by now uh which are hustling and bustling in all the chats that we are in in all the communications with the different projects uh that we are reaching out to on the partnership side to help with anything uh any problems anything where they get stuck in the process of upgrading to the decentralized network and this has been Paramount I can almost not stress this enough how much value the support team is creating for the community so uh we really have seen them unblocking a lot of people that got stuck and uh they are increasing the experience for everyone in the network by 10x and if you have questions I can take them now see thanks Maran I don't see followup questions I'm not sure if you have if you mentioned how people can um get in touch if they need help you mentioned the for is it Discord the best venue for this thing yeah so basically you can you can reach out in Discord but also if we already have a telegram uh Channel open ping us there but uh Discord is a great place to start and uh any any questions will be picked up by our team we have constant screening on on all the different channels all right L your slides by the way thank you and thanks for taking the time and update us all I don't see followup questions in the chat so I assume we can proceed as always folks do reach out if you need help yeah thanks Maran all right then moving on with the agenda we're gonna have Paka from me node who's been working closely with Dylan from massari and um I think we'll go through the latest thinking on the development experience with cross chain subs and uh yes I let me just ensure bua are you sharing your screen oh you are not yet will in a second because I'm seeing a screen is it Marian's it's still mine yeah y yep y okay yeah uh to kill a little time um this is kind of a brief uh I play a brief DX research update as we kind of talk about some of the findings initial findings that uh I've kind of come to and a lot of them are thanks to Dylan from misari so shout out to him and uh I might just steal control all right so I'm going to try to monitor chat with apologies if I miss your comment um I can relate comments um if there come if people ask questions back up okay awesome cool um well cross chain subgraphs a brief DX research update and uh Dylan I think you're here so feel free to unmute and uh chime in as desired yeah but um to start I want to lay some context for kind of the the iies and uh techniques that I've seen uh in the wild um starting with kind of the more base level uh developer trying to deploy a subgraph on multiple chains I mean that that's not super base it's it's a fairly complicated problem but uh just to set the context we have some existing um workflows uh in our docs that's show people how to do this uh one of them involves using mustache templating um um and you can see we have configuration files for multiple chains different addresses and we're able to templae our subgraph uh manifest and then use yarn to magically prepare the Manifest we need and then deploy so that that's fine enough and sorry if you're not a developer it's going to be a little codyy today but um this is kind of one of the entry points into deploying on multiple chains unfortunately there's limitations to this as with the next method um you can see you can't really specify event handlers per chain overrides or anything like that you're really Mass kind of blast deploying things on different chains um the network. Json method is a newer kind of way to do this uh using uh a network Json file where you're able to put in this information and then we nicely uh prepare the relevant subgraph manifest using some yarn command and you can see here you just specify what network you're operating on and then you're able to really uh just deploy there but there's still some friction um again we're limited to the same kind of handlers uh you could write like a bash script to just like Loop through all the networks if you want but uh that's not ideal and so um now that we've briefly overviewed some of the more uh simple uh implementations of of cross-chain kind of subgraph deployment I want to Pivot to slightly more uh involved it's when you have mostly the same but not identical subgraph on each chain and so in the wild this is kind of what I'm seeing mostly um and by the wild I mean on GitHub just uh lurking through public repositories of actual subgraphs for projects uh and even just talking to people and hearing what they do and so uh in this most of the same but not identical subgraphs uh strategy I'm seeing two kind of sub uh strategies one is to have one subgraph per chain and then uh optional but uh common is a management layer to really streamline aspects of operating across multiple chains and uh some of these uh examples include graph client masari's subgraph CLI and even a competitor's product called gold mirror where they kind of wrap subgraph entities into some yl and you're able to Mush things across chains um and in this diagram you can kind of see uh we have this hypothetical Fu protocol uh there's an artifact or a subgraph per chain with the schema manifest in mappings and they can be slightly different uh just because there's differences on chains sometimes between smart contracts and then you'll notice here in this uh kind of orange circle this optional management layer but uh increasingly I'm seeing that it's not optional once you hit a certain scale of operation and so talking to teams like Masari and graph Builder Dow they have their own solutions for that um and then pivoting to the other kind of alternative way of doing things is having a single artifact for all chains and so now we have this other fictitious project called bar Swap and they have a cross-chain artifact that's comprised of schema mapping a manifest that is across all chains and then these optional overrides that let you kind of specify things on a per chain basis and the most prominent kind of solution in this space is Ponder and so uh now kind of kicking it over a little bit to Dylan uh I just wanted to highlight one of the quotes that I took from a recent meeting we had discussing cross chain subgraphs and it's um allowing one subgraph to pull data from multiple networks seems like too much complexity and could cause issues and make the dev experience not so good and so I'm curious uh if there's any feedback from the crowd uh either to kind of support or go against that sentiment from Dylan and the next slide that I'll kind of quickly uh tease kind of gets at this mental model that I'm starting to formulate about the maybe likelihood of adoption or uh interest in some kind of solution a single artifact solution uh from different team types and so maybe I'll uh I'll let this just sit over here as we maybe uh open it up for a broader discussion um and I can also quickly narrate my hypothesized uh adoption graph uh I think that teams like misari and uh large dexes yeah I'll share the link to the slides um I think that teams that have a lot of investment already into custom management layers uh there's a ton of friction or high switching costs to go to something new um especially if they're already dealing with quote unquote Legacy subgraphs um or projects that have multiple subgraph artifacts uh because they've just been around um same thing I think that a dow of Enthusiast Builders I graph Builder Dow um they also have high switching costs but they're more likely to switch or try this out because they're enthusiasts and really love building for the sake of building to an extent um kind of pivoting quickly to other projects something like uh a large existing project with subgraphs across chains uh I imagine they're not going to be super keen on Switching uh unless there's some kind of white glove migration experience that helps them and there's some kind of maybe more uh handholding to facilitate the switch and then finally new teams are existing teams to that are new to cross chain I think are the most likely to try this kind of solution um assuming we go with like a one artifact solution but I just wanted to uh quickly share how I'm kind of modeling uh teams I see and I would love to get inputs from you all that either confirm or refute how I'm thinking about things seeing the chat is a little quiet but I would love feedback there or unmuting or even from Dylan if you want any be chime in on your perspective if I'm misrepresenting you or if this is kind of accurate sure um I think in terms of like we we probably fall in like the high switching cost category as well um like our solution essentially we we have kind of some brief context we have an mpm package that we um made inhouse and it's essentially like a wrapper over the graph client and it allows us to like pretty easily deploy subgraphs based on like configurations and we can even do like like a large deployment at once so I could like deploy all of a in one command and it would deploy like 20 sub crafts which is pretty nice for us um so that's kind of our our solution and I mean it's been working for us but it's very like it's very specific to our repository um yeah is kind of the challenge with that um but definitely would incur like high switching costs no and even uh thank you for that context still in but even um the way you're talking about oh it's one command is deploying 20 subgraphs I don't know that NE neily all teams are at that scale and so a solution that works for you might not work for like the the hackathon team and unless we're at the point where people are deploying to that many chains day one and I don't know um and I could see where a single artifact could get messy if there's 20 or 100 chains that you're working on um so yeah what what do you all think I'm curious also what's your perspective on the future of chain um I'm seeing Matthew saying the world of rollup chains one chain per app yeah if we're that's a lot of subgraphs D's like excellent um I see a comment back from from ped I remember making two subs one for each chain on the consumer side front end the worst part was rating data from two different sources in a frictionless way I this might be related to composition as well maybe on totally I mean yeah it's still like client side composition maybe client could help you out but it's it's not the best way yeah that's a challenge and I guess I failed to highlight that uh these management layer solutions they vary in kind of the the feature set um like misari subgraph CLI I believe it's both Consolidated querying and deployment so it's quality of life for both of those like streamlining that I think right Dylan or um our our solution is only on the deployment side so we have like our Inus layer essentially kind of Loops through the subgraphs um and makes queries on from like a a template file of or a Json file that contains like the metadata about subgraphs that we have okay I think cool it would incur less it would incur less switching costs if there was like a more of like a roll up of you have AA V3 on all I guess if you were to combine the query layer more tightly that would incur less switching costs for us than the deployment layer okay yeah and uh Pedro is commenting about graph client and that's another thing I I pose to deal into and um I think that that might also be an interesting area of future exploration in this and maybe uh or maybe not but uh enhancing the deployment uh tooling of client just because it is already doing some of the query side uh streamlining graph cant lets you take uh subgraphs across different chains and kind of Consolidated into a single endpoint to query against so that's nice for uh certain teams but again uh may not work when there's 20 chains or 100 uh and by work I me just be streamlined or efficient for your needs um yeah uh next steps um kind of Dylan alluded to this that the deploy logic in misari subgraph CLI is pretty customized to their repository um like their needs and building subgraphs but there's some really useful Concepts there that might benefit the community at large and so um moving forward uh definitely can have more discussions on how we could generalize some of those uh tools for broader adoption across subcraft developers and then uh more feedback sessions with people like Dylan and others from the community and uh that's all I really have but are there any questions and thanks awesome thanks Paka and to our YouTube audience you not you can still Rel relay your feedback using our Discord this will probably be another Forum soon as well so you can use that feedback really is important for us so yeah don't be afraid to reach out all right and thank you Paka and Dylan for what Miss through this appreciate itk all right and ped I'm sharing yep uh we're sharing the I I'll also share the links in the show notes for those that are watching us on YouTube the link to graph cly and how you can try so graph composition on the client side that may help you with the data wrangling on the client side as P mentioned yeah yeah and we also have the slides thanks for sharing that P up uh yes Naran you can take over the meeting to respond uh let me you you're free to to speak let's uh no no actually I wanted you to take over the meeting because uh yeah it seems like uh I'm the host now I just wanted to hand it over oh that's fine that's totally fine let me H you're the co-host so ohol there you go it's totally fine all right awesome let's move forward we have Pablo from Eder node um Pablo has been on this call many times before I always appreciate Pao taking the time to come here and update all you might have seen a proposal on the Forum related to indexing fees this is a old GP or a draft um since then team has been hard at work um fine tuning and thinking of an MVP and so I believe uh another GP update or another draft will soon be available on the Forum but we figured we should take this call to share with you what our latest thinking is as well um so again Pablo thank you so much I see you coming online so you should be able to speak and present awesome thanks Pedro and hi everyone um it's always good to be here I'm GNA share my screen um I don't have a presentation but I do want to walk through some of the things that we have so far um yeah and hopefully we will have a JP for this relatively soon I hope um but yeah as P said we want to have give give a glimpse of what what we've been working on what we have in mind um and eventually when it hits the Forum we'll have some discussions as usual but we'll also be discussing this in index office hours and other venues um so in case you're not familiar with the old indexing pce proposal the original Gap that was Gap 58 it its approach was uh quite different from what we're thinking right now first it was designed as something that would Place duration and replace its uh bonding curves um it is still in a way something that that we've built that that we building to address some of the challenges with curation some of the things that don't quite work um as as we need them to um but it had a few things where it it's different from what we're thinking right now so um to summarize a little bit um the idea is curation is a bit complicated especially like for subgraph developers it's not a very intuitive thing and it has a few problems and and how it makes it hard for an indexer to predict how much they'll get for a specific subgraphs and it makes it hard for for a developer or someone interested in in a subgraph being index to know how um what what qos they get uh for however amount of GRT they put in um so to solve this the the proposed solution um was to have this indexing Fe scenario where um basically in the original proposal it was a consumer choosing an indexer and agreeing with that indexer for uh price to index a subgraph um this um was meant to have these desata that is you know giving indexers a good certainty of the revenue and profitability having low volatility having a quite good certainty on on the qos and making it hopefully as Cil resistant as possible um efficient and simple um this actually sparked quite an interesting uh discussion in the forums uh like it's it's probably one of the longest threats in the Forum um there were some concerns that were raised um in part part of the problem was this uh proposal was relying on on a very early idea of what we eventually called graph Horizon um where it had more of a a specific approach to changing issuance and and changing indexing Rewards since then the graph Horizon proposal has evolved to what you may have seen in the forums as well uh so we do have a a proposal out right now that has been discussed we we have uh the council has expressed support to for the Brownfield version of this and it doesn't include any changes to issuance um it's mostly building a sort of framework of of staking of a staking mechanism for uh the pro protocol to allow permissionless deployment of data services um So within that graph Horizon the original graph Horizon proposal there was this change to issuance this uh there was not a lot of clarity to this so it made sense that like people were concerned like what's coming up uh what are we replacing duration with um and what happens with rewards and if the only source of uh funding for for indexers is this new indexing feace mechanism how like how do we make it sustainable for for the large base of indexes that we have right now especially during during the bootst base um so since then so that that was one of the concerns the other concern was um some indexers in particular were were worried that that like this idea of consumers like and subgraph developers choosing the indexers kind of breaks a lot of the the way the network is designed um and I I actually agree with this like the um the design of the network is is a network model where the network itself sort of sort of abstracts the service providers the indexers from the consumer um and and that is something we want to preserve because it also helps with decentralization it makes it harder for a single provider to ACR Network effects instead of the network itself acre Network effects um so the way we're thinking about this now uh is different from that original mechanism in that it's much more reliant on automated selection um that is kind of the thing that we're building the thing that we think will provide the best quality of service for consumers um the and uh the best you know overall uh value salign designed for the network um so and at the same time like we removed this idea of you know replacing issuance we are working on a very comprehensive um proposal to change the way issuance and indexing rewards work U but that's going to be a separate thing that we're going to present and and it'll address all of these concerns from indexers and from from other members of the community so we're we're still working on that so that's going to be for a future cep go but I think it's worth mentioning that yes we do want to change indexing rewards and and change the way we do issurance in general um but our proposal will definitely consider a lot of these concerns like um yeah ensuring indexer uh indexers have a sustainable um income and uh like ensuring the decentralization of the network and hopefully addressing a few other things as well um cool but um so with these changes um the indexing fees mechanism that we want to build um is um from the consumer's point of view actually a lot simpler in that we're kind of separating the product from the protocol I don't know if some folks have heard of the web 3 mullet where it's kind of web two in the front and web three in the back um and I think we're kind of looking for an approach like this where the developer when they're interacting with a product like the soft Studio they just select some sort of plan uh some form of uh payment approach for um how much they'll get charged for the subgraphs we're still kind of figuring out if this is a pay as you go thing if it's like a fixed plan or or whatever but then behind the scenes the these uh this goes to a Gateway instance uh that gets that subgraph into a list of subgraphs to uh to index and and to pay for indexing um and it uses an indexing what we call an IA so an indexing index inding selection algorithm to differentiate it from the query indexing selection indexer selection algorithm I know this is a mle so if we might look for a different name for that um the Gateway will uh request that um will request the chosen indexer uh for uh indexing that subgraph it sends a signed voucher saying you know I want you to index it subgraph this is the price um because the the indexer will previously post what is their price um and the indexer will then automatically create an indexing uh like an allocation for the sub graph and start indexing uh eventually when they post a POI they get a voucher from the Gateway saying okay here's your payments and they collect it just like they correct cor pce now this is MVP this is like how we can do this in the simplest possible way without even modifying the smart contracts um and and we think we can get this uh to at least a demo relatively soon and hopefully to production also relatively soon uh so that people can start using it um obviously obviously we're going to need uh indexers to support this so we will be chatting with indexers in the uh like yeah in the future uh hopefully like index office hours and yeah we'll probably have a few conversations about you know getting you set up with this uh new thing and also getting your feedback on um the experience of setting this up an index it as well because we obviously want this to work for you um and we need to understand how we're going to do that pricing in a way that works for you as well um so this is the MVP but this MVP has obviously a lot of trust assumptions when the index are gets the voucher from the gayway saying you know I want you to Index this they are in a way trusting the gayway uh to pay them once they've actually posted the POI for that um and we want to build the network in in the most trustless or minimal trust way possible um so what's coming right after that and and we're kind of working on the on the smart contracts for that soon um is an extension of that where once the indexer gets the voucher um and and they start indexing that subgraph they posst that voucher on chain into a subgraph service contract that will be part of this upcoming graph for Ison big upgrade um well probably a second iteration of that um and a after that they can um as long as the the payer the Gateway has funds on on the top well the scalar escro they can automatically collect whenever they post a POI that payment and there's no way the payer can get away from doing that payment as long as they have funds in the escrow obviously you can cancel the agreement at some point but the indexer is always guaranteed to get a payment up to the point where they've indexed so far um so we think this is kind of the the soundest possible way to implement this the more trustless approach um but starting with the MVP allows us to um try this out with real subgraphs with real indexers um out in the world and see how everything else besides the smart contracts um Works um out in the field um there's a lot of things to tweak like how does the pricing work um how how do we get a good qos how do we design that indexer selection algorithm that we're working on right now so that it balances choosing the the indexes that give you good qos for a good price and also um in a decentralized way in that like you don't want to send all of the contracts to the same all the agreements to the same indexers partly because this is not great for qos but also this is not great for Economic Security because you know every time an indexer gets more business for the same stake their Economic Security rating in a way goes down uh so the ISA will consider all these things and and what I I would expect is we're going to see not a round robin but but something where like every indexer that has a decent qos a competitive price um and uh kind of they're they're doing things well they'll get a chance at being selected for these algorithms but at the same time um this um kind of provides the uh the kind of setting for indexers to actually start competing for this and the best indexers will get uh more business in the form of indexing fees um but it's still in a way where like it's open for a big number of indexers to be able to get this rather than kind of sending everything to a single one um and also I mean just as a reminder this works in parallel to the existing indexing rewards mechanism uh so there will still be curation um just not done by subgraph developers now hopefully uh but like we can have pure curators that or it might be the same indexs uh adding GRT for specific subgraphs and and that can act as a as a boost for um the income from indexing fece um so yeah we are hoping that this addresses the main uh concerns uh that were raised before um we we we're quite aligned I think in in trying to ensure that uh indexing fees are built in a way that is sustainable for indexers while at the same time providing the best experience for subra developers and consumers um and yeah as usual we're going to love hearing your feedback in the forums I think that's I got yeah awesome just relaying message from Vince have to chooses the best performing get more business power pres uh yeah maybe one one caveat to this is actually it like currently it's a gayway choosing um gayway is a permissionless role if someone doesn't want to trust the Gateway uh like to to do these arrangements for them they can set up like their own Gateway instance so to speak so like if you were very parano you like if you want to do the more trustless setup and and just run this yourself you can um but I think we're building it in a way that will make it very clear that the best way of choosing whether it's through someone else's Gateway or your own is with this kind of Isa like the first things we're saying is like if you have I don't know 100 indexers and they all have a 97% success rate then actually if you choose like two or three of them um that's the best way you can get like three or four NES success rate or uptime um like and in general of the analysis that we're doing so far seems to show like actually decentral decentralization is is good for qos which is I think was one hypothesis we've always had and it's nice to see that at least in the pre preliminary analysis um it's it's good that the network chooses and it's good to choose following the Network's kind of proposed Isa very nice super exciting check in the chat don't see questions so yeah as PA mentioned more details will be on the Forum soon also deiminated through ex office hours in the following weeks and months yeah it's ni to progress and we're heading we're getting [Music] there all right I don't see more questions we have three minutes left if that's all I think you can take those three minutes back this will be on YouTube as always meeting notes will be on the Forum as well yeah as always do reach out to all of those venues if you have some feedback all right let's wrap it up thanks y' I'll see you in a month thanks for all thanks thank you all for joining thanks for all the speakers for taking the time to present all of these nice updates and yeah have a good day y'all see you thanks see cheers thank you [Music]