Gil Binder & Yair Cleper: Lava Network – Decentralising RPC and Node Providers - podcast episode cover

Gil Binder & Yair Cleper: Lava Network – Decentralising RPC and Node Providers

Feb 23, 202455 minEp. 536
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

The monolithic blockchain era appears to be sunsetting. Among the first to contribute to this paradigm shift was Cosmos, which introduced the idea of specialized sovereign blockchains (appchains), made possible by the Cosmos SDK. Nowadays, the modular thesis employs external data availability and even execution solutions, which enables the creation of countless new chains. Each new blockchains comes with its own ‘specs’, and centralised RPC and node providers have to adapt to each chain’s setting. However, the saying ‘Jack of all trades, master of none’ applies in this scenario too - we have often witnessed RPC failures during high demand periods. Lava Network aims to provide a competitive marketplace for RPC and node providers, which would compete based on their performance and user feedback.

We were joined by Gil and Yair to discuss Lava Network’s RPC decentralisation in the modular, multi-chain landscape.

Topics covered in this episode:

  • High-level overview of Lava Network
  • What problem Lava Network solves
  • Decentralised marketplace for RPC providers
  • Quality of centralised vs. decentralised RPC providers
  • Gateways
  • Lava Network participants
  • Specs & APIs
  • Quality of service & provider optimizer
  • How services are priced
  • Relayers
  • Modularity & chain abstraction
  • Magma & Lava mainnet

Episode links:

Sponsors:

  • Gnosis: Gnosis builds decentralized infrastructure for the Ethereum ecosystem, since 2015. This year marks the launch of Gnosis Pay— the world's first Decentralized Payment Network. Get started today at - gnosis.io
  • Chorus One: Chorus One is one of the largest node operators worldwide, supporting more than 100,000 delegators, across 45 networks. The recently launched OPUS allows staking up to 8,000 ETH in a single transaction. Enjoy the highest yields and institutional grade security at - chorus.one

This episode is hosted by Sebastien Couture & Brian Fabian Crain. Show notes and listening options: epicenter.tv/536

Transcript

This episode is brought to you by Gnosis. Gnosis builds decentralized infrastructure for the Ethereum ecosystem with a rich history dating back to 2015 and products like Safe Cow Swap or Gnosis Chain. Gnosis combines needs driven development with deep technical expertise. This year marks the launch of Gnosis Pay, the world's first decentralized payment network. With a Gnosis card, you can spend self custody crypto at any Visa accepting merchant around the world.

If you're an individual looking to live more on chain or business looking to white label the stack, visit gnosispay.com. There are lots of ways you can join the Gnosis journey. Drop in the Gnosis Dow Governance form, become a Gnosis validator with a single GNO token and low cost hardware, or deploy your product on the EVM compatible and highly

decentralized Gnosis chain. Get started today at gnosis dot IO. Cos One is one of the biggest node operators globally and help you stake your tokens on 45 plus networks like Ethereum, Cosmos to last year and dydx. More than 100,000 delegators stake with Chorus One, including institutions like Bit Go and Ledger. Sticking with Chorus 1 not only gets you the highest years but also the most robust security practices and infrastructure that are usually exclusive for institutions.

You can stake directly to Chorus One's public note from your wallet, set up a white table note, or use the recently launched product Opus to stake up to 8000 ETH in a single transaction. You can even offer high yield staking to your own customers using their API. Your assets always remain in your custody, so you can have complete Peace of Mind. Start staking today at Corus .1.

Welcome to Epicenter of the show, which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Sebastian Kritio and I'm here with Brian Crane. Today we're speaking with Gil Binder and Yair Klepper, Co founders and respectively, CTO and CEO at Lava Network. Lava is an innovative project that aims to decentralize data provisioning for blockchains.

I like to call it Uber for blockchain data, and so we're going to be diving deep into Lava today and understanding how it works, the different participants of the network, and what it means for decentralized application development. Hey, guys. Thanks for joining. Hey, how are you? Super exciting to be here. I'm trying to think when was my last podcast with Gil. I can't, I can't remember pleasure to be here. Great to be here guys. Cool. Yeah. Thanks so much for joining us.

Can you guys just walk us through like, what is the high level vision of lava? What is the problem that you're

trying to solve? Yeah. Definitely. I think you know every great solution that started in the war in the world in general, especially in blockchain, had some thesis behind that and we jumped into into lava about 2 1/2 years ago, almost three years it was developing MEVNFT slapping and you know he dragged me in to jump into the rabbit hole and we explore the the the gap that there is about the RPC service. That basically was rubbish and super unreliable.

So we thought that you know the most of the web three is the core data that at the end of the day there are a few infrastructure providers there. So this is how Lava began. It began exactly I was I mentioned before is the Uber for notes. So building a resilient, scalable and decentralized RPC network that every developer can plug into and get service. Today you can get this service from more under the 300 providers and it's super

reliable and super scalable. But that was two years ago and we see that there was maybe a handful of different chains back then and since then the web three evolved. You know we we've seen many different shaping events kind of the, you know the the lunar crash and today we have Bitcoin ETFs, we didn't think about that two years ago. So it means it meant to us that the the problems that back then developer has today, they're much more bigger.

It's not only in the larger scale, but today they spread across of hundreds of different blockchains. So obviously the key innovation here that enabled that is what we call the modular blockchain and modular blockchains were very interesting to me back then, two years ago I think Mustafa mentioned that in his white paper a lazy Ledger, it called it pluggable, maybe a less sexy name.

But today everyone talk about modularity, right chain obstruction and obviously the main thesis for now is building hundreds and thousands of blockchain. And this is what modularity will create over the very near future. And we've seen that there are three main layers for modular blockchain. You have the execution, the execution layer, you have the data availability and consensus layer and you have the

settlement layer. But as we see more and more blockchain, while Celeste for example made it 100 X time easier to roll up one, we've think that there is a convergence in which every every roll up, every L1, every layer that's going to come up, every bloch that come up will need. And this is the data access layer. It started with RPC and indexing.

And you know if for those here who doesn't know what's RPC, basically communication protocol in order to query data every time you open the meta mask wallet making a transaction. Basically it's ARPC request if you check the account balance. So Madamask is querying the blockchain for that. And today, in order to scale the apps over blockchain, they need to get access to data, right? But what's the point? What's the point of storing the? Yeah, just jumping in a little

bit. I'm curious like, so there's a lot of, like different things one could do in crypto, right? A lot of different business models, use cases. Like, what was it about this particular problem that you know you found so exciting? Like, why I built this? Why not something else? It's really a great question. You know, when I started in web three we were like doing MEV stuff, you know, writing bots to snipe tokens and to snipe NFTS and some other really cool stuff.

And it was a huge struggle to just have the nodes right. So if you were trying back then to get the data to run all these operations, you needed to either use like centralized providers like Inferior Alchemy, which sometimes were just very slow. It's just not fast enough for this type of operation. But you also weren't sure that the data is up to date like that you're getting the latest block and this is, you know, what makes or breaks a trade. It's super critical for for the

bot of the latest data. So we started with that. So I was running some bots, you know, I was running some notes here next to me. I had some machines running some notes, and then I wanted to do the same thing on Polygon, right. So I was like, OK, now I need to run Heimdall and you know, I need to run Gore, I need to run more and more nodes. And then I want to do it on Avalanche, you know, And he just became such a struggle and I realized, you know, this is not scalable.

There's no way that I can keep, you know, writing and running all the services myself in a way that's scalable and performance. And I think this is, I think this is one of the core problems in Web Three. If you take it out into the bigger picture in which it's just fragmentation, every single blockchain, every rollout, they have their own concepts, they have their own data access. And this creates this huge user experience problem for everybody.

If it's like, let's say you want to trade on a wallet, you know you're getting an AirDrop from somebody, You have to get another wallet, another wallet, You have to figure out what cast token is being used. And I think this connects with their longer vision. Yes, you have Celestia, you have Dimension, and then I think one of the key unlocks is heavy lava on top of that. And then making everything connect. All of those chains, they need

access to the data. They're useless without all these raw OPS on Eigenlayer, on Ethereum. And this is what we do, right? We're building this permissionless network that lets anyone showing give service to any of these blockchains in a very easy way. So I think the long term vision is like making all web three like A1A one or two or three, but top three like super usable experiences. With our PC. I mean today, right. Like you described, I think the

problem well, right. Like OK, you want to do something on one chain and then you need to snow and now another chain, you know and of course this. Yeah, like a lot of projects applications are struggling with this and and so they like how like free lava, right. If you ignore lava like how are people are? I mean my understanding is right. They mostly use centralized providers like you know Alchemy, quick Notes, chain stack, maybe inferior things like that.

How would you rate the quality of those products? Like what is the What's sort of the weaknesses and problems with the centralized RPC providers? So I think some of them provide amazing service, you know, I think they optimized the service very well. For example Alchemy on an on Ethereum is really good, you know quick now it is really good service and Fewer Eyes is a pretty decent service as well. So I think that there are trade-offs to be to talk about.

But if you look at the numbers of supported chains, they're very small because it's very hard to optimize for many many chains and you might be a champion or like provide the best infrastructure for a single chain and like write your own layer of caching and optimizations to make very make it very cost efficient and fast But to scale it up to many chains and this comes back to the core issue. You need to be an expert in that specific chain and this is where

Lava is different. First, it's not just one provider. It can be if you are quick node and Alchemy all competing. It's like a death match. Like imagine like all the bots are fighting who's giving the best service and in the end you have like the few champions are getting the belts and this is what Lava is like. It's a competition between the providers to give the best

service. So in every single chain of this competition and whoever comes up with the brightest, you know, most unique, most novel way to optimize wins and that translates to really good user experience for the user and the most rewards for that provider. So it kind of makes sense. OK. Yeah. Thanks so much, Gil. That was very helpful.

So basically is you feel like one of the main value propositions is that the centralized RPC providers, they can only cover sort of a limited amount of networks and they're going to have a hard time scaling that up and maybe especially if you see like a big increase in number of chains. And then with Lava you can have a sort of uniform like developer experience uniform way to integrate RPCS across, you know

like all the different chains. And because then you can have different providers basically sort of together providing a service and some focusing on different chains. So be of course, being way easier to scale to like, you know, support a much larger number of chains. Exactly. Lava is like a distribution channel for these providers. Think about it that way.

They can write the best code, run the best operation and infrastructure, and then they compete on this battleground and in the end they get all the users, the best ones. So they're able to iterate, are able to innovate, they're able to build the best data access, you know, capabilities and then they can win and get more rewards. And this is a real time, so over time they they can get better or get worse versus their opponents.

I guess the big question that comes up for me here and I think that maybe Ty serving the next topic, if you actually want to go a bit deeper in here is I guess one of the, I mean I understand the downside of the central SRBC providers. But of course the. Upside is there's like a company and I can sign an SLA and they're going to have a support thing and I get to call them up and and and you know I can probably expect a pretty consistent level of service.

Whereas here if you have like all kinds of different operators for different chains, different, you know, maybe big companies, small companies. How? How does that? Work in terms of the quality of service being provided. It's a really good question, right. So, so I'll just say quality of services like at the core of what we've built at Lava, we spent so much time and energy and effort into ensuring that the quality of services is top notch.

And I think it really is on Lava and I think it's only going to get better. It's got, it's I think it's going to crush everybody else just because we we designed it from the ground up in such a way that the users are actually the ones rating the provider based on their experience. But I also want to touch on your question about Slas, you know signing contracts because I think these are really, really important. I also support support is

critical. You know we spoke, we speak with let's hear, I think we spoke with approximately 1000 projects, you know from the apps to change to ecosystems and getting their feedback on you know what what do they need, You know how is what whether or not happy right now with their infrastructure and support is critical for them. So the way I see it, you know in this, in this world of Web three, there has to be a way to build a business that also supports the ecosystem that it serves.

And the way I see it, maybe it's very similar to the Red Hat Foundation for example, where you have this open source project or like you have the the Lava network and then you have this company or multiple companies that basically provide support for customers the onboarding them through gateways. So they can use the gateways,

they can pay for these gateways. The clients also pay on chain for the service, but they get the support package, they get the Slas and they get all these enterprise features, maybe it's on SoC certification so that they can operate under the standards that they need to. So I think these are these are two answers. And can you explain what? Gateways are. Yeah, OK.

Sorry, I didn't touch on that. But basically when you use Lava, and we built it like this because we thought this is the best way to to provide, you know, really good quality service to everybody. When you use Lava, you don't have to go through any central server. So think about, you know, centralized servers as basically like a middleman that sits between you and the and the data

that you want. And this middleman is basically you're going to it and it's going to get the data for you and then it brings it back to you. He lava, we build it the own way and such. You talk directly to the providers, so there's no middleman. You directly go to them, you get the data. A gateway is a middleman like that, only it enables easier access to the data by providing support and Slas and everything that you mentioned.

It's funny, Brian, when you were asking about whether you know you could well when you were comparing to to centralized providers and you were saying that with a centralized provider you have this SLA and you can call them up and whatever. I just couldn't help but think, well isn't, I mean that's the same for your bank and you still use blockchain and crypto,

right? I mean, you know, this, this extends to the broader, you know, the broader crypto space I think and and yeah, so it was just like a sort of funny remark there. You're just using Web two tools in order to operate in web three and for us it didn't make sense in the beginning. And in order to scale to cause the billion daps and people like onboarding on web three, we need the scalability infra. Yeah, no, I I think that answer

makes sense. I mean, I I guess one thing, the other thing that comes to my mind here is of course we have we've also seen some decentralized projects actually doing like an OK job, my understanding or me maybe maybe even good job at support. I think osmosis is like an example, right? Where they're used to community pool, to like fun teams, to you know, deal with support requests and generally I've heard like good feedback that seems to be

working pretty well. But yeah, the gateway thing also makes sense. So basically then I would yeah, like let's say as. A as an. Operator or like as someone needing RBC, I signed some contract and then I can all, you know, always query.

Basically all the requests get routed through that gateway node and then they can like let's say track up time and if they're issues they troubleshoot it and maybe I can pay them with dollars or credit card and they pay cause 'cause in the end the operators would get paid on chain using lava tokens or like how do the payments? Work to the operators. So yeah, so the way it would work and I think you know the gateway concept is an open gateway.

You know anyone can talk to the foundation put up a governance proposal and start operating gateway the the but the important part and this is also touching on Seb's points I think is which is interesting is that it's it's done in a way that is also familiar to the customer. I think this is in general a way that you know web three projects need to be able to to give answers to web two type customers.

I think it's, I think it's crucial in the end you want to operate with many, many different companies that want to use a service and they need some sort of a gateway right, to get familiar with it because they don't know how to buy tokens and go on chain and buy a subscription on level.

So maybe it's easier for the first step for them is to pay this type of gateway operator to buy for them and then give them the service and then the operator you know goes by tokens, goes on chain buys it for them with some kind of referral code. And this is how it works. And this referral code basically gives that provider a portion whatever he agreed with the governance.

To now operate this contract. So say you want to buy the service, you come to this operator, you pay, let's say 100 lava, he goes on chain, he buys it for you and he takes a 20% cut. And then with this 20% he operates, You know the servers, he operates the support centre, he offers Slas, he does audits and gives you the convenience that you need for Web 2 project. But if you're a fully Web 3 project and don't need any of that crap, you can just go and

change. You can buy the subscription with tokens and you don't need to talk to anybody or go for any governance or go for anything else. Let's go a little bit under the hood here. I'd, I'd love to get a better understanding of like what the network topology looks like. So you know, we talked about some of the like the, the, these operators, but what are all of the roles in the network and how are they interacting with each other and I think importantly how are they interacting with

applications? So I think one of the core principles that guided us when thinking about Lava and by the way we are Lava protocol. So the core contributors to the Lava network was to keep it simple, right? We have three different actors, main actors on the chain. We have the Dapps buying on chain subscription.

We have the providers taking Lava in order to participate and we have the validators that keeping you know keeping the service running And down into that we see that note providing note provider serving data modules that they're called specs and those specs are being defined by the Champions that Gil mentioned before. Champion can be anyone from any

chain. Whether it's a small upcoming roll up or it's a used existing chain doesn't matter but just coming up with the governor's proposal in order to define this spec. Actually it's creating this unique spec that the dapps can afterward use. So these Dapps in consumer, they using this data and they being paired off with the off chain peer-to-peer communication protocol directly to the provider themselves.

So imagine that that from the browser you can get a list of top providers and receive service. When Gil mentioned before we were speaking with more than thousands project this year, they constantly refer back and told us about the problems that they're having. They they're using centralized provider and usually not once, but then they need to come up with node balancing with disaster recovery with all of these different things that is a small DAP, they don't need to do so.

Lava taking this burden away from them and implementing that and give them 99.999 availability of the service. After the service has been done, the DAP signing the transaction and sending back all the different parameters about the service. So availability, the reliability of the service, the accuracy and this is made, this is being used for this score to score again the provider for them to get more and more service. That's in general the different

actors on the chain. So just one thing, you know, think about the blockchain like a restaurant and think about specs is like the menu at the restaurant, right? So the menu of the restaurant tells the people come to eat, this is what you can have. You can have this type of salad or this type of soup or entry and this is what specs are. So for every chain you have these, these different menus,

right. And the way we see it is that you know any chain that is launching an OP stack, you know, like BLAST or any other ones or any chain that is launching on Dimension, for example, any roll up that is launching on Dimension or Arbiter, they can immediately, this is the vision, the spur of the launch, you know, propose this back on chain, this menu that immediately you have all these, you know, hundreds of providers who this is their job, this is

their bread and butter. They come in and they're like we're going to run nodes for this. We think this is going to, you know, give us a lot of rewards. They go ahead and run nodes. Then you have, you have this amazing network of node operators giving all these customers the best service. One thing that you know always happens and we see it every single time. I think everybody's going to agree with me.

As soon as there's like an AirDrop or there's like a test net being launched that people start. So you know, farming we're playing with, the first thing that happened is the RPC crashes and collapses. We see it every single time. So this is where like lava can completely shine and take over all this usage and scale really easily. So I want to talk a bit more

about this this spec concept. So a spec is a document or specification that a a a chain or project will put forth and then it specifies as a specification does what data to provide. Does it also specify like how to in the case of an indexer. For example, let's say we need to fetch like some time weighted average price like some some some some price or like some complex data feed that requires some complex calculations about like pricing data that that is

found on chain. Does the spec also specify how to arrive at that result so that it can be displayed in the application in the front end? And I think importantly, what is the method by which you know this valid? This data is verified and validated in order to maintain like accuracy of the data that's provided. That's really good question because yes, it so the spec, it defines as you've said what type of data you can get like a restaurant, like a menu at the restaurant.

OK, you can get the soup, but you want the soup without you want the salad, but you don't want the dressing you want on the side, right. So the spec would specify you can oh, can you get the dressing on the side? Can you remove the onions? I'm going to have a steak, if you don't mind. So what's your, you know what How would you like it cooked? Medium well, So this is what the

spec specifies, right? It does not specify, it does not go into the kitchen and tells the chef, oh, make it like this or make it like that, right. This is something the spec does not. This is the burden of the developers that are building the chain. So they're building the way to actually go and get the steak, Make the steak, where to get it from 1 supplier. What it does with the menu. It does tell you what the steak

is, right? Is this a Wagyu A5 or are you getting some you know something you know low rate. So this does define the the quality, right. So these are I hope, I hope it explains as well. I think it's a really cool concept.

So I'm curious so I I mean in the case of IPC then that maybe it's like slightly less relevant I imagine no because like you have like a chain has this like RP spec or or like maybe but it's like you know it's it's basically like RPC node for like a particular chain is I imagine going to be pretty uniform. But I guess I wonder is that where this sort of API concept comes in as well, where someone can make you know a spec for something like you know that you cannot get from a normal RPC

node. And yeah, maybe can you talk a little bit about sort of beyond RBCS and especially like how Lava can be used to provide AP? Is yes. So first, it's not uniform at all at all Ryan. It's completely any. Every single Cosmos chain for example has like a different variations and add-ons and every one of them has a different versions of of Cosmos SDK. OK, so every version has a different spec, so it's not,

it's super fragmented. This is why RPC is difficult, that's why it's tough to get right. This is why we've built it in such a modular way. The second thing that is important before I get to API is that the spec also allows you to specify validations, which is like how many blocks are you expected to get. Because a lot of our customers, they want to get, you know, they want to index the whole blockchain from from block 0.

For that you need to store on many chains, you know, 10 terabytes, 1220 terabytes, maybe even more. On some chains. This is a huge burden. Obviously not all every operator can could do that, right? So This is why we have these types of validations and extensions. So an extension allows you to say, you know, I'm offering you know, the latest data for the last two weeks, whatever however many blocks it is.

Or you could say I'm an archive node, you know I have the storage and capabilities, but I expect to get paid five times for archive data because I am taking a bigger burden to touch on APIs. So yes, the way we've built specs is a way that allows anyone to write spec in a way that is supporting of APIs like indexing, like sub graphs, any types of APIs. So you can go and write a spec

that gives you access. And we're working on partnerships with different indexing projects like Subsequid for example that that you basically you know copy paste a subgraph run it on faster infrastructure, faster indexing using Lava and subsequent and still get all the the many providers quality of service and the the data reliability. So we we touched briefly on the quality of service aspect which is like very important in the context of RPC and and data

provisioning. How can you go into detail about how the quality of service algorithm works and how to do users that are, you know, pinging RPCS know that they're going to get a good quality RPC provider or indexer? Yeah, you know, we went to great lengths to make sure that the the service is really top notch. We really did and it starts from the from the beginning. Basically, how do you choose the

provider? So you choose the provider based on how much money, how much stake they have in the system. So the more stake they have, the more likely that they will be in your pairing list. Pairing list is the list of providers that you can use. Once you have this list, you can talk to any of these providers. So we've written this very complex engineering feat we call the the provider optimizer. It's it's by the way, everything is seamless for you, just like

using a regular RPC. So the RPC, the provider optimizer is basically like a friend that goes and checks every provider, Give me the latest block. Give me the latest block. Whoever is the fastest and has the most relevant fresh information like the latest block, so that you're not looking at all data. It basically saves them at the top of the list and then when you get the data, you're talking to them. So let's say you have all these providers, you're in Europe,

right? So someone in, you know, Central Europe has a server, and he's really, really fast. You're gonna be talking to them. So this is what the RPC, the provider optimizer does. Now, as you talk to him, you start writing down, OK, this guy, OK, it's giving me, you know, it's fast. It's slow. Oh, here he was, you know, he was not as fast as I expected. You know move to somebody else, you write his report cards, you save them and then you send them and then they get on chain from

these providers. There's a process I won't get into it. These report cards go on chain and they affect the providers payout basically. So the provider has an incentive to always provide really good service. So but it doesn't affect the whole payout. On top of that, we have what we call excellence, quality of service. And this is the same report cards. Over time, they accumulate on chain and they are saved in

this, this provider's profile. So this is like a way to build reputation for a provider on chain. And then the last step, not too much the excellence, quality of service score. Their reputation for this provider is also one of the factors that affects its pairing list. So go back to the first step, it's how much money is taking because if he takes a lot of money saying I'm serious, I'm here, I can handle your requests. And then over time, how good

were you? And we have all these customers that are paying and they're using their, you know, payouts basically to score. If you go back to the menu example, it's like you have TripAdvisor connected directly with the with the menu itself. So it gives you constant feedbacks for the meal you just ate. But it's built in, you don't need afterwards to get something. Everything is happening on

chain. OK, and so users are rating the the service providers, it is the end user like the guy who's doing the transaction in meta mask, you know on Uniswap or whatever application is using Lava that is doing this rating or is it the developers? Yeah, it's it's when you say doing that's that's an interesting way with everything is happening automatically, right. So during the transaction we are aggregating all the different parameters, all the scalability, the freshness of the data.

So those are being used in order to score the existing transaction, the existing session with the provider and during during the lifespan, obviously the scoring change according to the service they they give. So how does that work if if the actual service is provided like peer-to-peer without some node in between like, how would you? How do you even have that information? That's that's really good question.

I think it's and it's a a bit complex just because of how the protocol is working and I think you know this is where the gateways come in and this is where the SDK comes in. So as I've said in the beginning, you know you can use Lava without any central middleman to do that. You can use the SDK or you can run your own gateway right? And this is all open source. The other way is if you use a gateway. If you use a gateway then the gateway basically scores for you.

OK, so this is how it works. Now the spec. That we talked. About, which is like one of the core components of Lava, is basically defining the communication between the consumer and the and the provider. So actually there's a, there's a protocol, there's a network protocol that wraps the actual

RPC query. With everything we just spoke about, this is like a channel between the consumer and the provider with everything, the rating, the quality of service, the conflict detection, which we didn't talk about. It's a way to ensure that the data is accurate as well. Cool. And how does the pricing work here? How is it determined you know how much these services cost? You know the beginning. We were always giving this answer that, you know, ask us

how. How come you were coming up with this good service and basically we said we took all the top centralized provider pricing list, put it into the ChatGPT came up with a better price. But the thing behind Lava is the that is a real economy, right. It's a real market that going to balance between the supply and demand. So if you start with a certain price it can goes up and down based on the demand. So I it can give you an example.

If there is a you know a service, an NFT drop that's being given in like a place that there are not many supply, obviously the price is going to go up and going to going to invite more and more providers. Let's say you know suddenly there there is you know NFT drop and a need in Africa or South Africa or something and you have only two providers there.

So obviously the the demand upon the drop going to be higher and higher again and this is how we balancing the, the protocol is automatically balancing the supply and demand mechanism. I'll just add that even though we're you know we've been running in test net with we've already signed contracts with ecosystems and these ecosystems have distributed 10s of thousands of dollars to providers.

This has already been done and there's hundreds of thousands more that are going to sign and distributed in this year. So I think you know it's already showing, it's lava's already showing instability to really support different blockchains and to touch on the pricing. As I said for for ecosystems today, you know the way it works is they go to let's say one of the big centralized providers and they sign a contract.

This contract can be for a whole year, can be for multiple years and this contracts locks them in to a certain price. And one of the complaints we've heard from them is that they don't want to be locked in because sometimes the market is not active and sometimes the market is really active. So they want to be able to balance the payouts to these node drivers based on the demand. And I think it makes complete sense, right.

Second pay as you go. So it is the most, the most efficient way to to to pay providers. So this is what is built in love. So these ecosystems like Efmos, like XLR, like Near and and many others that are signing and have signed already, they are able to set their own budget. They're saying this month or next three months I'm going to put let's say 10,000 lava tokens in the in the pool, on chain, in this, on the spec, on the menu and then all the providers know this month you get it 10,000.

So they can decide is this worth enough there OK, there's 1000 providers. Does it make sense for me to join? Maybe not. OK, there's 20 providers. Does it make sense From Yes. Hell yeah. You know, if I'm good, I can get a really good share of the pie. And This is why it's a dynamic market. Interesting. Yeah. So, so there is this kind of like market equilibrium that you know you hope to achieve here depending on like demand and you know how well networks are being

served. Is this something you've already demonstrated with the networks on which you've been, you've been working with like that data providers rearrange and reposition themselves on particular networks when demand is higher and retract when demand is lower? We've been able to demonstrate that using Lava you you're able to give an excellent top notch service of RPC and attract many providers, but the payout has been constant.

In the near future as we launch Mainnet, I believe this is going to change and it's going to be much more dynamic, but it's a process that will happen over time. We are seeing that and this is already live on test net that these rewards they make sense for providers to run and give

really good service. We've, we've received a lot of praise for the different services we're offering to these ecosystems and we're seeing inbound from other chains that have recently launched test Nets and has been struggling. They're reaching out to us asking can we use the same incentivization model to bring in more providers for our network. So we're definitely seeing it

taking off. Yeah, and I think it bears reminding people that Lava has been in test net for a while, but that it it's actually like working with live chains. So even though the network is in test net, all of the data providers are actually providing like real data and there's something like 30 or 35 networks currently live on Lava, correct? Yeah, it's a production grade system, right, Right now, like

for for one year. And I just want to touch upon the previous, you know what brought us to ecosystem because Lava started as a decentralized service and today everyone is talking about decentralized RPC service. But then we got approaches by ecosystem to solve and take away the burden of public RPC. Because public RPC is the first stop of every dev into the ecosystem.

So if the ecosystem is able to provide a scalable service RPC and then APIs and solve these you know headaches of how do they accessing data for different apps, It goes without

saying. So ecosystem came back to us and told us can Lava actually provide this public RPC, can they give, can you give us insight into the ecosystem And obviously we jumped into that and we presented in October 1st time that incentivize public RPC when the ecosystem put in incentives for different provider to join permissionlessly and get reward for the service they give.

And we started doing that in Ivmos and afterwards in Axel R we just announced near and all of this distribution of the different rewards being being done only in the last few months. So working on three different chains. So in the pipeline we have now from 5 core and Starknetcoy Agoric and more are coming to level. OK, very cool. One thing I wanted to inquire about as well is relayers.

So one of the issues, you know, particularly in cosmos chains is that like realays are not incentivized for their work. Does Lava facilitate the matching of, you know, chains and relayers as well, or is that completely outside of the scope? Yeah. I think that you know we're seeing a lot of discussions around IBC and it's fundamental design and I think you know IBC has been an incredible protocol that really puts you know cosmos lights here ahead of any other

ecosystem. But in at its core there's a core issue with payments for real layers and I think that we will definitely be able to see Lava help with that. Right now our focus is launching mainnet, you know bringing the power of of you know the modular unlocked as we can do with lava to to chains and roll ups. You know they're built on Eigen

layer on Ethereum, on dimension. But for sure, you know once we're, you know we're more, we're done with that, we're definitely be able to help with relayers and and try to solve core issues like that in the Cosmos ecosystem as well. So you mentioned model again. Yeah, you mentioned it earlier. So of course I understand that you know for also modular chains roll ups, well you still need RPC, you still need this thing.

So I understand how like you know the you know lava stack is still is still relevant in that kind of modular world. But I'm curious is, is there more to this or? What do you see? As sort of the connection between lava and modular chains. If you look at you know Web 3, right, if you look at what's happening today, I think that everyone's coming to the same conclusion, right.

There's going to be an explosion of chains, but how many chains are going to be like the full purpose, not specific purpose, Like if you're on full purpose, you know you can run anything you want, smart contract or you have application specific ones on Cosmos or roll ups. So I think, I think it's pretty obvious that in the future we're going to have all these chains, they're going to explode, they're going to be super successful, but how do you weave one path through all of them?

It's super difficult. And it sucks. I mean, it sucks today trying to use all these chains. It sucks. It's really, it's really difficult even for, you know, I'm a tech user and consider myself a power user. It's difficult for me to keep track of all the chains and all of my assets across all of them and to interact with them and and bridge tokens and make sure I'm using the right bridge and don't get hacked. Until we solve this core issues, we're not going to have a good,

a good system. And one of the things that we're seeing prop up and I've been thinking about it a lot is how do you like imagine the future Web Three, you have one wallet and it has access to all of the chains and it shows you the assets on all of your chains And you don't care where your assets are. You don't care if they're you know on on you know Cosmos, Habi don't care if the the assets are on Ethereum Arbitrum, you don't care where they are.

They're just there and you want to move them somewhere. No problem. You don't need to think about wait, do I have Osmosis OSMO token to perform the trade to do to move the tokens or do I have this token or that token or start thinking about the gas, you know, so I think the future of Web Three is some kind of system that allows, you know, for full chain obstruction. So you don't even think, you don't know what a bridge is, you don't want gases.

This is the only way to reach mass adoption, which I think is the goal of what we're doing. And when we were thinking about lava, we think about modularity. We're thinking how can lava be one of these core key unlocks in this, in this stack. And we see that, you know, OK, there's RPC, we can talk about RPC all day, but it's really, really boring. But you have to do it really well, but then you have to be able to launch it really fast for all these chains.

But what if you could, on top of the RPC and on top of the APIs use this now network that has basically stakes from every single ecosystem and all these providers are now staked to verify the data is correct on lava. What if you're able to use that to build song chain abstraction that enables you to, you know, more freely, move assets around, you know, access all the different blocks without even known and still trusting that the data is correct, still have

everything decentralized. So this is what we're trying to think of, of the grander vision of of chain abstraction and how long it fits in and unlocks this. If I had on top of that you know what you said before when describing like doesn't matter if you take the monolithic path thesis right the the modular blockchain or if you go to the roll up centric all of them need the data access layer.

If you give devs devs the the right tools to build the the infrastructure, if you build them with you take the burden away from them from whatever they building. This will scale the industry and Seb you mentioned before the the

banks right? So if there is a 2 providers that you go for them for the data and and two of them is down, how are you going to get access to your meta mask, How you can promise your users as a wallet that they can make transactions, all of that we believe with this modular layer, it's something that Lava is able able to save and we call it build whatever, wherever, build whatever it's you build it whatever you want, whatever adapts, not focusing on the

infra and wherever is in the multi chain. So can you guys talk about Magma? Yes, of course. Magma is a super exciting confidential project that's not anymore gonna lie. Sorry, but it's not live right. So we're gonna, yeah, it's gonna we're gonna announce it on the 15th of of February and this is basically brings in non-technical users, all of us that have a wallet to share the the Lava vision to share the web three values. The magma is the point system

that Lava is presenting. It allows any user to use the Lava endpoints chain that at the back end of the wallet in order to get access that is super available. It's decentralized and obviously it's it's scalable. So basically jumping quickly into the magma. Magma is the phase coming always before the lava and we already announced that the minute is going to come up soon.

Magma Point system is a signing. It's a program that every every use every user that has a wallet can sign up and start receiving points for the the usage you do with the wallet. For transaction you get scores for just watching the wallet. It also create creates points and because all of them is at the core that making RPC request and every RPC request is being scored for you as a as a as a user and you can watch it over

the lead port. Cool. And so, which brings me to my next question, when mainnet. Mainnet, you know our engineers working around the clock in order to address the mainnet, we're trying to push for end of Q1 and yeah, this is a super exciting time. So, you know, stay tuned for that. Very cool. And so where where should people go if? Well, I guess it's a couple

things right? If you're building application and want to integrate Lava to provide RPC to your users, like there's like one category of people that should check out Lava. But also, if you're an infrastructure provider and want to provide infrastructure for the Lava network, where should these categories of listeners go to? So I think the team did a great job writing the, the, the documentation.

We have an amazing discord channel with thousands of member, very vibrant and always asking questions, getting getting them answered by the community themselves for the new users. So start with our website lava net dot XYZ. You can see there are a lot of documentation and jumping over this court. We call also the non crypto non tech users to amplify and bring

more of the values of of lava. In the upcoming months, the foundation will reach out and, you know, present different programs and we all start tomorrow or the 15th of of February with the Magma with the Magma program. Cool. Well, thank you. So thank you so much for coming on. Actually we just wanted to mention one thing which I think we you should have mentioned the start but we forgot. So you know as most of you know my main thing is running course

one. And with course one we did invest in Lava and we're running Validator and I think Seb Rip his fund also invested in Lava. So we just wanted to mention that. Yes, Interrupt Ventures are also investors in LAVA, so Full disclosure and running validators. Cool. Well, thanks so much guys for coming on. That was super interesting. I think it's definitely something that I could see getting a lot of traction right.

And it will be really great to see how this sort of things evolve once a minute is live and you know over the next year. So thanks so much for coming on guys. Thank you so much. Pleasure being here. Cheers. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever

you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it. To listen to the latest episode of the Epicenter podcast, go to epicenter.tv/subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter so you get new episodes in your inbox as they're released. If. You want to interact with us guests or other podcast listeners? You can follow us on Twitter and please leave us a review on

iTunes. It helps people find the show and we're always happy to read them. Well, thanks so much and we look forward to being back next week.

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android