Web3, Blockchain, and dApps with Ben

Speaker 0: Hello. My name's Kevin, and welcome to Learning Things I Love to Hate. The goal of this show is to go into situations with an open mind and learn more about the tech behind the hype. And in this episode, I'm joined by my dear friend, Ben Greenberg. Hello, Ben.

Speaker 1: Hello, Kevin.

Speaker 0: How are you doing today?

Speaker 1: I am doing really well. How are you?

Speaker 0: I'm fantastic for speaking to you. The topic of today is about web 3. There are so many realms of web 3, but because I don't know much about it at all, I thought let's start with a pretty generalist view. But before we jump into that, could you tell us a little bit about yourself, where you work, and just why why we're speaking about this topic.

Speaker 1: Yeah. Absolutely. So, Kevin, it is so great to be joining you on this. We've known each other for quite a while, and it's such a pleasure to be always in conversation with you. So I am the head of DevRel at a company called Fuel, Fuel Labs.

We are building the fastest execution layer on Ethereum, and we offer a really developer centric, platform with a set of developer tools focused primarily on the ability to build decentralized applications, dApps, as one might wanna call them, in the blockchain space and to be offering, really performant and intuitive and developer facing, developer forward, Outlook for developers to build, whatever they're looking to build and to get going in in the space.

Speaker 0: So I don't understand some of those words. I don't know what an execution layer is. I'm sure we'll talk about that in a bit. But given that I don't know much about web 3, and I imagine quite a lot of the people watching this might be joining me, I thought we should start with this primer. And I thought a good way to start this is just a a real, like, candid point of just sharing some of my skepticisms that maybe we can address throughout this period we're chatting.

If If we don't get to all of them, that's cool. But just at kind of a high level, the idea, the promise of decentralization, I think, is promising. And I think many people viewing will think, yes. Of course, that's promising in a world where large companies control large swaths of our data. But it always seems rooted in some kind of cryptocurrency, and I can't, in my mind, kind of sever and understand the difference between web 3 and decentralization and cryptocurrencies or tokens or something rooted in an area of tech that often is associated with scams.

So maybe we can talk a bit about that because I I imagine it isn't all just one big, you know, interchangeable blob. And, also, I just don't get it. I don't know how how better way to say it. Like, if we just zoom in and look at the tech and forget all of the, like, idealistic, you know, backing of of why they exist, I don't really understand the characteristics of a web 3 application or a a dApp, and why they're unique and interesting. So I figured we might start by talking a bit about that, and then, we can get into some codes and maybe you can show me a little bit around.

Speaker 1: That sounds lovely. So where should we start, Kevin? You you you lead us on this journey.

Speaker 0: I think I kinda have these 2 main skepticisms. 1 around, decentralization and blockchain and cryptocurrency and kind of maybe just not even addressing the skepticism necessarily directly first at least, but what are the differences between these? That would be good. And then maybe talking about then we can jump into more more of the, like, technical, talking about what are the characteristics, like, how does it work at a high level, and then maybe we can jump into a demo. Does that work?

Speaker 1: That sounds perfectly fine. So first of all, just a bit of background on my, involvement in this space. So I only came into web 3 blockchain, working in it professionally about a year and a half ago or so, and I too was incredibly skeptical for a very long period of time. And I actually think I remain still a bit of a skeptic on a lot of it, and I think that perspective is actually incredibly valuable when you're working in any space, regardless of whether it's blockchain or microservice architecture or, you know, you're working on Kubernetes clusters. It doesn't really matter what it is as long as you kind of have and retain that element of healthy, constructive criticism and skepticism, I think that just benefits your work and sort of everything you're going forward on.

And so I empathize with you and I share a lot of that same sense of unsureness or like, what the what the heck is this? So having said that, I think for me, one of the ways that I've synthesized understanding what we're doing here is my involvement back in, like, connected networking, pre web kind of goes back to the early nineties, and I used to run something back when I was a kid. I'm not that old, but I used to run something back when I was a kid, and I begged my parents back then to get me a few phone lines to make this possible, but it was called the bulletin board system at BBS. And I don't know if you remember or even heard of BBS's. Kevin, you're so young.

You don't know these things.

Speaker 0: I don't wanna age you. I don't wanna necessarily make

Speaker 1: you feel too. Let's let's talk about BBS's for a minute. So BBS is where these, like, pre web places online where people could dial in and there were shared discussion forums. There were file servers. You could share data.

It might take you on a, you know, 24 ks modem, you know, an entire day to download something. There were, you know, text based role playing games where you had 2 or 3 turns a day. And that was my introduction to, I guess, what one might call the online community was through BBS. I used to run run-in San Diego where I'm from, born and raised, called the Freethinker BBS. That was my BBS.

I was that kind of kid back in the days. And, and then the web came. Right? And, and the web began in the kind of the same modality where it was kind of run by people in their homes or, you know, local. You would you would have a web server on your running on your 48680 megahertz PC, in your basement somewhere, and you'd be serving websites on an Apache web server, you know, on your 486.

And then, of course, things dramatically shift. We don't go through the whole history of the web. But, we got to a point where we are now where everything is essentially running on AWS. AWS is running AWS in every other service you're probably ever going to access is somehow connected to AWS. And I think part of what the premise of what we're what we're working on in this space is how can we get back to a place where people own more of their data, where people own more of the, access their data and you have more familiarity and a sense of confidence and where things live.

And there's more of a communal aspect to everything we're trying to do. And so I think that is like at writ large from a balcony perspective, kind of like the idea. That's the idea. And the way that it's it's run-in a blockchain context is so one of the first questions people always ask, and I think it's a really good question, is that so I'm accessing some blockchain application. Where the where is the data?

Like, where is that actual data living? You know? So if I know if I go to, you know, x slash Twitter or I go to, you know, Instagram or I go to any of these places, I have a general idea from a web developer where the data is. But where is the data on any kind of decentralized application? And the honest answer is that data is everywhere.

The data is replicated and duplicated on people's computers and on organizations around the world, at all times. So that spread of the data is, I think, the first thing that we want to tackle and address, and then we can get to other parts as well. But I think understanding that is a fundamental premise to understanding everything else that the data is not owned in any central server or any central node. It's actually spread across, multiple, potentially countless nodes. Obviously, not countless.

Nothing is infinite. But yes. Sorry?

Speaker 0: No. Could I pause you for a moment and go back a couple of sec? Yeah.

Speaker 1: Definitely not. Sorry.

Speaker 0: The end. It's a it's a it's a train. We ain't stopping. So okay.

Speaker 1: So Okay. We'll take a break. We're at the trade station. Let me get it done.

Speaker 0: So on that train of thought, and I wanna come back to this train of thought, I wanna talk about the how does it work, right, and what are these nodes, how does the decentralization work, how can you trust it and so on and so forth? Can we take one step back? And I'm kinda curious again. What is the relationship between decent and maybe maybe you're like, no. Actually, we need to tackle them this way around for it to make sense.

But I'm curious. What is the relationship between decentralized apps, cryptocurrency slash token slash some kind of fiscal value item and blockchain. And you you might just be like, of course, it's obvious, but, like, I really need

Speaker 1: to start thinking about it. Rule of anything is to never assume that anything is obvious. And I think that's like the first lesson we help teach people writing documentation, technical documentation. Right. Don't ever assume what is obvious to you is obvious to others.

So to answer that question, I think you actually need to unpack a little bit more. And you need to you need to kind of further accentuate the issues. So considering that the the entire enterprise rests on the notion that people will choose to run these nodes, these data warehouses that replicate the data across the world. So assume people are going to do that. That's the assumption.

Then you baked into that assumption has to be some kind of incentivization model for how one does that. And unless you operate on a fully altruistic model of being where I will voluntarily give my, I will voluntarily give my my electricity costs and my Internet costs and and my hardware costs, and I'm just gonna do this for the betterment of humanity, which I think you you and I, of course, operate in that level. Everyone else, I mean, we don't really know. Yeah. But, you know, obviously, we work for our companies entirely altruistically.

Then you have to do some kind of incentivization model baked into it. So I think that's the first layer. And then you may say to yourself, okay, that sounds all well and good, Ben, But why can't that incentivization model be based on euros or pounds or dollars or Canadian dollars or pesos or any other form of currency? Why why does it have to be a digital kind of currency? And I think to answer that question, you have to then make that question larger.

What is the value of any digital collectible or digital good that exists in any way, shape, and form from the gaming enterprises and beyond. So for example, I have a couple sons. One of them, he's, you know, fast becoming a teenager, is really into this game called Fortnite. I didn't know Fortnite existed until he got into it. That's how much, you know, you know, how how much of a dad I am.

But he got he's really into Fortnite. And there's these, like, digital collectibles and things you can do in Fortnite that are really valuable to him. Why is that valuable? It itself is not, doesn't hold intrinsic value. I mean, we could also argue that a US dollar doesn't hold intrinsic value by itself.

It's representation of value, but he finds value in it. So then I think the question becomes, if you're building this system and you want it to be digital first, so maybe you ought to create the incentivization model also grounded in a digital value and a digital collectible, a digital good. So then that's the second the second layer. And the third layer is, okay, Ben, what about cryptocurrencies? And to that layer, because then you're now extrapolating to, okay, now it's value transcends the incentivization model of of hardware storage and, you know, incentivizing me to run a node, etc.

Now it's suddenly a competing currency in the in the world competing against, you know, global government backed currencies. And to that question, Kevin, I'm gonna say I don't want to get into that because I am not a cryptocurrency person. Like that's not what interests me, I would say, in this space. It's not what motivates me. And I do think and I will end this little bit with a little bit of a caveat, there is a bit of a privilege to not be a cryptocurrency enthusiast in this space.

For example, when I travel to parts of the world where the governments are less stable and the currency is less reliable, there is a, there is a deference, to cryptocurrency that I am unfamiliar with as someone who has only lived in first world global north countries. And I am and I was actually a bit taken by surprise by that, and that just reveals sort of the the the places that I've spent most of my life living in. But, you know, the the there are places I've been where the the first question is asked to pay for something, what's your wallet address?

Speaker 0: So

Speaker 1: At a store.

Speaker 0: Interesting. The I don't I don't necessarily wanna go down the, like, and this is why cryptocurrency is a valuable track, which is, like, where this this area is going. But alright. So there's one question I have that I can't quite unpack yet, which is okay. To have people participate and participate, my understanding is there's, like, various degrees to participation, in a decentralized network, I suppose.

You might correct me on my terminology by decentralized network or whatever. There's some kind of incentive. And, okay, your son gets Fortnite.

Speaker 1: Whatever it whatever he gets.

Speaker 0: Yeah. Sure. They don't have real world value. I mean, they possibly do. I think that is a whole marketplace, but whatever.

Speaker 1: You know, I think in digital games in general, those things have quite a lot of value.

Speaker 0: But let's assume let's assume they don't, and it's just I want I I want to give you something to participate. Actually, I'm going too far off the the end. Let me just ask the direct question. To to be involved in these networks, does it have to have be backed by some degree of, like, cryptocurrency token or something that converts into real money? For example, you were talking about I have sir a server in the basement, and it's running something, and that's great.

And, you know, the web is weird, and we all host our own stuff. Now it's all hosted on, like, 20 data centers around the world, and now we'd like to go back to that. But, perhaps at that point in time, people were just hosting stuff altruistically. If I want people to participate in a decentralized thing that I build, why why is there a financial backing to or is there? Can can I just I'm gonna use some words perhaps ignorantly, stake some token for that has no real that isn't backed by anything that has real money.

It's just a number of a thing that just exists. It just bites in the in the world, and that's that or does it always eventually get backed by one of these primitives that get traded?

Speaker 1: Yeah. I think well, to there's a couple of different questions in that. But I think, first of all so there's, you know, obviously, I began this our conversation with a bit of nostalgia back to the BBS world. And the thing that I don't have nostalgia about in the BBS world is how far we've come and what one can accomplish with the modern web and the modern Internet infrastructure. And I don't think any of us I'm actually going to take that back.

I don't. There are probably people out in the world who do, but I don't want to go back to a world of, you know, 48 ks, 24 ks modems. And I like the conveniences that are wrapped up into my phone into the ability to do the things that we do on on a daily basis. I happen to enjoy that. But that kind and I rely upon it.

I more than enjoy upon I rely upon it. But that kind of sophisticated infrastructure requires a lot more than, you know, the the 486 80 megahertz p Intel PCs that, you know, that we used to run things on back in the day.

Speaker 0: Oh, we. Yeah.

Speaker 1: Yeah. The we. The we. The we. And so I think the infrastructure needs are a lot greater than they were back then.

And so even if it was the case that there was a that you could assume a level of altruism, today you have to you have to compensate people for their, for their costs. And then the second layer in that question is, well, what about a translation at some point to a real world value of the incentivization token and tokenization? Like, does it ever have to does it always have to translate back to a real world value? You know, I don't really know. And I'm going to defer to other people who probably will comment in the comments on this or offer their own perspectives.

I don't really know if a this is a philosophical question. Right? Do if something is valuable inside a system, does it also have to be able to translate to value external from that is external to the system? And and what are the bridges that one needs to create to create that kind of synchronicity of value from inside a system to outside a system? You know, for I mean, I don't know about you, but I and I but I know for myself, I remember I'm a member of communities where there are value things there are things that are valuable that we do in those communities that are not valuable outside those communities, levels of, communal participation, levels of voluntary service, actions we do as part of, you know, social and ethnic and sub communities in the world that don't translate to value outside of themselves.

But do I need to have bridges to show that value, externalize that value, and and translate the value to a larger the larger community, you know, that we live in, whether it's in in the United States or in Germany or anywhere. And, you know, that's, like, that's a philosophical question. Right? That's a larger question. I think in the case of of blockchain tokenization, the answer has been demonstratively yes because they have built those bridges to to convert the token that is used as an incentivization model to US dollar or to euro or to I

Speaker 0: think what I'm just thinking is if I wanted to host it and once again, I I wanna, I want us to move on a little bit in a moment, but maybe just for one more, like, quick quick bit here. But, like, if I just wanted to host a thing for me and my mates and this idea of it's decentralized just among us just among us, this is all cool. You know, there's, like, you know, 20 of us. Maybe it's like a school hacker club, whatever. And money doesn't need to be moving hands here.

We're happy to spend some resources and not be reimbursed for them. It feels like just doing that is intrinsically wrapped up in a cryptocurrency of some kind. Even if it's small value, even if it's, like, not very much at all, it always from what I'm understanding, you can tell me no, actually. I'm not sure that's true, and it just happens to be true in most cases. It seems like it always ends up back in the world of Ethereum or Bitcoin or insert other I don't only know those 2.

I'm sure there are.

Speaker 1: I think that I don't think that's true. I think that, if you don't require an incentivization model to to help, inspire people, motivate people, get them involved, then I think you can build your socialist utopia and and everyone can donate their resources as they as they choose and donate their time and their hardware and their costs. And that's entire and that works to some scale. It doesn't work. I don't think I don't think it's been proven to to work at a scale that can power something that is trans transnational that

Speaker 0: Sure, sure, sure. But that's much bigger. I'm just talking about, like, in theory, the concepts I'm about to we're about

Speaker 1: to talk about. Can create tokenless blockchain, of course. Yeah. A 100%.

Speaker 0: I mean, there there was no of course. I had no idea. I always thought there is no world in which that would, like, technically works, but it is. It just why would you slash? It's not very common, you know, or whatever.

It only works as

Speaker 1: And and and, actually caveat. Fascinatingly, there are private companies that have you and we'll maybe we'll get to this in a little bit, but there are private companies that have built blockchain networks internally that are not, we would call, decentralized, but they're using the primitives of blockchain. They're using blockchain in order for things like provenance, tracking, inventory tracking, things like that. And they're not using it with token because it's all within their system. It's employees using the thing that the incentivization in the company is the is the salary and the stock options.

Yeah. And they're using blockchain for the for the utility of inventory tracking, let's say.

Speaker 0: So the utility is what I the utility and the kind of these primitives and the structure, I'd love to talk about it. We're we're bumping up on you know, we're starting we've done about

Speaker 1: 20 minutes. We're bumping. We're talking. We're getting everything.

Speaker 0: Lots, that of already some of my assumptions have been dismantled, which is good. You know, that's that's why I invited you here. I wanted to genuinely learn more. There is I'd love to move on to a demo soon. But before we do that, maybe in, like, 5

Speaker 1: ish You like my big Stanley Cup, by the way? This is the new rage in the United States. Everyone has these huge

Speaker 0: Stanley Cup now. Some of my friends got them. You know? Some people would call them quite basic.

Speaker 1: 40 ounces.

Speaker 0: But you know what they're gonna

Speaker 1: do, though? This is 40 ounces of water.

Speaker 0: I've seen Starbucks have just come out with, like, a Christmassy one. I'm gonna date this video and the the time we're recording.

Speaker 1: Yes. I know. You just did that.

Speaker 0: That's a bit of a problem. It's this this lovely red, like, you you know, matte red one.

Speaker 1: Yeah. That's nice. Yeah. But they

Speaker 0: only sell it in the US

Speaker 1: as well. Because we Americans, we really hydrate quite a lot, I guess, opposed to the Europeans. What was that type

Speaker 0: of trash? Ice.

Speaker 1: Right? The Europeans don't like to drink water as much as Americans do, apparently. There was a whole social media trend there.

Speaker 0: Looking at my soda here. So let's so let's move on. I would love to know just, like, at a high level, in about 5 minutes ish, I would love to, like I I wanna absorb as much as I can in the 5. I'd love you to, like, show me stuff. Show

Speaker 1: me stuff.

Speaker 0: Could you maybe talk about some of these primitives and the structure? And I understand that there's this idea of, like, not everyone has the same role within a decentralized network, and I'd love to talk about that how it works. We when we briefly prepped for this, we spoke very briefly about this thing called, like, a consensus mechanism. Don't know what it is. If you could share that, that would be awesome.

Speaker 1: Absolutely. So cut me off at any point because, you know, as you know me very well, I can be long winded in my in

Speaker 0: my life. The timer?

Speaker 1: I do see the timer, but you're not you're not gonna pay attention to the timer. I'm actually

Speaker 0: You'll ignore it. That's my job. Fine.

Speaker 1: A timer like Kevin. Yes. So, essentially, we had already mentioned briefly that the way this, works at a basic level is that data is replicated across all these individual servers and, you know, people's computers around the world, and those are called nodes. Right. And the question, of course, has to arise.

What happens when there is a dispute amongst the nodes? What happens when node 1 and node 33 say, no, the data is actually node 1 says one way and node 33 says the other way? And before we even get to there, what is the data? So we talk about blockchains. Right?

What is a blockchain? It's a chain of blocks. What is a block?

Speaker 0: Wow. Thanks.

Speaker 1: I I know. Right? Was that was that definitionally circular? What is a hand? It is something that displays the characteristics of a hand.

What is a blockchain? It is a chain that has blocks in it. I know. I'm like it's we're mind blowingly like astute and wise in this in this episode. But essentially what is a block?

A block is a defined discrete piece of data that contains different elements of of of things important to the chain. So it's going to contain a cryptographic hash of the transaction used oftentimes, using Merkle Tree cryptography. So a Merkle ized hash, whatever that means, that's gonna have the previous block, the hash of the previous block, meaning the previous defined set of data and its current data. So that's and then that becomes like a hash that again can get proven cryptographically between the nodes that this hash is valid. It's gonna have some metadata at the top of the block sort of on the version of the chain, you know, versioning, you know, like we're all familiar with semantic versioning, versioning of the chain, other kind of pieces of metadata, and some other bits and bobs is going to be in the block.

And so that block gets then disseminated across the nodes for consensus, and that's where we get to consensus mechanism. And consensus has to happen fast, efficiently, and also has to happen securely. And that's a complicated, dilemma. How do you affect fast oh, and don't forget, obviously, it goes without saying decentralized. Right?

So how do you affect a decentralized and crazily fast and secure consensus across nodes around the world? Right. Because you you need to ensure these things. So that's where the mechanisms come into place. And there's different consensus mechanisms, and they you can kind of imagine them on a spectrum of decentralization and and and centralization, right, to try and to try and grapple with these things.

The the most famous one that often people are aware of is the Bitcoin model, which is proof of work, a proof of work consensus. Proof of work consensus basically requires the servers to solve very complex mathematical operations in order to validate the transaction and then create that new block. That is the least centralized. It is the most decentralized because it doesn't designate or delegate any any node. It's just whoever finishes the mathematical operation first gets to be the node that offers the validation proof that again again gets disseminated across all the other nodes Oh.

For validation. But

Speaker 0: Sorry. And by doing it first and providing the validation proof, you get more of the insight.

Speaker 1: You get the reward. You get the reward.

Speaker 0: So you're trying to get the in that model,

Speaker 1: you're basically There you understand the incentivization model there.

Speaker 0: And you burn the planet in that way because it's really computationally expensive, but you get like, and that's that model. But that isn't that's not universal. Every No.

Speaker 1: No. No. That's not universal. And I I by the way, I think to understand a lot of this, one also needs to understand game theory and, the whole pursuit of game theory of, like, how do you incentivize players in a game to complete compete? Where do you find the equilibrium of players?

Like, what in game theory, we call that the Nash equilibrium. Like, what is the perfect moment in a game where all players are playing their optimal moves, that's called the Nash equilibrium game theory. And there's a there's really interesting like economics and game theory and cryptography, like, a lot of stuff that goes into this, but that's not for here.

Speaker 0: Beyond the scope. Yeah. Yeah.

Speaker 1: That's for beyond the scope of this conversation. So that's called proof of work. The problem with proof of work is it's incredibly energy intensive, and it's destroying the world. Okay. So let's let's put that in a category.

We don't wanna destroy the world. We kinda like this world. You know? It's got its problems, but it's a nice place to live. It's maybe our only place to live for the foreseeable future.

We kinda wanna keep it going. I know Kevin, you got a couple kids. I have a couple kids who kinda want them to have a world to live on. It's a nice

Speaker 0: Yeah. Yeah. You

Speaker 1: know, it's fine. Maybe we wanted to go. Okay. Yeah. So then the the the other model that is very popular, is called proof of stake.

And so as opposed to proof of stake, proof as opposed to proof of work, proof of stake is essentially that, the node operators stake their token to validate. And the ones that stake more, as collateral tend to get chosen more to be the validator, and then they get more stake and they get more back as a reward. There's a variation of this called delegated proof of stake where also delegators can participate in this consensus mechanism and can choose. So I'll tell you that people, other people who are playing in this game can choose a node operator and say, I'm going to stake as well on that node operator and I'm gonna get a portion of the reward and the operator will get a portion of the reward. And so people get to choose operators.

So the benefit of this is it's less energy intensive by far, dramatically less energy intensive by scale, extraordinary scale. It is clearly a little less decentralized, because right? For obvious reasons. But the energy intensive nature of it, the the fact that it doesn't really destroy the planet any more than any other web application destroys the planet, is is a good thing. Like, let's say that's an unreserved good.

It's a good. Right. And there's other models as well that are even less decentralized. There's something called proof of authority where basically the chain chooses, through its however the chain chooses things, and that's a whole another conversation. But the chain chooses approved approved nodes to be the validators.

And those are unapproved like an approved list of node operators that can validate. That is clearly not super decentralized, but it is obviously also much more fast. And and you could argue more secure because you've you have a defined list of vetted

Speaker 0: As as long as those nodes are kept secure. But, sure, you're right.

Speaker 1: As long as nodes are kept secure.

Speaker 0: I'm kept. In this in this world of it, it has to be energy efficient, decentralized, secure, fast. It's like the all of these various models

Speaker 1: It's like a trifecta of a dilemma. Yes. Exactly.

Speaker 0: So so all of these all of these, you know, do it different ways, and I'm sure you build your applications on different

Speaker 1: And you also need to have an element of fault tolerance for bad actors as well. Sure. And we call that the Byzantine general's dilemma. And if you ever heard of the Byzantine general's lemma. It doesn't it's not from blockchain, but it applies to blockchain.

It's the have you heard of this, Kevin? No. No. So very briefly because this is actually quite fascinating. Let's say you are that it comes from, army met army terminology.

You are the Byzantine army, right, and you are surrounding a city and you're, you are proceeding to invade the city. The only way to tell all the generals that are surrounding this quite large metropolis that it's time to go, like lunchtime, is by sending messengers to all the generals around the place. And you don't get feedback from the messengers whether the generals have accepted or not. You just have to assume that all the generals will then activate their whatever they call them in armies, brigades. I don't know what whatever the thing is.

So you have to assume that a certain percentage of your generals, either by malintent or by incompetence, will not activate their brigades. And maybe they're traitors. Maybe they're just bad at their jobs. We don't know. So you have to have an element of tolerance for ineptitude or for maliciousness.

And all of these systems have to have what we call technically the BFT, the Byzantine Fault Tolerance.

Speaker 0: The twins' exhausting, but I get it.

Speaker 1: It's really really interesting. It's really interesting from, like, a nerd perspective.

Speaker 0: So so just to help me understand, because I really wanna jump into, like, if you could if we can maybe build a little dApp, decentralized app together if you're open to that. But do that. But but just to help me understand, just at the core, there are a few players here. There are the developers of a chain, but they they will inevitably participate in it. But those two things are not are not a given.

Then you're in the participation of a chain. You have validators, and and they are they might be on an approved list. It might be whatever.

Speaker 1: You have to Depending on the mechanism the chain is.

Speaker 0: Depending on the mechanism, they will validate and and drive consensus on what the

Speaker 1: And send and send those validated blocks and they'll send those validated blocks to all the other nodes

Speaker 0: to That was my last question. And then nodes are generic whether you validate this or not, and then you have what I may just call users, standard nodes, not

Speaker 1: There are differentiated nodes, and, yeah, that's what you're, I think, intimating at right now.

Speaker 0: Yeah. But but but there is there's

Speaker 1: there's what we call user. There's what we call full nodes, which are the ones that can validate and affirm and do all the operations of a chain. Sure. Then there's archival nodes, which as the name sounds, are there to preserve the history of the chain. And then there's things that we call light nodes or light clients, which participate in some of the operations of the chain but don't validate.

And those are really helpful when you have low low infrastructure, like if you wanna have a mobile app participate or you wanna have a wallet a mobile wallet participate. It would

Speaker 0: just be like users. I'm a consumer.

Speaker 1: Basically users, and they would query full nodes for more data, but they themselves don't possess the entire history of the chain, and they don't participate in the full validation of a chain. And there's other nodes as well, but those are some of the big ones.

Speaker 0: That's really interesting. And then just my final question, just to make sure I got it. When I I'm a user. I have a I run a light node, which could be a client, right, a web app, whatever, and I want to gain data. I'm not going to a specific node for that data.

No. I'm asking the the chain. There is a mechanism for me to just go out and say, I would like the latest version of a thing. No. Because all the nodes should have the latest version.

Speaker 1: So there's different ways there's different ways of doing that from the, application Velma perspective as well. Some chains can expose things like GraphQL API endpoints that allow you to query the chain through like a GraphQL API query. So from the web app developer, it doesn't feel any different than you're building any other app and you have to unfortunately use GraphQL and create very long verbose queries that you could just do with the REST API. But that's for another episode of yours. But so, so it doesn't feel any different from that perspective of a web developer.

And then you would there's also the the archive nodes that could be used just to query for data. And so you're querying specifically to the archive node asking it for, you know, current state. That's another example, but often it's through, like, API endpoints that are exposed.

Speaker 0: But then if I want to participate, that's the difference between a read only application and one that I can post a status to or something like that. And at that point, I'm no longer a light node. No. I I could be a light node.

Speaker 1: Light node. Even when you're sending a transaction, you can still be a light node. It's not

Speaker 0: gonna be validating it

Speaker 1: right now. You won't be validating and, and unauthoring and participating in the authoring of that block. You'll be spending the transition transaction to the chain to be included in the next block, I. E. The next discrete data bit, but you won't be part of the affirmation process of that block.

Speaker 0: So we have to summarize, and I know this is still a a a light version and a bridged version of reality. We have light nodes, which you can think of as just users of an application. They can query. They can send data in. Then you have, then you have full nodes, which are part of the they are they are basically the keepers of the chain.

They will, based on some mechanism, decide what is what is true amongst themselves with some degree of fault tolerance call, and they generally will stake some kind of resource on their ability to do that accurately fast accurately and and correctly. And then you have archival nodes, which just store state, but they won't be part of that consensus mechanism. And there are various other kinds. These are these kind of big you I don't think primitives is the right way, but categories of these nodes. That makes lots of sense.

I would love to see this in action, and I'm sure I will have loads more questions.

Speaker 1: I love that we had this conversation, by the way, Kevin, just to reflect on it for a moment. I think what you're doing is so valuable because we all come to things with a lot of opinions, but to be able to gain just and most of us who are listening to this or watching this later, not all of us, but a lot of but many of us will come at it from some set of technical background and we approach things from a technical perspective. And so to be empowered more with the technical implementation details, it's not that it's to change one's opinion either which way, but to empower one in their opinion, to give them actually and maybe it does change your opinion. But, you know, we approach things through technicalities and through understanding technical specs. And so this conversation doesn't happen enough.

So, really, I think it's a really, really good thing that we're doing this.

Speaker 0: Thank you. And that's really the point of this series is I'm trying to put away the, you know, any negative, bias that I come with, and you're one of the people I trust most to come in and kinda just cut the idealistic vision piece, which a lot of folks

Speaker 1: because I'm such a I'm such a pessimist realist.

Speaker 0: Such a pessimist, but but I I knew I know that I can just pause you and go hang on. We're going on an idealistic train here. I and we haven't Good faith. Too much here, but, like, I just wanna know. I just have questions.

Now I've already learned stuff. There was also some assumptions I had. I don't wanna kind of ruin where where I land with this, but, like, not every blockchain has to be tokenized. That is really interesting to me. So there is a technical nature of this where if characteristics are are correct for your use case, You can use this, and it doesn't have to be backed by by cryptocurrencies, which many see as scammy.

And I will not pass comment on that in this moment. But those 2 those 2 worlds, they are not they are quite linked, but they are not inextricably linked. Like, they can exist.

Speaker 1: One one could say I have evidence. I think this is an actually an accurate thing to say that cryptocurrencies are an articulation of a use case of blockchain, but in itself is not the totality of blockchain. It is by far one of the most and maybe the most prominent use case that's been developed to blockchain. And for obvious reasons, human nature, right? We as people tend to want to seek things that will improve our wealth standing and improve our, That's just how we are.

And if we're being honest with ourselves as people, that is that is like baked in to to humanity. So that's it. It's not a surprise that new technologies often get articulated early on by those seeking profit first and foremost and maximizing profit. That is true with all new technologies that have ever been developed, including decentralized ledgers like blockchain.

Speaker 0: But that isn't but I think what you've said in the reality are not the same thing there. Like, if crypto I I would love to get into the demo in a moment, but just to kind of, articulate my response to that, like, sure. I've heard loads of people in web 3 say cryptocurrency is but one use case. It is but one very common use case for it. However, it's until this conversation, I believed every other use case was built on top of that on top of cryptocurrency.

Therefore, they are 1 in the same. It's not a use case that it is the fundamental piece that without this whole thing doesn't work. Well, that isn't the case. You

Speaker 1: just have to flesh out the distinction between tokenization of incentive and cryptocurrency. Those are not exactly the same thing. That an internal system has a way to incentivize participation and using your resources and time and hardware is not the exact same thing as cryptocurrencies as a competitor to, you know, a government backed fiat currency. Right? Those are those are 2 interweaved, interwoven, whatever the correct grammar is there, but they but they're they are slightly different.

Speaker 0: Yeah. Cool. Good to know. And then the other thing was just I think I just didn't understand enough about the tech, the characteristics. I'm starting to get that a little bit now.

If you're able to, if you're willing to

Speaker 1: Can we look at something together?

Speaker 0: I would I would love that. I would love

Speaker 1: that. Let me just see if, let's do this.

Speaker 0: So I did ask you before this to maybe, like, prepare a little something. So I'd kinda be curious just to set the groundwork for for what we're gonna do. I'd love to know what we're gonna look at together and maybe just the background of, you know, there is gonna be some level of infrastructure already in place. We're not gonna go and set up, maybe we will, but we you know, this may be be built on top of some existing chain infrastruct the the wording, I'm not quite finding No.

Speaker 1: I appreciate that because I think that'd be given the time constraints, we're not gonna build together on this on this, moment at this moment. But what we will do is walk through some of the code because just like what we did, now by demystifying some of the terminology of the technical specs and how it works from a technical layer, I think it's also equally important, and I think you agree on this, to also demystify some of the technical specs. And when we talk about decentralized applications or dApps, how is that actually different from any other kind of app that one may build? And, you know, the TLDR, by the way, is just not that different. It's quite similar.

And, and honestly, from a design perspective, that was intentional because if we want to help people build, developers to build in a new space, do you create an entirely new way of doing things, or do you just build on top of the familiar patterns anyone has when they're building, let's just say a web app or a mobile app, right? So you're gonna do the exact same things and in many cases use either the exact same language stack or slightly modified domain specific versions of that language stack, And and, and this case is what we're gonna look at, and the latter is what we're gonna look at. So what we're gonna look at is very briefly a very small sample dApp, to essentially create your own personal micro journal or microblog that you can store your thoughts and only you can access your thoughts, and it's it's your kind of, like, personal remember they used to be these web apps. I forgot what they were called even. Maybe LiveJournal was one of them where you could publish your thoughts and remember that.

Was it LiveJournal? It was LiveJournal. Right?

Speaker 0: Yeah. It

Speaker 1: was. And was LiveJournal gated, I. E, like, I can only see my own thoughts if I wanted to. Was that a setting? I think you could share it or you could you could make the setting that you don't.

Right. Yeah. So kind of a similar idea, a scaled down version of that. And so if we look in the folder structure, what we see is actually 2 different folders. We see what's called here a blog contract as one folder and then the front end as the other folder.

And, that's obvious that in our case of a dApp, the back end is called the contract. The back end is a smart contract, and I think it's not an exact one for one synonymous comparison, but it is a great simplification of it for our purposes that a smart contract is essentially a piece of executable code that lives on the chain, that lives on the blockchain, lives on a block that can be called to do things. So it's code that lives on chain. And the 1st blockchain to make programmable blockchain possible with smart contracts is Ethereum. Right?

Before Ethereum was Bitcoin, Bitcoin was not a programmable blockchain. You cannot put smart contracts on it, but Ethereum was the first one to make that possible.

Speaker 0: You put code in a block. It goes in the chain. All the validator nodes go, yeah. Cool. This is part of the chain now.

And at any point, I can call the code that lives on the chain.

Speaker 1: Yeah. So, actually, let me show you very briefly. Let me open up a code editor here. So if I No. I don't

Speaker 0: want to bump up that font size.

Speaker 1: No. But this is I will bump it up. I know. I just opened it. But, let's see.

Where is it? Why is it not I'm not seeing it. Oh, it's in here maybe. Wait. Where am I missing it?

My dot env. I don't know why I can't find it right now. Should be in there. Anyhoo. So Maybe it's oh, I know where it is.

Sorry. See, this is real time. Right? There it is. So in the front end side, so in fact, the only thing I have in my dot end file is my contract ID.

And what is my contract? I'm using a React. My front end revealed. It's a React app on the front end. Oh my god.

The great reveal has been shared. But, what is and, you know, you preface, you know, your dot end variables in React with React app to make them available. Right? That's kind of the part of the architecture of React. So what's the contract ID?

That is the address of my code on the chain. That's the that's the, the place, the location identifier of my code on the chain,

Speaker 0: Which you don't

Speaker 1: need to do

Speaker 0: on the chain.

Speaker 1: That's not private. Right? So I'm just using dotendvariables just for convenience, but this is my contract address for this contract. Right? So this is the the location on on this particular chain, whatever chain I'm

Speaker 0: putting in. This is similar this is similar to, like, writing some code that has to be hosted on AWS. You have to deploy it to get the URL in order to call a serverless

Speaker 1: serverless serverless serverless serverless

Speaker 0: serverless serverless serverless serverless. This is the

Speaker 1: equivalent of the URL. Exactly. And anyone could query this chain and see the contracts that are on this chain, anyone. And and look at this address and see the code that I've uploaded at this address through a query for a a block explorer.

Speaker 0: Which is how you increase trust because anyone can Exactly. That's fine.

Speaker 1: It's how you eliminate the need to have trust.

Speaker 0: So, I mean, I think this is that might be idealistic semantics, but it's how you build trust. It's I can go look at it. Right?

Speaker 1: It's how you label people to verify for themselves, basically. Right?

Speaker 0: Sure.

Speaker 1: So, okay, so we have these 2 folders. We're going to close the front end just for a minute just so we could walk through the back end, the contract, because I think that's a bit more interesting. So just by full disclosure, what you're going to see is one implementation of smart contract architecture. This is coming from the company I work at because why not? I work at Fuel.

It's building an execution layer for Ethereum. So when I talk about an execution layer, I'm talking about and I'm gonna give you a 60 second synopsis of this because if I don't, it doesn't make any sense. When we talk about execution layer, we're talking about in the context of a modular architecture where you separated out the concerns like a separation of concerns, kind of like a models, views, controllers, MVC model, web framework, where you have the consensus layer and the execution layer as and there's another layer as well. I can't remember on top of my head, but someone will tell me in the comments, I'm sure, once this is out, and I'll look it up as soon as we're done, but the you separate out those concerns and there are different, parts of the different parts of the chain functioning in different ways and sharing the data between them to enable, basically higher throughput, right, higher speed. You you you have dedicated parts of the chain that do dedicated things in order to just, well, it's it's good.

It's good architectural design, first of all, if you believe in like microservices, and it's also it just makes it more easier to debug when there's problems, and it increases increases throughput. Right? Some of the benefits. So we're building out an execution layer. Right?

So as part of that developer centered kind of experience, we built out a DSL, a domain specific language for smart contracts called Sway. It's based on Rust, so it's it's Rust based DSL. So it looks a lot like Rust, but incorporates a lot of features that make it a lot more intuitive for smart contract design or more tailored to smart contract design. And so in that context, everything starts at a main file. And the main file, you can have 3 types of files, contract, which is the executable state full piece of code on the chain.

You can also have a script, which is, can access state but is not stateful. Right. It's only state oh, actually, I take that back. It's stateful in the moment of when it's executed, but it doesn't hold state. It doesn't keep state.

Speaker 0: Like a serverless function? Sure.

Speaker 1: It's like a it is a serverless function. That's exactly what it is. Amazing. And the other, the other type of thing you could define here is a predicate, and predicates evaluate to true or false. They they don't hold state and they don't access state.

They evaluate a a, a, they basically create a a Boolean evaluation. And if the thing evaluates a true or false, that can then call a transaction on a chain or it can call a thing to do something on the contract. So you could incorporate that kind of interface. You can incorporate that kind of functionality, I should say, in a smart contract. But to further round the separation of concerns, removing out that true or false, like, did I give you 50 tokens or not?

If I gave you 50 tokens, do this. If I didn't, don't do that. So instead of having that as part of a contract interface, I take that out and I just make that its own little snippet of code that just checks whether this is true or it's false. And then if it's false, do y. If it's true, do x, and that's essentially it.

So that's the 3rd type, of of code you can have, contract script or predicate.

Speaker 0: Can I ask

Speaker 1: one quick question quickly? Of course.

Speaker 0: So we've got 2 parts. We've got front end, which will just run-in a browser that can be hosted on AWS or Netlify

Speaker 1: or Or Vercel or Netlify.

Speaker 0: And we have the back end. I understand it's not a a straight one for 1, but the executable code that will touch state and the rest of the chain, the database in the it's not quite that, but whatever. And that is that lives on the chain. I'm one thing I'm not really getting is when does the user of the React app, like, have to provide token to participate? Like, what part what part of this does this touch a a store of token?

Speaker 1: They may or may not ever need to touch token. It just will depend on the design and the decisions of the particular application developer and what they want to build. So if they wanna build something that requires the user to pay for things or then they would need to provide some token. If you don't want to build something like this small sample application, which I'll run-in a moment, you can see it, it doesn't require any any token because there's nothing it requires an account. It requires a wallet address because that wallet address becomes your identity, but it doesn't require any token.

If you want to build something that is you know, a marketplace, I think you would probably wanna have token. If you don't wanna build a marketplace, you don't you're not building a trading platform or a lending platform or any of those kind of things, then you don't you don't need to have token. If you want to pay for the cost of querying the chain because, you know, that has cost to it because you're using people's infrastructure, then you as the application developer can cover that cost. And maybe you have other revenue models for your application. Maybe it's through advertising.

Maybe it's through, all the other ways app developers in any in any web space get revenue. Right? Like, it doesn't have to be through the user.

Speaker 0: I think you answered it. I might just dig what a little more you said. If the application owner wants to pay for the I forgot the exact wording you said. I'm a little bit confused. This is being hosted on a block on an Ethereum blockchain.

Speaker 1: It's being hosted on a fuel on the fuel testnet.

Speaker 0: Right. And that is

Speaker 1: We're not yet to, like, production main status on

Speaker 0: deployment of this block, the submitting this this executable this smart contract, that would cost some money. And then to query it would cost some

Speaker 1: So when I right. So when I would publish a new journal entry, that's putting data into the next block that will be finalized, which costs money, infrastructure. It's infrastructure costs infrastructure cost. That is equivalent of AWS cost or the equivalent of AWS

Speaker 0: I'm not I'm not against it. I'm not trying to be like, oh, you have have to pay for it. I'm for pay people for for infrastructure. I was just trying to understand what, where, how

Speaker 1: And so you as an application developer can choose how you, you know, build your cost models and your revenue.

Speaker 0: Wallet addresses their ID, so that is kinda how this all hooks into it's like log in with PayPal. You know? Yes.

Speaker 1: So exactly. So There's

Speaker 0: a wallet there with money in it.

Speaker 1: In the other in the more, you know, in the prevalent kind of web 2 models, login is done with login and password or login with username password or login with social accounts. In the web 3 model, login is done with your account, your wallet account, your ID. And that's an immutable address that links you across, you know, the network, and, and you can use it in any way you want. Many people have many different wallet accounts for different things. Right?

So I may have a wallet account that I keep in a place that's very hard to access online and I where I may keep more of my funds. I may have a wallet account I use for debugging and, like, testing things when I'm building applications and many of those. I may have one I use for, like, common, you know, web apps where I'm using, you know, the very popular Chrome extension called MetaMask or a browser extension to enter, and I don't want to, like, put a lot of sensitive data with it. So I may just use that for, like, you know, social apps where it's requiring me to log on. And there's all different sorts of addresses you use, but the address becomes your login.

Speaker 0: Got it. So they're inextricably linked in this setup. Again, these tokenless tokenless blockchains are completely separate from this. It's a different implementation of the same concept. So I'm sorry for interrupting you.

I just felt that was really important.

Speaker 1: No. It's an important thing.

Speaker 0: And so should run us through. Yeah.

Speaker 1: Yeah. So just to very very briefly run through. So this is essentially a lot of Rust syntax, so it looks a bit like Rust, but if, but with any Rust developer would see differences. But here I'm including some modules and because I separate out the concerns, I have a module I created for my data structure. I have a module I created for my interface, meaning, you know, so I have down here an implementation block and this sounds familiar to a lot of different languages as well.

So I have an interface that defines what my code will look like and what each thing returns. And then I have an impl block for the actual implementation of that interface. Right? So if I go to the interface and it's in a file called interface, look at that. If I go to my interface, I see this is a library.

Right? This is not a contract. It's the library. And I'm using my data structure of a post, which we can look at in just a second, and I'm also using from the standard, Rust library, vector, storage vector, a data type, right, kind of like an array, and here is my interface, my where I define what a blog is, what is inside a blog. It has a post function.

It has a get post by author function, initialize user function, a get number of posts function, and a get post, and each one of them returns a different thing. This returns a vector of posts. This returns an identity of a user, which is a type. Right? That's a class.

This returns a unsigned 64 bit integer of getting number of posts and this returns a post. When I get a post, it returns a post. What is a post? A post is this. And where I define posts?

In the post file. I love it's simple. From okay. You know, my background, by the way, Kevin, is I was a for a long time a Ruby on Rails developer. And we have to get back to that, right?

Because one of the things I love about Ruby on Rails is the convention over configuration and that things live in certain defined places. And one of the things I find most frustrating for myself personally, just speaking personally, in the JavaScript framework landscape is the lack of convention. And I love frameworks like Vue, for example, that start imposing a bit of convention. And so I can go into a Vue a lot of Vue web apps and I start understanding you introduced me to Vue, and I'm grateful for you to you for that because I can go into Vue and I can at most web apps and get a sense of the land fairly quickly. With rails, that happens instantaneously because of conventional reconfiguration.

So this kind of convention makes me very happy. So I go into the post data structure, and this is another library. Right? And I have my struct, which is kind of like, a class in Rust. I have my struct for a post, which has 3 types, 3 fields, an ID, an unsigned, 64 integer, a content type, which equals a string of 280 characters, and an author, which is an identity.

And then I have an implementation of my post where I can create a new post. This is like a class method. Right? Create a new post. And it returns back the self containing an object of ID, the content, and the author.

So that's now getting back to main. So I have I've included these two things in my main, which is the main interface for the applications, the call point. It's like the app dot JS or what have you. And then I'm saying I want to use all these different libraries. I want to use a hash.

I want to use a vector, etc. I want to use my post data structure. I want to use my blog interface that I define. And then I have a storage. This is what it will be go into my block.

This is what gets published in the block. What gets published in the block are the posts, the number of posts, and the user. And so the post is a map of key value, the key being a number and the post. The number of posts is just a number, and the user is an as an identity. And using option, which is, you know, oh, helpful, helpful,

Speaker 0: Type that represents an optional value.

Speaker 1: Right? It's an at an enum that represents an optional value, either some or none. So I default it to none, and then I provide it with it. And then basically the rest of it is kind of standard Rust code. So, this is meta programming in Rust.

This actually goes if you would dive into the Sway code base, you'll find, like, hundreds of lines of code defining what this is. But this is Rust uses a lot of meta programming or you can use a lot of meta programming in Rust to define macros. So these macros, like, abstract away a lot of the things, so I just have to write my actual logic. And then this is, like, create a post. This is get a post, and this is initialize a user and etcetera.

And then that's basically the back end. Does that feel dramatically different? Obviously, it's not JavaScript or TypeScript. It's Rust, but does it feel dramatically different to you?

Speaker 0: No. Not particularly. I'd be interested in the intricacy where it starts to involve token, but, like, no. Not on the surface. And this these are, as you say, the primitives.

Can we see the front end briefly? We're we're starting to we're starting to run on both of our times.

Speaker 1: Very, very briefly. So the front end,

Speaker 0: essentially Even just the API calls would be interesting.

Speaker 1: Yeah. So let's go to, the so first of all, it's TypeScript. It's a React app with TypeScript, and we then generated a lot of different type generate a lot of types for the front end to interact with the back end. Right? And so if we look at the front end, well, that's the index file.

That's not so interesting. But if we look if we look here, we're using we're basically using the the, we have a, a wallet SDK for TypeScript, and React libraries within it, and that allows us to basically, you know, abstract away a lot of that concern as well. So we're importing useAccount, use connect, use wallet, use is connected. These are different, like, what's the fancy word for it in React? But different, like, state, verifiers.

Right? So, like, if I go

Speaker 0: sounds plausible.

Speaker 1: That is but it's not it's not the term in React. We know that. But I'm not a React developer. I barely can write React, essentially.

Speaker 0: Neither am I. You told me I taught you Vue, and then immediately, here's the React app.

Speaker 1: I know. What can I say? I what can you do? So, you know, we're basically defining the different state of the app. Right?

So, is connected, uses that, connect, yada yada yada yada. And then we create posts. We use state. We create a post as an empty array. New post content is a string, etcetera.

We define a type for post output, with different, you know, parameters and their types, and a type for a post, and then we set the wallet address. So once we set the wallet address, if I was building an application with tokenization as part of it, then I could also do things like request payment. I could request to pay. I could send token, and I could do all that sort of stuff. I'm I'm not doing any of that here.

I'm just getting the wallet address for the contract from the person. And then the rest of it will kind of look similar to another any other React app. I define some some functions like get posts, and then, you know, like, the checks, like, if there's a value, if there's not a value, right, I wanna catch that and put a console in the log. Like, it's not that's kind of standard JavaScript React programming or TypeScript in this case. And then down here is the actual front end

Speaker 0: Sure.

Speaker 1: Kind of standard. So if we run this, so let me go into the front end. Now if I can type. Thank you.

Speaker 0: It's fair. It's what I write most times.

Speaker 1: I so appreciate that.

Speaker 0: Set up an alias.

Speaker 1: I should alias it as well because it's even in there. Look at that. Nom, was there for a second. Alright. So npm start, and it's gonna

Speaker 0: pop up. Look it doesn't look that different if you were just using any kind of authentication service plus a payment service, I guess.

Speaker 1: So this is, like, my this is my my little blog. Right? Like, this is exactly what it looks like, and there's no post in there currently, but I could write a post. Let's see if this works. It may not work, but let's see because I haven't played with it in a while.

But we're live. This is fun. This is a post of mine. And, of course, it's not working right now. Because that's the that's the law.

That's the law of things.

Speaker 0: We don't need to work it out. In theory, that then gets submitted as a block on the chain.

Speaker 1: In theory, it gets submitted as a block on the chain. I do not know why it did not work, but it did not work. Oh, there we go. Thank you. Now it's working.

I don't know why it didn't work before. I think I was making changes. I didn't save it, the file.

Speaker 0: That was

Speaker 1: the that was very basic. So here you see it prompted already because I have 2 wallet extensions loaded. So it's asked me which wallet I want to connect with. Right? So initially, I've these are just 2 different wallets in our ecosystem, and I play with both of them.

So I'm going to connect with this wallet. Why isn't it

Speaker 0: Is it the fact that you're in this little mini arc thing? Oh, no. Popped up another one.

Speaker 1: So I'm connecting. Right? And it's saying, okay. You wanna connect to this application on local host. It wants it can view your balance and activity and then and can request approval for transaction.

Speaker 0: Like an OAuth flow.

Speaker 1: Yeah. Right. So I'm gonna connect.

Speaker 0: I'm sure that isn't the mechanism of that. That's Oh,

Speaker 1: why is it not working, Kevin? Nothing ever works when you want it to work in real time. Oh, now it's working.

Speaker 0: Yay. It's all good. It's all good. I mean, a lot of this is about illustration rather than, like, oh, I click So

Speaker 1: here you see my post, and let's see if I create a new post. This is a new post. Beautiful. Okay. Approve.

Speaker 0: Approve transaction because that's what's happening here. You're providing token even if it's is a text And

Speaker 1: there it is. This is a new post.

Speaker 0: And there it is. Interesting. Yeah. I mean, that's the case on the front end. It doesn't feel terribly different to This

Speaker 1: is why, by the way, I tell all my DevRel colleagues to always record their live coding for presentations and not do live coding from the state.

Speaker 0: Not. I think the wealth of knowledge that I have gained as a result of talking to you today transcends the fact that you pressed the button and and something

Speaker 1: didn't change. And by the way, the way this would start is actually quite easy. So, you know, you have, create react app, right, in the react land. If I wanna create a new contract, so we have a tool called fork, which is the fuel orchestrator, and I would just do fork new and the name of the contract and instantiate an entirely new contract for me. So fork new blog contract.

Speaker 0: Which which, just to be clear, is the local code required to write it. That would still need deploying. That would still need submitting Right.

Speaker 1: So let's let's get out of this for a second and see what that looks like. So fork new sample contract. And then if I go to sample contract and I take a look at it, it's very small. There's nothing in there.

Speaker 0: So so

Speaker 1: It just here's my AB. And you see it's not even separated out. So that can be

Speaker 0: that can be deployed. That could be

Speaker 1: That could be deployed. It's just a contract that returns a boolean of true, and it'll always be true. Right? There's not there's no operation happening. It's always gonna be true.

Speaker 0: It's really interesting. So that's I suppose I suppose a lot of the complexity here is abstracted away by helper libraries It provided by fuel my guests, which is really interesting, all the ecosystem writ large. But, thank you. That was that was a great episode of learning things I love to hate. I hope that that was that was good for you.

I feel like I hopefully didn't ask too many really difficult questions, but the questions I did ask allowed

Speaker 1: Kevin, anyone who knows you knows you are a wonderful person, and anything you ask is fantastic. I think this is a very good conversation. Thank you for inviting me.

Speaker 0: Thank you for being part of it, and thank you everyone for watching this. Until next time. This has been learning things I love to hate. Bye for now.