Graph Protocol Core Devs, 21 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: The Graph | Core Devs Call #19

Description

The Graph is an indexing protocol for querying networks like Ethereum and IPFS. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

Timestamps:
00:00 Intro
05:03 Billing 2.0
06:28 Layer 2 Scaling Updates 30:30
44:00 Developer Experience with Substreams

Link to external sources mentioned in the call:
- Billing 2.0: https://thegraph.com/docs/en/billing/
-GIP-0046: Migration Helpers: https://forum.thegraph.com/t/gip-0046-l2-migration-helpers/4023
- GIP-0043: Indexing Rewards on Arbitrum One: https://forum.thegraph.com/t/gip-0043-activate-indexing-rewards-in-the-graph-network-on-arbitrum-one/3999
- Substream Documentation: http://substreams.streamingfast.io/

Follow The Graph on social media
Twitter: https://twitter.com/graphprotocol
Instagram: https://instagram.com/graphprotocol
LinkedIn: https://www.linkedin.com/company/thegraph/
GitHub: https://github.com/graphprotocol
Website: https://thegraph.com

A

Hi everyone welcome back to our 19th core devs call as always a little bit of context. The purpose of these calls are for core contributors to present what they've been working dating the community on. What's coming and brainstorm with core working groups, task forces and community members like you, so it's so much uh happening um yeah. It's also hard to fit into a one-hour slot and have lengthy discussions.

A

So, while there's time for Q a after each topic, you're highly encouraged to continue the conversations over slack and sorry over forums and Discord and GitHub, and everything is out there in the open. So we do want to hear from your feedback from from you and your feedback and questions you might you might.

A

You might have so I'll paste in the chat and the video description, also the links to the graphs ecosystem calendar so that you can be subscribed to future calls and there's also I'll, also post a link to a new Forum category where core developers are sharing their updates as well on a monthly basis. So that's highly I highly recommend you um yeah going back to the forums and seeing all of those okay. For today we have uh four topics in the on the agenda, starting with building 2.0 and Studio updates.

A

Let me just quickly take a look at Jen.

B

A

um Yeah thanks thanks BK the beeping sound, yes, they're, they're back. Thank you! So yeah building in studio we've been talking about our plans to augment the user experience, especially for developers and consumers. Bk from agent node has already walked us through some of the upcoming changes, I believe a month or two months ago, yeah a month ago, and so um there's been great progress and today we'll take some time to hear what uh is coming on this new building system.

A

That's bringing much requested features like Fiat payments, predictable pricing and just the better and simplified overall user experience. Really um then somewhat related will VK will also talk about, um but more focused on the indexers and developers. We'll also share, what's been discussed in the protocol working group around potential improvements to the indexing rewards and curation system internally, I think we're calling it direct indexer payments right and the official gips will soon be out as well, we'll be sharing those in our GitHub repo, but also in the Forum.

A

So you can all go back and and give us some feedback on then um the Out tool, migration roadmap- there's also we've also been covering this larger initiative during this.

A

During these last calls- um and it's been- there's been a lot of progress here as well, uh and you might have seen in in the Forum a recent threat around my migration helpers that started in indexers and delegators to facilitate my migrating stake to orbital or the L2, and so we'll use today's call to know more a little bit about these tools what's coming to the studio, but also what the recent thinking is on the protocol issuance. That's also that will also be my my my migrating to L2 or arbitrum and yeah.

A

That's, basically, the indexing rewards that was slowly enabled on our arbit room, that which is which is where will the protocol lived and so shifting gears a little bit substreams? This is all about building subgraphs following the well-known and beloved subgraph development experience, while leveraging substreams sort of as a separate ETL pipeline or framework which allows for more performant indexing speeds, and so it's pretty cool Masari has also been building a few there's.

A

A couple of examples out there that we'll be sharing here as well and I believe we'll have Robin from asari doing a demo here and so yeah we'll see today what it looks like what this, what what what that stack looks like the roadmap there to bring it to the network and also the indexing performance gains. We are already seeing um so yeah. That's all for today's agenda again after each topic, we'll give everyone some time to go over to do some q, a and so yeah welcome everyone. Let's get started BK you're up.

A

You should be able to share your screen now.

C

And I'll hand over the uh the admin uh letting everybody into you for now, yep thank.

A

You and we're seeing your screen.

C

Great excellent, it's perfect, so, okay, so I'll be reading a little bit so I apologize for that in advance. But uh overall it should take um hopefully about 10 to 15 minutes um and we'll leave some questions at the end for uh any kind of feedback or questions you guys have so uh yeah, so uh generally I'm a product manager, uh my name is BK or Brandon: Kramer I'm, a product manager uh at Edge, node and I'm, mostly focused on pricing and payments.

C

At the moment, uh I'll spend around 10-15 minutes talking about this and then we'll leave some um time for questions and comment at the end.

C

uh So, generally, today, the graphic building experience leaves a little bit to be desired uh if you're a sub graph developer or consumer uh you'll log into sub graph studio, uh which is uh uh here at the top uh you'll click on billing and or connect your wallet and then you'll need to add grp here in the middle, uh a pane will open up, as you see in the right hand, side and let's go through a few steps.

C

uh First you'll have to acquire grd and that can be somewhat of a time consuming process, especially if you use a centralized exchange uh like like I have to in in New York. uh It can be like seven to ten days. You have to wait um to acquire GRT and I'll be allowed to transfer that out, depending on how much you have um once this is completed.

C

uh You'll have the additional Obstacle of needing to know how much DRT you'll need to deposit and how that translates the queries each month um and then, ultimately, after you've figured all of that out, you'll be able to allow and add GRT to pay your billing balance. So obviously this isn't the ideal experience, um but in recent months it's gotten a little bit better. uh That said, there's still some room for improvement and that's what I'll be talking about today.

C

um Okay, so building 1.0 is, uh as many of you may know, it's pretty flexible kind of like pay as you go: Billing, System or payment system, um but right now, you're only allowed to pay in one current.

C

The involves a lot of friction as I just pointed out, I'm waiting a little too much trust and ultimately makes it a little difficult for a consumer to be able to predict how much a subgraph is going to cost on a monthly basis, and that's really what we're hoping to be able to address uh with some of the upgrades that you'll that'll be talking about today.

C

uh Moreover, there's a lot of complications on the back end to be able to run a building system, um it's a kind of a cumbersome infrastructure, uh quite time consuming to set up and and also operate, uh So based on the feedback that we've gotten from users over the past several months, uh we're already in the process of Shifting to a kind of a new Billing System uh that complements the one that we already have set in place.

C

So billing 2.0 uh is essentially we aim to we're aiming to offer a flex the flexibility of pay, as you go alongside new monthly subscription plans um that help users lock in at the number of queries that have picked right initially, we'll be able to offer these subscriptions to a smaller group of beta testers.

C

With the goal of graduating to a fully integrated billing experience that has kind of building 1.0 as the pay as you go, and billing 2.0 with subscriptions so I'll State a kind of in advance here that uh what you're seeing in your screen and the specifics of these plans may change, but this is kind of a general outline of what we're hoping to be able to uh to offer in the coming.

C

um You know coming period here so uh as you enter kind of the subscriptions or payment process, what we're hoping to do is first, a consumer or subgraph developer. That's um going to pay uh is looking to first pick a plan. uh Well, the specific specifics of these plans might change what we're hoping for is around three to four plans to be able to choose from. In the first example. On the left hand side you see a consumer plan uh where uh users are allowed to kind of lock in the set number queries.

C

Let's just say a million queries for 100 usbp, and these numbers are uh not what are necessarily what a pricing plan would be just an example in this particular case um and for subgraph developers uh that don't want to deal with publishing, curation or upgrades they'll.

C

Be this option here in the middle that the developer bundle, which kind of abstracts a lot of those complexities away, while still being able to lock in the set number of queries and really the main goal of this to be able to say, okay, I'm going to pay 100 USD um this month be able to lock in that that amount and then be able to go forward throughout the month. Knowing that you'll have the subscription set in place. Yes, um on the far right hand, side, this is the pay as you go system.

C

That is much like what we have today to essentially allow users to add in a second a set amount to deposit at any point they want to and just be able to pay for the amount of queries that they're using as time goes on.

C

The next phase in this process would be to estimate the number of queries that a user might want. So in this case, they'd be able to enter our UI and then be able to say I want a million queries uh choose a slider that allows you to get to that one million queries and then it would give you an estimate of how much that would cost.

C

Alternatively, if you just want to, if you know that you only want to pay 100 usdc or something like that, you can kind of choose this option and it'll tell you how many queries you'll get without that amount. But overall, this kind of take away the the element of getting or having to already have the experience of knowing how many queries you have. um This will be the case or there'll be a a feature offered in this new billing system.

C

That allows you to kind of estimate that and if you're not familiar or don't have that previous experience on the network, you'll be able to touch base with a solution scheme or a number of other community members to be able to help you with some of those estimates as well and the last aspects here or the last phase. Here uh we have um the different ways that you can choose to pay.

C

The graphs existing Billing System only accepts grp at the moment, and for this uh for those interested I recommend that you keep your eyes peeled a little bit later today or um in the coming days uh for an announcement about about this particular in particular, there can be an announcement about uh via payments um that we're really excited um to release. So uh please keep your eyes peeled on that.

C

um The the forthcoming subscription system, however, um which is likely to come a little bit later, uh is, uh is looking to open up stable coins, especially usdc as a payment option. So this would mean that users would have the ability to paint and Fiat pay in usdc or Japan grp, depending on the Billing System, um and this really optimizes kind of different onboarding flows on thumb, web 2 or up to the more experience web 3 developer.

C

um So again, lots of options to kind of choose from your plan um to be able to estimate how much you're going to be um charged or paying on a monthly basis, as well as different options for choosing how to engage in those payments so overall a much more expanded, Billing System, but hopefully uh still streamlined and um pretty straightforward for users to understand. uh So we can look at it like this.

C

um Ultimately, what we want to be able to offer a number of these advantages again, uh keep the flexible pay as you go, uh but also offer monthly subscriptions, have a built-in cost and query estimations a streamlined payment flow. That is, uh you know not so complicated, not for confusing, but really the straightforward one. Two three you make these decisions, you're able to choose from those options and then move forward, uh and ultimately our hope is to be able to offer something. That's much more uh automated and recurring um mainly.

C

We want to be able to offer these automated recurring payments so that users can set up their plans.

C

um You know paying the currency that they want and then that that's on a recurring payment, much like the credit card systems that exist today in web 2 only without the the burden of having to give somebody your credit card to store and worry about that uh all the downsides of that.

C

um So ultimately, this is kind of where we're headed. The added Advantage here is that the billing 2.0 system that we're they're, closing and working on right now also has some added Advantage for those that are running the billing systems. It's a much more streamlined, backend and and uh allow the operation to be somewhat streamlined or quicker as well.

C

So uh thinking about this in kind of a big picture, the Milestones that we're headed for the other thing that I'm I'm most excited about is to eventually get to the point where at the very bottom here you see that set it and forget it type billing experience and what I mean by this is that a consumer essentially should be able to set up the plan.

C

That's right for them um from from the options or perhaps even more options uh that are available um to be able to set that up turn on recurring payments, much like the credit card systems in web 2 uh and then largely set it and forget, and not have to think about that, just automatically pay them a monthly basis or a periodic basis, um so that you can think about your adapt or developing your project rather than the payment system um and and what you need to do there in terms of manual transactions, and things like that.

C

So in order to get to that, uh there are a few milestones. We have to pick off along the way, so the first big one that you should keep your eyes up for are Fiat payments um and again this should be a fairly imminent announcement. Keep your eyes up for that. uh The second thing that we looked do is set up subscriptions um and I mentioned earlier.

C

uh This is something we're already in the process of working on edge and node hopes to drop in MVP, uh that that will be open to a group of beta testers to be able to make sure that the feature or um that subscriptions are kind of up to par, so that we're offering a really good experience um and if and ultimately the the benefit of this or that we can offer users a much more uh predictable experience.

C

uh We can also have the ability to pay enabled, as well as as well as Fiat, and it really streamens the billing back in for those that are operating and Building Systems, which I think is an added advantage that um not necessarily everybody will get to see uh the next step or uh kind of one of the next death uh I'll say um necessarily committing to the particular order here.

C

But um one of the next steps in the process is then to think about managed, subgraph payment plans, um and this is along the lines of a developer bundle that I mentioned earlier, where users that are a little bit more inexperienced to web3 can be able to have a sub graph that they pay for they pay for a plan and that uh the The Entity, that's offering that particular plan would be able to publish curate and upgrade uh for those subgraph developers or consumers.

C

um In that case, it kind of streamlined. The onboarding process makes it much easier to know what you're going to get when you sign up and be able to kind of automate that process as well.

C

So if you want to focus just your project rather than the the subgraph, um you can do that uh after that, we're looking to move towards Auto, recruiting payments, and this would essentially be a weekly or monthly path, perhaps even a trigger that if your balance is running low, to be able to fill it up to the correct amount and um at that point of bringing all these things together, we'd be able to have this.

C

That and forget it experience that would hopefully uh streamline a lot of the billing uh issues that users are experiencing today, so uh that is kind of what we're we're hoping for over the over the coming months. um Be able to you know achieve all of these things and ultimately offer this this more streamlined experience.

C

So that's a part one uh really I, uh hopefully not too much repetition there, and hopefully the big points uh came out with with billing I'm going to move on to curation and cover the last, maybe five, five minutes or so on this okay, so uh for everybody, that's familiar with curation um say that this is somewhat of a controversial controversial topic. We've been talking about it for several months now and much like billing. uh Curation has a lot of room to improve uh curation view.

C

V1.0, for instance, uh was the graph's initial mechanism um that still exists on the graph ethereum today and as many of you may know, the main point of curation is to allow subgraph developers, consumers and curators the opportunity to add signal to a sub graph to attract and compensate indexers to index of subgraph data. It's basically a way of getting quality of service and saying hey. My sub graph is important. Please index it today.

C

It takes around four thousand to ten thousand grd to get high quality observance indexing on the subgraph on the on the graph network uh and most to have very few problems today. But that isn't to say that this mechanism is perfect, so uh the curation experience right now, for instance, it's not perfect. It poses risk to both indexers and sub graph developers.

C

It sometimes fails to fully ensure that subgraph developers will be able to control for their quality of service on a subgraph at any given time, and this is partly due to uh subgraph developers, consumers and curators, not always sharing the same Financial incentives. uh It's partly due to Signal not being directly connected to indexers costs, and it's also due to a slew of other reasons that we don't have uh the time to go into today.

C

um That said, curation b1.x has, uh you know, mitigated some of these problems to a certain extent. uh It was implemented on the graph arbitrum um and has really affect a lot of the the issues around like bonding curves and allowing some graph developers to have less risk um when they're being affected by these other stakeholders. That are, um you know, adding signal to a subgraph. So unfortunately, b1.x was not really meant to be a long-term solution.

C

It wasn't meant to solve all the problems that uh that we could have solved or that we can solve with curation Bo or, if you uh b1.0. So what we're really looking to do is kind of move forward with a new mechanism and be able to address the the core issues that we've we've recognized within curation and be able to offer a better system for all the personas in mind.

C

Okay. So what we're moving towards is a proposal called uh dips or direct indexer payments, um and the essence of this is that um that dips recommends that developers and consumers should be able to directly pay indexers for the work that they do without the confusion of converting these payments to signal on bonding curve.

C

Generally, the latest version of dip proposal envisioned the marketplace where indexers can post their initial and ongoing indexer prices to developers or consumers, and then they can easily add dips or payments uh when publishing or upgrading, to ensure that they get a high quality of service on their subgraph, and this proposal aligns quite nicely with a billing proposal outline before making uh meaning that it can go well with both the pay, as you go, opt-in, as well as the subscription plans that I detailed uh before so um before.

C

We can really Advance the curation side of dip and start to implement that design and Implement that, rather uh that we would have have indexing, rewards change as well. Today, indexing rewards are largely predicated on the amount of signal on subgraphs um and another system. We need to replace with signal mechanism to Define how inductors are subsidized for the ongoing work they have or the ongoing role that they have in growing the graph Network.

C

So, moreover, indexers also need to actively set prices on these indexing costs that they would post and which is a non-trivial operational cost for most entities in the ecosystem.

C

um So, if we're thinking about this in terms of bigger Milestones, the things that we need to move forward again, I'll I just want to say up front that I'm not necessarily or we're not necessarily committing or I'm saying that that will happen in this particular order.

C

But some of the Milestones that we're kind of looking out for and hoping to um see over the coming uh coming period here, that's first uh you'll you'll likely see a Gip or graph Improvement proposal on index team rewards be released uh with the objective of generating debate on the grass community members, especially among indexers, about how uh the proposals for index changing index, name, rewards, would uh unravel and and how that would impact, um not only indexers but other other members of communities or other members of the community.

C

Excuse me a second assuming that you can surpass a critical threshold of um at least partial consensus on this particular issue. We would then be able to kind of shift into uh the dips curation mechanism start to design and Implement and see how that would affect user flows and ensure that things are in fact getting easier for curators.

C

um We have a fair degree of contents already from from previous office and discussions uh amongst the community, knowing that we have a strong Proposal with dips, but again how indexing reward will be affected. It's still kind of an open question that we have to have more considerable debate about.

C

In the meantime, it's worth mentioning that um we are going to try to use this managed subgraph payment plans as a way of kind of mitigating some of the the pitfalls or current Pitfall of duration, um 1.0 and 1.x, um mainly in trying to abstract away um some of those curation complexities from users that don't have interest in pursuing that or engaging with that, um so being able to offer manage subgraph plans where you can cover all the things uh would be a way of you know streamlining that, for the time being, until we can move into a more sufficient um uh solution for how curation would be handled in the long term.

C

Okay. So with all that said, uh oh thank you for your time, uh we'll open up a more for questions and comments um and I see, there's a bunch in the chat already so.

A

Yes, a bunch of questions in the chat already thanks.

B

A

Do you want to go through uh the question? Let's see.

B

A

Sure yeah is this building system specific to yeah this in the future? Yeah uh no wait! What is it I lost that one.

B

A

D

A

Is also asking because more blockchains are added to the decentralized network. Will the building system accept payments from those blockchains either native token or like usdc, which is on those chains or always need to pay from ethereum I'm just reading out loud, so that it's uh in the recording.

C

Sure uh so I guess I'll address um Matthew's question. First, um no, that's not necessarily the case. um The way that this particular Billing System is set up is right. Now that um the the contract that we're moving to with a billion subscriptions contract uh is is on arbitrum, um so all all payments. uh My understanding is that this, a particular mechanism would accept any er320 token.

C

um However, it would require a different contract for each of those tokens. So in our case we're we're really interested in trying to offer stable coins so that our MVP will only offer USBC as a payment type, um but obviously we'll uh have. uh We want to kind of expand that to have accepting GRT, um there's, probably an argument for having things like eth or other other tokens as well.

C

um That's not currently within the scope of what we're doing, but we have the the billing 2.0 kind of mechanism or the graph the description protocol, it's fairly robust enough to be able to have um you know different billion operator, think about this and accept the the tokens or currency that they want um to kind of optimize for their situation. So, but my understanding is that they're all currently on um on arbitrine, but probably a better question for for Theo I, can follow up and get a more thorough answer on that.

C

So I'll pick Derek's question. Next, uh with dip back into the coordination between consumer to inductors, will there be a curator stakeholder role, yeah a great question, um I think in our current design we are prioritizing um the role of inductors and uh subgraph developer their consumer to ensure that they're able to achieve both of their goals mainly to be able to control quality of service on a cloud graph.

C

um I do think. I personally do think that there is a role um for sub for curators in this mechanism, however, I think there does need to be a little bit of research to determine um in what way uh the curation role you know has not necessarily achieved what it's set out to do. um It is really to about bring attract and um compensate inductors where that hasn't always been the case in the past.

C

So uh at the moment, I think there's more research to do there, but I know that is an active thing that we're discussing so sorry I. Don't have a better answer for you, but that's currently how at least on thinking about it worth thinking about it a little bit more. Obviously,.

C

Perfect yeah and I see a note from uni YouTube for expanding the role of a curator, which is which is great um okay, so I'll move on to uh yaniv's question up here from the very top uh when users pay in Fiat or usdc is the currently converted to GRT before uh being used in the network or the protocol being changed to accept fees in the currency or in other currencies. uh Yeah that depends on the um on the billing system.

C

So in the case of Fiat, users are um at least in the the current scope of how we're thinking about that users will be able to go into the existing filling system. uh They'll have the option to um pay in either grp or Fiat, they'll jump out to uh Fiat um payment system and be able to acquire grp there, and it will go directly to their billing uh billing balance, so it is streamlined, but they are still technically paying in GRT uh I think there are.

C

um There are other proposals or there are other assistance here. So the subscription protocol would not be in GRT. The payment could be accepted in USBC initially, and then we expand beyond the MVP to accept grp and USBC at least the potential for any erc20 token. But that's not currently uh something where uh you know kind of set on yet uh I think there is another possibility, something that I've that we've explored as well is thinking about um a direct Fiat payment.

C

That uh would be yeah, obviously, in this case not shifting from Fiat to DRT, but instead just to allow a direct Fiat payments, and that would require it likely. A third party.

C

um There are some advantages, for uh you know kind of like these bigger companies uh that more traditional companies, but that's not currently within the scope of what we're trying to do. um But the company we're definitely open to discussing a little bit later on to streamline from the onboarding for these larger entities that are more in the traditional Finance space.

C

C

Great yeah just to call out Brandon's comment as well: query: payments between gateways and indexers are still in grp. Yes, that that is correct um and and what I'm talking to yes, is much more between the consumer and the Gateway. So, but all the indexers and gateways will be transacting in GRT.

C

um See here uh so another question here: could there be an API access to monitor billing API key usage for a particular account? uh Yes, and so Simone has already followed up on that. um There is a sub graph for that uh it looked like a devil girl also has dashboards, as pagers mentioned.

C

I, don't think there are any other outstanding questions there, but feel free to speak up if I'm missing something here.

A

Yeah I've also picked Nana to try to answer this. If she wanted I didn't realize she was not co-host Nana. If you want to write in the chat or just speak, you know you know you're able to.

B

uh Yeah I was just going to say the API key used. Studio I wanted to share a few screenshots uh for more clarity, I'm trying to get that in.

A

You should be able, then, if not I can not share the screenshots you've sent me.

C

Sorry I was sharing my screen. Oh.

A

She's sharing in the chat, okay,.

A

And then I'm not sure if you're talking but you're you're on Europe now.

B

Yes, sorry I think I have some internet issues, but this would be the overview of the API keys that we're currently storing in our database.

A

I'll make sure I add those to the recording so that others can then see it so I'll just attach.

C

A

Description and.

C

It's worth calling out too, that will, um you know, be uh offering some some more additional features with the with billing 2.0 as well, so that users will be able to monitor the amount of queries and and the overall cost that they have uh for uh billing 2.0 or building 1.0, depending on the system uh over time.

C

So in building 1.0 as it's pay as you go, you'll be able to see the the payments that you have on a weekly or monthly basis um in in cure in Billing 2.0, where you have a subscription you'll be able to trace how much you've, um obviously how much you paid and how much of that subscription or how? Much of the queries that you've locked in are being used over the course of time um and we'll be able to offer uh kind of this system where you'll be able to.

C

You know fairly easily renew, um ultimately be able to uh do that automated obviously, uh and then this other this other opportunity to upgrade or downgrade. If you want to change the amount of queries that you have, so you won't be necessary, really set you'll, be able to preflexibly adjust your plan. When you know. That's the case, and obviously a kind of an analytic system to be able to overlook that and initially first fairly small, but hopefully that's something we can expand in the future.

A

Great, thank you so much Mikey. um Thank you all for your questions. Thanks man also for jumping in and help Simon too. uh We in the interest of time we have to go. We have to move forward um thanks, BK again, uh Pablo I think you're up I just quickly mentioned what this will be about in the beginning. So I'll try to save some time and let you go for it.

E

Hey folks, thanks, Pedro um I am going to share my screen and see if this works, can you all see video two updates twice: okay, great um cool. So, um as Pedro mentioned, we already did an update about this last month. um So there are some things where I. Okay, there.

E

um There are things where I'm going to repeat the whole presentation from last time, I I would recommend. If you want more detail, you can watch the recording for the February quarter of school. That has some more information on the things that we did previously, but still for a bit of context.

E

um We are working on scaling the graph on arbitrary and this means migrating the protocol contracts to arbitrim um so that all participants can interact with these smart contracts running on arbitrum instead of the ones on ethereum. But in the meantime we have contacts running on both ethereum mainnet and RB from one, and this was launched as part of stage one for the bridge. So we launched a bridge that allows you to send GRT from the ethereum mainnet network to orbital one and we've launched all of the contracts on L2 only without indexing Rewards.

E

So there is a fully functioning protocol that runs an arbitrine one. It just doesn't have induction rewards, and obviously this means there's little incentive for indexers to actually set up operations there um and therefore, there's uh still, you know not a lot of uh capacity in terms of uh serving subgraphs and therefore not a lot of subgraphs. But hopefully we can change this in the near future.

E

So stage two would be to enable induction rewards on the RB from one network and slowly move um the the issuance the GRT tokenitions from currently 100 on Mainland and zero percent on Arboretum to eventually the other way around that will have 100 of issuance on arbition one, but we're going to go slowly, because we want to be very careful and make sure that everything works along the way and then finally, there is a stage three that is also coming very soon.

E

That is having migration helpers so that protocol participants can very easily move their states, their GRT from the mainnet contracts to the Aboriginal one contracts, so for subgrade developers being able to migrate a subgraph for curators, be able to move their signal from the subject 101 to the migrated, subgraph 102 um and, in the same way, for indexers to be able to move their state tool to and delegators to move their delegated stake from the index terminal, one to the migrated index terminal 2.. um So all of this is coming very soon.

E

um As part of this, um we did some mips missions um so for those not familiar, Maps is a program that incentivizes uh indexers to perform some missions for points um which uh is being used mostly to test and prepare for launching new Chains new index changes on the network. But we also did some like special optional missions to test all of the L2 contracts on the arbitrary Testament.

E

So um there were a few bumps along the way, but this was part of what we wanted to have uh to iron out. All of the wrinkles, so I would say the mission for a success. We had about 300 participants, doing different actions like stating um delegating allocating to subcrafts and actually serving queries on the arbitrary testnet. Through this process we had some great feedback on the products and all of the UI, some bugs that came up and we were able to our products.

E

Team was able to fix because of this, and while doing this, we validated that the contracts, the Gateway, the subgraphs, the products, everything works well together. So we have a you know: a fully functional protocol with all the things around the contracts that are actually working properly as well. So we tested this on testnet and then um just some more General update. We've done that. Okay now we think we're quite ready to deploy stage two and actually enable rewards on arbitrary.

E

So um as part of the testing plan, we first deployed this to test net and this happened yesterday. Actually, so, if you're running an indexer on arbitrine Gurley, you might have noticed that your allocations are suddenly giving you indexing rewards.

E

um So we redirected five percent of the fake test net trt issuance from Quarry to arborly and because we're so close to finishing the testing- and this is you know today tomorrow- just a few more tests and missing. If everything goes well, we will deploy the L2 rewards, these ones to arbitrine one next week um and obviously this requires transactions from the council multi-stick to enable the upgrades and then to actually set that five percentage once on O2.

E

um If you want to read the details about this and how it all works, check out, jp43 um and it's predecessor, JP 37- that actually explains how the new insurance system works, so that we can issue and mint GRT, both funnel 2 and 101.. So I'm, assuming everything goes well next week or soon thereafter. As soon as the transactions are signed, um an indexer that is allocating to stock graphs on arbitrine one will see a small amount of rewards being issued.

E

um Well, it could be a big amount if there are a few indexers and so on, but um basically there's going to be a little bit of rewards on L2 and there's going to be a little bit less rewards on a one as we shift these ones, 95 on garlic on Main net and five percent on Origin one.

E

um At the same time, the contracts for stage three that are these migration helpers are going through the last audit we already audited all the software conclusion migration helpers and we're auditing the stake and delegation investing contracts. Migration helpers for details about this. You can check out Gip 46 in the forums. As you see how all of these migration helpers would work.

E

If, uh assuming things go well with the audit, we will be launching first, the subgraph and uh curation migration helpers and a few weeks after or a little bit more after the stake and delegation migration helpers. So as we do this, we will propose to the council to increase the yield to rewards as it's going to be easier for people to move over 122.

E

It would make sense to uh incentivize um also that they'll do a bit more and increase their rewards so that we can, you know, move forward towards this 100 issuance on how to Target.

E

um Assuming you know, the community is happy with how things are going on O2 as well, um and while we're doing this, uh the a general products team is also working on the UI development world of these migration helpers. Obviously, um making these easy to use is going to be very important so that people can actually do it um and there's uh also work on.

E

You know changing network subgraphs uh done by one from graph Ops um and a few other things around it that are happening so that we can get everything ready um so yeah. This is a the current state of things.

E

Big things happening this week and the next and hopefully soon after once, we finish Audits and the UI and everything we're going to have the helpers and we can move pull steam ahead on going to arbitrary, um so I think that's all I had so I I, don't know if we have time for the questions, um I'm gonna stop sharing. Now. Thank you.

A

Thank you, Pablo yeah, I, still I see, Mark, have a question. There's a question and Jim as well.

A

um uh Pablo. Do you want to answer Mark's question the question.

E

E

The question is: is it still expected that owners are fully vested uh item token? Love contracts will be able to use normal migration helpers important to have an assurance on this before most indexes start setting up on O2? Yes, that is what we want to uh we want to do. We need to get the approval from the entities that issued those testing contracts and I think in most cases, that's the foundation um or yeah I'm, not sure, but we're working to get the explicit approval um for that. But that is definitely the plan.

E

uh People that have fully vested vesting blogs. They shouldn't need to use the special vesting log migration process. They should be able to just use the normal migration process. We just need to get everyone on board because that's going to take some Logistics to actually move those vesting contracts into a new investing contract manager, contract um and then authorize those uh normal migration helper functions, so um that is our plan.

E

I haven't updated that on the forums yet because uh we're discussing among the core deficit Foundation to make sure that this is um approved and there are no unexpected issues but yeah thanks for bringing that up. That's an important one.

F

A

James I think you can speak hey.

G

Can you hear me okay,.

A

Yes, India, hey.

G

Pablo, thanks for the the update man, I appreciate it. I just had a quick question um if I want to set up a new indexer today on on Layer Two, let's say I just fund one with 100K GRT, which is the you know, the Threshold at which I need to meet in order to deploy an indexer completely separate from my existing mainnet.

G

One will I be able to then use a helper to move my existing operation on mainnet to the address that I'm already running, with a potentially different set of parameters um to that new L2 and then eventually deal with all the you know, ens and all that later down the line.

E

Yes, so if you have a vesting contract that is not fully vested, then no uh because you'll need to migrate your investing contract first to get what your L2 address would be to operate um if you're, using a fully vested uh besting contract or just a regular, you know multi-sig or or um normal address, then, yes, you can just start a new indexing operation on L2 and when you migrate the state from a one, you can specify the L2 beneficiary to be that address that you're already using 102. So what will happen?

E

Is you'll just be sending um that L1 state to that existing L2 indexer instead of creating a new one, um make sure that answers your.

G

Question that fully answers it thanks very much Pablo.

E

Well, good thing.

A

Nice, thank you. Pablo I'm, not seeing any question in the Forum. um Do raise your hand if you want to speak or just write your question in the chat.

A

I'll just give you a couple seconds, if not we'll move over to the other topic.

E

And if, if there are more questions, feel free to also ask in the forums, especially the JP, 46 um post, um so yeah there's been some good conversation. There.

A

Yeah, absolutely thanks all for the feedback. I did post the links to those threads in the chat. I'll also posted in the video description. So yes, recall, um yeah I'm not seeing any questions. So, let's move over. Thank you again. Pablo always nice having you uh I, believe uh we'll have Robin from asari I just made your co-host. Can you try to speak.

A

Oh wait a second.

A

Okay, Robin, you can try now, please is.

D

A

E

Yeah there you go.

A

D

uh Great I'll share my screen. Oh it's uh disabled screen sharing as well. You.

E

F

D

Sorry, it's one second.

D

So I'm gonna have to drop and uh get back on the call, let's be one second,.

A

If, okay, if that's, if it's locked up, it's not okay, we can wait a couple seconds.

A

Yeah, like I mentioned um in the beginning, this is the substreams powered subgraphs that um we've been working on and masary has some great use cases ready to Showcase here. So we'll be talking about what they've been building the indexing performance. The performance indexing speeds that we've been seeing and hopefully talk a little bit about how we can bring this to the network. Soon. So I see Robin you're staring your screen already Chrome full screen, yeah I see tabs as well. Let's Robin can you? Oh sorry, just a second.

D

A

Yeah yeah, we can hear you now you're, sharing uh your browser, your Chrome, a chrome window, I mean or actually I'm. Sorry, your full background, yeah.

D

Great yes, I just wanted to talk briefly about uh my sort of uh developer experience um when uh we worked on the uh Network Sub sub graph powered by substreams uh for ethereum. uh So this is here it here. Synced it took um roughly a week to sync um so I think our subgraph, the equivalent took two months, so it's roughly eight times quicker, which is um pretty great.

D

um It's almost exactly the same. uh There are a couple of limitations uh we found when it came to um taking uh stats data. uh We had a couple um objects that couldn't be replicated, but almost everything is uh kind of there uh on the graph. We've got uh for this one. It's just uh tracking Network entity uh with some snapshots uh for days and hours um and yeah we've kind of uh copied everything exactly the same.

D

So we're you know, tracking our proper stats for a lot of things um uh counts of just general uh stats uh really but um uh yeah the uh pull up some of the uh uh code in terms of the dev experience it was. uh It was quite nice. It felt fairly uh straightforward. uh We sort of came up with some, uh like quite like nice uh patterns, to kind of keep things neat um at preserving sort of uh making easy to track.

D

The execution order and sort of separate everything into uh sort of far past we sort of um kind of stuck to this pattern quite early on, um uh but yeah everything kind of uh wasn't wasn't too bad of the experience, um uh things that were slightly uh more tricky than others were stuff, like uh tracking uniqueness, um taking um uh Statistics over like time frames. uh Time periods um uh just starts in general really, uh but we did come up with some like fairly Keen patterns to kind of get around all this so uh yeah.

D

The experience was quite quite nice. In general, um things are slightly hard as well were um uh debugging when uh deploying uh the subgraph. uh Sometimes uh there's a lot of uh iteration that was kind of slow, but I think we have something in the mix for that. We want to um automatically generate uh unit tests to be able to debug the same locally. So hopefully uh any of the things we had minor issues with we'll be able to uh patch up and be good but uh yeah.

D

The experience was uh quite nice in general, um so uh yeah, that's a refund for me. uh That's it uh any any questions tool.

A

I'm not seeing yet, but would be great to share the GitHub repo for this one. If folks wanna check.

D

A

The source code yeah for.

D

Sure um it's currently in PR at the moment, uh but I'll show you the link for the pr thank.

A

You and then you leave it asking a question that I believe you've already answered, which is any performance numbers to share I. Believe you mentioned them, 8X Improvement was it.

D

Yes uh is an eight-fold uh sorry Ajax, Improvement um yeah. It was from two months uh before to a week.

A

Wow yeah, oh I, see Vincent is also in the chat. um I'd, be curious to know if you folks have been working on other sub uh sub graphs like porting existing ones like big ones, that that are known for taking a lot of time indexing if you've seen other or similar performance increase.

D

um I'm, not I, don't think there's anything else. That's large! That's quite uh ready. Yet I think this is the first one, but uh working on stuff, like uh uni swap V2 and you've got a couple, others in the mix um but uh yeah. This is the first one. We've got actually deployed to the hosted server so far.

A

uh Yeah Vincent is saying that is also working on the the swap people. As you mentioned, work work in progress. uh Yeah you did have some yeah uh Yaniv. Was there any functionality that you felt you couldn't Implement with substance, yet.

D

um Yeah I think uh the hardest thing is um uh it's just storing of large values in general when processing through the chain so stuff, like tracking uniqueness, was kind of hard uh there's a certain threshold which is fairly low um for uh storing a list of values and checking through it. uh So yeah uniqueness was hard. We had to drop a couple things from that um and uh yeah. Some of the uh aggregation stuff was a little Punky, but uh it wasn't too bad to implement.

D

uh Yes, is mainly just tracking of um uh sort of lists of values uh which we couldn't do but yeah it's fine.

A

I see also BK um asking if there are any plans to share on documentation on how to optimize the development experience like you were, showing yeah.

D

I wrote a couple of um uh documents on there, so I'll have to share share them in uh maybe the working API Group or something like that, um but yeah definitely some uh patterns that we uh worked out that were made it a lot simpler for building this stuff, uh in particular, just separating out the module code into files was uh quite nice just on its own, but um yeah there's a there's a proper worksheet somewhere, so I'll uh copy the link for that.

B

H

B

H

Pretty that was a pretty discussion in yesterday's um uh working group meeting just around some of the patterns and um like anti-patterns when it comes to developing sub streams. So we're looking to um flesh out the substrings documentation to have more examples of what to do, but I think in also some cases uh what not to do, because there are some. um There are some things which you shouldn't shouldn't, necessarily try and do in sub streams, where there's a sort of more native Native way.

H

So um yeah we're definitely looking to keep track of those um as we as people are building more substreams.

A

I think it's also worth pointing out that um there's nothing in a protocol stopping us from getting these on to the network, meaning no protocol changes.

A

So, um as things are maturing- and uh you know we're adding robustness to the whole stack, we should like indexes should get ready with fire hose for ethereum, for instance, because that's really the only let's say, back-end components required to get ready to start serving these substance powered sub sub graphs on the network, right I'm, not sure if you can, if you want to speak to that as well Adam or if there's much more to say really at this point.

H

Yeah, no, no I, think I think the only thing would be obviously outside the normal sort of uh experimental feature sort of feature: approval like feature Matrix um sort of Step. But um uh yes, there's nothing like a subgraph, uh substream based subgraph um looks exactly the same um outside. Obviously the Manifest is is a bit different and points to slightly different sort of files, um but yeah yeah. It's um that does the quite neat thing about this integration. I guess.

A

Very little looking forward to seeing that on the mentor for sure um Simone, you always have questions around about sub graphs and sub streams. Features you want anything. You want to add last four minutes.

F

A question about substreams.

F

I'm not prepared, let me think.

A

I was just wondering you always have something to ask the windows in these sections.

F

Oh yeah I want to know yeah. So um if this implementation is the sub streams configured to directly write into the postgres sync or is there still a mappings file, um so certain kind of Fitness classical sub graph way.

D

um We just returned the output from uh our last module as a set of entity. Changes is that is that what you were sort of looking for, um but yeah that gets mapped into um a bunch of table, updates.

D

um That's done at the graph node uh side of things.

F

Okay, so it's the the schema is written as chemograph quail and then the sub streams more or less directly write into that database as the schema expected to be.

D

uh Yeah, so uh we, this is like uh an example of our last module, uh the uh we're just uh returning a set of these structures. um So it's uh every single entity. We have uh we just uh returning like a list of kind of uh field, modifications uh sort of with the difference in values um at each block, and these get mapped at the graph side uh into the corresponding postgres um updates.

F

Okay, cool that makes sense foreign.

A

Thank you so much Robin and the whole Missouri team for building this and sharing will be waiting to see more of these for sure and hopefully on the network soon as well and, more importantly, see also more developers building with the stack stack and if you want to share some feedback on this, there's a substreams Discord channel so feel free to reach out to streaming fast team has always been monitoring this that channel as well and all other core development teams that are working on this new feature.

A

Let's say so, yeah do Reach Out want to hear some feed feedback while we're still in this early stage, let's say the very promising tech for sure, as we just we just saw.

A

I, don't see any any other questions, I think that's all for today. So thank you all for joining once again, this will be on YouTube as always, and show notes from Ethan Community, member and Annie, also helping out now we'll be sharing these on the Forum as well. So thanks all I'll see you in a month right.