Hashing It Out
Hashing It Out

Episode 127 · 2 months ago

Application infrastructure Pt. 1

ABOUT THIS EPISODE

Hashing It Out is continuing its series on the blockchain infrastructure with the Application layer.

In this episode, Corey and Jessie talk to Patrick McCorry, of Infura and Lemniscap.

Click here for the Infinity Keys Challenge. 

Part 2 of the Application layer, coming soon. 

We don't really introduce ourselves, should we. They know who I am, they know me. Welcome to the Hashing it Out podcast, where we talked to the tech innovators behind blockchain infrastructure and decentralized networks. Your hosts are Dr Corey Petty, currently doing research at Status and waiting for other people to keep up. That requires no effort from us. Jesse Santiago, a former electrical engineer now working on decentralized storage at Status. No no no, I thought we were wrapping up. You're going to end the recording and with a deep voice and the deep questions de ferguson okay, strapping in. All right, let's go, and I'm the Hashing it Out showrunner Christian no Gara. He's like, I don't know what to say to that. Thank you. Hashing and Up Blockchain Structure series continues with today's episode on the Application Layer with Patrick McClory. Welcome back to the Hashing It Out series, where we talk about Obviously, this series talks about all the infrastructure put into place in UH blockchain networks and some of the trade offs that we have to make when designing these systems and choosing this These particular technologies to build the networks. As a short recap for you, Patrick, we have gone through uh so far in the series, starting with computational infrastructure, moving into networking, which covered a lot of like peer to peer networks and what it's like to introduce privacy and secrecy and trade off of gossiping things like that. And then the consensus, because once you have a network, you need to agree on something, so we talked about distributing consensus and the kind of flavors of that, and then from there we talked about data, which is what you're coming to consistus on UM and what is the purpose of data within a blockchain network. Now that we've gotten past that, we're talking about kind of execution environments and the application layer. So like you have data, but like what do you do with it? And what are different ways you can UM create execution environments to make distriguar applications. So with that in mind, why don't you give our audience a quick introduction as to who you are and what you do? Yeah, um, so, I guess, like historically, speaking out as an academic, I did my PhD in bitcoin and then etherorium from and I shortly made the transition in later years just to work on the theoryum uh. But I guess historically I've always been interested in all cheon scalability, you know, the ideas can we take you know, transactions that should be on the men che and but move it somewhere else, you know, as we move the competition away from the men And so I was excited for the Lightning network back in ten for bitcoin. I still I'm excited for that today. And I guess in later years I was excited for plasma and roll ups and sort of just really watched how they've evolved over the years. And I spent probably the past year trying to figure out an easy way to explain why rule ups are useful, you know, really explained to normalis you aren't really into the I don't know the deep technical details of why this is a useful technology and why we should care about it. So that's sort of what I've been doing for the past year. Well, it's just assume that people understand, um, where to go to get data and how to interpret it. How do you how do you think about building an application on top of that? Um? I mean, I mean this does get into a debate between the Theoryum and Celestia in terms of you know, building the app. So really what it comes down to is, uh, you build an up and you deploy it to this network. You know who's protecting who's protecting it. You know who's guaranteeing that the application has runners expected, You know that the program is fearfully executed and opdates to the end of bit is fearfully on. Atheroreum, we're relying on the entire Ethereum network. You know, the validators appear to hear network because...

...we all follow exactly the same rules. So we can guarantee that if you deploy an application to Ethereum, the network as a whole guarantees that is executed correctly. Um where if you start moving to a strict data availability layer sort of like Celestia, or all they care about is pools in the data, then what you're really relying on is anyone who cared for your application. So let's say I've deployed my sovereign rollout. You know on Celestia, anyone who's running my client software and can interpret interpret the data that's relevant for my application, they are the ones who's protecting it. And so it's very it's a very different security model. One is the users of the system are protecting it or the entire networks protecting it, and that really comes down to, you know, the client server that's being run and the expectation of people that run that client software. So it comes down to trust and guarantee is fearfully executed. I don't know too much about Celestia, but I keep hearing more and more about that one. Um. So in in this case um Celestial, it would be the ecosystem in which the users caring about the application ensure security versus ethereum it's the entire network exactly. So it's a bit like color coins back in the day. So color Coin was a application built on top of Bitcoin that lived outside of the Bitcoin script. So the idea was that I could run I could download the color Coin application. I could then and my color coin client would process the Bitcoin blockchain. It would find the data that's relevant and then given that data, it would work out if I own any color coins. You know, it with check the validity of those transactions. But the important bit is Bitcoin wasn't checking the validity. It was just a bulletin board for the data. It was the color Coin software that was really validating whether a color Coin transaction was correct or not. And so there you're relying on the color Coin users to check the correct and so Letsie is a very similar model of that. They just got rid of Bitcoin scripting and get rid of all the scripting for the native layers. A set, here's all the data if you want, you know, if you want to, there's a public hard hard it's hard to mess with the database exactly as a public bulletin board, even as this pushes all the data there. Yeah, and then anyone then you can decide how to interpret the data afterwards. So yeah, it's very most like color Coin back in the day. But it does come down to your question if I'm gonna if you know, if I'm designing applications for a data layer, what do I have to think about? And ultimately what you have to think about is how do you guarantee that's fearfully executed and who's protecting it when it comes down to users or the actual network itself. And the network comes with a cost because it's expensive to do globe with senses. That's interesting because the I don't know the seeming of how to think about the future of this stuff keeps changing slightly because it started out as this kind of everyone runs all the software and has a local copy of it UM the theory. I'm kind of ran that concept into the ground by expanding so quickly and generalizing what you can do with the network and the network and everyone of the network doing everything UM. But it also made it easier to reason about how to build applications on top of it. I build this application that leverages the theory network if their network handles most of it, especially the trust part. All I'm doing is making you know, ostensibly a front end that access is a portion of the network. UM. And now we're moving back to this this concept where like that trust isn't guaranteed as much, and you need to contextualize the trust to the application. And it's not just the dumb front end because you can't scale that monolithic entity. Were like all my trust that's pushed into the computer to the network. Uh. And I'm trying to...

...think about like how reasonable that is for regular people to navigate. People get their application, they just want to use it, and now we've had additional responsibilities to them. Again of what am I using and how do I trust it? As opposed to it's the theory of network. I already have a general idea of how much I can trust it. Yeah, um, I'm trying to think the best bad They answer, that's so that's quite tricky because I would I'm my philosophy as our users shout and have to care about the security of the system. As in, you know, they're non tackies. They they just want to you know, lock their coins into a system. I actually want to lock their moon cat into a system. I'm band sell their mooncat. You know, that's that's sort of their goal. But what a user does care about and I think this is very important to sort of you know, profous Elvency. I want to make sure if I'm using a system, well they can actually get my moon cat back out. Um, so I feel like that the be so I think he really cares about this for developers and organizations. You know, if I'm an organization today or a venture funded start up, and let's say I want to compete with coin bas you know, I'm not going to be able to compete with coin bases operational security to protect cans and billions of dollars. That's impossible for me to do. Well, maybe it's not impossible, but as huge mountain the client. But I could deploy software that automatically protects the funds for me, but I can still build that coin be as like experience. Then That's what I'm going to do because then I don't have to take I don't have to worry about protecting users offsets because the software takes care of that for me. And then you just get down the robot hole off you know, how does it protect the users offsets and the funds locked into the system? And then that comes down to do you want to side chin? Do you want to roll up? Do you want to I don't know cosmos chain and there's that's a different ways to think about how you know the software STACTU do a take to protect the user's funds? Interesting, I have a I I guess I subscribe to the philosophy where like I want to run everything and I want to understand how it works. I'm not you know, I'm I don't consider myself a developer, but I also don't consider myself like a normal user. I kind of want to be able to say that I understand enough of what I'm running that I have control over my data. Uh, and you know, I I don't have to use UM or I don't. I don't have to trust that the security of the network allies with some other entity and say moon math you know, I don't know. We trust moon Maths all the time, and I think that's a time trust. Yeah. Okay, but I think you I think you made an interesting point there that you want control of your datas That's one I thing I would ask is do you want control of your OFF? I think it's not that you want control of your data. I think what you make care about is who ultimately controls your funds or I guess when you say did I think OFF you have your private key, you can sign transactions, people can still your funds. But you still want to use, you know, an external service, so you need spops nice because it lives on ethereum. But let's say you want to use coin based, then you have to give up custody of your funds, and that's really annoying because it's this big black box that you can't see into. So I think what you probably wanted as a way to audit a system before you use it so you can have some confidence that your funds will be see if when you're interacting with it. Would that be a fair classification of I think I think a little bit like a few levels higher than that, but close. Yeah, Like for instance, we had um, we had uh whole Landski and Eduardo from depth note on. So you know, like adapt node stereum model where you...

...know, they make it quite easy for users to run your own node something like that. That appeals to me. Um, yeah, I mean that'd be really cool, like like let's buy a big fan of the rule ups. So if you look at Arbitrum, for example, you can download a replica node and you can check what their database looks like in real time, you know. So it's a been like you know, when use Arbitram's been like coinbaus in the way it's like you send a transaction, get this instant confirmation that's complete, and then it goes through the stages and gets processed and on an up node. I don't know if they support replica nodes yet, but they will someday, and then you can actually know check in real time that something like arbitraum is you know, it's it's actually secure and see if in your assets are there and no one's hacked it yet. Um so yeahm very much in the philosophy. Wold be really nice to be able to check in real time of these off team systems are actually working as we expect. Yeah, that sounds like a good compromise something like that. I think that's interesting to kind of dive into a little bit more your um, what are what are the guarantees we can expect a blockchain never to be giving when they're incorporated into an application, Like why use a blockchain? And what should we expect the user to understand in the process of using using an application that leverages a blockchain? Yeah, I think there's several ways the answers is and just de beating the best Where the answer to begin with? Okay, let's start with the network one, like the fundamentum when you were talking about earlier. So, um so we sort of give that. You give the example of a theory went down one extreme and of having two most programmability and this is really expensive for everyone to verify in real time where a Celestia went on the other end? Was this data? You know there's new computation there really Well, maybe they will when they release. I don't know, but it's minimal computation. I think an ideal blockchain for developers to build on would be like in the middle that you want to express, have blockchain so you can write smart contracts that define the conditions to keep a system see if you know. H So for example, Uh, you know, I want to lock my funds into an off chain system. I want to know the exact conditions in which they can be withdrawn. Ah, So what my ideal one would be ideal layer with minimal competition or minimal it's fully expressive, but the computation here's is very minimal in terms of just enough associated guarantees you get from yes that data, yeah exactly. Yeah, where most of the competition would help happens somewhere else would be nice. You know. It's uh, that's how you can scale these networks. But I guess that's how we have skilled these networks. Um, and I'm trying to think of the other way. What can you repeat your question again just so I can what guarantees to start to users to have when leveraging an application. That's awesome. Yeah, so basically that really comp so instead of you know, why use a blockchain? What is a blockchain? It's probably the easiest way to answer this, so people typically get confused when we talk about blockchains. The blockchain is as an automatic I call it a cryptographic audit trial. At what cryptographic data? You know? It's just a cryptographic audit trial, data trial, a trial. Yeah. It allows you to audit a database in real time. So the idea is that you're running in you know, your your developer, you want to launch your service, you have to create a database. Now, most databases are private by default because that's is how we build stuff and web. Two, I would use the blockchain because one, my database can be public, so anyone can read it, anyone can get a copy of it. And to the blockchain is as an audit trial that gives other people confidence. So I hang down with the blockchain. I can recompute the database that you have and if I can check them my database is the same as your database, then...

I have confidence that is correct. So it really comes down the confidence and you know, minimizing trust that I don't have to trust you necessarily because I know your database is correct, and that's because I can independently verify that is correct as well. So I think fundamentally it just comes down to do you want your system to have an auditorial or not that anyone can verify as correct. And so in the case of the f t X, that would have been really useful because we all could have checked in real time if they're assets covered the liabilities. That would be a really useful feature to have. So that's one reason to use a block you in. And then when you get to sort of like stuff like the Ethereum network and this autonomous network where you can deploy autonomous smart contracts, and I think what it really comes down to you there is, you know, could you build an application that replaces an intermediary. So if you look at really popular applications on Ethereum, you know we have we have exchanges, we have voting, we have auctions um and then even token issues. You know, there's rays the issue tokens. And what's nice for most of these applications is that we've replaced human operators with autonomous you know, programmable smart contracts and we can have auctions without any auctioneer because the auctioneer is the smart contract. We can have voting without, you know, Italian authority because the Italian authority. It's a smart contract and we can have exchanges without you know, I don't know what you call it brokers without brokers, because the smart contract is the broker. It's matching the band and the sailor automatically and so on. The on the least extreme, and it says you have an audit trail. One reason he's a blockchain and more more networks is that you can just replace intermediaries of code. And that's great because now there's no bottomneck because you're just dealing with code and not humans. We know software scales human stone. So it's a very good reason to use a blockchain. And there's not a trailer. When you look at that layer two, there's also an audit trail of yep, those those contracts, so you can see how they're changed in real time to make sure that exactly. Yeah, in fact, even those not to be it a sort of sorry, not that to be a boot. A lot of people are sort of upset at the ill twos right now because a lot of the ill twos have been described as vanity projects. They're more like these trusted side chins because they're not fully implemented yet. But the reason why I'm gonna make fun of IL twos and even something like buying not smart ching with a lot of people also hit on is because of the time the software is running to protect the system. Uh, you know, we can all we can go on the buying on smartching today, we can download the blockchain and we can check that everything in that network was running well, that system was running correctly. But one percent of the time you may need some human intervention in order to upgreate the software, update the contracts, or do something that's beneficial to the users. So I'm actually credit fon of systems where ninety nine percent of the time it's software. One percent of the time there's some human involvement because you know, they all still have training wheels on. So to me, that's even another reason why to use a block chain. Of the time, the selfware is dealing with the hard work and you don't have to. It seems as though, um the mental model to think about these things has changed, and that like using a blockchain is now like if when you had an application, and like bickcoin days in earlier Theorium days or even the ethereum a couple of years ago with the most uh, it was like, I'm making an application that is built on top of X blockchain, and you leverage you leverage that that network to do everything. But now it seems as though applications are starting to have to make more decisions in how they leverage multiple layers of blockchains in order to get to the end user application. Because you have like l one Ethereum. L one is now providing a data availability layer. This is where the data is and some rule around how that data is processed. But if you really...

...want to do something at the mass scale, you need to like another blockchain basically leverages that to then do add to add more constraints and more rules and a different trust assumption that then gives the users some ability to do something. And so when you're building an application nowadays, you have to then think about like what you what you just said the basic layer blockchain, which is just here's trusted ordered data or like auditable data, and from there I need to go somewhere else to figure out what to do with that data and figure out the consequences of how that passes down whatever property to my users. And that's a more complex thing. For the development process, but at the end of the day, probably h ultimately the only way we actually scale the stuff out to serve humanity. Yeah, Actually, maybe another way to summarize that as sort of there's three layers that are being built. One is data availability with you you know, we've spoke about a length, you know, the idea that you post the data somewhere and it eventually gets interpreted. A theorem is building that. Another networks are building that. And there's two more layers. One is the settlement layer. Was you know, a good way to summarize is summarize that is, you know, where are the assets? You know, who maintains the rack cores of the assets and ownership of those assets? And the theorem is also doing that role. You know a lot of people have their funds and ethereum and we can verif and you know, if I want to transfer you money, will settle that on ethereum. And then you have the execution layer, which is really should be doing most of the hard work. You know, given these assets coming, you know, execute on them, do something interesting of them, and then eventually settle back to something like ethereum. And so as a developer, but I really have to care about is one, you know, what's the settlement layer? Where are the assets? You know what assets can access my system? You know, if I built a Salana for example, then all the Salona assets can access my system, but maybe the Etherorum asset is a bit more differ built um. And two what execution layor do I use? You know, where am I going to deploy my smart contracts? And you know how expensive of those fees? And what is even the programming environment there? Because a lot of these layer two's have experimental virtual machines. You know, they're just not not They're not exactly the e v M anymore. And so I think it's a developer that's what you're concerned with. You know what our sets can access my system? And too what are the execution layers? Where do I deploy my smart contracts? And what users around those layers as well? You know, do I deploy on a I don't know, maybe like feel V one just because that only has eight dollars locked into it. If I if I deploy there, then you know I'm not going to have any users. You know, not to say as about system, but they moved on the V two immediately you know, so you have to really think about what execution ayorgs and what what what users they have there? What are your thoughts on I have an idea and where you think this is going and why you spend your time doing what you do, But like, what are your thoughts on the general consensus of people making those decisions? Is it if they're in the layer two's is it uh a the kind of expansion of alternative layer ones in bridging across those? Is it analgamation of the two? What do you think? I mean, I think it's a multi chain world. I think we already have several popular layer ones you know, probably gone to popular Nayer one that tries to tail people that are layer too. I mean, there'll be a layer to you someday, but through a very much lawyer one. Right now, Um, you have Salana. I mean Salana is going through some difficult times right now, but that is another layer one that has some popular usage. Um. I think what's really important is is the bridges. I think ultimately it'll be down to you know, how do you get your assets from block to block? G m B A lot of security guarantees you get there. You know, if I are the only way I can get my assets from the theorem to Salana or maybe a theorme with the bitcoin, because that's ren BTC, not the trust one oracle to protect my funds. Well, you know...

...that's not great for the users. Um So, I think it really comes down to how welcome we build bridges between these systems, and ideally especially with the rollouts. Well maybe a good example of this is d I d X. So d I d X was on stark neet and now they're moving the cosmoss. They're going to use the Cosmos SDK for their new system. And I'm not spoke to d I d X, nor have I spoke the starknet about it, but my my suspicion is that they're moving the cost moss because the Starknet SDK wasn't ready yet. You know, they want to build their exchange, they want to work on their product, but the STK just isn't there yet. We're Cosmos STK is probably quite mature. So even just because of the s d K s, I think we're going to be in this multi chain world. You know, if if you deploy a new l one or and you alre you have a really good SDK, you're probably gonna get people building there as long as you have good bridges so you can make sure the ass can actually get over the lossyste them. So I think it's the Actually the hardest problems are just the bridges, and there's kew bridges. They will have a multich in world that most people can use. So far that's not the case. Yeah, well, I mean they keep getting hacked, and actually, you know, it's funny, funny of you know, back in eight Team Surran. Now all the bridges are getting hacked every month. You know, we've seen that with I don't know no mod who was one of the biggest with five hundred million dollars lost, and that hack was really frustrating because it was a really basic solidity bug um. But back in twenty seven team had a similar experience. There used to be this website and as a really long year rails paraphree is it now? When was the last time and Exchange got hacked and lost more than a hundred million dollars? And I have a slide actually from an old presentation that sho was thirty seven days ago before next Years got hacked and a new won't get hacked that day. So from teen exchanges got hacked every two to three months. Um, I mean there's a whole degree yard of exchanges here, and exchanges were ostensibly the bridges. Yeah, oh yeah, exactly the bridges, Yeah, exactly, there's a single authority bridge. There's still a bridge, they're controlled by one party. You know, that was just you know, a very bas bridge that kept getting hacked. Where now people are building more sophisticated bridges and they we're very much in that they're going to get hacked every two months. But just like exchanges, you would like to think over time, they will stop getting hacked as much because we'll get one or two do designs that actually work. Because now exchanges don't get hacked as often. I mean FTX wasn't a hack. That was fraud disappropriation. Yeah, that's just that's bazzlement. But well MOSIC, like a lot exchanges don't naturally get hacked anymore. And that's because they've realized that they've worked out how to secure the outsets for you know, nine of the time, and so bridges will eventually go down that route. It's just right now, Yeah, they keep getting hacked. So I think that's actually the biggest problem is building good bridges. Yeah, I don't know anything about building bridges. I just keep saying that they get keep getting hacked, and so I'm just like, why are they doing this over and over again? Yeah, I mean, maybe I could give some insight for the bridges. You know, over the years they've evolved. You know, the if you think of like there's like four different ways to describe different heavy bridges. One of the single authority that's like coinbis bit stop finance. One authority has the power to you know, withdraw assets from the bridge. So maybe another way luke at it is the bridge has all the offsets, and the bridge wants to be convinced that the off chin data be is is okay. It's well, let's see if before it allows a user to withdraw their funds. And so in a single authority model, what authority can tell the bridge that the offchin data be is okay. So you know, and coin b is will The test is the fact you can give all this one thousand because our liability data be it is okay. We know all we know all of our lab abilities. We can you know, the outs has covered the abilities.

You can take the funds. Then over the years we tried to you know, reduce that trust. So like a multi authority bridge, that's sort of like a multi sake. If five out of nine validators say that the off team databases okay and all this can take her one thousand eighth from the system, then the bridge will accept that and rum of it. Um. But the issue there is, you know, you're going from one authority to multiple authorities, but it's still possible for multiple authorities to get hacked. So that was the I'm trying to remember the name of that bridge now, the ron On bridge, you know, that was a multi authority bridge. Seven signators were the same person. I was just about to mention that it was a multi authority bridge, but really it was just a single authority bridge. Um. Because one person controled like four of validators, then how pseudo access to the other one. So um, yeah, so it's sort of like Mascara security. But but you know, but conceptually speaking, it should be harder for multiple authorities to get hacked. And so the real difference with the rule ups is that in the previous bridges, you're always trusting the word of a set of authorities. You know, maybe less intent people control the bridge on a rule up I would call it a validating bridge because the bridge will independently check what they're saying is correct. So you have to convince the bridge with real evidence that there's off the database is okay before a process the funds. So you're really moving from a model where whatever I say is true to you know, this is what I've said, and here's evidence for wise truth. And so now we're just trying to build these better bridges that include evidence of whether the database is okay before the funds get withdrawn. So that's sort of like, you know, the evolution of bridges. Because maybe it's a lot to take in. I don't know, But where were now on the conversation in general on this in a series where it spreads out pretty substantially, Yeah, you know, coming from computational hardware too, at the ridiculously broad see of applications you can build on top of these things. Like, it's a lot, but the goal is to try and give people a mental model of like how to think about block chains these days and if you're going to build something, why would you do it? And what are the trade offs associated with it? And and then look at the kind of the future of where are these networks going and is there a semblance of like I can contribute to them as an individual as opposed to I rely on other people with more resources to contribute to them. Because like in that early days of bitcoin, one cpu, one vote, I run these things on my laptop and the goal was you have real decentralized access and contribution to these networks, and we've moved very far from that, and it seems as though we're maybe trying to reintroduce in inklings of it. But if you look at most of the players that are the core of the security guarantees of the network, it's a small amount of people with limited resources. And yeah, I think I'm trying to move back to that through and that's your knowledge tet like the knowledge and yeah, interesting ways of contributing a different layers of the stack. Yeah, I mean there's actually exist speaking of decentralization, there's a really nice I think there's like three parts to that was the sort of you know, I will hopefully help what I explain. Maybe I'll help explain why it's relevant. Um so I think we're decentralization. I normally think about it in three parts. One, you know, who can maintain the system, who can order transactions, who can propose blocks? The sacond one is who can verify that is correct? You know, so if there's someone out there proposing transactions and blocks, what of the sat that people who can verify that's correct and accept it. And then the third one is affordability. You can afford to use this network?...

You know. The cause is four hundred dollars for a transaction, which maybe you guys have done that ab curtly done that, you know, well, it becomes a wheel chain in that sense, you know, So it's not really decentralized because you need four hundred dollars before you can transact. And so we've always had this like tree it off between affordability and who can verify the networks correct? You know, because if you make it's where of like the little bitcoin argument to be a big blocks, then the transaction. There can be lots of transactions, but they're not as many people can verify their correct or not um And that's where I think over the years we've sort of money to get out of that rout. We've monaged to find a third way to get away from that, you know, the idea that the settlement layer is minimal and everyone can verify that their assets. Well, see if that sort of gets around that, then pushing the execution elsewhere and then using fancy moon mouth like zero Ali's proofs, you can sort of have one entity that does all of the hard work and then as users we all these tiny proofs to check that they're correct. So you can really maximize you know, your population of users. You can verify the systems running correctly, um participating in the network and producing you know, blocks and transactions. That probably will become more centralized over time just because if you're processing so many transactions you need a lot of resources for that. At the same time, where uh, increasing the height of the stack pretty substantially, meaning there's a lot more things that people can do and be incentivized to do to establish a baseline health of the entire network and not just this base layer. And I think that differentiation of roles is what you'll start to see where oh, I can't be a base layer validator because it's too expensive round access that hardware bandwidth or uptime, But I can provide this cashing service or something else in the middle to make sure people have a better user experience or can interpret that data will and we can build decentralized systems for those things too, And that's where you increase the overall level participation. Well not necessarily like maintaining incredibly permission lists inclusive access at the very basic layer that is where like the majority of the security lines. Yeah, I agree with that. Yeah, I think there's definitely more. I've used the thing of the Bitcoin days there were block proposals and there were verifiers or people running notes. That's what we had a Bitcoin for a very long time, where an ethereum and the rule ups. There's so many different rules involved. You know, you could be an MTV bop that's you know, building the blocks that are sent to the flashbot relay that then gets sent to the validators so anyone can actually compete and try to extract them with MTV. That's a very dedicated role. You could be a validator on the proof of stickchy and where you're proposing transactions and you know, guarante helping the network conversion a single on a single blockchain. You could run a rule up. You could be a sequencer running your own coin ba s lack experience, but then you're relying on a different set people to protect the back end. There's a lot more dedicated roles for people to join, and they all have different resource requirements. Um, but yeah, there's definitely a lot of rules that people can participate in now. It's very much a diverse world than it used to be. Hashing it Out is working with Infinity Keys to let you claim a free listener n f T for this episode. You can find the Hashing it Out challenge on the Infinity Keys dot io puzzle page or use the link in the show notes entered this week's past code Potato that's pot a t O. Then claim the n f T on Ethereum, Avalanche, polygon or optimism. I've always wondered if the reason why um, Amazon or Google like never announced, you know, officially participating in in like the ecosystem, is because everybody is running their vps through them, and so they already know like they're probably going to be the backbone over time. Well you know what actually Google have now, Google, we're very very pro a theorum at the moment. Yeah,...

...your choice, but all right, but yeah, but that's actually great, doesn't they we're in a bear market, but everything exploding around us. Then Google comes in and like, oh yeah, we're gonna start to putting these networks. You know, we have our own dedicated blockchain team. Now. Yeah, so it's very deleisous for that. It's uh but yeah, yeah, sorry, but yeah, I was just gonna say this is like it goes. It goes opposite to the idea that you know, average joke and just pop open his laptop and participate. Now, you know, everybody's running, Like a lot of the tutorials I find for running notes on any different l one are through you know, like a digital ocean or some sort of you know, VPS provider versus. You know, hey, do you have an old laptop sitting in the corner, you know, pop that open. So it's it's for me. It's a little bit sad um. I wish that, you know, older hardware could be repurposed to be useful to the network, but it can be. It's just we don't prioritize it because the standards cloud. Yeah, like you having something that runs smoothly. But first of all, like the networks that operate today, you a certain level of up time, especially when you move to proof of steake, but most version, most flavors of proof of steak, your your computer needs to be on have good access to the Internet, reasonable bandwidth, and I can't, like, in order to for the network to run properly, the majority of the device is doing this need to be there and stay there during the lifetime of them participating. They can't have power outages. That can't have you know, bad bandwidth because you know their friends start streaming on the same network. Like, none of the stuff can happen for the entire network to be to run properly. And that's not reasonable for a lot of people. Ah, And so you have to draw the line somewhere. And that's kind of the hallmark of what cloud providers do is they say, like, here's what looks like a machine. There's a bunch of stuff going on the background that makes it run all the time that we handle. You offload that work to them, and convenience is very comfortable for people if they say like, Okay, that's fine, that's worth it. Yeah, I know, but for you and I, we like stuff. I have a chill of computers in my house. That's that's what I'm gonna stay like Yeah, I mean, so like the theorem room up does like long term room up should be better for home like solo validators and steakers. So they have this uh concept called weeks weak statelessness. Well that means basically is that the validators don't have to keep around a copy of the database. If all the dators have to do is collect transactions, put them in a block, and then send off the block. So the actual database itself and even I guess to some extent Valdy and the transactions no longer have to be the responsibility. You know, they're literally just packing blocks and that's it. It's kind of differentiation of roles in the network is people can contribute in different ways depending upon what resources are required to do it exactly. Yeah, So that would assume that the database has kept up with someone else, maybe someone like in fear or some other new provider. And so what someone like in fear would do is they would collect the transactions, provide something called an access list, and I guess, I know merkel trees approved that this transaction is valid and here's all the items in the database that is accessing. Then that would be possible off to the validators so as soon as there's someone else doing all of the hard work, but then the validators can pick it up and then remove it. And so yeah, there's different rules there. You know someone that basically you know, validators were pack blocks. There will be some new providers who do have all the hard work the guarantee that the volatators get nice clean information to pack their blocks with. It's like a digital cast system. Yeah way, yeah, what a great way to wrap up an episode. Uh. Is there anything that you...

...wish we would have asked you or you wanted to talk about it that we didn't get to. UM. I think the only thing that might be interested just for this discussion is sort of why is something like why is this service I can fear useful? Or like a new provider useful? UM. I thought about that a lot myself when when I first went to I Fear, I was like, why is this useful? For why why are people using the furam? I mean we all offer that don't really think that one of the master notes although people don't get that reference anymore, so it kills me. UM, you know it's um, but I is I rationalize it as it's basically a low balance in service. You know, people like if you're adopt and you have I don't know a hundred or question per second from your users, then actually setting up that infrastructure to pain in the ass. You need your dedicated DevOps team to deal with that. So services like if you're another new providers like kind of blockdeamon Che and stack whatever. You know, there's just really useful loot like low balance and services and that's it. Especially just say yeah exactly after the JASEMRPC. So maybe that's the only things just because it's relevant to the discussion. Sort of on top of that, I mean, what's nice about like for the for the while, that was a centralizing effect and we had to trust in FURA in order to make sure that to assume that that data was appropriate, Like they didn't just alter like we're the blockchain said not, I don't like that, I'm giving something else. So there no, there'd be no way for us to know unless we ran our own, which defeats the purpose of using there in the first place. Basically having a light client experience. Uh. Now with the move the merge and moved to POS, we're able to basically subscribe to an alternative feed that allows you to quickly and cheaply verify any third party source like Infuria to show that what they give you is correct and you can trust it. So like a really adds a tremendous amount of value to load balancing services like Infuria. Yeah. What people also do is they sent up the multiple providers and they checked the response from each provider. I called it like the octil approach. You know, you have three different subscriptions, you send the same request all of them and you check its correct or not. I know only there's several companies doing that now, but it's inefficient compared to how we can do it now. That was oh no, definitely, yes, it's in efficient. Yeah. I mean even like plan support would be quite nice, you know, being able to prove to you that this is a olive response from the data this that would be nice. Great, Uh, definitely thanks for coming on the show. And where can people reach out learn more about you and what you do? And then yeah, what do you mean where? I don't know? Just Twitter? I guess so sorry, just's just set a stone call pot zero on Twitter. I guess that's about it. Yeah, it's easier. Part two of the Application Layer coming soon. S very tough match.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (134)