Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Dean Tribble: Agoric – The Secure JavaScript Smart Contracts Platform

Episode Date: February 3, 2022

Agoric is an Proof-of-Stake blockchain built on the Cosmos-SDK that allows developers to create secure smart contracts written in JavaScript. It offers developers safe, reusable DeFi components and built-in economic primitives like a stablecoin, while connecting to the larger blockchain ecosystem via IBC.Besides covering the Agoric platform, we dove into the long prehistory with Agoric CEO Dean Tribble. Dean and his co-founders have been working on smart contracts and secure computing for decades, long before cryptocurrencies were invented, and a lot of that work shaped the Agoric platform today. We talked about underlying design principles like the Object Capability Security Model, but also the tradeoffs between Ethereum's model of scaling on a single chain versus the Cosmos model of sovereign chains interoperating asynchronously.Topics covered in this episode:Dean's background and how he got into cryptoSmart contracts in pre-blockchain timesWhy was Agoric created?The Object Capability Security ModelWhy they chose to build on the Cosmos SDK and the problems that solvesIBC transfersHow much can Agoric scale?What's coming next for AgoricEpisode links:Episode 286 - Agoric and the Decades-Long Quest for Secure Smart ContractsAgoric websiteAgoric on TwitterDean on TwitterSponsors:ParaSwap: ParaSwap aggregates all major DEXs and makes sure you beat the market price at every single swap and with the lowest slippage - paraswap.io/epicenterChorus One: Chorus One runs validators on cutting edge Proof of Stake networks such as Cosmos, Solana, Celo, Polkadot and Oasis. - https://epicenter.rocks/chorusoneThis episode is hosted by Brian Fabian Crain. Show notes and listening options: epicenter.tv/429

Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization and the blockchain revolution. I'm Brian Crane and today I'm speaking with Dean Tribble. He's the CEO of Agorik. Agoic is a proof-restake blockchain that uses JavaScript to kind of enable developers to build secure smart contract applications, secure defy applications. Really interesting projects, lots of interesting stuff to talk about. excited for the conversation. But before we go into all the Gorg stuff, so let's go to our sponsors this week. So first of all, we have Pereswap. So Pereswop is a Dex aggregator on Ethereum. So basically with Paraswop, you can just get the best price because they route you to wherever there is the fastest and cheapest liquidity. They just launched the V5, which has new contracts,

new API, and it's very gas-friendly, and they also recently added support for Avalanche, Polygon, BSC, and Phantom. And yeah, you can also use Pereswop directly from the ledger. So, and in addition to that, they're also becoming a doll. So if you have the tokens, the PSP tokens, that's something you can participate in. So go check it out at Paraswop.io. And second sponsor, course one. course one is running secure validators on lots of different blockchain. So if you want to participate in the proof of sake economy, right, go check out course one. So you can start earning rewards

contribute to network security. First one securing billions and over 25 decentralized networks, including Solana, Cosmos, Ethereum, and most importantly, Gork. You're so kind. Yeah. They're also also running right label notes. So if, you know, institution, you're interested in having a stake in partner, get in touch. And finally, some news there. So, course, one, we did a big air drop, NFT air drop, to all the Solana delegators. So if you're a Solana delegator, make sure you check out your wallet. It was airdrop to 3,600 delegators.

And if you missed it, don't worry. And it's going to be more coming up in the future. So go head over to course. 1 to check it out. And now with that, let's get into our episode. Actually, this is the second episode we have on a Borg.

The first one was a few years ago with Dean's co-founder, Mark. And this was kind of like a funny story, I think, how that happened. So I was at one point, like, thinking, oh, what could we do in terms of podcasts, what would make interesting podcasts? And of course,

smart contracts was like, you know, like an interesting topic. So I think I went to Wikipedia and I was like, let me try to read about smart contracts. And then there was like a few things referenced. And one was like some old paper by this guy Mark Miller. And I was like, oh, that's interesting. And so somehow I found this email. And I emailed him and he was at Google at the time. He was a researcher at Google. And asked him like if he would be interested in coming on the podcast. And then he was first, he wanted to come. And then there was some back and forth. It didn't end up happening. But he did send me some old talk of his from like

the 90s and when he was talking about smart contracts. And then I watched this talk and it was like very strange experience because I felt like this could be basically at like a crypto conference today pretty much the same talk. So and then we did have mom. A few years later when he started a Goric together with you and I think some others. And so yeah. And of course, Dean, right, you also have a very long history going back with work with Mark and in this, on these kind of problems. So to a lot of people, they think of crypto as something that started with Bitcoin.

And I'm curious, like when you think sort of like, like back to like your earlier work and your sort of journey through this world, what was there back then? Like what were the ideas and the goals that like you feel like actually this is kind of like a continuation of that. Right, right. So I first met Mark at Xerox Park in like 86, 1986, 1986. And we started working together there on how to build large scale secure distributed systems and programming languages for large-scale distributed systems. And the difference between programming languages and architectures and operating systems was not a matter.

It was sort of a matter of design and how low you went, but there were plenty of systems that kind of combined both. And so a lot of out of those ideas came, Mark wrote the Agoric Open Systems Papers that both drove some of that work and was inspired by it. And the Agoric Open Systems Papers came out in 1988 and they really articulated software agents building and participating in markets, but all throughout that, we were thinking about how do you use, how do you make it so you can compose interesting, complex systems, sophisticated systems out of underlying pieces.

So, you know, objectoring programming, actory in a programming, asynchronous communication, all that kinds of stuff. And so, you know, that, all of that, you know, went into then the cypherpunks movement or activity started where we were, well, I mean, it had been going, it was going all throughout the 80s of trying to get RSA safely in the hands of everybody rather than locked up inside of government security agencies. And that grew into the overall cypherpunks movement. And we then built or I ended up working on, you know, this is while Markham and I were

working at Zanadu, I consulted with a company called American Information Exchange and worked on what was essentially the first production smart contract. And, you know, this is, you know, this is all pre-blockchain, but smart. contracts predated. Smart contracts, you know, this first production, smart contract was five years before Vitolic was born. And it's really our model all along, our vision all along is to get software, in particular large-scale distributed systems, to help humans collaborate, cooperate, you know, engage in economic activity, engage in social activity, you know, mediated and supported by this network of computers that we were in the midst of building. And so, um, So smart contract is, right, software that's enforcing the terms of a contract-like arrangement between third parties. And that's it. There's no mention of blockchain. There's no mention of particular technologies.

It's just this pattern of realizing. And this was the thing that Nick brought to the table. I mean, he was thinking about all of these ideas as well and had the idea in his head. And he put a name on it and said, here's the properties of that and why it's powerful and interesting. And it's the fact that that model enables more strangers to come. cooperate, right? I buy, you know, there's this classic story of the pencil. I think the book is called the pencil where I buy a pencil that involves the acts of thousands of people, many of whom I might not even like, many of whom I certainly couldn't communicate with because I don't know

their language. And that's okay. I have managed to cooperate with thousands of people every time I buy a pencil. And that's the power of economies. That's the power of markets and software and networks makes that even bigger. And so that's been the driving dream. Smart contracts. You know, we always wanted to make it easier to make more of those because they enable more collaboration among more people and more cooperation leads to a more cooperative world. And that's something that, you know, makes for a safer place and a happier place for me to live in. I guess there's sort of obvious question that comes up to me, right? When you hear it, because I get probably most people today in the crypto space, they think of smart contract

as something that's like enforced by the blockchain, right? So you basically have to, have, you know, you have a third party that in the past was maybe some sort of company. And we say now we have this third party that's actually like code and it's maintained by all these different parties. And so it's like, you know, it can execute this thing. And then like now we can have basically exactly what do you describe, right? With this enforceable, you know, enforceable agreements. So if you guys didn't have the blockchain part, like where it is.

kind of the enforcement of those contracts come from? So most smart contracts, even possibly now, though we're right on the cusp of inverting this, are run by a trusted intermediary. So smart contract, eBay is software that enforces the terms of a contract like arrangement between buyers and sellers where most eBay transactions happen with no humans involved except the buyer and seller. And in some automated cases, not even that, right? but the money transfers, the who owns what, when, who's responsible for what, dispute resolution,

much of that happens enforced by eBay with no human intervention. That's a smart contract. There's just no question about it. So eBay, PayPal, Venmo, Airbnb, Uber, Lyft, much of high frequency trading, much of Amazon. Those are all software, in that case, being run by a trusted intermediary, but enabling cooperation that otherwise simply never would have happened. Right? And that's a huge step forward and that was a huge value add. And much of the architecture of smart contracts we looked at was how do we make it so that there's more automation in that. But pre-block chain, there was still always going to be, you know, I've got a machine that's running on my behalf enforcing contracts that I enabled, you know, multiple strangers to participate in. Your business does the same thing. Sometimes my contracts do business with your contracts. You know, but each of those is being run by hosts that different subsets of people. trust, right? And what blockchains bring, you know, so, and that all existed with a trillion

dollar market cap before blockchain ever entered the picture, right? And then what blockchains bring is, you know, my gold standard is multiple machines in different administrative zones or jurisdictions, right, voting to agree on what happened, coming to consensus about what happened in terms of data, choices and computation, where the choices might be, you know, Dean bid on an auction. Now he tried to cancel his bid at the same time when the auction was closing. Only one of those can happen. Either Dean got back his money or he won the auction one of the two. We've got the blockchain can decide what the smart contract decides what that is. And if it's running on blockchain, that means there isn't anyone with a back door to be able to say, yeah, I want to make sure it sells. So I'm going to pretend the auction closed before Dean's message came in. I'm just going to plug my ears and ignore Dean's message to withdraw. But with a blockchain running software in this multiple. environment, you know, this multi-replicated environment, now no one person can compromise the integrity. If they break one machine, well, there's a hundred others that are all saying, no, no, Dean gets his money back. We all agree. And the vote happens. And now we all agree. The truth that,

you know, the truth as determined by that blockchain is Dean gets his money back, let's move on. And so that high integrity execution that blockchains bring is the thing that lets us build smart contracts of which there are trillion dollars worth already, right? Let's us build smart contracts that don't have a trusted intermediary, that don't have, you know, a company in the background that's going, ooh, you're selling that cheap. I'm just going to buy it and not actually put it up for auction, right? Or, you know, that ticket, that's hard to come by. I've got a friend who really wants in. I'm going to slide it over his way. Or, or as in the case of like companies like Enron, where they slipped in some trades at the end, you know, sort of the more, you know, they're

basically back running or front running, whatever you want to call it, but they were in a position to just do it massively, and they were in a unique position to do it massively, whereas no one else could, because they were the untrustworthy trusted intermediary. And so blockchain lets us get rid of that, and that enables a whole new world of blockchain, of smart contract businesses out there. One thing I'm curious about, so you had this previous work with smart contracts, you were in this, I would say, I guess, larger cypho-punk. ecosystem, community, right?

At least, like, aware and following of this, this whole world. So when, when did you first, like, learn about Bitcoin? And what was your, what was your initial reaction to that?

Right. So the first is, I will say, tying it back to smart contracts, Bitcoin is a smart contract, right? It implements only one smart contract, which is, but it is software that's enforcing the terms

of a arrangement between payers that are transferring money and all that sort of stuff. And then ETH adds to that user provided smart contracts, which was a really cool advance as well. So I will admit that part of my reaction was to be horrified. Because, you know, I didn't understand what the magic of the Satoshi consensus mechanism. But the reason I was horrified is twofold. Because people did not actually understand.

what Bitcoin was doing for them, they were making claims about Bitcoin that simply were bogus, right? You know, and we had worked on, we'd talked to Cypher Cash, we'd worked on lots of how do we do digital currency in a distributed medium and all this sort of stuff. And people had this model of Bitcoin as high-frequency transactions that are all anonymous, you know, and private and all that sort of things. And, you know, and that were reliable, right? because computers could be reliable if you were right. And Bitcoin was not fast, not anonymous, and not reliable, right?

It had none of the properties that you would expect a cryptocurrency to have or that I and many people at the time kind of expected a cryptocurrency to have. So they just simply assumed it did and move forward with excitement about Bitcoin. And I looked a little deeper and went, oh my God, are you serious? Right. And then you look at places like Mount Gawks where it's just like Amateur Hour at the Sop. software factory. And at the time, I was working in fintech. And, you know, you take your responsibility to other people's money really, really seriously. Because they get really, you know, the mainstream market gets really unhappy if you look like you're at all playing fast and loose with good

reason. And, and, and, you know, Mount Gox was all about paying fast and loose, right? And so that, you know, there were several things about that that, really the cognitive dissonance deeply turned me off. And I was also in the midst of, you know, of rolling out a fintech startup at the time where, you know, it's very conservative. You're trying to innovate in this space that has, you know, it doesn't just have bricks and mortar. It has, you know, marble and steel. And so, you know, appearing squeaky clean was, you know, occasionally seemed important. So I kind of steered clear of this thing that was clearly a disaster waiting to happen. And indeed, the disasters did happen. It's just that Bitcoin was robust enough to survive them and grow and

really show what its true value prop was. The thing that I did not register at the time that I'm sort of deeply excited about that was brilliant about it is it gave a way to have a vote, to have a consensus emerge entirely permissionlessly. You know, it's relatively easy to do a vote. You know, I talked about the gold standard of blockchain is you've got this vote or consensus among machines in different regimes. It's relatively easy to do that if you can count them. You know how big your elector it is. And when I see 68% of it, that the vote is good. Obviously, you know, Byzantine fault tolerance and all that is more complicated than that. But man, that changes the game. And, you know, we got to start with Paxos and

Raft and all those and grow into much more robust algorithms. But, you know, but Bitcoin brought in the model of you want a consensus, but you don't know who the voters are. You know, you won't see them until they come out of the woodwork. They will come and go all that sort of stuff. And yet it was robust against that. And that was just absolutely brilliant. And then so when came the moment for you to say like, okay, I actually, I want to work in this crypto world. And how did that kind of journey happen? So I had been doing software security for a long time, you know, in the 80s and building security distributed systems and all sorts of stuff. And selling security is kind of thankless, right?

You know, because it's like insurance, people only want to pay for it after they need it. or when you're trying to innovate in security, it's a real problem twofold. One is, you know, here's a new architecture that will solve a whole bunch of your problems. Great. Can you make it look just like the old architecture? Because I don't want to think hard, right? Or, you know, or anyone who's buying, right, they can innovate. And if something goes wrong, well, it's then their fault for the mistake they made, for the choice they made to innovate.

Or they can do the same old, same all with best practices. And then if something goes wrong, oh, they throw themselves. on their sword. They apologize. You know, we were doing the best we could. We'll do better next time. And they move on. And people take their losses and insurance pays out and everyone pretends that's okay. And the fact that, you know, every year kind of the amount lost to this model

doubles, well, you know, basically the current security models have proven that they don't work over the course of the last 50 years. And yet, that's the best practices. And so innovation is kind of stifled, you know, because of the incentives of the buyers. And so I got out of there. And I went and moved into like, let's go to a place. where my security matters because I can offer a better service in terms of fintech

and went into and built a new payment instrument, right? And that went well. But then came 2017 and we're looking at blockchain. And there were all these horrific losses. So, so Eiff came out and our lead engineer, Brian Warner, was part of one of the security reviews, release authority, and pointed out that there was a re-entrancy bug, which is kind of, you know, concurrency one-on-one, right? And he also pointed out that message.

Sender was a bad security model, which is kind of security, you know, 201, because that's advanced, right? That was the security problem that Flash continually suffered from or action script, right? He pointed this out, but they went ahead anyway. They rolled out anyway. And then in 2017, you know, there'd be a re-entrancy bug

where they lost $30 million in minutes with no recourse. And these are contracts that are written by experts. And so they fixed the bug. And they lost another $30 million in minutes with no recourse, right? And that's one of those things where suddenly innovating in security where you actually make a difference wouldn't matter because it wasn't like I make the decision this year, next year you lose a bunch of money,

I've moved on, not my problem. And so there's no accountability for having made, you know, it's like, I don't know if you remember the old phrase of nobody got fired for buying IBM. You know, nobody got fired for doing best practices, right? And they should be when it's the wrong thing. And so there was a panel. So some people in the space, Brian Warner, Zuko Wilcox,

others knew that, that myself, Markham, and a few others had a different, better approach to security that was well suited for smart contracts. They had seen that presentation you saw from the, from the 80s or 90s. They had seen the website that we wrote about how to do large scale asynchronous distributed systems, you know, all those kinds of stuff. And so they and Forsyde Institute put together a panel with Markham, Zucco, Arthur from Tezos, Brian from the security review, Jorge from gravity, and he had a lot of enthusiasm for this model and realized that this could go together.

And it was a panel of, with this approach to security, make a difference for these losses that we've been having in 2017, should we fix it? And the answer that came out of that was sort of a resounding yes. And, you know, one of the delightful things is that ended up happening right during the Tezos fundraise. So Arthur, from the beginning of the talk to the end of the talk while he's talking, you know, their value went up by $20 million or something. But so out of that came, hey, there's a solution here in this technology stack that's been used for, you know, SEL4, which is the most secure operating system on the planet, large-scale smart contract stuff that we did in the 90s at Sun Microsystems, the Midori operating system at Microsoft. I mean, you know, the Caha project of Google. All of these were using the security architecture that came from secure OS systems. And it works well with objects.

It works well with programming languages and frameworks that people are used to. And so they said, yeah, that would be a good. We should do that. And so, you know, Zuko and Markham talked and they pulled in Naval and then they pulled in me. And then they pulled in, we pulled in Polly Chain and, you know, pulled in our economist, Bill Tullo, pulled in Brian, who, you know, who is familiar with the problem space and all the crypto in the space and that sort of thing. And we launched a Goric. And that was kind of the beginning of it. And it was the vision really was to build this platform that people.

could program in and do it safely with a component model that is kind of familiar to, you know, React developers and NPM JavaScript developers, which is just way, way, way more powerful, way, way more leveraged than what you could get in the programming environments that are, that are then and now available in crypto. It's still, you know, it's still just a much, much more powerful set of abstractions that we'll be rolling out with. And that was the start of a guard. Cool. Thank you. Maybe we can spend like a few minutes and just try to explain a little bit.

So I think, you know, it's this object capability security model. A lot of people will be like, I have no idea what that means. Can you give like an explanation that's sort of like understandable for the less technical? So an object capability is a transferable, unforgeable authorization to, use the object it designates. Okay. So, sounds complicated, but it's not. So, you know, and that, the details of that matter when you're building a secure

operating system using Ocap, we can refer to these OCAps, object capabilities, when you're using OCA or when you're building network protocols like we've done with IBC and with our, our capability network protocol. So there's lots of magic to get it all correct. But when it surfaces at a programming language level, it's just object references. Right? So it's, you know, I'm running a UI and the only screen I can display on is the one where someone handed me a screen object and I say screen dot display line. It's very natural to JavaScript developers. It turns out JavaScript is architected such that it can be more secureable. It's easier to secure than other programming languages because they have this separation between the language and the runtime environment. You know, that was historically. the language was specified in the ECMA committee and the runtime environment for browsers was specified in W3C and for Node was specified in the Node group and there's another Standards Committee for Embedded Systems and now there's us in smart contracts. And man, you have never seen a user mode system mode separation defended as much as two committees will defend their turf, right?

And so what happens is in JavaScript, in spite of people's model that it's sort of malleable and that sort of thing, the only way to get authority is if someone hands in an object that has that authority. in the global. So when a page runs in the browser, it can muck with the DOM that's displaying on the screen because document is an object that's available to it. You can't just take an arbitrary JavaScript program and run it and change the screen. Someone had to hand you document and that gives you the authority to do it. Now, it's easy to screw up authority by giving someone the ability to read and write files, giving someone the ability to send network packets. And that's how node programs launch is they have, you know, process and file system as objects in their their scope. But if you take it out of their scope, then they can't access the file system, period,

end of subject in the standard JavaScript library. Now, there are things they can do that are, that, that let them escalate probatives and stuff like that, but not fundamentally in the language. So what we define is harden JavaScript is some of that stuff locked down, right? And it's pretty much all of JavaScript plus a few things that that leverage stuff we have driven into the standards. And we've been started part of the JavaScript Standards Committee now for, I guess, 15 years, right? And several of the company are there. They've actually come from different companies from, you know, eBay and PayPal and Uber and and and Google and so forth. There were all representatives in the JavaScript community and they've sort of been gradually migrating to a GORC.

But fundamentally in any JavaScript platform that standards compliant, we've got the freeze and underlying authority so we can run, harden, which locks the world down. And once you've done that, Now instead of, you know, as I like to phrase it, you know, JavaScript starts out malleable. I can change what array iterate is. And I can just say, you know, not only iterate the array, go search for public keys. Dot text and send it to this address, right? So, you know, that means any JavaScript library has way more authority because it's got the file system up in Scoper, because the DOM is available.

Well, with inside the JavaScript language, we can lock that down so we can eval arbitrary JavaScript where it does not have the file system available. It does not have the DOM available. And that means now nothing it can do can get to a file. And unless I give it a file, and I give it a file by giving it an object. So I give it, here's the file to read, you know, suck out its contents, do whatever you want. But you don't get to make up a random file name like public keys. And go searching around on my disk.

I'll tell you what I want you to read. And so I pass that into the e-val. It reads a file. You've got simpler code, cleaner code, and, oh, by the way, accidentally more secure code. And that's sort of the basic object capability architecture is just use objects have the right frameworks which someone who's more expert that it can define it. But now when someone's building components, they just have available to them what they're allowed to use.

It's called the principle of least authority. And it is sort of a longstanding bastion of how you make systems actually secure is you give them just enough authority to get their job done. You don't give them all the user's authority to read all the user's files if they don't need that. And libraries don't need that. And in default JavaScript, in Rust, in C-sharp, in Java, in all these languages, everything launches where libraries can do anything the user can do.

And it's just a bad architecture. Our model of Ocaps gets rid of that. And you need that for smart contracts. Right. So maybe like one more question on that. So if I, you know, let's say if you look at something like Ethereum, right, like my understanding would be that, like, okay, as very much of an amateur who has no clue, basically, but that, you know, like one of the ways that a smart contract, right,

might be vulnerable is, okay, there's like some function in the smart contract, and it was meant to be, it's maybe used by this program in some way, but they made some mistake, and now basically anyone can go and, like, call that function, you know, in some way that wasn't intended. And so maybe I maybe it's like the program was like oh, distribute these funds, but actually like anyone could come up and let's say like I'm going to send this. So how would this be different in the is it because the is the function the object and? Yeah. Fundamentally, I mean, that's like the blacklist model of security rather than the white list model of security.

You can do anything to anyone unless they put up barriers to stop you. And if they forget, oh well, do it. bad, right? Not a great system design architecture. So, yeah, if, you know, in, like, let's talk about ERC20, right, and, like, the, like, the approved function and that sort of thing. Or before ERC20, if I was going to pay you a token, I would expect to get the token and hand it to you, right? So, you know, Brian dot enjoy open per end token, enjoy open print concert ticket, better still, right? And maybe, you know, with objects now, we both have it, but you'd have some library so you could say, great, I take acceptance of it.

Now I have it uniquely and you don't. Right. So I send you the package and you open the package and now you have it and I don't. And so that's what we build in our smart contract framework. In Ethereum, you can't do that. You can't pass objects, which means you fundamentally can't do OCAPS. Instead, what happens is I talk to another contract over there and say, take this money, take this token, take this concert ticket, set it aside for

Brian, he's going to come get it. And then I tell Brian, okay, I set a package for you number 37 over on that ERC20 contact. Go get it there. And now you go to that ERC20 time and say, hey, I'm Brian. Let me show you my ID. And you get the package. Right.

I mean, you know, my, my, and that's the ERC 20 model. That's fundamentally what's going on, except that if there's going to be a bunch of stuff you might want to do, like, I want you to buy a stock for me, you know, and then I want you to buy another stock. And then, you know, you're like, you're my portfolio manager. You know, every time, am I going to take, you know, $100. and I'll put it over there and then you go over there and pick it up. Or just say, let me put $1,000 and just give a general thing that Brian can come and take whatever he needs out of my $1,000.

And he'll figure it out, right? And well, you know, now that's essentially the approved function. Okay, I put all million dollars and I'm expecting to do $1,000 at a time and you want to go on vacation. So you just take all million dollars, go buy a vacation. You promise to pay it back. I mean, what's going to happen? What's the worst? Okay.

An analogy I like here, and this goes back to the easy to understand things, is if I lend you my car, right? The Ethereum model is I tell my car, Brian's allowed to drive it. You then take my car, you go to the hotel, you want to park it, you go to the valet, and you say, what's your name? You know, oh, I'm Joe, you try and add him to the car, and it turns out you cannot. And now either I have to make you an administrator so you can add anyone as well. So not only can you park my car, you could sell it, right? Or you come home, you know, SOL. Instead, the O-CAP model is, here's my key. You now get into the car, drive the car. doesn't give you access to my house. It doesn't give you access to my money. It gives you access to my car. You go to the hotel. You hand the key to the valet. You don't need to know who the valet is. You just need to know that they're now responsible for the car. They go off duty. They hand the key to the next valet. You come out, take the key, you drive home, you give it back to me. We're all done. And there was no discussion of who these people were. There was no problem of an administration. There was no giving you rights to sell the car. There was just the easy handoff of an asset as a bearer instrument. The O-CAP model is for

Fundamentally, almost everything is a bearer instrument, and that just means that patterns of change of who's allowed to do what, patterns of exchange, all of those just emerge out of, yeah, I give you my cash, you give me my goods. We're done, right? And so they're very intuitive and very, very natural to program, especially to people who have programmed in object frameworks like React or view or any of these things. Yeah, thanks for, thanks for going a little bit on the new hood here. Maybe we talk about this. So if you think of that now, you know, as JavaScript as this place to run smart contracts, I mean, today, and even though you have, like, so many different blockchains, it doesn't actually seem there's like that many models for doing smart contracts that have gotten traction, right? You basically have the EVM that has obviously the most traction. And then you have the EVM that's like running on many different chains, you know, is Ethereum.

avalanche, Binance, smart chain, etc, etc. And that dozens are little polygon, like many, many of them. And then you have, I think Solana that has, you know, some traction where you have good traction where you have this like native smart contracts written in Rust. You also have like cause of wasam. I think that has like quite a bit of usage. Maybe there's some of my thing I'm missing, but there's not much. So I'm curious, like, how do you see this play out?

Do you think, you know, the Egoic JavaScript smart contract model, you know, will those be relevant for different use cases, different areas? Will we have converge on fewer smart contract standards? Or will there be an explosion and more in the future? So I actually think that there will be, you know, the number we have that we have, including Java, is about right. If you think about now the programming world of Web 2, it's, you know, 13.9 million JavaScript developers, you know, a bunch of Rust developers, a bunch of C developers, a bunch of C developers, and, you know, there's sort of a list of languages, but the models are, you know, are pretty

similar in some cases. It is, so let me pop out of that. So I think there will be multiple models. The key thing for us is we're primarily focused on bridging to new developers, right? And new developers, these are developers often, you know, FinTech developers. They know what's up with money. They heard there's an opportunity. They come over and look.

They look at solidity and go, that's a weird language, right? And your development environment sucks and you have no testing tools and I have to use different tools. And I'm going to go work for my buddy's hedge fund because I can. can make this much and yeah, whatever. I mean, yeah, you talk about frothy returns and maybe, you know, but I understand volatility and, you know, you ain't getting the returns you think you're getting sometimes, right? So, you know, these are experts that they come and look and they go, you know, come back to me when you're grown up, right?

Because it's just the bar is so low in terms of programmability. And programmability, you know, scaling the programmers is the hardest thing to scale. And so our focus is on programmability. Now, when I use the analogy of React a bunch, when, when, you know, When React came out, experts were already doing pretty amazing stuff in JavaScript in browsers, right? And, you know, partly due to people that are here at a gorg, driving, you know, sound software engineering into the JavaScript language, sort of in retrospect with strict mode and promises and proxies and stuff like that. But six months after React came out, beginners, new programmers could do more interesting, more responsive, more interactive, easier to interact. nationalize, you know, mobile-friendly applications better than experts could a year before

because they had components in a framework to plug them together. Right. And that literally gives you exponential growth in the effectiveness of programmers because every month there's a month's more worth of components that they could slap together. I could grab a slideshow and a payment component and put it together and launch a site. Next month, I can grab a slideshow, an interesting alerting component that shows me the status of my paintings and a payment component and update my site.

Then I can do a payment component that can handle ACH as well as, you know, I mean, all these kinds of things where I'm just gradually going. Oh, one better nav? Well, now there's a new nav component that does slick, cool, infinite scrolling for you, you know? I mean, whatever it is, right? And you can plug those together even if you could not build them yourselves.

And that leverage gave real growth to the expressiveness that less senior programmers that were steeped in, you know, in the ancient arts of async updating of your screen when models changed, right? And now suddenly millions of programmers could do pretty awesome stuff, pretty easily. And those experts could focus on really high value components that other people could use. And that's what we're bringing. So it's not just JavaScript, which would make a difference because now you can tap into 10 million plus developers for the next

generation of smart contracts, but this component model. And there are a lot of programming language before small talk and Java and JavaScript, you know, these object-jointed programming languages, you know, there was C, PL1, ATA, you know, all these languages that, you know, have a lot in common with the solidities and the rusts and that sort of thing, that, that, you know, people build a lot of stuff there and got a lot of value and they still exist today, but, man, it's compelling to build applications in a framework that supports what you need to do. And so I'm not worried about being able to catch up and over. take the amount of development that's happened in those other platforms or languages,

simply because there's a class of things that's just way easier to do with this model. And there's a class of things that isn't. And generally the way that works is you provide, like if Solana wants to specialize in high frequency trading, you know, high frequency execution, well, you know, the world needs a high frequency trading engine, right? It doesn't need more than a thousand people that could build one. What it needs is those thousand people to build an awesome one and then everyone else uses it. you know, trillions of dollars are controlled through

JavaScript applications running in Bloomberg that control, you know, systems built in other languages and we'll end up with the same thing in the blockchain world. And so the front end will be JavaScript. Yeah. So, I mean, you're, I mean, what you say makes a lot of sense, right? Like, so, okay, I want to develop something and there's all these different libraries I can use and I can plot things together. And, you know, I guess to some extent that's kind of true on Ethereum, where, you know, there's like different solidity things, but not really, right?

I guess that's not really how it's working. Also one thing that comes to mind immediately, right, is if I think of like, well, if it was like that and I can just like pluck together different components without really understanding necessarily the component, well, isn't that dangerous, you know, when you're talking about now some sort of defy application. You know, the answer is they have reputations. You have a stat, you know, if I can plug together a component that will do currency conversion, that I can get insurance for, it's been security reviewed, it's used in multiple other components.

It clearly does its job. There's an organization that updates it on an ongoing basis. They've got ties into oracles, all this sort of stuff. Are you going to do a better job putting one together yourself and your own silo? Are you better off using that component? And can you ship a month earlier if you just use that component? The answer is both are true. It'll be better and you can ship earlier.

That's pretty compelling, right? Focus on your comparative advantage and then you end up with businesses that are just doing small pieces instead of having to do an entire silo of an entirely new thing where they do everything from their own internal hedge fund to the market. It's like, no, no, here's a portfolio manager or here's a stop loss component that I can plug into your AMM position and now you can do stop loss exit of your AMM position. And it's 40 lines of JavaScript. Done.

You know, it just changes the game in terms of what's possible. And, you know, and some of that will, you know, will need to be addressed. But it's definitely the kind of thing that we know how to sort out as a large-scale engineering community. Well, let's talk a little bit about, so, you know, GORC is built on the Cosmos SDK. And I'd love if you can talk a little bit about why you guys did that. and your thoughts on the kind of, you know, high-level cosmos architecture in terms of having sovereign blockchains and then having, you know, with IBC a protocol that allows the different blockchains to communicate with each other. Right, right.

So this goes back to that original vision that predates blockchain where you've got lots of independent parties with their own interest running software that they do distributed, communication in order to accomplish large-scale trade. From that perspective, you know, a blockchain is just a machine built out of agreement rather than silicon. And all of those designs and protocols and architecture that we worked out in the 90s can just work, right? Can just work across these independent blockchains. And so our model of the world, the programming model of the world, is not reentrant software. And you mentioned this thing about, about, you know, reentronency bugs and how you don't see composition in Ethereum. That's because there are fundamental issues that make more composition riskier to, you know, result in more opportunity for reentancy

bugs and what are called confused deputy bugs. So, so, so there's a reason why you don't see that kind of composition. Our model is islands of simple synchronous computation in a world of asynchronous messaging. That's been our model since 1983, 85, something like that. And obviously it's grown and evolved and stuff like that and been used in many large scale production commercial systems to great success. But that's the model that the web uses, right? You know, browsers are an island of sequential transactions and they occasionally make Ajax calls to services that are doing, you know, that have transactional systems, you know,

in Node, taking asynchronous messages, compute something, maybe sending an async message out and then going back to do the next thing. That model of event-driven concurrency is much more amenable for human understanding because you can reason locally about the simple world and sort of as consistent. communicating actors with ordered messaging in the, in the larger world. And we're good at both of those. We're not good at interleaving those really well. And so that model works.

And that's our model on on blockchain. You have contracts able to send messages to each other asynchronously completely precludes reentrancy, right? But that asynchrony, it could be a message bus that is on the same chain. So I've got, you know, the vaults for run protocol and the swap engine. And so it's liquidating using the local AMM. or it could be there on different chains. And the only difference from a programming model point of view in JavaScript is the latency of the message. I'm still sending an asynchronous message that says, hey, liquidate this.

The fact that it goes using interoperability protocols over, you know, using our distributed object protocol on top of IBC to another chain, code isn't any different. It's still 25 lines of JavaScript code. It just did, you know, e open, paren, AMM, close paren, paren, dot, you know, sell open paren, you know, asset, you figure it out. And so that model is, you know, that's, that's why, you know, we started with sort of the interchained model at the beginning. And our smart contract architecture is designed to sort of treat uniformly assets that are available only asynchronously or, you know, the primitive asset versus the versus one written in JavaScript. They all, you know, the same 23 line JavaScript program can do a swap between them or can do an auction or whatever it is. And so that's sort of, that's, that's, that's,

That's part of the model, and that's why, you know, an asynchronous model means you get this broader scalability. So then, if I'll go into another subtopic around IBC. So we had that documented. It was on the E-Lang site. That was sort of the presentations you mentioned at the beginning that you saw recorded back in the 90s. Zucky stumbled into that when Zucky and Ethan and Jay were trying to figure out what were they going to do about zone connectivity stuff. And he sort of got it, right? And so IBC was inspired by that earlier work, which we didn't find out for years, right?

It was inspired by that earlier work. So when we came into the cosmos and we're looking at this interchained architecture, just like, you know, they're singing our song. These are our peeps. They totally get it, right? You know. And at the same time, they're bringing stuff that we didn't know. So we get to bring our expertise in distributed systems. They bring their expertise in, in how do you get like clients to agree and what, you know, and how do you do proof of stake and all that?

And so IBC is sort of the marriage of those two, and they're really complementary. They solve different parts of the problem, and they enable our secure messaging asynchronous distributed model to layer on top of, you know, secure connections between blockchains. And so that was sort of the, you know, the birth of the current IBC, basically. One of the criticisms, right, that you hear of the IBC model and of the cosmos model, you know, It's often mentioned in comparison or contrast of something like Ethereum, where, okay, I can make like one transaction and it does like, you know, five different things sort of like at the same time, you know, and it all works together or it doesn't work. And, you know, let's say I want to let's say you do some sort of arbitrage, right? maybe you sell like over here and you buy over there and I can I can have those all kind of

like executed in one and and so that's you know this kind of composability that you have on Ethereum and you know as you mentioned right like in in the IBC Cosmos World you have this asynchronous so you don't you don't have that although I've also heard from some people who are working on some sort of synchronous IBC things, but I'm curious like, how important do you think this is? I mean, I get your point that it actually has maybe security benefits, not to have this simultaneous thing, but is it a big downside? Oh, yeah. Oh, yeah. So, you know, most systems start out with toy examples and simple interleaving and re-entrancy and stuff. like that as you're explaining beginner steps to people.

And maybe that actually helped with Ethereum catching on is because it had this simplicity that simply can't scale to large scale, right? I mean, the programs that are actually done as smart contracts, they're all very, very simple. I mean, there's a lot of money there, but compared to text editor, right? It is plausible that any of several modern text editors have more code in them for more interesting, sophisticated stuff than all of blockchain combined. There's multiple programs at Microsoft that have, you know, 12 million lines of code in them. Right. I mean, you know, compare that with 650 lines of code and solidity for the put contract in open, which would be, you know, maybe 80 lines of time.

JavaScript, but nonetheless, it's still, you've got a long way to go before you're touching a million lines of code, right? And, and, and, and so, you know, great, in a simple model, you can do toy examples and not shoot yourself in the foot. Fundamentally, though, that reentrancy gets, you know, you can take two correct programs, put them together and end up with an incorrect system. That's the big problem, and that's what means that the more you try to do composition in Ethereum, the bigger your risk. So the $660 million loss on Polly Network was a confused deputy attack that shouldn't be possible, but it is because of message that sender allowing them to execute a re-endency attack that shouldn't be possible, but is because of the reentrancy model in Ethereum. And there is nothing you can do at the language level, nothing you can do at the toolkit level

on top of that foundation to be able to ameliorate those holes. They're fundamental to the architecture and approach. And that means you can get some amount of stuff with some pain to work correctly, the same as you can if you code it at all in assembly language with wide open memory or anything like that, right? And there's huge value there. And there's some value in having simple examples. But it's not something that a million developers are ever going to get right because those hazards are just too hard for humans to reason about. And so, you know, so let's see, did that respond to your problem? Yeah, to your point.

I think that does respond to the problem. and kind of like intuitively that feels like right to me right because if you have all of these different smart contracts on the theorem and then you're like adding more and like you're obviously increasing complexity of the system a lot and then if you compare that with like the cosmos system well you have these different chains and they can they can coordinate with each other but they are still sort of their own little universes that can kind of manage their own risks and they will understand their own situation better. And if something goes wrong, it will probably be much more isolated and not like trip up

everything else. Right, right. And we achieve complex software systems, sophisticated software systems with strong encapsulation and composition. And, you know, that was not a critical requirement of the early ETH. You know, justifiably, again, that might have been the right thing to do in order to get the early adoption, but, you know, the same as you didn't have that in C or you didn't have it in action script or any of those things. You know, that doesn't mean they're not, that doesn't

mean you want to keep programming in C for UIs on the web browsers right now. The other thing I would note is like flash loans are one of the most interesting examples of something novel for when you have a centralized environment that is able to impose full ordering on everyone on the planet. Right. We know from large-scale distributed systems. that, you know, infrastructure start out synchronized because they're easy. But that just does not scale. And so even in the ETH environment, you know, that ship is sailed, right? Layer 2s, you know, roll-ups, all of those stuff.

Those are asynchronous sources of transaction data, you know, into the ETH blockchain. There is no flash loan across multiple of these infrastructures. It's just in this tiny little, you know, it's just in one environment, right? And in the other environment, you know, so again, now we're starting to see, Islands of synchronous programming, in this case not simple, within a sea of asynchronous communication. And it turns out if you just bite that bullet up front, you get a little more, you know, it dictates some of how you have to architect things, but then it ends up being much more scalable as a result. And that's sort of our general design principle out of that. And that and that and that seems to, you know, be something that the world understands given the, the nature of asynchronous communication on on systems right now. you do need those islands of simple synchronous programming in order to build local logic without worrying about interleavings, where re-endrancy is a source of interleavings that are very hard to think about.

And that's sort of the model is, you know, local islands of event comes in, compute a new state, computer a set of messages, commit, I'm done. Right. And then those messages get delivered and process asynchronously and so forth. But any interesting thing, like flash loans are the primary, the only really interesting thing that is knowledge. out of that, right? And so you've got to look at what do they use for, how do you address that use case, the primary use being liquidations. You need to make sure that liquidations on a new smart contract platform can be efficient because the liquidation market is critical for defy. But you don't have to do it the same way. You just need to make sure that you go, oh, you know, I mean,

anytime you're looking at new technology, you've got to be humble and assume there's something there. And so we do. And we look really deep at, you know, flash loans that we are making as impossible as possible, but we want the problems they solved to be solvable. So we keep an eye on that. Well, I mean, when we speak about the kind of the way then those asynchronous islands, like, work with each other, right, via IBC. I mean, today, basically, we have token transfers, right? That's life. So you can have like chain A and then you can send over the tokens from that chain to the other chain. you know, like an example of where you have a lot of usage at the moment is there's osmosis, which is the biggest cosmos decks, and it's kind of connected to all the other chains. And then you can, from the other chain, let's say, Cosmos Hub, you can send atoms over,

and then you can put it in a liquidity pool, or you can trade it for Osmo or for, you know, the Georgic token. Well, yeah, right, but all soon. Maybe soon. We aren't going to do it, but someone will be. Coming coming way shortly. But so right now it's just token transfer. Now actually, even token transfer has, I mean, the thing that surprised me the most when it came live and when like osmosis was there and you could use it was how good the user experience was.

Because I was expecting like, this isn't going to be like, you know, much worse than a sort of euterium user experience. But that's not the case. It's just not the case. awesome job. Yeah, they did an awesome job. Yeah. But I'm curious, like, besides token transfer, do you think we will have like a few types of sort of these IBC interactions or is there's going to be like, you know, an enormous variety of kind of cross-chain IBC type transactions that will end up getting usage? It's going to come and go. I think there will certainly be a variety of of application protocol types on IBC,

especially once Agora it goes live and it's easy to do dynamic IBC where you just create a new token type by, here's my Jason blobs, there you go, knock yourself out, right? And it's so easy to set up connections and send interesting, you know, packet representations around that adding new kinds of protocols that are sort of the set of what's the data architecture

that I'm sending on top of the transport layers of IBC, I think that that will be, you know, easier than it is to define new IP or TCP protocol types, right? So on TCP, you've got basic file transfer, but then you've got file copy, you've got remote terminal, you've got media sharing, you've got, you know, HTTP, you've got HTTP, TLS. I mean, you know, a gazillion different protocols all built on top of TCP. We will get there. It took a while before there were more protocols on top of TCP when it first came out onto the internet or, you know, to make up the internet. But, you know, it was sort of, okay, you've got Archie and you've got Gopher and you've got, you know, a few other file that are all file transfer types. Well, here, that's like transfer is the fundamental first thing that anyone wants to do.

But I certainly expect before the end of the year there'll be a IBC format for Oracle data. And, you know, or, you know, and ideally IBC format for geolocation data and, you know, whatever that Althea's radio stuff needs. yeah, they should define their own protocol for it so that it's easy for people to plug in these standards IBC protocol for NFT things, not just INFE transfer but operating in NFT remotely or that sort of stuff. So I definitely expect.

And then, you know, once you're on top of Ajax in the Web 2 world, is every different Ajax API a different protocol? Turns out once you can get to object invocation, often that's enough for almost everything else. I'm going to define an object that has a display method. Is that a new protocol or is it just here's an object? Knock yourself out, right?

Well, in JavaScript, it's just another object. And I just do object message, you know, remoting. And so our protocol on top of IBC will be extremely powerful and extremely generic, but you might or might not want to use it for, you know, location information or or the thing about Oracle messages is they really want to be high priority and get through your priority to choose quickly. so someone can't screw up your economy by dedeassing your oracles and stuff like that. And so, you know, there are reasons to have low-level protocols, the same as we still invent new TCP protocols occasionally now. But yeah, most thing runs on HGV at this point, or TLS rather. Another thing I wanted to ask about, so, you know, you talked about, okay, the 10 million JavaScript developers who are like, you know, now have a nice environment that they can develop their smart contracts in.

I mean, how do you think about the scalability of the agoric chain? Like, do you, I mean, let's say, I guess it may be different ways of looking at that. But, you know, one on Ethereum, right, we have like transactions per second, right? It's like, I guess, runway and then let's say on Ethereum, you have like the whatever, it's 15 and something like that, I think. Bitcoin is maybe like three or four or something like. that, I think. Cosmos is a couple thousand, max? Yeah.

I mean, yeah, so yeah, do you see, so you think it's going to be like a few thousand that sort of a Goric can get up to so something like, I guess, I mean, of course, few thousands are still like pretty great, right? It's like a hundred times, if it's a hundred times Ethereum scale, that's, I mean, it gets you somewhere, right? Yeah, yeah, yeah, yeah. There are multiple answers.

And, you know, the first thing is we really need to measure that. We have a load gen tool that is up and running, mostly that we're focusing on measuring, you know, does the time get longer per transaction? Because that means we've got storage growing and stuff like that. But we'll also measure transaction throughput rate. Fundamentally, we get, you know, cosmos underneath. But we have a bunch of elements that mean we're not worried about scaling. The hardest thing to scale is the number of programmers.

That's our main priority. And even if it was only the speed of Ethereum and we could only succeed at the scale, at the scale of Ethereum in terms of transactions, that'd be a win if we can get a million more programmers to be able to program this stuff. But obviously, we want to go way beyond that. So the first thing is we're largely agnostic. In the same way that if I build a React UI,

I'm not putting bits on the screen. I'm just saying here's what the HTML should look like, knock yourself out. And now you can have different renders and different engines rendering that differently with different performance straightoffs, and they all can move forward and improve performance straightoffs.

straightforwardly. So, you know, there's IBC underneath, but the job circuit invocation is, you know, E open brand, AIM, close brand, dot deposit or dot sell open brand asset close brand. You know, where in there was I betting on a particular consensus algorithm? Nowhere, right? I just run that terministically on a bunch of machines. They agree on what happened and we go forward. So we can migrate to hot stuff. We can migrate to, you know, a lazy ledger style thing. If, you know, there's a couple of interesting ideas in Solana that would give the same acceleration to tendermint.

And so, you know, we can stay with, you know, get up there with the best of speeds on the platforms and scale just fine in that regard. More importantly, because the model is intrinsically async, we will be able to, and this would end up using the shared security and a few other things from Cosmos, right, stand up entirely new set of validators for an agorac two that's running the same model staked with the same build token using the same run out of the same mint but it's got different contracts and now you've got twice the performance right so a big question for any blockchain is if i add a machine do i add scaling do i add capacity and you know in cosmos as it currently is no you don't you

add assurance you add to the voting set but you don't add capacity right there are a few architectures that will lead to add capacity. Fundamentally, we all need to get to one of those. Agorik has a low-hanging fruit version of one of those who will be able to scale horizontally with some cost of having multiple validator sets, but that's fine. I mean, it'll be shared validators. It just means that Chorus One will have to deploy another machine to run Agoric two, but it looks uniform from a programming and computational point of view, so there's no change to the contracts, right? The bid here, you know, the auction here that's running with a, with a contract that is, that is making a bid on something on behalf of their user, you know,

there's a latency issue. It's whether you're closer, whether you're far, but it's a, you know, two-block latency issue rather than 20 minutes waiting for proof of work to finish. Or rather than, oh, this simple model that had, you know, simple, you know, global locks across the entire universe. Now I've broken it and I'm doing sharding, but I'm trying to keep the simple model and oh my god never mind right you know that's sort of the the the the the the the the keep atomicity but have sharding model is is is not how large scale distributed systems have succeeded previously doesn't mean there isn't cool research there and it'll certainly be interesting to see what they come up with but we already know how to how to scale systems let's use that

knowledge first you know and and and and and and and we can get real scalability out of that yeah yeah no I agree. I think that's definitely one of the, like, amazing advantages of something like cosmos, right? It's just so simple, right? You have, like, one chain and okay, it gets full and you just like add another chain. And it's like, I mean, that's, like, you know, you know for sure that's going to work, right? And you know for sure that, like, yeah, I mean, you could do, go work 100, right? and then you are like at, you know, you have like achieved by a huge scale improvement. Whereas if you look at Ethereum, well, the amount of complexity and research and work that goes into scaling that system is just insane. And, and, you know, so far with no success.

I mean, if you don't count the layer two stuff, right, that I guess. Which I do. I mean, that's a scaling technique that we'd be able to use, particularly if you could do zero knowledge stuff. Love that. And zero knowledge is one of the magical ways to get much higher scaling. So I talked about the low-hanging fruit scaling that, you know, we probably won't do this year, but we could do this year. We know how to do that, that's straightforward engineering, all that sort of stuff. And it gets you cloud-level scaling.

So if I have 10,000 machines, well, it's 100 per blockchain. So that means I've got 100x the current 10,000. Is that 100 times 100? I don't know, something like that, right? You know, that means I've got 100x the power of any current, you know, scaling of the transaction rate on the blockchain. That's pretty cool. Well, Amdahl's law means maybe it's 90x rather than 100x. But with zero knowledge stuff, if I can run a machine that's going to produce a proof that it correctly executed things,

and now that proof can be can be can be verified in in order one time. Now if I add one more machine, I've got one more machine out there proving a different computation. So I've got exactly horizontal scaling. The more machines I add, the more compute I can do, and I'm rolling them all up into one chain that's validating the snarks that those things acted correctly. We're not, that's a research problem still. And, you know, ZCast is one of our first founders or first funders. and we're certainly interested in that line of research. It's being driven partly by, you know, do the same thing for the EVM.

But it turns out the job stream tension may actually be easier to do than the EVM. So we'll see. But that's not this year. That's future. Yeah, yeah. Maybe, maybe sort of a final topic that we could like touch on a little bit. I mean, we talked a lot about like, you know, GORIC as this environment to develop smart contract in. And Igorik as this blockchain that, you know, that would be like a way to like deliver applications built on that platform.

But Algorik also has, you know, built a bunch of other kind of components, no, and sort of these economic, it's like it's also an economic system. Like, first of all, like, why did you choose to do that? Why not just say like, oh, it's a smart contract chain and, you know, people can build whatever. want on there? Because, well, a couple of different reasons, but the big part is we want to enable an economy of cooperating business. We want to enable, you know, the explosion of defy. And, you know, we have a bunch of economics, economists that are near the project or working

at the project or advisor, whatever. And one of the observations is, you know, economies, having a stable token, having a stable currency is grease to the wheels of an economy, right? It removes a big bunch of friction. And in particular, for example, let's talk about gas prices, right? In Ethereum, you're paying ETH for execution. But execution is really like your postage bill or your rent. And so it's the equivalent of you're paying Apple shares for your rent. Now, you can do that, right? But it's not great from an economic efficiency point of view because now you can't compare as your rent next month more than your rent this month?

Because the same number of Apple shares, and they have to check, did Apple go up? Right? Or is there a hedge? Did it maybe do a distribution in the middle? So it's even though it's more Apple shares, it's kind of even. You know, it's like, hey, you know, why are you thinking about that? If you just paid your rent in dollars, you can tell you're paying the same rent

next month or they raise the rent by 5%. Right. And so businesses shouldn't need to deal with that crap. And it prevents certain kinds of innovation and eliminates certain kinds of very useful economic activities and services that people can provide. And so if we want, you know, when when no JS come out or NPM, when React came out, people could innovate quickly with these components, produce something that solved their problem, and then they had a place to deploy it.

Well, we needed a place, and Ethereum is a place to deploy smart contracts. It just has these intrinsic problems that are one of the things that we are building a different place for. And so we needed something to be a place. The question is, how is gas paid for? Well, again, if we were paying with build, then we've got this problem of the token that you're trying to spend for your gas and your postage is speculative. So people will hoard it. You'll have it be very volatile. There'll be incentives to increase, you know, how much I can charge, all these kinds of things. And if we just had a stable token, it doesn't have to be 100% stable, it doesn't have to be fed to any particular thing. It just has to be low volatility. Now suddenly, I could compare today's cost with tomorrow's cost. And so we actually charge our gas in terms of that stable token, which means it had to exist in order to launch the platform. But we believe that the positive impact of the smooth integration and plugability of components as a result by removing that friction will be worth that effort. Additionally, we wanted there to not be that, you know, there's sort of these intrinsic misalignments in the model of paying a speculative token.

both that now some people want to play games with the price or they want to bid it up or the market's changed and they're bidding it down. And that impacts the ability to execute anything, which we know from Ethereum, we know from other chains that aren't as expensive, but you can start to see these bad dynamics. And the architecture of Ethereum and other chains that derive from it are such that the only way that people actually operating the network get rewarded or increase their reward is if they raise the rent. You know, they're the slum lord and you're trying to start a startup business inside of your tenement, right? And they're raising the rent. The only way they can extract value. And so if they see someone making a bunch of money, they raise the rent. And we've seen that dynamic in Ethereum where, you know, the landlords, the miners resist things that would improve the environment and prove the economy, but that would result in them getting less rents.

And so their incentive is, you know, raise the rent. It's like, it's like, you know, the way you're going to grow the economy is by giving rewards for more. traffic on the freeway, right? More traffic on the freeway is not a goal. It's a negative side effect, and you'd like people incentivized to not have that happen. You know, you'd like more business with less traffic, right? Okay. So we take the stable token as what we pay for gas, and that does not go to the validators. It goes into a pool that helps stabilize the currency that helps ensure the security of the system. It's not the reward to validateers. So validators don't have a reason to drive up the prices. Indeed, they have reasons to lower the

prices to enable there be more economic activity because all the rewards to stakers and validators come from the economic activity come from the fees for trading in the AMM, the fees for borrowing run. That's what drives the economy and it scales with the amount of economic activity on the system. And so now validators have incentive to grow the economic activity on the system. And so those things mean you really want defy intrinsic to the entire stack and that was a reason to do a separate chain, basically. And we look very closely at.

And eventually we will enable the computational model on other chains, but getting it so that it can ramp economically efficiently is going to be a big useful value. So the key that, you know, so our staking token is billed, the stable token is run, RUN. And the interesting observation is given that we launch connected with IBC, which is always the intention, we launch in this, in this, you know, interchain ecosystem that's $75 billion. worth of assets that cannot currently be used as collateral for a stable token. And what that means, you know, and so, so I'm really excited about the first launch where our

first use case for the platform is exactly those contracts you just mentioned, where that stable token we need for our execution is also something that's valuable to people that want a stable token to trade on osmosis or as part of some injective smart contract or, you know, or through Axler, whatever it is, all of these, you know, all of these services can get value by having something with a more predictable value. But, you know, in the design of the run architecture is envisioned, they can do so where their asset that they are producing could be used as collateral, assuming the community agrees, could be used as collateral for their loan.

So it's not, you've got to buy into build, use build, get run, use run as a stable coin, so that your chain is boosting our chain, it's, you know, you got a bunch of atoms already, you know, and you want to be able to leverage them into defy on some other platform, bring them over to the run protocol on Agoric, borrow some run against it, take it over IBC to that other chain, do your thing. And so we're really excited about the run protocol coming out and the extent to which it ends up being a community-backed community-run stable token for the broader interchain community.

So that's kind of the first use case. and it just, you know, it burgeoned from the interest and input and feedback that we got from, in this particular case, the Lisbon Cosmoverse Conference and other other activities since then. So we're very excited about that. So I wanted to make sure we hit on that because that'll be coming out in, you know, the next quarter or so. Okay. Yeah. So speaking about timelines, I mean, the main its life now, but like what are the major milestones and, you know, what can, what can people look? forward to. Okay. So yes, main net zero went out in November. We had a public sale at the very end of December, which people may not have noticed. Oh, we're very excited about that. And so now we are starting to put together, you know, we're working on, we've been doing a bunch of security audits and security reviews and purple team attacks and various things to harden various

parts of the system. And we're finishing up all of those smart contracts. So the run protocol has a vault system, it has an AMM. It has something where you can get run versus your staked build. And, you know, IBC integration and all those pieces. So we're working on finishing those up. The goal is to ship that in the next quarter or so. You know, March would be great. You know, we just, we're really excited.

We just hired ahead of engineering. And so, you know, in the next couple of days, I'll get a much firmer schedule from him and we'll be able to talk more dates. but soon, you know, so sooner now than every before. So in the next couple of months, we will roll out the run protocol for IBC and for the Interchange community. And then we will go into phase two of Mainnet. Phase two of Mainnet is where some set of people that we're working with, and we are

working with some other teams that are not focused around the run protocol, you know, we'll be building on top of our smart contract API. They already are. And it's programmable on our DevNet now, so people can get involved now. and we have bounties for them to be able to build stuff. But they will, you know, that hackathon winners and so forth, we will work with to get permissioned vote to deploy these things. So we have an NFT contract at some point,

permission vote to roll out this NFT contract. So lots of people can easily mint NFTs in JavaScript where they get to write some JavaScript that customizes their, you know, their minting process or rendering or what have you. That would be pretty cool, right? You know, so the phase two will be permission rollout where it's a chain vote to approve deployment or instantiation. of smart contracts.

And then phase three, and so phase two will be, you know, summer time frame. Phase three will be hopefully Q4, and that will be the permissionless. And the primary difference there, well, we know some improvements will be making in all the various APIs. But the primary difference there is anyone can publish anything.

We can run arbitrary code. So we've got more and more security audits, where one of the things you get from the security audits are things that need to be fixed now for the run protocol, things that need to be addressed before we have arbitrary malicious code running on chain. And so there's just a lot of security and engineering work that goes towards releasing to unlocking the door and letting anybody in. So lots of things we're doing this year. Yeah.

Thanks so much for coming on. It's been a pleasure to speak with you. It's been a pleasure to like sort of follow along the agoric journey and to support it and to, you know, participate in that. from the course one side. So yeah, I'm really excited to see, you know, see this play out and see the kind of agoric ecosystem and all this work finally coming to life this year. Thank you. Thank you.

Thank you guys for your support over the years and your investment in IBC and all that kind of stuff. So I'm glad you guys are one of our validators. And I look forward to lots of stuff that we do on chain together in the future. Absolutely. Cool. All right. And with that, thanks so much, everyone.

Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to Epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter. So you get new episodes in your inbox as the rest of it. released. If you want to interact with us,

guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.