GRTiQ Podcast: 105 Scaling on Arbitrum

The following podcast is for informational purposes only. The contents of this podcast do not constitute tax, legal or investment advice. Take responsibility for your own decisions, consult with the proper professionals and do your own research.

Daniel Nfodjo (00:14):

As The Graph being, what we like to say as, a beacon of web3 I think it’s important to involve community members to have a voice in making decisions that are going to have an impact on the protocol.

Nick (01:01):

Welcome to the GRTiQ Podcast. Today I’m doing a deep dive on the recent news regarding The Graph Network moving to Arbitrum. If you’re a regular listener of the podcast, then you know that last week we featured an interview with A.J. Warner, Chief Strategy Officer at Offchain Labs, the team behind Arbitrum. During the interview, A.J. not only shared his journey into web3, but he also provided a nice introduction to Arbitrum and the community. But this week we’re going to go a level deeper and explore everything you need to know about The Graphs move to L2 and how it’ll impact the network.

(01:34):

I’m fortunate to be joined by a panel of guests who can provide an inside glimpse to the process of scaling an Arbitrum, what that actually means and what some of the benefits are, an overview of the phased rollout and how it’ll impact network contributors like Indexers, Curators and Delegators. My guests are Ariel Barmat, Daniel Nfodjo, Pablo Carranza Velez, and Simon Emanuel Schmid, each of whom are from Edge & Node, the core dev team responsible for implementing many aspects of the move to L2 for the network. And as you’re about to hear, each panelist offers a key perspective of what it took to get here, what needs to happen next, and where the network is heading. I started a discussion by asking each panelist to introduce themselves.

Ariel Barmat (02:18):

Here. Ariel, I’m working as a lead of the smart contracts team at Edge & Node, and I’ve been a contributor for The Graph for many years already.

Daniel Nfodjo (02:27):

I’m Daniel. I’m a software engineer on the product engineering team working on the consumer facing products at The Graph, like self graph studio, explorer, hosted service, things along those lines. I’ve been working with Edge & Node for going on two years now and excited to be here.

Pablo Carranza Velez (02:44):

Hi, it’s great to be here. I’m Pablo and I’m also part of the smart contracts team by Ariel, been here for about a year and working almost exclusively on the thing we’re going to discuss today.

Simon Emanuel Schmid (02:59):

Hi. My name is Simon. I’m doing developer experience, meaning I be out with the developer at the front at hackathons, but also in support channels, helping them through the process. Yeah, that’s what I do here.

Nick (03:12):

Well, I’m super excited to have such a great panel to talk about some really important things that are happening at The Graph. And obviously, this Arbitrum announcement is big news. I was fortunate to host A.J. Warner last week from Arbitrum to talk a little bit more about that community and what they’re doing there. But for the sake of any listeners that didn’t catch that podcast and they want to understand a little bit better why we’re talking about L2 and Arbitrum, Ariel, let’s start with you. How would you describe what an L2 is and how Arbitrum fits into that?

Ariel Barmat (03:43):

Well, an L2 is a concept, I will say a group of technologies that describes ways to scale Ethereum. Well, when we talk about scaling Ethereum is clearly adding more capacity to it, like users being able to send more transactions at a lower cost. And this group of technologies share that they use Ethereum as a base layer for security. So an L2 is clearly a new chain, but all these chains are sharing the base security of Ethereum. So they use it to store some information that can reconstruct the state. A bit technical that part, but that’s the shared security properties. Particularly Arbitrum, Arbitrum is one of these L2 technologies in the ecosystem. It’s very interesting because they started many years ago, they launched on mainnet during 2021 along with Optimism and they are considered something called optimistic rollups. That is a kind of an L2 technology. And I’m really excited to be integrating the protocol with Arbitrum and really be playing with these L2 technologies. Super excited about what it is going to be for mainstream adoption.

Nick (04:57):

Well, that’s very helpful overview there Ariel. And again, I want to encourage listeners that didn’t catch the interview with A.J. Warner to go back and check that out. We talk a lot about Arbitrum and the community there and some of the origins of where that project came from. Let’s talk more specifically about what it means to say The Graph is scaling to Arbitrum. Pablo, when we hear that, what should we think about? What does it actually mean to say The Graph is moving or scaling to Arbitrum?

Pablo Carranza Velez (05:24):

Yeah, so currently we say The Graph protocol runs on Ethereum mainnet and that means that we have some smart contracts deployed there and whenever someone wants to interact with the protocol, they have to perform a transaction there. For instance, if you’re an Indexer, if you want to be an Indexer, you have to stake some GRT and then you have to signal say, I’m going to index these subgraphs, and then you present proofs of indexing. So when you do that, each of those steps means sending a transaction to those contracts on Ethereum mainnet.

(05:56):

And what we’ve done is we’ve deployed the same set of contracts maybe with a few changes to this new blockchain to Arbitrum. So now people who want to drag the protocol can either do it on Ethereum mainnet and central transactions to those contracts, or they can do it on Arbitrum and send transactions to those contracts. And that means for now we have the protocol running in two places, but hopefully eventually everyone moves over to the L2 and then we will have moved completely to Arbitrum.

Simon Emanuel Schmid (06:27):

I just want to add here that the protocol or the chain where the protocol is running is independent from the chains that The Graph Network can index. So that’s the caveat that we often see. In fact, if I’m not mistaken, we’ll move the protocol to Arbitrum while indexing subgraphs on Arbitrum won’t be enabled at the same time. So that’s actually two separate the things to think about.

Pablo Carranza Velez (06:54):

So Simon makes a really good point that it’s very easy to get confused between indexing Arbitrum as a chain that you want to consume and running the protocol and running the actions there. One thing I would notice, the other thing is actually happening now. I believe we are through the first steps of also being able to index Arbitrum, but I think that’s a great clarification.

Nick (07:15):

Well, I guess I should go back a little bit here, but my understanding is that there’s a phased rollout so to speak of this. Let’s maybe start there real quick and just provide an overview of how the phases will work. What’s the rollout plan here. Ariel, is that a question you could take?

Ariel Barmat (07:31):

Yeah, sure. When we started thinking about this bigger lift, moving our protocol from one chain to a different chain is something that you can’t force. The community needs to be behind that. Every action in a blockchain is user initiated. So users need to wanting to actually move to a different place. You can see that in Uniswap V1, V2, V3. This platform still coexist and people basically decide what’s best and because it’s also risky, we thought about how we decompose this big challenge and we split it in three phases. Everything was described in GIP that we share with the community and it was a conversation with the community because we’re posting in the forums as we were learning and designing these phases and there are pretty interesting conversations in the form. So the stage one, we decided to work on a bridge, basically a basic component that will allow to move GRT over from mainnet to Arbitrum one.

(08:41):

So that was the basic and the building base of the construction of all the things that came after that. So we had a bridge, you can move GRT over, we can add some special features that we want in that bridge like being able to add some protections and checks in case something wrong happens. And the other thing was deploying the protocol as is the same way it is today in mainnet but on average. So we have let’s say a mirror of the protocol along with the bridge. So that’s stage one. Maybe there’s some details I’m missing, but that’s roughly the idea. Then we moved something very, I would say important in the protocol that is rewards distribution. As you all know, the protocol is issuing GRT as a part of the indexing rewards that indexes received for the work. What we did was to do some changes to the way that reward distribution is working so that we can support adding or moving over part of the issues to L2 while keeping submissions in L1 gradually, right?

(09:50):

Because it’s very hard to turn off something on L1 and activating that on a L2 in a single day clearly because there are some risks involved in that. So we wanted to be able to test as we go. So the idea of stage two is moving some insurance to L2 and getting Indexers to move over gradually. As we go and we learn from a stage two and we have everything set up, we have monitoring, we have everything working, people reporting issues, et cetera. We are embedded working on something called the stage three that we set an aim called the migration helpers, and the idea of the migration helpers is that users can have an easy way to move over their subgraph, to move over the Indexer stake, to move over the delegation in a close to one click, one or few clicks migration to make it easier, with the end goal to having every participant running on the L2.

(10:48):

Again because this reason I mentioned that every action is used initiated, you need to create the incentives for people to move over and both stage two by moving indexing rewards and stage three by making really migration helpers to make it easy to migrate. We are working on that code.

Nick (11:05):

We should probably clarify what is meant by scaling. And so Ariel, maybe I’ll throw it to you, but when we say The Graph is scaling with Arbitrum, what is meant by that?

Ariel Barmat (11:16):

Yeah, I see scaling technically you can define it as adding more capacity basically, adding more bandwidth to what users can do. But there’s another way to see it and it’s like a way to fit the large vision of the protocol. The Graph has a very large vision of indexing all the blockchain data and it’s really a huge vision. To accommodate that vision, you really need a network that can stands for many, many, many years and decades and it’s the base where many people will build on top. So that’s the way I see scaling. And scaling can be solved in different technical ways. I think that in the future we’ll need to adapt as we go as technology progresses, but the most important thing is to be super sure about the vision and that the technology encompass and be following what we are thinking about how large The Graph will be.

Nick (12:16):

Pablo, going back to what you said, The Graph Network will be on two chains for a period of time, Ethereum and Arbitrum. Moving to Arbitrum will take place over a series of steps. And then is it correct that eventually everything will be over at Arbitrum and people won’t necessarily be interacting with The Graph through Ethereum? Have I got that right?

Pablo Carranza Velez (12:40):

Yeah, that’s correct. Assuming everything goes well during this migration and the community is happy with the change and we see Arbitrum keep progressing towards more decentralization and so on, I think we’re all hoping that the move will be complete and total and no one will need to use Ethereum mainnet anymore eventually.

Nick (13:00):

One of the things that came out of my interview with A.J. Warner was I asked him about competition among L2s, right? How does Arbitrum position itself against competition in the L2 space? And he had a great answer to that. I want to build on what he said during that interview with this question to you guys which is, were there other options of available to The Graph when it was thinking about scaling and if there were, why was Arbitrum the best option?

Ariel Barmat (13:29):

Well, there were a few options at that time, but not many. We started thinking about scaling the protocol in 2021, I would say mid 2021 and the market condition was, I think we all remember, pretty crazy with NFTs being minted every day, gas costs going through the roof. So we in a way were in a bit of hurry to define where we could move the protocol to make it cheaper. Clearly, the protocol is used by all the participants in Indexer, Curators, Delegators and it was getting more and more expensive to run. So at that time, the viable solutions were Polygon, Optimism and Arbitrum in terms of projects that were on mainnet or close to mainnet. We already Polygon, but Polygon uses a different system where it relies on Ethereum for some security, but it’s not posting all the data as a full L2.

(14:28):

And we were looking for something more secure in that sense. We evaluated Optimism and Arbitrum and we decided to go with Arbitrum. At that time, I would say Arbitrum and Optimism are really similar, but at that time we were a bit different. Optimism were using a different concept for compiling the contracts. They had some sort of an OVM and Arbitrum tried to keep more of a closer EVM compatibility and that was very interesting. And the other thing is, they had a flow proof system that was working in a way that when we studied it, it sounded reasonable while Optimism was still working on that. So I would say that today they are closer in a way, they work pretty similarly, but at that time we choose Arbitrum for those reasons and because all the work we had to do took a lot of a long time. I mean we bet on Arbitrum and today, we have a running network on Arbitrum. But that’s the core of the decision.

Nick (15:35):

And if I have it right, really the origins of the move to L2 and Arbitrum started as a GIP. I mean this was a community led initiative where people are able to vote in interact on The Graph forum, is that correct?

Ariel Barmat (15:48):

That’s correct. One of the first thing that Pablo did when he joined the team was researching the different tools in more detail. We decided to go with Arbitrum, but Pablo dig into how a bridge works, all the security, I would say all the different edge cases we might need to deal with and et cetera. I would say his first big contribution was writing a JP proposing how a bridge with Arbitrum would work and leading out the different steps into a potential migration to our. I think Pablo can say more about that, but clearly it was a very big contribution from him.

Pablo Carranza Velez (16:29):

It was definitely a fun way to start working here. But yeah, I was also building on a previous forum post by I believe someone in the community. There was already some discussion going on about whether The Graph would do any L2 scaling or not. So I took that as a starting point and that’s the first thing that I used for that GIP.

Simon Emanuel Schmid (16:51):

Yeah, reading these GIPs actually is super interesting if you are interested in how such a thing develops. They really go into technical details and I would recommend to every listener of this podcast who’s interested to see behind the scenes the decision makings, but also really the technical details to read those GIPs. I didn’t do it from the beginning, but now it’s something that I do it regularly and I enjoyed a lot.

Nick (17:18):

Well, I want to double click on that Simon, because I do think that this is really an incredible case example of that web3 ethos of the community drafting a proposal and then the community getting engaged and involved in it. Daniel, what does it say about The Graph, about decentralization that something is important like this emerged within the community in the form of a GIP?

Daniel Nfodjo (17:41):

I think it’s super important as The Graph being what we like to say as a beacon of web3. I think it’s important to involve community members to have a voice in making decisions that are going to have an impact on the protocol. So having things like GIPs that are eventually something like moving to Arbitrum, starting from somebody within the community, creating a GIP and then Pablo picking up on top of that proves out what we stand for in the web3 space, which is anybody can make a contribution that can affect a protocol as important as The Graph and that’s something that we champion, something that we want to support and encourage community members to continue to do. Very happy about that.

Nick (18:26):

Incredible. Thank you Daniel, and totally agree. And I love this scaling to Arbitrum and what it says about the community and the things that are happening within The Graph. I want to now turn our attention to the benefits. So it’s great background. We’ve learned a little bit about L2s, Arbitrum and the thinking behind scaling to Arbitrum and where it emerged from. Let’s talk now about why it matters and I’m going to frame this as like the benefits, benefits to participants within the ecosystem. So Pablo, let’s start with you. What are the benefits to participants within The Graph ecosystem of a move like this?

Pablo Carranza Velez (19:03):

So I think it all comes down to one word and that word is gas. The main difficulty we have if staying in it through mainnet is that gas prices can be really, really high. Right now, they’re better than maybe at the heights of the craziness that I mentioned in 2021, but it’s still significant cost for everyone that wants to participate in the protocol. So by moving to Arbitrum, we’re able to reduce those costs a lot. For instance, I checked maybe last week and a simple token transfer, a GRT transfer costs more than $3 in gas, whereas doing that same thing on Arbitrum costs about seven cents. So this is a very important reduction and this affects everyone.

(19:53):

So if you’re an Indexer then all of your operating costs become cheaper and this affects everyone else and so on. And this also opens up the space for us to do more improvements to the protocol and the economic mechanisms that make the network work. We’re limited in mainnet as to what kind of computation we can do there because everything we do can be very, very expensive, especially if gas price goes up. But on Arbitrum, I mean we still have to be very careful. We can’t just add a very weird algorithm that takes up a lot of gas, but we can experiment a bit more and produce something that might be a bit more complex or infeasible in mainnet, but it’s still reasonable cost on Arbitrum. So it really opens up a lot of possibilities.

Nick (20:39):

It’s a great general overview of the benefits Pablo. I appreciate the detail there. I do want to for the benefit of listeners who want to understand how they might be impacted in their specific role within the ecosystem to talk a little bit more specifically about those benefits. And so I know I got a lot of Delegators that tune into the podcast every week. Let’s start there. Daniel, how would you characterize the benefits of this move to members of the Delegator community?

Daniel Nfodjo (21:06):

Yeah. I think I want to go back to something Pablo said earlier around the whole benefit and reasoning around Arbitrum being around one big word called gas, right? I think that’s going to be the biggest thing that Delegators are going to see an improvement on and I think it will lower the barrier of entry for more Delegators to be able to be onboarded onto the platform if they don’t have to spend as much on gas. We talked about how cost of NFTs on L1 and all the different things that are helping on L1 can spike cost, which may deter Delegators, especially the smaller Delegators that are within the community. Maybe they’re learning about their graph, learning about indexing, delegating and they want to contribute to the ecosystem as a Delegator, maybe not something more technical like an Indexer, but want to dip their toes in there.

(21:59):

And a lot of the times they’re blocked by the fact that they have to put up so much ETH or they have to cut into the amount of GRT they might want to contribute to delegating because they have to cut a little bit of that budget into gas fees on Ethereum and buying Ethereum in order to be able to do that. So I think the immediate benefit for users, I mean that are going to be Delegators on Arbitrum would be giving them a lot more wiggle room to be able to deposit more GRT into the ecosystem because they are spending less money on gas and also lowering the barrier of entry for the littler guys who just either want to dip their toes into delegating and not necessarily want to spend a ton of money, they aren’t automatically knocked out of being able to do so due to gas costs.

(22:48):

They’re able to contribute as little as they feel the need to. So I think that’s really big and as it continues to scale, more people will be able to delegate without feeling that they have to add a huge amount in order to delegate and undelegate due to gas fees.

Ariel Barmat (23:04):

I was thinking a few other benefits for Delegators clearly related to gas that by being cheaper I can see Delegators maybe bit more active, some Delegators that were, I don’t know, they need to send a transaction, maybe it’s a bit expensive. So now they might be able to redelegate and change the way they’re delegating to different Indexers even maybe distributing their GRT into more Indexers.

(23:33):

So I can see that a cheaper network can make Delegators to be more active and that’s very healthy for the protocol because delegation as a function was meant to be a way to bring some signal for Indexers are working properly and Delegators voting on them. So I’m very excited to see that. And there’s an additional one that is related to the cost of running an Indexer operation. Delegators are receiving in a way some share of the work Indexers are doing. So if the Indexers get a better margin of their operations and I would say the gas expenses for them is quite big in their operations. So if they get better margins, I think they can share more with the Delegators. So I expect to see more competition in that sense.

Nick (24:23):

Well Ariel, that’s super interesting because when you think about some of the hot topics within the Delegator and Indexer community, you think about things like keep stake decentralized and you think about some of these other things that you alluded to there and I hadn’t until this moment thought about how the move to Arbitrum would facilitate addressing some of those issues that have been talking points within the community. So very exciting and appreciate that explanation. I think a lot of Delegators that listen to the podcast will have some questions and one of them I think will be, if I delegated a year ago, do I need to now undelegate, wait the 28 day thaw period and then delegate on Arbitrum? Is there a deadline by which I need to do that? How would you answer questions like that from a Delegator?

Pablo Carranza Velez (25:10):

Yeah. So if a Delegator wanted to move to Arbitrum today, yes they would have to do that. As Ariel mentioned, we’re thinking about this process in stages. So we’re currently stage one, we’ve deployed the bridge and the ATO network. It still doesn’t have index rewards, so Delegators wouldn’t benefit a lot from being on Arbitrum right now. But very, very soon we should be moving to stage two, we should be enabling index and rewards and those should start growing as a council approves switching the percentages over time. But very, very soon as well, we should be releasing the migration helpers. And the way we’re thinking about this is we want to provide maybe a single transaction process by which Delegators can just say, okay, I’m delegating to this Indexer on L1, the Indexer has migrated to L2, and then I can move my delegation from that Indexer in L1 to the same Indexer in L2 with just that transaction that goes over the Arbitrum GRT bridge.

(26:14):

So that should save the thawing period and even do it without charging any of the protocol taxes that are involved in the way. So hopefully that should make the transition a lot easier. Obviously, because we still need to preserve the security of the system, we can’t do it in a way where you migrate to L2 to any new Indexer and you do whatever you want. There’s still going to be some guardrails around that so that no one can take advantage of it.

(26:39):

But the main thing is you want to move from that index in L1 to the same Indexer that migrated to L2, you should be able to do it very, very easily. Now will it be required? No, at least not for quite a while. While we still have both networks running, you can still stay in L1. If your Indexer moves to L2 and they don’t have any stake in L1 anymore, then you won’t be making any rewards or query fees there until you migrate, but you’re not forced. Your GRT is there, you can withdraw it whenever you want. There’s nothing that that’s going to force you to move to Arbitrum if you don’t want.

Nick (27:12):

So if I delegate to an Indexer who moves to L2 and I’m no longer earning rewards because I haven’t myself as a Delegator moved to L2, will I still incur like a 28 day thaw period if I want to delegate from L1 and figure out what I’m going to do or were you speaking to that when you were talking about there’s plans to help people make that move?

Pablo Carranza Velez (27:35):

That’s a great question. I think it’ll obviously come down to how the community receives the proposal we have for this, but the current plan is that if you’re migrating your delegation to an Indexer that has moved to L2, you wouldn’t have to wait for that delegating period. But also if the Indexer has fully migrated to L2 and therefore you’re not accruing anymore delegation rewards, then it does make sense that you would be able to withdraw without having to wait.

(28:04):

So our proposal does account for this and there is a way in which you would be able to delegate without having to wait. This would only be a case if the Indexer has fully migrated and they don’t have any stake left behind in L1 because if they’re still operating in L1, then I think to maintain the security of the delegation, it does make sense that you still need to wait for that period.

Nick (28:28):

And you mentioned a proposal there Pablo, if people want to read that, where should they go and what is the name of the GIP they should look up?

Pablo Carranza Velez (28:35):

Yes, there is a GIP that went out quite recently and it’s GIP-46 that includes all of our proposal for the migration helpers and the detail, like there’s an overview of how they would work, but also the detailed spec of the specific changes to the contracts and the specific interface for that.

(30:09):

I want to encourage listeners that have questions or might be confused about some of this to visit the forum. There’s also some FAQs related to all of this information. So there’s ways to educate yourself and of course you can always go on The Graph Discord and post questions there. So we’ve addressed the benefits to Delegators, but there’s obviously other participants in the ecosystem that will benefit as well. Maybe I’ll just open it up to the panelists and let you talk about some of the benefits to different stakeholder groups. Maybe start off with you Simon. When you take a look at this outside of benefits to Delegators, what’s got you excited?

Simon Emanuel Schmid (30:53):

Yeah. How would that impact subgraph developers? Somehow I would say not at all because for the subgraph developers. As for now, they just maybe once or they publish their subgraph to the network and then more or less it’s done. I mean they do have the billing, but the billing won’t change. Seems to be already migrated the billing to Arbitrum. But since the creation market starts to change and there won’t be this bonding curve anymore where you have to be first and second and that makes a difference.

(31:34):

Curators are hopefully, in my opinion, let’s see how this plays out, more willing to be a more active participant in the network because they don’t risk anything if they go in and correct on the subgraph, a worst case could be that subgraph just doesn’t generate any query fees so they could move away, whereas in the protocol and Ethereum mainnet, it could be that you go in and then the Curator before you withdraws the signal and that could result in a less signal and GRT and stuff. So I hope that the Curators will become more active and as a subgraph developer, we are not forced anymore or advised to self signal.

Pablo Carranza Velez (32:14):

I’m not so sure that self signal won’t be needed anymore. Hopefully you’re right and it will turn out like that, but at least immediately developers will still have to signal some GRT to get their subgraphs syntax. There are people working on changing the curation, improving the curation mechanism so that it gets to something like that or it changes to a completely different thing. So we’ll see what happens with that.

(32:38):

But I think you’re right in that the creation market will be much healthier and even if subgraph developers still have to self signal, it’s at least going to be a lot more predictable to do it. They won’t be putting any GRT at risk when they’re going through that process. So you can add remove, add again, remove again as maybe you want to scale your queries or whatever and it’s a lot safer to do that as well.

Simon Emanuel Schmid (33:03):

So yeah, that’s actually very cool. I mean I know about some subgraphs on the decentralized network that actually want to curate more on their own subgraphs, but they also know that between the deployment and now there were other Curators jumped in and now they are disincentivized to create more, but it would be good for more Indexers, but they’re also afraid that these other Curators would withdraw before. So that’s definitely something that is solved and I’m very excited about this.

Daniel Nfodjo (33:35):

Simon, I think that’s a really good point you made about subgraph developers. I also think that there is a distinction whenever we talk about the query market, that involving people not are not subgraph developers but are subgraph consumers. We do know most people who are subgraph developers are subgraph consumers, but there is a percentage of subgraph consumers that are not subgraph-developers.

(34:00):

And I think the query fee market side of things can stand to benefit as well from the migration to L2 due to the lowering of operation cost and also lowering the barrier to entry for Indexers to join, creating more competition within the query marketplace in general, which could then by default potentially lower query fees, provide more effective, more efficient queries and just the overall increase in quality of service because there’s just more competition, there’s lowering of operation costs. So those funds can maybe be redirected towards increasing the quality of the queries that are served on the network. So I think it’ll benefit subgraph developers that are querying their subgraphs as well as subgraph consumers that are not necessarily subgraph developers but are consuming those subgraphs in order to build their gaps.

Nick (34:52):

Yeah, it’s a great distinction to make Daniel, and I appreciate you doing it here. I want to throw it over to you Ariel. If you look out at the different stakeholder groups, we’ve talked a little bit about Delegators, talked a little bit about subgraph developers and subgraph consumers. What has you excited about other participants within the network and the benefits they’ll gain from this?

Ariel Barmat (35:10):

I think we are not touched on Indexers and probably is one of the, I mean we talk about Delegators, we talk about universe, but Indexers are the group that clearly are running most of the transactions. They need to allocate multiple times to different subgraphs, they need to maintain the allocations open, et cetera. So again, there’s a cost reduction for them huge in this case. And again, as I said with the Delegators, I think that it will make the protocol more lively because indexes cannot adjust their strategies faster with this cost reduction.

(35:48):

And we will get to a better optimization of the resources. Whenever a subgraph is signaling indexes can jump in into allocating that faster than today without thinking too much on the cost and on the bets they’re doing and they can adjust the strategy faster. Eventually, this is something that we haven’t discussed yet, but eventually there are some time units in the protocol like the Epoch time, the thawing periods, et cetera, that are set to quite high values that are related to the gas cost because we didn’t want Indexers to incur in super high gas costs because they need to recycle the location too often.

(36:29):

But those values can be reconsidered once the network gets stable in Arbitrum. If the gas cost comes down, I don’t know a 100X, let’s say those values can be reviewed and that means that thawing period can be shorter, Indexers maybe can recycle, allocations are different length of time, EPOCH also can be changed. Again, this wasn’t proposed yet, but there will be second order effects of having less gas costs in the protocol.

Nick (36:59):

And Daniel, will this impact how data consumers actually interact with the network maybe in terms of billing or other touch points?

Daniel Nfodjo (37:07):

Yeah, that’s a very good point. We’ve currently migrated the billing service over to Arbitrum. That’s one of the first things in the protocol that was migrated to Arbitrum and it’s actually currently live. Before then, the billing process for subgraph consumers that were creating API keys and querying the network was complicated and involved processes around having to buy your GRT on mainnet, bridge your GRT over to Polygon and then deposit your GRT into a billing contract just to have enough GRT to be able to pay the query fees that were created based on you querying the network. With the move to Arbitrum which is currently live now, that process has been simplified dramatically allowing users to have a much more seamless process when interacting with API keys and billing on the network overall.

(38:01):

Currently, now if users want to create an API key and deposit GRT into their billing contract, it’s as simple as taking your GRT from mainnet. We’ve built a contract that will basically deposit your GRT into your billing contract directly from mainnet, bridge it over and deposit into your billing contract in one transaction, right? So you can have your GRT on mainnet, let’s say you buy it on the Uniswap or any exchange that you prefer, you move it into your wallet and it’s as simple as just running one transaction and immediately being able to deposit your GRT on Arbitrum, which is much faster, much more efficient and solves a large pain point around getting started and shifting away from the hosted service onto using the network through studio. So that’s something we’re super excited about and Arbitrum enabled us to be able to provide that.

Nick (38:55):

Simon, all the listeners are going to know that a big push has been this migration to the decentralized network and things are in full sway. It’s incredible to watch more and more drafts migrate to the decentralized network. But now we’re talking about this L1, L2 situation and I don’t know if I’m framing it properly that there will be or need to be a migration there, but how would you address confusion that might be around these different migrations?

Simon Emanuel Schmid (39:23):

You mean the migration after the migration before the next migration?

Nick (39:26):

Correct.

Simon Emanuel Schmid (39:31):

No, it’s not like that. No, basically I think we talked already about if you have already published your subgraphs or decentralized network on Ethereum mainnet, there is nothing that you need to do right now. It’ll just work. You can eventually migrate your subgraph over. But as far as I know, there will be also helpers to do this. So again, nothing to be concerned. Now if you did not migrate yet to the decentralized network, then you just publish your subgraphs directly on Arbitrum with all the benefits that we already heard about. So you don’t need to migrate after the migration as of now.

Nick (40:11):

Daniel, I want to ask you this question about the effort and time that goes into upgrading or revising the interfaces that the community and stakeholder groups interact with a change like this. And so you’re on the team that spent a lot of time doing this. What can you tell us about what type of work and activities go into those components of something like this?

Daniel Nfodjo (40:34):

Yeah. I really enjoy working on the product engineering team just because I think our team interfaces with so many different parts of the organization and is the center that’s able to bring everything that everyone is working to life. We’re working with smart contract teams, we’re working with the solution engineers, we’re working with product, we’re working with design, we’re working with marketing. And all of those people had an impact on what we’re presenting as a product. But in retrospect, thinking about how we were able to integrate Arbitrum into all of our systems, one of the biggest things that we wanted to focus on is being clear and concise about the deter between Arbitrum and mainnet, presenting a way for users to still be able to use the protocol the way they’re used to with the interfaces that they’re used to using, but replacing the things like smart contracts in the backend so that people can get access to the benefits that Arbitrum offers.

(41:30):

So to split it up, the work was tied into two different products that we were integrating. There is the explorer product that basically users interact with the protocol through there by curating, by delegating and all the other index or actions that are involved like staking, unstaking. And in order to do that, we basically introduced the concept of a network switcher and basically I’ll explain it in very simple terms, a lot more technical than that. But basically what the network switcher does is it takes all of the different interactions, specifically the contracts that are involved that are happening when someone clicks a button to delegate and when somebody clicks a button to stake or unstake. There’s a contract being called and those contracts are either on L1 or on L2, which is on Arbitrum. So basically what the switcher enables is basically a configuration change below the interface or below the UI that basically flips a switch on all of the different protocol actions within Explore.

(42:32):

So on you can find the network switcher on the top, which allows you to indicate viewing subgraphs that are deployed on Arbitrum, viewing subgraphs that are deployed on mainnet and be able to switch between those super quickly. If for whatever reason you’re searching for a subgraph that you are used to being on mainnet and you can’t find it anymore, maybe you can easily switch and then still see the same view but now be able to see all the different subgraphs. And the same thing with being able to participate in the ecosystem people are used to doing on mainnet, but just making that process super simple for users so that there’s no confusion whenever it comes to all of this great work that everybody on different teams are doing, simplifying that with the user interface that can be interacted with the same way that people are accustomed to doing, but also being able to get the benefits like lower gas costs, lowering a barrier to entry for people to join the network and things like that, but not having to reteach them a new way of doing things.

(43:30):

And then for subgraph developers, which primarily interact with Sub-graph Studio, allowing them to be able to publish to a network, be able to deploy their subgraphs to Arbitrum also requires a bit of configuration on our end to be able to provide a sandbox for them to be able to query their subgraphs that are going to be published on the network and then tracking all of the different versions.

(43:57):

So when you start publishing different versions, you can have them published on any network and then including things like Arbitrum and as well as Arbitrum Galxe because most people who are developing their subgraphs are not publishing directly on network. They need a test network and Arbitrum Galxe is what Galxe is to Ethereum. So integrating Arbitrum Galxe was something that was also big for us.

(44:19):

So it allows subgraph developers to be able to deploy versions of their subgraphs to Arbitrum Galxe, test it, make sure everything is good to go on that end before deploying to Arbitrum. So those are just a few of the things that we had to integrate. Ideally for users that are going to be using products from a front end standpoint, it should look very similar to what they’re used to doing on mainnet, but they will be able to inherently benefit from all the work done by everybody on this call and even people outside of this call to move the protocol over to Arbitrum in a seamless way that they’re already used to doing.

Nick (44:53):

An incredible amount of work goes into something like this. And I really appreciate Daniel, the overview there from the contributions from your team and of course Pablo, Ariel, Simon, super interesting information and background here about this exciting news. And I know a lot of people within the community are excited about the move to Arbitrum and have a lot of questions.

(45:12):

And I think this podcast will serve as a great resource in addition to the forum post and the FAQs that have been provided. I want to wrap up this panel discussion by asking each of you a final question. And we’ve talked about Arbitrum, we know it’s big news, people are excited, but what’s the next big thing? What are other things that you’re working on or that you’re looking at that has you excited about the future of The Graph? Maybe we’ll go around the horn here and start with you, Simon. Simon, what’s got you excited about the future of The Graph?

Simon Emanuel Schmid (45:44):

So apart from scaling on Arbitrum, there’s one idea that starts to float around that we see this idea of having fusing The Graph for more just as powering front ends or some data analytics, but even opening up bigger use cases. So one thing that goes in that direction is the subgraph bridge that a team is working on, this possibility of then using a subgraph and to graph as a network with all the security guarantees for data and then that data back on chainsaw.

(46:17):

You can think about some risk models that source data from independent sensors that are distributed across the globe built, which then will be deterministically calculated together inside of a subgraph and then the final result of a probability will be then put on chain again. That kind of stuff. It’s more as a think about, the more that my head is like boom, wow, okay. That is really cool stuff coming up.

Nick (46:44):

Well actually blew my mind as well. That’s incredible stuff. How about you Pablo? Anything that you’re excited about?

Pablo Carranza Velez (46:50):

So I think Simon’s answer was a really good one. I’m also very excited about the idea of the subgraph bridge and subgraphs says read oriented rollups. I think that’s very exciting. But I have the feeling that I don’t know exactly what’s coming. I have some ideas and I also find that exciting. The possibilities are so limitless. I do see Substreams coming along into the network as something that is going to be very exciting, seeing a different data type that we’re going to see on the network at different data service. Seeing that integrated is going to be very cool. And then another thing is, we’re starting to see a lot of other protocols and web3 things starting to use account abstraction and simplifying user experience by abstracting a little bit the web3 experience while still providing the same data ownership and security guarantee. So we’re starting to think about ways that we can integrate that with The Graph. I’m excited to see what we come up with and what this team comes up with to do that.

Nick (47:52):

What about you, Ariel?

Ariel Barmat (47:54):

I share some excitement about these integrated multiple data services into the network. As Pablo mentioned, Substreams is one. There’s a fire hose all from other quarter teams in the ecosystem. There might be many more. And clearly this is related to what The Graph is doing, indexing all the information, and it is really unique in the sense of creating a decentralized backend for web3 is hard and challenging, but I think that different pieces are coming together. We see services different in paradigm way to the subgraph like the Substreams, but we also see improvements in what we can do with UI of methods transactions, counter selection, things that can get the consumer closer to an experience that they get in a SaaS but on a decentralized network.

(48:45):

And if we can get to merge that in a way, people can perceive using the decentralized network as a SaaS, that’s a huge win because you have a decentralized backend, it’s easy to use and I mean it’s super powerful. And clearly, nobody did that yet. So it’s very challenging, but I think we are getting closer and closer.

Nick (49:04):

And what about for you, Daniel?

Daniel Nfodjo (49:06):

What I’m excited about is a merge of what Ariel and Pablo mentioned, just from getting The Graph on par or better than the services that are currently offered on web2. I think web2 in itself can be limiting just because of the centralized nature of it, whereas web3 is infinitely scalable just by nature. So getting The Graph that is serving the entire world’s data in a decentralized way, but also simplifying it in a way that people are accustomed to in web2, which is something web2 did really well, which is simplifying things that are super technical and making it easy from a UX standpoint for people to be able to access this data and bringing that over to web3 so that people can’t even necessarily can get all the benefits that they’re getting from web3, like security decentralization.

(50:00):

But the UX and the look and feel of everything is super simple, easy to understand, to the point where people don’t even know that they’re using web3. I think it’s something that The Graph is really focusing on, and I’m super excited about where we can go with that because I think that would be the coming out party for web3 when people can use web3 and not even know that they’re using it. So that’s something that we’re working really hard on and I’m super excited to see how that comes into fruition.

Nick (50:28):

Ariel, Daniel, Pablo, Simon, I’m extremely grateful that you had spent time here today talking about everything that’s happening related to Arbitrum, and again, creating an incredible community resource for people to want to be more educated and informed about all the things that happened to get us here and some of the things that we can look forward to ahead. Pablo, if listeners want to stay in touch and monitor everything that’s happening in relationship to Arbitrum, what’s the best way for them to do it?

Pablo Carranza Velez (50:57):

So one thing is everything we do is on chain, at least from the contract side. So people who are more tech-savvy and can look at that and verify that we’re doing what we’re saying we’re doing. But also, we post a lot on the forums. So we’ve done already several GIPs for this process and there’s a few more coming and there’s good discussions there and there’s a lot of feedback from different participants there.

(51:20):

So yeah, I would invite everyone to take a look at those and send us their feedback. It’s always very valuable and it’s probably the place where you get most of our updates as we go along. We deploy something and almost immediately we say, hey, we’ve deployed this GAP, or this is going through the governance process or whatever. Yeah, I think that that’s probably a good place to take a look.