Web3 Galaxy Brain 🌌🧠

Nicholas: Before we get started, I'm collecting Web3 Galaxy Brain listener testimonies for a new section on the website. If you love the show, please send me a tweet-length testimony saying why you listen and what makes the show special for you. DM me your testimony @Nicholas with four leading ends on Twitter or Telegram, or @Nicholas on Warpcast. Thank you. Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guest today is Sam Hart. Sam is a developer, artist, and biochemist. He is head of product and strategy at Skip Protocol and co-founder at TimeWave Labs. He has contributed to the Cosmos ecosystem for years and is also co-founder of Folia, a blockchain art collective. On September 1, 2023, Sam wrote a long and detailed post to the MakerDAO forums, pitching Cosmos as an interesting option for the AppChain aspect of Maker's endgame. Inspired by that post, this episode is an introduction to Cosmos for EVM devs. In this conversation, Sam and I discuss the major components of Cosmos, Comet BFT, Cosmos SDK, IBC, VMs like CosmWasm, and client tooling like CosmJS. We also compare the design philosophy of Cosmos and Ethereum. Good starting points for interested builders are included at the end of the interview. It was fun chatting with Sam about Cosmos, which is an ambitious project whose many flexible affordances can make it challenging to get a handle on. My thanks to Sam for sharing his knowledge. I hope you enjoy the show. As always, this show is provided as entertainment and does not constitute legal, financial, or tax advice, or any form of endorsement or suggestion. Crypto has risks, and you alone are responsible for doing your research and making your own decisions. Hey, everybody. Hey, Sam, how's it going?

Sam Hart: It's good. It's good.

Nicholas: It's morning time here, but you're in Berlin, right?

Sam Hart: And it is 2.40 here. All right.

Nicholas: Afternoon. Not so early. It's good to have you. I'm excited to talk about Cosmos. Are you excited to talk about Cosmos?

Sam Hart: Yeah.

Nicholas: Yeah. So this conversation started because of the post you made in the MakerDAO forums. Yeah, maybe, I don't know if you wanted to touch on that post, or actually, my first real question is, how did you get involved in Cosmos in the first place?

Sam Hart: Yeah, we can start there. So maybe start even further back. So I moved to New York right after the financial crisis, and basically was there during Occupy Wall Street. It was kind of a big influence on my thinking at the time, kind of exposed me to a lot of the kind of underbelly of financial politics. And I was working as a researcher at the time, doing basically biomedical research, like genomics research in the city. Post-Occupy, a bunch of my friends started these kind of new institution projects. And some of those were art projects, some of those were startups. Those kind of diverted into what would become 2016-17 era ICOs. So I ended up just kind of helping a number of these people on these early projects. And I just had a lot of fun doing that. I kind of did it on the side until it just became basically a full-time job. And I ended up getting some offers to join crypto full-time. I was getting kind of disillusioned with lab work and moved into crypto. I also moved to Berlin, kind of used that as an opportunity to like, I don't know, convince myself that a new career, new continent, like new life. And yeah, I did a bunch of consulting for a while. I worked with a number of different projects. Some of them were Cosmos projects actually. And then when the pandemic started, I was living in Berlin. This was right as one of the founding teams kind of melted down. My best friend in Berlin at the time, Billy Rennekamp, was at that team, Tenerman Inc. And he would kind of tap to migrate the engineering team to the Interchain Foundation, which is the kind of foundation associated with Cosmos project. And he wanted some help cleaning that up. So I was the first hire there. And yeah, I didn't, I mean, the rationale is like, I didn't want to be doing freelance work during a pandemic. So I jumped into Cosmos and it was like pretty messed up at the time. So our job was just like, pick up all pieces and set up contracts with this like, fragmented array of teams that had kind of spawned out of Tenerman Inc. And yeah, just kind of like turn that into a functioning ecosystem. that like, the first thing we did was ship IBC, the kind of core messaging protocol. And then it's just been kind of an incremental series of fixes since then. The ecosystem is, you know, actually functioning quite well today, still has its, you know, sore spots. But the technology is like, is really coming together. A lot of the core financial primitives are there. And...

Nicholas: So just before we jump into Cosmos, I'm just curious, what kind of genetics research were you doing? or biochemistry research?

Sam Hart: Yeah, I did a bunch of things. So I was in the industry for 10 years, I started out doing protein folding research. So like simulations of biomolecules, like protein DNA interaction, things like that. And then I moved into a lab that was doing. it was, it was really kind of the heart of this high throughput sequencing, Moore's law phenomenon where the cost of genomic sequencing went from like a billion dollars to $1,000 in a matter of like 10 years. So we were getting like all these new data sets. I was doing kind of cross, like population studies with brand new data sets, like different cancer types.

Nicholas: And that, like, precipitous drop in the cost of sequencing was based on like a computational approach to reconstituting more raggedly sequenced DNA, is that right? Or actually using the biological system to reorder the like shotgun sequenced data?

Sam Hart: Yeah, it was a kind of a combination, a creative combination of things. One was the reconstruction of fragmented data sets, so you could kind of stochastically rebuild a set of independent fragments, as long as you had some understanding that there was like, they were randomly broken. So yeah, it was part like kind of computational and then part procedural. There was some very interesting kind of chemical innovations where basically you'd like break up fragments of DNA, bind them to like magnetic beads. And then you could, you could kind of adhere those beads to like, you know, a surface and have like solvents away at them at like specific rates. It was pretty insane. Yes, set of like innovations that have had to all kind of interlock to make that work.

Nicholas: Very cool. All right, we won't dwell on the genetics too long. But I think it's worth noting that you have a serious background in that. And also, again, we won't dip into it too much, but also in art, and also the encounter of art and blockchain. You have a lot of experience too.

Sam Hart: Yeah, my parents are both artists. And I grew up in an art household, still kind of keep it as a, as a passion of mine. And I do some NFT stuff with a gallery called Folia.

Nicholas: Right. And there's another episode that you guest on that people can go check out if they want to hear more about the art and blockchain side. So jumping into Cosmos, then. So Cosmos came out of this 2017 era originally?

Sam Hart: Yeah, I was not involved at that point. But I kind of saw it happen from afar.

Nicholas: What was the impetus for it at that time, or when you rejoined the project a couple years later?

Sam Hart: So I might get the dates slightly wrong on this, but like about 2015, basically, one of the founders, Cosmos, Jay Kwan, was working on a consensus protocol called Tenormint, now called Comet BFT, but originally called Tenormint. And he basically was seeing what was going on in Bitcoin and kind of actively involved in conversations there. And so Bitcoin kind of created a novel consensus protocol, the longest chain proof of work. And Jay Kwan was trying to kind of apply classical BFT principles to creating a Byzantine fault-tolerant public blockchain network or system. So he was kind of pushing those ideas forward. Ended up connecting with the other co-founder of Cosmos, Ethan Tuckman, who had distributed systems, also, and a biophysics background, a bit of a common theme in Cosmos.

Nicholas: That's interesting. Unexpected.

Sam Hart: And yeah, and they first tried to apply that to more of a kind of commercial, like private blockchain context. And then kind of realized that really, kind of where this was most interesting was in a public blockchain context. And so they came up with this idea of like, okay, we have these BFT chains with a proof of stake system, and we can network those together, similar to a kind of internet topology where you have servers that are networked together with a standard networking protocol. They wrote the paper.

Nicholas: The premise even back then was that they would be smart contract chains?

Sam Hart: Agnostic. It really did kind of start with this like application-specific chain design. So that could include smart contracts, but they were kind of more interested in the vertical integration of the application, which may not necessarily be smart contracts.

Nicholas: So you were aware of it at the time, but it wasn't your main squeeze, you're working on other things. And so you land there a little later.

Sam Hart: And yeah, I mean, I intersect with it kind of. before actually working at the ICF full-time, I worked on a project called Foam, which is like a geospatial blockchain project that used Tendermint for a while. I did some consulting for them. There's some very, very interesting projects in Cosmos that I ended up just kind of like meeting them and working on some small contract things. for what kind of thing.

Nicholas: So the two main things that I want to get through in this conversation are one, for people who are more familiar with EVM, get a kind of technical architectural background for what Cosmos is, how it compares to EVM for people who are more familiar with that, and maybe understand some of the unique affordances of Cosmos. And the other thread I want to address is kind of what the cultural side of Cosmos is. And I think you're getting at that a little bit with sort of dabbling in different projects contractually, starting to sound a little bit like what the Ethereum ecosystem has to offer in terms of a bunch of projects that are kind of interrelated on the same stack and friendly to one another, sharing people working on them. Is that a fair read?

Sam Hart: Yeah, I've gotten some exposure to Cosmos project before. There's a really interesting community there. And when Billy had kind of asked me to join the ICS, I understood a little bit about what was going on, the architecture, but also there's definitely something that resonated with the vision. Just the general topology of the network. It is a very bottom-up kind of system. And yeah, that just spoke to me. So that was part of my interest in joining and helping to push that forward.

Nicholas: Great. Two threads that I want to address in this conversation are, first of all, for an EVM familiar person, what is the Cosmos architecture? What are the pieces? And how does the overall picture compare to EVM for people who are more familiar with that? And what unique affordances does it have? And the second thread I'd like to get to is this more cultural piece about what the vibe is of the Cosmos ecosystem. And from what you said about dabbling in different projects contractually early on, it sounds like it has some shades of what might be familiar to someone who knows the Ethereum ecosystem. Is that a fair read of the cultural ecosystem there?

Sam Hart: Yeah, I can speak to that a bit. So yeah, there's some similarities and differences with Ethereum. So the Cosmos architecture from the EVM or solidity perspective, if you're on ETH mainchain, applications take the form of a smart contract or set of smart contracts and a front-end application typically. And what is a smart contract doing? It's basically defining a state machine, but it's relying on the Ethereum virtual machine to advance that state machine, to kind of validate that you're advancing the state machine correctly. And then it relies on the consensus engine to make sure that everybody agrees that that sequence is correct. In the Cosmos architecture, basically you can imagine like taking that Ethereum contract and putting it on, you know, you're forking the entire Ethereum code base. You're just taking that contract and you have nothing, no other state on the system. So now you have your own consensus engine. You have your own EVM and you have your own contracts. And now, you know, you're on an island and because nobody else is here, you can even start changing all the pieces below you. So if you want to increase the block times, you can do that. If you want to make changes to EVM, you can do that. If you want to, if you don't want to use solidity anymore, you can, you can use something else. You can actually, you can actually just throw away the entire EVM and write the same application, but just into like the guest node. And this is like a precompile. But except that literally there's no EVM, like that you just, it's all, it's all just part of the binary. And, you know, so that's kind of like the, the logic that you're, that you would follow as a solidity dev. I mean, you're already kind of seeing this in Ethereum today with these L2s that are, you know, trying to mostly stay Ethereum compatible, but like, then they'll add like a couple, you know, so like gas will be a little bit different or to add like one op code or something like that. Cause it's just really helpful.

Nicholas: Yeah. R1 verification or something like that.

Sam Hart: And, you know, and then most recently, like you're starting to see a little bit of this like application specific rollup idea. Which is a little bit, if you're coming from a Cosmos perspective, it's a little bit like this looks like a toy, but what about?

Nicholas: it looks like a toy because just messing with the EVM and messing with the relaying infrastructure for getting data back to L1 is like bolted on relative to how essential it is to Cosmos?

Sam Hart: Mainly because the kind of coolest stuff that you can do with Cosmos is all like at the lower layer, you know, so you're going to be like ripping out parts of consensus and changing that or the P2P layer or changing the execution model or like, you know, making like adding parallelism, just like stuff that's, it's not, it's not like available to the EVM. It's like not within the EVM developers kind of like worldview to be doing those things.

Nicholas: So just before we get, because it's tough, because it seems with Cosmos, it's like one of these things where anything can be changed. And so it's hard to get a handle on what the essence is in a sort of default setup. So there's Comet BFT. So this is the Byzantine fault tolerant consensus protocol. Some things I was reading, it has sub-second block times. Is that right?

Sam Hart: Yeah, yeah.

Nicholas: So is there, I guess, say like a smart contract developer doesn't really think too much about that. Maybe they just think about what the performance characteristics are of the L2 that they're picking if they're going to deploy on something other than L1, but they don't really think about the consensus protocol too much. So maybe can you give me a little picture of Comet BFT?

Sam Hart: They do. Yeah. I mean, so someone who's deploying on L2, they might think about like, is this a ZK rollup? Is it an optimistic rollup? What is the kind of finality conditions? What happens when I exit? You have this kind of indirect relationship to the consensus protocol, but it's a little bit oblique. And I guess you might also think about the sequencer, which is typically kind of married to the consensus protocol when you have your own chain. But yeah, Cosmos is a very different paradigm. So the one way that I typically start with explaining Cosmos is, Cosmos is not like a specific instantiation of a piece of software like Ethereum is. Ethereum is like a singular network that everybody's running the same way, like bytecode compatible clients. Cosmos is the closest thing that I can, the closest analogy I think is like a, it's a design pattern basically. So like the Jamstack is a good example, if anybody's familiar with this. Like the Jamstack is not actually any specific pieces of technology. It's like, it is a set of modular components, any of which could actually be swapped out for another thing. But it's like, you can create a static site with the Jamstack and plug these things together, and you can swap them out and whatever. Similar idea with Cosmos. It is a design pattern that has a consensus protocol, an application or application framework, and a networking protocol. That's it. So any of those could be swapped out. And people in fact have swapped all of them out in different instances. People have changed, a bunch of people have changed the application framework, like written their own. IBC is like kind of the, a lot of Cosmos people like rally around the most. So that's kind of the thing that's been like least swapped. That's inter-blockchain communication. Yes, that's the networking protocol, inter-blockchain communication.

Nicholas: So we have consensus protocol, application framework, and a communications protocol. That's Comet, BFT, application framework is whichever you choose. I guess the standard is Cosmos SDK.

Sam Hart: Cosmos SDK is the most popular, but there are others.

Nicholas: Okay, and then inter-blockchain communication is the communications protocol. So we can kind of think of these three building blocks, which you can each swap out, but these are the three things that you need to have a Cosmos. Would you call it a Cosmos chain?

Sam Hart: Yeah. And notably, like we didn't say VM there. So like, however, a lot of Cosmos chains like have VMs, basically like plug that into the application framework. So there are Cosmos chains that have EVM. There's actually two entirely different like EVM implementations. There's actually a third that I heard about the other day. There's a Wasm execution environment called Cosmos. There's a move execution environment somebody's building. There's a whole bunch. So yeah, that kind of is like nested into the application framework, similar to how, I mean, I guess it doesn't really like divide this quite the same way, but like the EVM actually like sits in the geth node and then the geth node actually has the, is kind of like integrated quite directly into the consensus

Nicholas: protocol. Got it. So maybe we can go through each one in a little bit more detail just to make people familiar. So let's start with the consensus protocol. So Comet BFT, we talked about it a bit. Are there any properties that we could or design principles in it that we could share with people?

Sam Hart: Yeah. So Comet BFT is a classical BFT protocol. It is designed to be relatively simple to understand. That was one of the big design goals is to ensure that it's extremely well specified and kind of intelligible to developers.

Nicholas: Is that in contrast to other things that came before it that were harder to understand?

Sam Hart: Well, yeah, BFT, there's a whole like family of BFT protocols, and there's still like a lot of discovery being done there. And you end up kind of at different points in the trade off space, depending on what you're looking for. So for instance, Raft is a very simple protocol, but it like kind of has some overhead trade offs and like fault tolerance trade offs. Paxos is like kind of the oldest BFT protocol as far as I understand. And it has historically been like a little bit challenging to like to reason about. There's like some controversy about that. But anyway, Tenement's very close to PBFT. It's got a couple of kind of minor modifications, which is like very well studied consensus protocol. And yeah, one of the kind of primary features is that it'll be very familiar to anyone who has studied consensus protocols, like you'll be right at home. It's extremely well specified. It actually has the whole thing's been formally verified. And every time there's a modification to the software, the formal spec basically like generates a set of tests and the tests are like automatically validated against the implementation. So it's like there's an extreme emphasis on correctness of the protocol. And this is because it's designed with like clients in mind. So this kind of gets into the IBC, the networking protocol, and how that works. So if you are another chain that wants to talk to the first chain, you need to validate. The way that the verification works is the chain actually needs to understand the consensus process of its counterparty, does that with a like client, which basically tracks validator set updates and power changes, the staking power changes. And yeah, so it verifies the consensus process and will only admit messages that have been properly verified. So that process needs to be like 100% perfect for this whole network architecture to be secure.

Nicholas: Got it. So for Comet BFT, some properties maybe you could explain a little. You have instant finality, as opposed to something like proof of work, or even Ethereum's proof of stake, which I don't, you don't have instant finality, right? How does it achieve that?

Sam Hart: So this gets a little bit into like the philosophy or like the underpinnings of consensus. So there's like a fundamental trade off in consensus design between liveness and correctness basically, or safety. And Ethereum chooses, similar to Bitcoin, chooses liveness. They kind of locate themselves on that side of the consensus design space. They felt like having information about the chain and knowing that it was still continuing to attempt to construct blocks was more important than an external observer, knowing that a block was final. And so you see that in Ethereum protocol for anybody who's familiar with it. There's like a soft confirmation and then there's like a finality gadget. that like happens later on. In the Comet BFT case, we kind of put ourselves on the other side of the spectrum. So Comet BFT is safety favoring. And there's fundamental trade off here. So like if you're safety favoring, you are not liveness favoring. So if there's some, if not enough validators are attesting to a vote or like to advance the chain, the chain will halt. And that is like preferred in the Comet case. And you'll need to get the remaining kind of voting power on board to continue to advance the state machine. Again, for like any Ethereum people, the closest thing to Comet is basically going to be the Ethereum finality gadget. It's kind of like Comet is is like just the finality gadget. We really like center that and make that like. Got it.

Nicholas: And how do, how can we think about validators and the other actors in the Comet BFT network, you know, sub component of Cosmos?

Sam Hart: Comet BFT like any other public blockchain has validators. They it's a proof of stake chain. So they look and feel in some ways similar to Ethereum. The main, there's a couple differences. One of the differences is there is explicit delegation in the Cosmos like proof of stake architecture. So if I'm a token holder on Osmosis, I can stake that token with a, I do not have to run machine myself. I can stake my tokens to a validator and they are going to vote in the consensus protocol on my behalf. You end up getting something very similar in Ethereum with liquid staking. We can go into that if you want.

Nicholas: So it's kind of, kind of like rocket pool built in, but maybe not as much architecture because it's already.

Sam Hart: Exactly. So we like Cosmos kind of like realized or like, yeah, believed that not everybody was going to want to participate in consensus. And in fact, it wouldn't really be practical for everyone to participate in consensus given the architecture of the network. And so, okay, we're going to have people delegate. And really the kind of design philosophy around that is like, we are entrusting specific actors to run the infrastructure of the network. But so we're creating, we're creating a two tier or two different roles in the system. But the delegators need to be holding the validators to, to account. So they, delegators should be able to run a light client to see that validators are doing their job correctly. And they should be able to, to delegate away from validators that are, that are not performing well.

Nicholas: And not performing well would be lack of uptime and even, I don't know, false attestations or something? Or what would bad behavior be for a delegated validator?

Sam Hart: Yeah, so it could be, it could be missing blocks or lack of uptime. It could be potentially slowing down the network, like attesting late. It actually is very dependent on what the network, what the chain does. So if it's, if it's a DEX and the DEX is, kind of has the, the shared principle that like there shouldn't be any front running, validators shouldn't be doing that. Delegators, and it is observed that a validator does do that, or they allow that, then a delegate, delegator could delegate away. So this is kind of interesting. It's a very powerful accountability mechanism. And it actually allows for delegators to kind of like expect more of their validators. You can kind of make them do very specific operations.

Nicholas: But the action, the action of delegating away still has to go through the validators, right? So if there were, if validation was centralized sufficiently, they could censor the delegation away? No?

Sam Hart: I mean, only a single entity needs to like, submit the transaction to the mempool. And one, well, one third of the network could collude to censor transactions. But I've never seen that in practice. If that happens, the user could basically yell at you on Twitter and like, tell you that this is happening. So there's a, I think there's actually...

Nicholas: One third is enough to censor transactions?

Sam Hart: Yes. And this differs. So this comes to like the, the kind of key trade off in the consensus protocol design. These liveness favoring networks have a 50% threshold for censorship resistance and BFT networks have safety favoring have a one third threshold. So the threshold is lower is like a fundamental.

Nicholas: That's been countered.

Sam Hart: Limitation.

Nicholas: Well, if one third, one third is less than half, but it's, you said it's safety favoring.

Sam Hart: So one third is less than half, but it's safety favoring. This is for censorship resistance. So this doesn't really have a bearing on the, the agreement of what the state is.

Nicholas: Okay. So there's a trade off in censorship. or like the, the threshold for censoring goes down, but the ultimate security of the ledger goes up.

Sam Hart: Yes. So you have a higher assurance that the, if the state machine advances, it will, it, it will be like the correct state. You'll never revert to something else. But you are trading off the ability to advance the state and the ability to like continue block production. And that, that's kind of like married to the ability to submit transactions. So censorship resistance.

Nicholas: So this is what you're saying about. if there's some disagreement, the chain will halt, but the data in the chain will be, you know, very, very secure, but it's more likely to halt than, than say Ethereum.

Sam Hart: Yes, exactly.

Nicholas: Very cool.

Sam Hart: Sounds kind of like- Anyone interested in this should like look up the CAP theorem. I mean, that's like the core theoretical results or like the FOP theorem.

Nicholas: Okay. I'm going to look that up. So, okay. And in your post on the MakerDAO forum or the Maker Forum, you talk about the importance of this delegator validator relationship. Is there anything else to say on that? That's important to know?

Sam Hart: I can talk about that a bit. It is, yeah, it's definitely like a Cosmos superpower. And I wrote another post on this that was like more of an, in an MEV context, because I do a lot of MEV stuff at Skip. And so I can kind of like talk through that example.

Nicholas: Yeah, please.

Sam Hart: So we've been working a bunch with DOIDX, which is a derivatives protocol that is now building in Cosmos. And they are, they have a very interesting architecture that they've chosen where they have validators. They have all validators hold an order book off-chain. And so there's no singular order book. It's a subjective order book, basically. And they gossip updates to the order book to one another. And this is kind of scary in some ways, because the, the order book is very, it's integral to the like fairness of the system. So validators could manipulate the order book by excluding certain transactions or prioritizing certain transactions over the other, over others. They can withhold transactions from propagating them to other validators. And what we, what we've done is we've basically kind of created this globally distributed observability system where we collect copies of the order book from different validators and kind of statistically reconstruct like, whether validators are performing their, their duties correctly.

Nicholas: You're almost rating their honesty in the gossip protocol.

Sam Hart: Yeah, they're, and they're got with respect to gossip and the kind of actions that they perform. With their local copy order book. And, but, but we can't directly attribute any specific action as malicious. So in aggregate, over time, we can say that this validator is doing something funny. Got it. But we can't at any point be like, this one action was malicious.

Nicholas: You're saying you can't, you can't do it because you can't be sure that they didn't, they got the message or that, or you can't do it for a cryptographic reason.

Sam Hart: We can't do it because, yeah, we don't have like full observability into like their, what's happening on their machine. And, and like, there could be network latency. There's just like, there's little reasons that like, that some of these, these anomalies could happen. But over time, if, if a validator is being malicious, they're going to like, you know, they would continue doing that. And we can say, okay, you know, something's going on here. So it is a much weaker, you know, this is very different than like a smart contract system, right? Like where it's something, if, if an, if a smart contract is called, like it will execute exactly the way as intended in this off-chain system. First of all, it's all these order books are being kind of simultaneously updated. So there's no singular view of the application state. And we can't actually be a hundred percent certain that any specific operation has been performed exactly correctly, but we can get this aggregate kind of understanding. And so where does the validator delegator relationship come into play? Well, if we can, if we can kind of like build this metric of, of kind of good behavior over time, then, you know, we basically created like a, a dashboard for this, this creates a, it's basically a reputation system for the operators. And so when you're, when you're a delegator and you're, you know, you're presented with this, you're like, okay, well, am I going to delegate to operator? that's like fucking me over? Or am I going to delegate to ones that are actually performing their duties?

Nicholas: So it's more than a brand name list. It's a, it's a statistical analysis of their past behavior for you to choose who you want to delegate to.

Sam Hart: Cool. But it reflects on their brand and, and you can layer on like slashing and stuff like that. Something that the DODX community is kind of just discussing now, but even without it, we actually think that there's, it's quite a powerful mechanism because, primarily because it's not even restricted to just the DODX chain. So if I'm Chorus One on the DODX network, my brand as a validator is like super, super important because I attract delegations as Chorus One. And if I'm screwing around on DODX, that is actually going to kind of indirectly impact me on all the other networks that I'm validating on. Like the, the next time that somebody goes to delegate on Osmosis, they're going to be like, this Chorus One was completely fucking around on DODX. Like I don't trust them. So this kind of like weak horizontal reputation layer kind of unifies Cosmos in a very interesting way. And you can, yeah, you can just leverage that to do quite powerful things. And there's a really interesting phenomenon in Cosmos where like validators will kind of spontaneously do things that, to help the network, like they build dashboards, they do all the IBC relaying. They actually, all the IBC relaying is like done for free today for the most part. And it's, it's kind of like, I want to build my brand reputation and like kind of do right by the network, because it's important for my business. It's important for my reputation.

Nicholas: Those get figured into this statistical analysis?

Sam Hart: No, not in this case. But I'm saying that the, this DODX, we are kind of defining this metric in the DODX case. You know, are you messing with the order book on DODX? But it kind of contributes to this like overarching, you know, brand reputation of the validator. Like, I'm a validator who's done, you know, performed really well on DODX. I'm also like relaying on, you know, from DODX to Osmosis. And I made this other like staking rewards, a withdrawal system that's like really nice for delegators. Like, there's these things that like validators just like make stuff and like try to just help the network because it contributes to their brand and thereby their business.

Nicholas: These are the operators to be very specific?

Sam Hart: Yes, the validators, the operators of the network.

Nicholas: Why are there multiple order books in the DODX example? Why is there not a single order book and then it's just a matter of propagating it across all of the nodes? Why have separate order books?

Sam Hart: So DODX explored putting the order book on chain. But basically, the order book needs to be updated one or two orders of magnitude faster than like any block time, like available today. And okay, so you know, that basically like the inclusion there was like, okay, we can't do this on chain. And if you're not going to have it on chain, well, now who is going to hold it? The current version of DODX that's built on Starkware, DODX is holding the order book, and they're being trusted to kind of perform those order book updates correctly. However, they just can't continue to do that and claim the system is decentralized. So they, yeah, they set up a system where many actors are holding the order book and it's kind of interfaces with the consensus process to ensure that there's at least some degree of agreement between different order books.

Nicholas: And that's a part of their implementation of the Comet BFT or part of their communications protocol design? Or it's just a separate?

Sam Hart: So it's, the order book system is separate. It is, you can basically think about it as a, I mean, it is their mempool effectively, like they've kind of written their own mempool that integrates this order book system.

Nicholas: So that wouldn't fall neatly into any of the three categories we described earlier, the consensus protocol, the application framework, and its VM, or the communications protocol. This is like a separate piece, or it's one of those?

Sam Hart: So Comet BFT has a kind of out of the box mempool. Yeah, we're getting, we're going deep. It's good.

Nicholas: That's what we're here for.

Sam Hart: So Comet BFT has a default mempool. And the way that a, any consensus protocol works, we'll just stick to BFT for a second, is there are, yeah, there are basically votes. So the different actors in the system, and they, they vote on what they believe to be true. You know, in order to advance the system. And so there's these kind of, and there's actually multiple stages of voting. So you have these kind of this interleaved process where first, everybody needs to communicate with each other. So there's like a kind of end to end communication process where everybody tries to like, get the same information from, from each other about how the system is, you know, what transactions are available, basically.

Nicholas: Okay.

Sam Hart: And then a proposer, typically there's one proposer will say, Hey, okay, I got these transactions. And I'm the person who's been nominated to build the next block. I'm going to construct my block and distribute that to all the other validators. All the other validators can, they have already done a round of communication with each other. So they can compare that to their local set of transactions. be like, yes, this makes sense to me, I'm going to sign that proposed block, and then distribute it to, and then send, yeah, basically, like, send that back to the network. And so you basically go through these like rounds of voting, and gossip, and then voting, gossip, and then voting, in order to ensure that you are both getting all the information that you need, as a consensus participant, and validating that everyone else is kind of in agreement with, with your local perspective of the network.

Nicholas: So this is kind of tantamount to in the L2 space, the decentralized sequencing problem. And I suppose there is an Ethereum solution for this, too. I'm not super familiar with how, I don't really understand the PBS stuff in Ethereum fully. But you're trying to get to a solution where you can avoid censorship, essentially.

Sam Hart: Yeah, I mean, this is just common to all consensus processes, a decentralized sequencer. Well, maybe just put that on hold for a second. I mean, Ethereum has a very similar system. There's a P2P layer, mempool, validators collect transactions in the mempool, they get a block from the proposer, they sign it saying that this makes sense. Well, that's the same. There's some slight implementation differences, and different consensus protocols end up having kind of like different communication overhead and sign things different ways. But that's, you know, very similar in Ethereum. Your original question was about the mempool. Yes. Well, what is the mempool? The mempool is an abstraction that describes the collective, subjective views of all validators. So there's no singular mempool, it is actually this like, this subjective phenomenon of validators, like, having collected all these other transactions, understanding the network to be, you know, in this particular, understanding the network, being able to advance in this specific way. So, they use that information to be like, yeah, I'm comfortable signing this transaction, signing this proposal.

Nicholas: How is the operator validator selected that will be the block proposer? Like, I guess it to an extent, it doesn't matter as much because there's this, like, pre commit phase where they all confirm that they have similar data to begin with, to be able to detect censorship in the proposed block. But there is some selection of who gets to be the proposer who presumably is the one who's, who's staker gets rewarded, right?

Sam Hart: Yeah, so in Tendermint, this is an entirely deterministic process, based on, based on the stake weighted round robin process. So, yeah, basically, like, if you know, who is the current, current validator, and you know, all the stake weights of all the other validators, then, and you know, kind of like the, the array data structure that like, the validators have been kind of like, assigned to, then you can predict the next validator. This is not the same as Ethereum. Ethereum, well, Ethereum used to be proof of work. So select the validator, or select the proposer through proof of work. And that was like, you know, finding the golden knots. So very different. When they moved over to proof of stake, they, they selected a, a new validator selection mechanism. I know a little bit less about this. I know that there's like a, there's a kind of deterministic window where within that window, you know, who the next validators are going to be. And there's also like, kind of plans to like, to change this in the future, I guess, and like, do single secret leader election. But active, active development, ongoing in Ethereum ecosystem.

Nicholas: for this and Cosmos has a solution that because of this multiple rounds process allows you to check if operators are cheating.

Sam Hart: Yeah, you can, you can check whether a block has been constructed correctly, you can check whether you can see if individual transactions are constructed correctly, whether the signatures verify, or like correspond to the validators that, that you know, are part of the network. In terms of censorship. This is, this is a pretty like, also quite a deep, like concepts there. And it kind of occurs across like multiple different timescales. So if you're just talking about censorship of like a single validator, no, if you know in advance what the validator is going to be like, you could do like a DDoS attack against them, right? Which I think is kind of what you're alluding to earlier. There is, there's a mitigation in Cosmos where validators can run what we call sentry nodes, which is kind of like a, it's almost like a personal Cloudflare kind of thing, like CDN, like you're setting up nodes that you're separating the nodes that that accept transactions from the nodes that gossip transactions. And, and you can route between them. So you, you don't necessarily know, like someone may DDoS like one of these nodes, but you could still like gossip through the others. Very cool. So that's one. There's also a bunch of, there's like threshold signed validators similar to like dbt stuff in Ethereum. That also like helps with, can help with censorship resistance. It also can hurt in some configurations. And then there's a kind of censorship resistance over like many blocks, which, yeah, maybe we won't go into that because that's the whole.

Nicholas: If people want to look that up, is there, is there just a tag, something they can Google?

Sam Hart: Well, some of the most interesting stuff I think has been on censorship resistance, kind of measuring the cost of censorship resistance over for a certain duration. The, this became kind of acute or like the Ethereum community became like more acutely aware of this with the OFAC censorship stuff. And so there's a whole bunch of ETH research discussions about censorship. If you do like censorship OFAC and ETH research, you'll probably come up with like a whole bunch.

Nicholas: And that's relevant to Cosmos too, all that, that same thinking.

Sam Hart: Yeah. A lot of, there's definitely a kind of informal correspondence to a lot of the research going on.

Nicholas: So do you think we covered Comet BFT sufficiently. or is there any other main discussion of Comet BFT that we should get, get to before moving on?

Sam Hart: Well, the, one of the like really important thing, things to know about Comet that like, it's kind of like why you might want to build in Cosmos is you, you get access to the consensus process as an application developer. So like I was saying, Tendermint, uh, so DYDX like, uh, opted not to use Comet's mempool, right? They're like, we're going to scrap that. We're going to write our own that has this very specific property. And we're going to, one of the things about Comet is that it has a very sophisticated interface that basically allows you to interact with any validator individually at any point in the process. So for validators, there's kind of four-ish steps of consensus, like gossip, vote, gossip, vote. Um, you can address any single validator at any point in time during the consensus process and make them do something. Um, that can be part of your application design.

Nicholas: So why would I want to do that?

Sam Hart: So in the DYDX case, they, they want the individual validators to be doing something with the order book, for instance, because everybody's got a different view of the order book. Some of the stuff that we're doing with skip is we're, we're kind of making this a little bit more programmable and like providing some, some kind of standard applications that interact with the consensus process. So one, one thing we're doing is making it so that validators, so a lot of these applications need an Oracle, they want an Oracle, but Oracles kind of suck, just period. They're really, really hard to get right. And one of the, one of the issues with Oracles, there's many, but one of them is they're typically asynchronous with the, with consensus. So like when you do a, when you're using like a chain link Oracle, um, on Ethereum mainnet, you don't know that there's going to be an update at block at 1000. All you can do is like, wait for the next update to occur or just use the last update. That's, and not necessarily have an understanding that it, that it is the current state of the world and what we're, so we built like an Oracle system that makes it so that every single block, every single validator must post an Oracle update. So it is, it is integrated directly into the consensus process. The consensus cannot advance if the validators have not produced a fresh update. So you're, so then what happens is your application can now depend on a fresh price feed or whatever, every single block. Um, and you don't have to do this kind of like async logic to, and there's a lot of like, there's a lot of complexity produced to like accommodate this like asynchronous behavior of the Oracle updates that like you no longer have to worry about at all.

Nicholas: And so the chain would not advance if, uh, if we don't get a fresh, uh, Oracle update?

Sam Hart: Yes, exactly. I mean, this is programmable, so you can, like you can have different conditions here, but like that, uh, uh, if an application developer like chooses to, to kind of, to make that a safety property of the system, like I do not want the application state to advance without this new Oracle update, they can do that.

Nicholas: Got it. Okay. Amazing. I, in passing, DYDX, I mean, very willing to try out pretty deep, uh, projects, development projects to make their project work across different ecosystems. It's, uh, it's pretty impressive.

Sam Hart: Totally. I've been super impressed with them. We, we had to do a lot of, of onboarding because I mean, Cosmos just has like an insanely deep stack, but I mean, they, they're, you know, highest quality team out there for sure. And I, I don't know. I mean, they, they're like the most successful derivatives protocol decentralized derivatives protocol. And they're just like, yeah, we're going to blow up our existing system and build an entirely new one. Really.

Nicholas: Very cool. And not only a new version, but on entirely, I mean, this is the second time they've switched blockchains and with very radically different architectures. It's pretty cool. They're not just switching to, uh, some new rollup or something. They're really rewriting everything and rethinking everything. Very cool. Okay. So I think we, we did a good tour of Comet BFT. Uh, there's lots of extra questions, things about fees and, and more details on the mempool or block proposing, but I think this is a good overview. And maybe if anyone's listening and, and, and wants more detail, uh, you can send Sam a message and we'll get Sam back for, for another call for deeper conversation.

Sam Hart: Yeah, it just became a Comet BFT discussion mainly.

Nicholas: Let's try to run through a couple other things before the end of the hour. So Cosmos SDK, uh, this is the maintained by binary builders, uh, is, and it's one option for the application framework, but of course this is Cosmos. You're not required to use this one. And maybe so Cosmos SDK, what does it give me as a, as a developer? What, what, what affordances does it have and why might I want to deviate from it?

Sam Hart: Yeah. So it lets you build a state machine. It has hooks into Comet BFT out of the box. Um, so the way, so for instance, the way that dydx wrote their mempool was they actually wrote the mempool in, in the Cosmos SDK and, uh, and kind of pass that information back into Comet. So, you know, it's like writing an application, like server side instead of like application side or something like that. Um, uh, so yeah, I mean, it's extremely advanced system. This is where the proof of stake module, uh, like proof of stake system is written. Um, although you can rip that out and write your own people have written like POA or like different variants of proof of stake, uh, it has built-ins for, you know, basic operations like signature, signature verification. Although again, you can add your own stuff. It's, uh, it has the, it, it is an application framework. So if you're, if you use like a JavaScript application framework, like react or something like that, similar kind of idea. There is a, a kind of central like message bus. There's a, a built-in data store, uh, which, you know, writes things to, uh, to a Merkle tree. There's also a, a kind of sidecar database that, um, does indexing. So you, you have a, uh, you can access, uh, you can do reads from the, the, um, the Merkle tree without actually like traversing the tree. And yeah, I mean, it's just like incredibly flexible. So you can write your own governance system.

Nicholas: So for, for EVM heads, this is like the equivalent of the EVM, uh, and maybe parts of the graph or at least the event emission and then indexing over that. This gives you that, that what an EVM dev might think of as the EVM.

Sam Hart: Not really. Uh, it, the EVM is a virtual machine. So it is, it is a kind of turn complete, like metered environment. I mean, literally the best analogy I think is like the EVM is, is kind of like, or this virtual machine environment is kind of like user space or literally like a VM on your computer. Like you're like in that world and it's all sandboxed and you can do whatever you want in that world, but it like, doesn't like, doesn't touch the external world unless you, you do like very specific, uh, right operations or whatever.

Nicholas: So, so you're, it's not on chain, everything that's happening in this, uh, Cosmos SDK.

Sam Hart: No, it's on chain. Um, the, so basically a lot of what you're doing with the SDK is similar to rebuilding Guess itself. Like you are, um, if you want to change the RPC structure, if you want to change the database backend, if you want to change.

Nicholas: Okay. So the node software basically is the Cosmos SDK.

Sam Hart: The node software. Yes. Notably the EVM is like glued into Guess, right? Like it's part of Guess. It's all like consensus is formed on like solidity or like bytecode operations in Guess, but under the hood in, uh, there's also, yeah, these, these like, uh, you're writing to the Merkle, like the, the Patricia tree, um, things like that. And so in Cosmos, in Cosmos SDK, if you wanted to like rip out the Merkle tree and put a new one in because it has like a different, you know, a more optimized data structure or whatever, you can do that. Like you can, you can go, it's like writing kernel modules basically. So, you know, similar to like, if you were to program in Linux or something, like I'm going to like rewrite the Linux kernel to like have different drivers and, you know, to literally like change the, the like user, uh, permission, permissioning system. Um, I'm going to, you know, you, when you're at that level, you can do, you can do anything you want. You're like, you're interacting directly with, with the hardware.

Nicholas: So Comet SDK, so Comet BFT is the consensus and Cosmos SDK or this application framework. If you use something alternative to Cosmos SDK is both the VM and all the rules for how to make use of that consensus protocol in Comet BFT. So really you're interacting with the node software. is this application framework level, the Cosmos SDK level. So if people want to get involved in, I just don't want to make things too fluid or vague. So if people want to get involved in Cosmos or try things out, Cosmos SDK is like the first place to start, gives you a sensible default for starting to think about what your application chain might be like.

Sam Hart: Yeah. So, um, there's a couple of ways to get started. If you're an EVM dev, then, uh, you can like deploy things to the Cosmos chain that has the EVM. So, um, two, two of those chains are, or there's a couple of them. There's, uh, um, Kronos, the crypto.com chain, um, Evmos and, uh, Barra chain, which is coming soon. Those are all like different EVM chains. If you want to, like, you know, you're not gonna have kind of like a full Cosmos experience there, but like you want to dip your toes in the water, just like deploy some contracts to that easy. Cosmos is another VM, Wasm VM. That's like a little bit more IVC native, like Cosmos native and has kind of operations that are serviced that help you interact with that. So you could write a Rust based contract, compile it to Wasm and deploy it to Neutron or Osmosis or something like that. If you want to get into this, like Cosmos SDK level, the like kernel level, I would recommend going to tutorials.cosmos.network. And there's like a, it's, it's a pretty extensive introduction with, you know, where you're like building your own application, um, has a lot of like background info on, on the way things work. And, uh, and you could also like get started as a validator, um, which is, you know, a good way to kind of understand like the social layer and, and the underlying operations.

Nicholas: So the Cosmos SDK, just before we jump off that topic, um, what language is it written in and what language, languages are available to me if I want to make changes to it or propose an alternative?

Sam Hart: Uh, it's written in Go. Um, although, uh, like I mentioned before, it has this kind of module system and we, one of the things that binary is working on right now is making it so that you can actually like write modules in, um, another language. So you might be able to do like Rust and just have it like interact through a kind of shared message bus.

Nicholas: So anything that compiles down to Wasm or something else?

Sam Hart: No, it could be anything. I mean, in this case, it, and this is still like highly experimental feature, but for the most part is a, a Golang based application framework, but like any application framework, you can, right. You can create like a, you can talk to it from something else. Yeah. You can talk to it through a common interface and then you can program that. So there's kind of like a modularization of the application.

Nicholas: Okay. Okay. So you could plug in some additional functionality. in the same way you could like, uh, you know, add a precompile to your own L2. Uh, you can, this is even more affording for that, uh, deliberately in its design. Okay. So that's the, that's the application layer. And just, I know we're kind of running out of time, but I don't want to miss IBC. interblock, interblock communication is the third big piece. Aside from, I guess, the client development tooling stuff, there's like JS tooling for building front ends and things. We won't talk about that, but that exists. Uh, but for IBC, um, so it's maintained by Interchain Foundation.

Sam Hart: Yeah. Interchain Foundation and, uh, informal or like kind of primary contributors, although there's a bunch strange skip also contributes in some ways.

Nicholas: Okay. And this is the, this is the transport layer. This is the, the communications layer between Cosmos implementations.

Sam Hart: Yeah. Or between Cosmos chain implementations. Yeah. The, there's, there's a lot to say about IBC. It is kind of the, it's, I think it's the thing that like Cosmos ecosystem developers and Cosmos ecosystem are kind of like most proud of. It's, um, it's, you know, it's a very like elegant design.

Nicholas: So what does it do? Like very high level, what does it do?

Sam Hart: So it is, is it, it's a couple of things at once. Um, it is a standard messaging, uh, protocol. So it defines similar to a normal networking protocol. You'll, you'll have things like ports and packets and things like that. Um, so it defines the semantics of those things and then allows for kind of extensible layer of applications. So SMTP, uh, is a application standard that is, uh, leverages the underlying TCP/IP messaging standard, right? So in order for an SMT packet to be understood on both sides, we need both sides to have the SMT like application installed basically. So same idea, you have networking protocol or like a messaging protocol that allows for extensible application protocols. Uh, and then you have a transport layer. So there's, uh, these entities called relayers, um, off chain actors that basically ferry these messages across, uh, across from one chain to another. And then you have, uh, auth authentication of packets from one side to the other. And the way that we do authentication is through these like client proofs. And we're actually extending this to like full, full chain verification proofs. So like both consensus and execution. Um, so you can literally like run a, a succinct, like full node on, on the other chain.

Nicholas: What do you mean by that?

Sam Hart: And then, so this, this is very similar to the rollup bridge conversation. If anyone's familiar with Ethereum, like the, there's this like fraud proof versus ZK proof distinction, like what's going on there. Like basically what's happening is, uh, a proof is constructed that the, according to the application rules, the state machine rules, a computation has executed correctly. It's advanced the state machine in the correct way. And it's providing that proof to Ethereum, right? Same thing in Cosmos, except it's bilateral. So not only is one chain providing proof that it executed, uh, this operation correctly, it's getting proofs from the other side. And so, so there's no single source of truth here. It's like, you're in a kind of consensual relationship between different chains. You're verifying one another state. Um, if there are any updates to the application, like the way that the application should run, then those should be communicated to the other side. And, um, you know, then you can validate those, um, those rules moving forward.

Nicholas: So this is what you were saying, uh, quite a bit earlier in the conversation about one Cosmos chain being able to validate information on another Cosmos chain before incorporating it into its own chain.

Sam Hart: Yes, exactly. And one of the cool things, one of the kind of mind blowing things about this is the, so there's one, one block finality on every single Cosmos chain. that's running comic BFT. So the communication, so message can be sent on one chain received on another chain. Um, and it is final, um, immediately upon receipt and that whole process, depending on the speed of the chain, it could, it could be anywhere between like six and like one second. So you're getting, you know, it'd be similar to like bridging back to Ethereum in like one second.

Nicholas: And because it's able to essentially execute the other chains, VM, yes, or validate or validate that it was executed correctly.

Sam Hart: And this works. The topology of the network, like there's no like singular root of trust. So I, I can make that same, I can perform that same operation, like a, send a packet somewhere to any other chain. So this is kind of in contrast to Ethereum where you're like, you need to go back to the main chain and then you need to go into the canonical bridge of the other chain. Like, no, you just go straight from one chain to the other. And those chains validate that those operations were, were performed correctly on the other side.

Nicholas: And does the chain need to be set up like permissioned to accept data from another particular chain? or they all natively immediately support this and you can push from one to another without the other anticipating that push?

Sam Hart: Immediately. So anyone can set up a connection to any other chain, completely permissionless. You can set up, yeah, individual chains can like gate stuff if they really want to, but you can form a new connection between any chain. It would be like deploying a new canonical bridge, like a user can like deploy a new canonical bridge or whatever to, to a new chain. Permissionlessly. And maybe just like one thing I'll leave, leave you with is like the, I mean, IBC is, IBC is very advanced. So like the, the things that we're starting to do now are like multi-chain atomic flows. So like, cool. There's a lot of the stuff that Skip's doing right now. Like I, I want to perform an operation that requires touching five different chains. So I send a transaction here. I swap it here into another token. I send it over here. I sign something over here. And then I like, I don't know, like stake it into this, like bonded into this thing over here. The user signs one transaction on the origin. And this kind of cascade of like multi-chain interactions, like all is executed atomically. And yeah, I mean, it's extremely cool. Yeah. It's, it's a little, it's a, it's complicated, but like the, the kind of capabilities you get with this are, are pretty extraordinary.

Nicholas: And it's basically IBC is the advanced technology that allows you to do that.

Sam Hart: Yes.

Nicholas: Very cool. Just a couple, very quick questions before you go. What's the most popular programming language for people in Cosmos? Or is there such a thing?

Sam Hart: So at the smart contract level, Rust, people typically use Cosmosm, Swosm, VM. At this kernel level, Go is typically the most common. Although some of the, like I was saying that there's like other frameworks that are coming out. So there's also like Rust stuff available. You can really like mix and match in Cosmos.

Nicholas: Is there such a thing as a Cosmos wallet?

Sam Hart: Kind of.

Nicholas: At least as an entry point for people who want to experiment?

Sam Hart: Yeah. So, I mean, the two wallets that I think are really, I use most often are Kepler, K-E-P-L-R and Leap wallet. They're both excellent. You should try them both out.

Nicholas: And those would generally work across Cosmos chains or only chains that support some specific application structure?

Sam Hart: Those will work across all Cosmos chains. Also, one of the things I've been working on recently is getting MetaMask to support Cosmos, which they now do. So if you have a MetaMask wallet, you can use any Cosmos chain.

Nicholas: Very cool. Is that based on Snaps?

Sam Hart: Snaps. Yes.

Nicholas: Awesome. Wow, that's exciting. Okay. This was a wonderful conversation, Sam. Thank you so much for sharing your knowledge. And I hope we can get you back to talk more of the nitty gritty on IBC, because I think there's a lot to learn from it. And probably pretty enticing to EVM devs to hear about things like atomic transactions across five chains, especially as we head into or head out of L2 summer. Yeah, very interesting. This was a wonderful conversation. Thanks so much.

Sam Hart: Yeah, thank you. I was happy to talk about this stuff. Sorry, we took up 90% of our call on Comet BFT.

Nicholas: It was worth it.

Sam Hart: I hope it was educational.

Nicholas: It was worth it. I'm gonna have to get you back on. If you enjoyed this show, bug me and Sam about getting back on because this was a great conversation. And if you're interested in this conversation, also come back Friday for a couple more episodes. I think Forum DAO and also Ria Myers is going to be on at 5pm Eastern Time on Friday, which yes, you're friends, right?

Sam Hart: Yeah, say hi to her for me.

Nicholas: Will do. Will do. I'm very excited. I'm rifling through her book to be up to date on all of her work from the past 10 years. So it's going to be a great conversation. Thanks, everybody, for tuning in and see you Friday. Thanks, Sam.

Sam Hart: Bye bye. Thanks. Bye bye.

Nicholas: Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter @Nicholas with four leading ends. You can find links to the topics discussed on today's episode in the show notes. Podcast feed links are available at web3galaxybrain.com. Web3 Galaxy Brain airs live most Friday afternoons at 5pm Eastern Time, 2200 UTC on Twitter Spaces. I look forward to seeing you there.