Anna Rose (00:00:05):
Welcome to zero knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promised to change the way we interact and transact online.

Anna Rose (00:00:27):
This week, I chat with Dean Tribble co-founder and CEO of Agoric. Agoric is a JavaScript native smart contract platform built with the cosmos SDK. We chat about the development of different programming languages, as well as why allowing developers to code first to code blockchain smart contracts in a language that they are familiar with that is hardenedJS might actually bring a bigger wave of people to the space. We learn about the history of Agoric and more. But before we start in, if you are looking to jump into ZK professionally, I wanna remind you to head over to the ZK jobs board. There you can find job posts from the top teams, working ZK, find your next project or team over on the ZK jobs board. I've added the link in the show notes. So check it out. I also wanna make sure that the ZK Hack mini is on your radar. Last fall, we did a seven week event with puzzle hacking and ZK tool workshops. Now we bring it back for a mini version of the event. It's set to last two weeks and starts on March 1st. Our building part partner is Polygon, who is also the sponsor of this episode. Be sure to sign up today for the newsletter as well as the first ZK hack event that is on March 1st. There you'll get updates on our schedule and additional partners as they come. So hope to see you there. Now I'll let Tanya the podcast producer share a little bit more about this week's sponsor.

Tanya (00:01:39):
Today's episode is sponsored by Polygon. Polygon is one of the top Ethereum scaling platforms for developers with over 130 million unique user wallets. They're known for polygon POS chain. One of the most popular chains built on top of Ethereum, sometimes clocking even more daily active users than Ethereum itself. And the team is actually working on a spectrum of solutions, including EVM compatible, zero knowledge roll up solutions like Polygon Hermez, Polygon Miden, and Polygon Nightfall, which is built in association with Ernst & Young. They also recently announced their acquisition of Mir protocol. Now known as Polygon Zero. These solutions inherit the security of Ethereum and use the power of zero knowledge. Over here at the podcast we've been tracking Polygon's journey and have recently had Bobbin Threadbare from Miden and Jordi and David from Hermez on the show to talk out the respective projects. We recommend you check out those episodes to learn more about their vision, project roadmap and progress so far. Polygon is also hiring and they have a few jobs listed on the ZK jobs board. You can check out that link in the show notes. So thank you again, Polygon. Now here is Anna's interview with Agoric.

Anna Rose (00:02:42):
So today I wanna welcome Dean Tribble to the show. Dean is the co-founder and CEO of Agoric. So welcome Dean.

Dean Tribble (00:02:49):
Thank you for having me. Good to talk to you again, Anna.

Anna Rose (00:02:52):
Dean, this is not the first time you're on the show. I did an episode quite a while ago. It was a combo episode where I, I think I interviewed this is like what I just started doing the podcast did not realize what I was getting myself into. I think I interviewed like 12 people and shoved them all onto one episode. And I had yourself and Mark on that episode,

Dean Tribble (00:03:13):
My co-founder Mark Miller.

Anna Rose (00:03:15):
Yes. And we got a, I mean, at this point, at that time it was Zcon0 in Montreal. It was the first Zcash conference. What were you doing around that time? Was Agoric already a thing had the, had the initial team formed?

Dean Tribble (00:03:30):
Yes. Agoric was already a thing. Zcash was the initial investor in Agoric. I think we had gotten the investment at that point, I guess. I'd have to remember the timing. Yeah. We'd gotten the investment at that point. So Zcash Naval and Polychain had invested and we brought the whole team all, you know, five or six of us out to Zcon0 to explain to the Zcash world why Zcash was, was investing in us. And, and what was this Agoric team doing anyway.

Anna Rose (00:04:04):
So tell me, but like what, what has your journey been since then? So you, yeah. Like what actually, what were you originally like? What was that original project company?

Dean Tribble (00:04:15):
The vision hasn't changed significantly specifics of the execution have changed and we've then gotta go to market that leverages it in, in an interesting way. But the vision has always been smart contracts written in hardened JavaScript, right? Something that, that means millions of developers can understand them. Millions of developers can build them. And that's what it takes to open up the world of blockchain and the world of smart contracts to mainstream developers and mainstream use cases, which to, to me, is the goal, you know, or rather the goal is enabling the cooperation that large scale deployed, secure, smart contracts can enable.

Anna Rose (00:05:00):
And that idea, I mean, basically bringing in all of these developers, can you tell me why, like, why doesn't Javas, why can't you write a blockchain in JavaScript or why can't you already, why is that a challenge? Like why haven't they already done that? What are the, what are the challenges of using something like JavaScript as a smart contract programming language?

Dean Tribble (00:05:22):
Sure. So there are, I would say two big challenges and we address them both. The JavaScript as is out of the box is very malleable, right? You can change what it means to iterate through an array, right. And have it, copy your data and send it off to another country and then iterate through the array or define iterate through the array as look around on your hard disk for a file named keys, right. And then send it somewhere. Right. So that's not great. Shall we say the other thing is that it is as with most languages not deterministic, which is to say, if you run the same program multiple times, or if you say run the same program from the same starting state on two different machines, it will produce two different answers or it could produce two different answers. And that means you can't really run a blockchain, because blockchain is all about running the same thing in multiple independent jurisdictions where they don't tRust each other and they're checking each other's work and they come to consensus about what happens. And so if you're gonna say run this smart contract, it better produce the same answer every time, whether on replay or in, you know, at the same time in different machines. So that the same thing happens. And we'd been in the JavaScript standards committee for years, even at that point and knew how to lock JavaScript down. And the technology for that has evolved and refined somewhat, especially in how it's named. So hardened JavaScript is the thing. It is standard track version of JavaScript. That is actually the standard now for embedded systems JavaScript, spearheaded by a company called Moddable. And it has a function literally called lockdown that is called to take that malleable base of array and number and string and all that sort of stuff and freeze them, lock them down. So they do the thing that is specified it in the standard. So array iteration does exactly this and you don't get to change it. And especially you don't get to change it for some other, you know, one library does not get to change it for how other libraries use it. And that means that much of, of the vulnerability that is pervasive, not just in JavaScript, but in Rust and in C sharp and in Java and in all these other things where, you know, if I can do something in one module that affects the, the shared world that other parts of the program are operating in terms of now, suddenly you can corrupt execution and with JavaScript lockdown like that, not only is it no longer bad, it's actually better than all the other programming languages out there. It's just easier to secure JavaScript than it all these other languages. And so we end up with, with this platform that you can suddenly build reliable and robust softwares.

Anna Rose (00:08:06):
Would you say like, was the project's inspiration more coming from the programming language side? Was it kind of like, I, we want a hardened JS, therefore we should do what, what needs some, some fine, like some fixed language or was it like, I wanna do a blockchain and we wanna use JavaScript.

Dean Tribble (00:08:25):
So so it was coming from yet a third direction. I'm a big fan of, of third solutions. So the primary redeeming feature of JavaScript is that it is the number one programming language on the planet. And if you're gonna solve the problem where you want millions of developers to join into that solution, you have to meet them where they're at. And, and, and help them use their tools and their practices to accomplish this new goal. And so it was definitely not about JavaScript. I've designed secure programming language before Mark Miller has designed secure programming languages before, you know, Kris Kowal, you know, all of us have been involved in lots of other systems and lots of other secure systems that were motivated by the, the values and features of the language, except for all those languages had, you know, a few that thousand really excited people at best, right, as opposed to millions of people. And so, so if you wanna solve a problem, go where the light is and do what you can to make that work well for people. And so Mark was already in the JavaScript standards committee driving these security features into JavaScript for the last, literally 15 years at this point, but they had evolved from technologies that we had built in previous languages. So we've done the same style of thing in Java, C sharp, tickle, C ++, OCaml. I mean, all of these systems we've applied the same design techniques that come from secure operating system approaches and technologies, but the key was how do we bring that technology? How do we bring that solution into the blockchain world? So, you know, Agoric was started as a result of a panel. One of the seeds of which was, was Zooko. And that's how they got involved in getting Agoric off the ground, which was in 2017. Oh my gosh, there's all these horrible security holes. Reentrancy bugs have now lost us, you know, 30 million. So they fixed that bug and lost another 30 million. Right. And this is not sustainable, right. If security experts can't get it right, what chance does the general populace of, developers have to get it right? And the answer is, you know, big, fat Goose egg right. But they, you know, Zooko, Jorge from Gravity, Brian Warner, who had just been on security review committee for Ethereum through Least Authority, they knew that we had this other approach in this other technology. And so they brought together a panel with Arthur and Mark and, Zooko and, and, and Jorge and so forth to talk about, would this approach that Mark and I, and a few others have spearheaded help with the problems that we're seeing, the exploits that we're seeing in the overall Cryptoverse and the net conclusion was yeah, basically it would. And it was colored by the fact that it happened during the Tezos raise. And so, you know, Arthur's on stage talking about this model that he'd spent, you know, weeks and weeks chatting with Mark about. And, you know, from the beginning of the conversation to the end, you know, that, you know, Tezos went up by 20 million dollars or whatever it is. So that was, that was sort of an entertaining color to, to the scene at this, at this conference. And those of us who were not currently in the space were like, what, you know, totally surprised

Anna Rose (00:11:36):
So, so it sounds like you joined around the same time I joined that would've been like summer 2017. Had you been working though in crypto land before? Or was it or blockchain land maybe?

Dean Tribble (00:11:49):
Well, so the answer is I was a, you know, one of the early cypherpunks back in the late eighties, early nineties. So there's a sense in which yes. Also I, so at the time I was working on a CeFi, shall we say it, project electronic checks and ironically, you know, and that had started in, I know, 2012 or something like that. And it was one of the very early users of technology that is related to blockchains though. Not quite the same. So it, it used digital timestamps, decentralized digital timestamps to enable replacing paper checks with the electronic version, right? Every prior to blockchain, every payment mechanism under the sun started as paper and, you know, credit cards when they lost credit card, paper slips, suddenly it got legs, and you could use it on the internet, all that sort of thing, you know, same with wire transfers, same with, and so the last bastion of requiring paper was checks, and there was still 20 billion paper checks in the world or in, in the us every year for 30 trillion dollars. So it's one of those things where, you know, blockchain still has a long way to catch up with 30 trillion dollars in transactions.

Anna Rose (00:12:53):
Is that, that's still the case that there's so many paper checks. I'm from Canada. And I know that like, checks are still a thing there, but when I moved to Europe, everyone was like, really, you use paper checks? They thought it was very, very funny.

Dean Tribble (00:13:07):
Yes. They thought it was very, very funny. And yet Britain, Portugal still using astonishing number of paper checks. I think Portugal is number three in the world.

Anna Rose (00:13:14):
Oh, is it? Germany does not use it at all anymore, I guess.

Dean Tribble (00:13:18):
Uh, yeah, we'll see. But maybe, but the reason is because as a payment flow, it's just better because if I want to pay you, if I have to do it digitally, now, the system I'm doing it through needs to understand all of the shipping information and detail about what I'm paying for. And so in the context business, you know, and, and part of the, Agoric model is inspired by this as well. In the context of business, I don't just send people money. There's a quid pro quo. I send people money to get something. So in the same way that I don't wanna be using wallets, where I send money to a random number and hope something good happens, which is basically the user model in most of crypto right now, I wanna say, I will give you this money. If you give me that NFT. And if you, if you don't give me that NFT, then the system guarantees that you do not get my money. Right. Well, checks are very similar. I will give you that this money, you know, and here's what I'm paying for. So you've shipped something to me, you know, I'm paying you 10% less because these three were damaged. There you go. Right. And that flow is just a better flow for business in spite of the fact that it, it, you know, it, that it means that banks don't get to sit in the middle and control your payments. Right. And so that's the reason why it hangs on is it is, it has just has faster payment with better information flow.

Anna Rose (00:14:25):
But that was the company you were basically working around that space around the checking space, but it was different. You were moving, you were like looking to move paper checks to a digital form using this different mechanism

Dean Tribble (00:14:37):
And have it still be legally a check payment, which has better laws for businesses around better, better. You know, so even at that time, I was in payments, navigating around regulations. Right. You know, that is, that is historically always a thing with payments is you're always innovating in a way that, that puts you on the edge of that. And so it's sort of natural to be in crypto because that was clearly one of the bullets that we were gonna be biting, but that kept me out of crypto for a while. Partly because, you know, blockchain was way more hype than substance. Even the blockchain is pretty wonderful. The hype, the people that did not understand it, what they were saying about it, you know, I would look at it and go, no, it's not. So that's pretty dumb. And so, so so I didn't get into it. And I sort of steered clear because when you're innovating in CeFi space with really conservative bankers, you wanna be squeaky clean. So that they're, they don't just have a irrelevant, allergic reaction to you. And instead, you know, seriously contemplate what you're, what you're telling them.

Anna Rose (00:15:36):
Got it. But you made the leap after this panel, after the initial investment, you made the leap into Agoric to basically bring a blockchain with smart contracts. That would be easily writeable by lots and lots of developers. Yep. I have to ask the question, what is your opinion of Solidity? Because Solidity is the kind of programming language for smart contracts. It's based, as I understand, roughly on like a JavaScript type model, but it's confusing to people because it's not exactly JavaScript. Tell me what you think. I feel like you're, you might have an opinion on this.

Dean Tribble (00:16:14):
I might have an opinion. So first off, you know, the most important thing is Solidity is wonderful because it brought smart contracts, which predate blockchain by years to the blockchain world, right? So smart contracts are software. That's enforcing the terms of a contract like arrangement between third parties. It's not simply autonomous programs running. It's really this pattern of, you know, two strangers being able to cooperate mediated by software and with the terms of that cooperation enforced by software. So Bitcoin is a smart contract. It, it's not a flexible one. It's a particular arrangement between parties is enforced by the execution of that software. And so, you know, smart contracts include eBay and PayPal and Venmo and Airbnb and Uber and Lyft and all those things. So, so smart contracts were trillion dollar market cap before, before blockchain ever existed. What Ethereum did, is it married smart contracts so that you could run user provided smart tracks on a blockchain. So it combined, you know, from my perspective, the, the value, what, what blockchains bring is replicated execution across multiple different machines in different jurisdictions, in different administrative zones, all voting through some consensus algorithm to agree on what happened to agree on the data and on the choices and, and the results of execution. And that's the gold standard of blockchains. And Ethereum was the first thing that brought that. So hugely valuable. It really made a big chunk of this world possible. So that having been said, Solidity is not JavaScript. I mean, it's, it's not JavaScript anymore than JavaScript is Java, right. They both use curly braces. Awesome. So does C you know, so do various Assembly languages that doesn't make it JavaScript, that's simply, you know, the standard kind of marketing lie. You tell people to, make them take their medicine. And so that's simply misleading. It is. I mean, it's, it's it type language. It has 250 signatures not floats. I mean, it doesn't have, it doesn't have a spec like, like JavaScript does it does, you know, I mean, it's just, it's just nothing like it. It's also got critical design issues, critical architectural issues that are the root cause of many of the losses that you see and are such that security experts cannot get it. Right. And the reason they're critical architecture issues is because humans can't get it. Right. Right. You know, experts can't get it. Right. Certainly not intermediate programmers and general mainstream programmers, can't get it, right. Because you can take two correct programs, put them together and get a bug. So reentrancy is not something you can paper over with changes in syntax. The security model of message.sender is not something you can paper over with different syntax, it's a vulnerability or an architectural choice right at the heart. Now it has the advantage, maybe that it made simple things really simple. And that might have been very important for getting this off the ground. So, you know, it's easy to second guess choices. In hindsight, though, at the time Brian Warner pointed out that you're gonna have reentrancy bugs here and that's going to be a continual plague. And indeed, you know, there was reentrancy bugs before that panel that I mentioned, and there reentrancy bugs last year where someone used one of the other intrinsic insurmountable vulnerabilities of message.sender to create a reentrancy bug and, and extract 660 million from Poly network, right? Same architectural issue. It's not as Vitalik claims because they're doing layer 2s. And somehow, you know, bridges are less safe than running directly on Ethereum. It's because it's got reentrancy architecture choices at the heart that are not scalable, that, that the more you break things down to make them composable, the more you create risk that you will have reentrancy bug. And so to me, it's, you know, there's some things that people have worked out that work. They've gotten battle tested. They've got assets, that's great. They may last forever, and we may leverage them forever, but every single new smart contract you build on Ethereum has an intrinsic, deep, architectural risk that, you know, I think there's just a, a strong limit to how much people are gonna be able to build in this model.

Anna Rose (00:20:23):
And at the same time though, I mean, I am curious to hear what you think of the proliferation of it. Like there's a whole generation of folks who've been onboarded into blockchain, into programming, potentially using this language. Do you think, do you actually, and now with the EVM compatible chains popping up pretty much every major L1 has an EVM component now. So like they're using Solidity too. So I am curious, like, how can you even imagine that evolving? Like, is that not going to be the standard somehow?

Dean Tribble (00:20:55):
No. I mean, yes, it looks like lots of people are coming in. There are fewer people programming in Solidity on a reliable basis and show up at most JavaScript conferences, right? So it looks like a big number or when you're in a small space, but 10,000 developers that could potentially do a halfway decent smart contract for DeFi was electric capital's estimate. There are 10 million, actually 13 million plus JavaScript developers and all of those 10,000 developers, you know, 80% of them know JavaScript. So it looks like a lot. It's great. It's important. It's valuable. What they learn about smart contracts will be useful, but it's still not the kind that you, you're not gonna get an exponential ramp there simply because the landmine security hazards are too deep with respect to the proliferation of EVMs. That's not software smart contract innovation, that's replication, right? It's not that at Evmos, which is a EVM chain. You know, it used to be Ethermint, I think, but it's EVM in the Cosmos ecosystem. People are not excited about how people are gonna be able to build new, smart contracts on Evmos. They're excited about being able to clone the existing battle, tested instances over from Ethereum and deploy them in Evmos. That's wonderful from a DeFi economic point of view, it's zero, it's uninteresting, from a evolving, the set of developers and evolving the ecosystem and so forth, right. So that will redistribute some of the Solidity programmers and make you that it make cause most more accessible to them. But we've talked to Solidity programmers where, oh my gosh, if I could program this stuff in JavaScript then you know, would take a factor of four or five less time to build it in JavaScript than in Solidity. And that's not counting the intrinsic security hazards.

Anna Rose (00:22:38):
There is one other language that is often used in the blockchain world. And one that I, I mean, my old co-host Fredrick was a huge fan of that's Rust. I'm curious what your take is on that sort of like that being used in blockchain. I mean, it's also obviously a much smaller community than something like JavaScript, but yeah. Do you have any other thoughts on it?

Dean Tribble (00:23:00):
Yes Rust is wonderful when we were doing the Midori secure operating system project at Microsoft, we had a similar thing called system C sharp that had, you know, some of the shared ideas from our compiler group in the nascent Rust community at the time. And, and that's really cool. It's really cool for system programming.

Anna Rose (00:23:18):
That's like building the blockchain maybe.

Dean Tribble (00:23:20):
Yeah. So, so we have Agoric VM, you know, we did a toy version in Rust. Eventually we'll be able to reproduce it in Rust in order to make it, you know, easier, safer, stronger, whatever, to be it for people to, to build and deploy JavaScript smart contracts. And, and there are lots of wonderful programming languages in the world, and there are 13.9 million developers that program in JavaScript. So, you know, so it can be a good programming language and it can have legs. And we will, we are actually designed, I mean, you know, I'm, I'm focused on hardened JavaScript, but our architecture is such that we'll be able to plug in things in other languages eventually at the point where we want to, the problem with Rust is, is kind of twofold. It has the normal problem of compile languages, where what you program in and what you're running are different. And Solidity has the same problem. There have been bugs where the semantics, the attacker used was the EVM semantics to express things that you could not express in Solidity. And that was what they used to convey the attack. The same thing happens in Rust where the attacker is programming is writing directly in assembly language or CosmWasm, which is just another assembly language. And they can do things that you can't express in Rust. So Rust has the same problem as Java and C Sharp and these other languages do where when you incorporate libraries, you are completely vulnerable to those libraries, right? So the same thing where you can mutate array in JavaScript, you might not be able to mutate array, but if there's any shared mutable state having to do with account balances and I incorporate a library to help me add them up, there's nothing you can do in Rust. Well, I that's too strong there it's, you must be vigilant and it's pretty infeasible to be continuously vigilant all these fronts to make sure that this library you brought in, doesn't just add up your numbers wrong, but go out and find your files and go and issue transactions, right? So the architecture of security is still an important thing. And if they aren't improving that and they aren't fixing that, then the fact that it's in a, in a language that doesn't have memory safety issues, isn't really important. Javascript also doesn't have memory safety issues, right? Small talk, didn't have memory safety issues. You know, now Rust gives you much more precision and control of the allocation of memory. And that's really nice for systems programming where you cannot afford to do garbage collection, but you know, it's not a game changer the way people think it is. It's a, it's a game changer for reliability of systems, not in some sense for correctness of systems.

Anna Rose (00:25:53):
Are there any other languages that do rival JavaScript in terms of popularity that you also thought of?

Dean Tribble (00:25:59):
Um no. I think the answer is really not you know, Python is, is, you know, has some of the same legs because, you know, the scientific community uses it. Google uses it, et cetera, but a, it's not, it's not in the, in the same world as JavaScript because it's not part of application building. Right? The, the thing about JavaScript is, is like, if you look at NFTs for engagement, so gaming sites, sports sites, music fan, all those kinds of things. They're innovating now forget blockchain. They're already innovating and how do they engage their fan base? Well, and whether that's mileage numbers for airlines or real estate sites with their wizzy maps and fly throughs, all that stuff is done in JavaScript. Right. And yeah. Okay. Now that we've added Wasm to that, and we were part of by the way, the growth of Wasm, but all the wiring, all the orchestration, all the imagination of that is done in JavaScript. And so we wanna empower those people to be able to extend that into, you know, the engagement using NFTs, where they're all already innovating and usability and engagement with their customers, that innovation is not happening in Python, right? That's, that's a different level of thing that is mostly disconnected from the world of app development and creation of new experiences. And so that's sort of the right audience to engage. So, no, I don't think there's anything close. You know, I would say, you know, my second theory of that would be C Sharp or Rust because those communities are kind of building the same kind of thing. But, you know, Rust is, as I said, much better for systems programming and I intend to use it that way, but, but not for real rapid application development.

Anna Rose (00:27:37):
All right. Let's jump into the challenge then of JavaScript making the hard into JavaScript. We'd already talked a little bit about, like, the fact is it's a malleable language. Do you feel like, as you were implementing this blockchain, did you learn new things? Did you have to change your initial spec of what this would be in order to fit into a blockchain context?

Dean Tribble (00:28:02):
So is two levels of answer to that. That's really interesting. There's what did we do with check to harden JavaScript? And then there's, what did we have to do for our chain architecture? And originally we were not, we were considering doing a chain. We were looking at being layer two instead because the, you know, the future vision is not just, there's an, Agoric chain with hardened JavaScript, but rather, you know, you use the same model of computation, which, which is islands of simple synchronous programming with asynchronous messaging between them, right. That's really the, the model of Agoric computation. And we've used that model in a wide variety of systems in a wide variety of production systems rolled out long before blockchain. And so being able to run the same computational model on your solo machine, in your data center for decentralized applications that have nothing to do with blockchain, they're just using multiple servers to do automated coordination on top of multiple different blockchains. That's the eventual future model, you know, in your clients and so forth, because it's a model that programmers understand, it's a model they can grow quickly. And it's a model that, that is secure, composable, scalable, et cetera. So at that level, when we looked at, how could we make this happen? We realized that there were elements to make it work that required being wired into the whole stack of a blockchain. So we couldn't just make it a layer two and really have it anchored in what blockchain folks needed to do. We needed to have a place where you could deploy these businesses in an economy that had roots in the infrastructure it was running in. And so we're not just building, here's smart contracts, but here's smart contracts with a few key market services, like a stable token that can use to grease the growing economy and with rewards for executing in that environment that are paid out in, in the form of staking rewards. So that there are people that are deeply embedded in that environment that are driving it forward. And so that's what led to, yes, we're going to do an Agoric chain at the core of it, but we'll be able to grow that horizontally with multiple chains, support consortium chains, gradually grow modules that would run on other platforms or run in the browser or in your cloud services when you're doing, you know, so you can build games the same way and so forth. But the heart of it is that Agoric chain with core economic modules built on it. So there was some architectural changes there, as well as technical things of, you know, if you're writing in JavaScript, there are sort of two ways to think about the state of your smart contracts. One is like Ruby on Rails of people, familiar with it. Transaction comes in, you know, I, I run JavaScript program. That's gonna load code from a database Merkle tree, whatever it is, load code, compute some state and then drop everything on the floor and write the state out. And that's a transaction. And when a new transaction comes in, you know, the execution is stateless. All the state is stored in your database or Merkle tree or whatever it is. And that's approximately the model of Ethereum. It's got some significant attractions, right? It is in many ways, it has some simplicity from an implementation point, if you, and it is, you know, easy to explain in some cases, or in many cases, what we're doing is more complicated, more challenging. And, and it is that core smart contract for services. Like if you're running a vault system, like our, our underlying run protocol is a stable token, built like maker is built, but the model of smart contracts is I start a JavaScript program and it just runs forever. Right. And if the machine crash, it comes back up and it can replay from scratch and get to the same answer, cuz remember deterministic execution, we're gonna get the same answer every time or it can reload from checkpoints. And so we have reload from checkpoints and our machines will restart, you know, the failed node would restart in six seconds. And so what you have is a simple JavaScript program that didn't think at all about the disc and it just lives persistently and accumulates state and it garbage collect. And it does all that thing and just lives forever on chain. That's a really nice model to get it to work. You gotta do hardcore determin, man. You've gotta have the magical persistence. So we're able to do check pointing so we can get that restart. And that took a lot of work that took a long time to get working.

Dean Tribble (00:32:12):
You know, our incentivized Testnet was to be able to test a bunch of that sort of thing and make sure machines didn't diverge. And it's a continual, you know, we have test, you know, CI infrastructure, you know, continuous integration infrastructure runs multiple machines and see if it can make them diverge and that sort of thing. So that's challenging tech, there's some really cool stuff in our stack. It also turns out that that's not good enough because if you got long lived service, like our, you know, vault engine for the stable token, that's gonna have a million, 10 million accounts in it. You don't want all those in memory, right? Even, even with fast replay and fast restart that's way too much. And so you need this hybrid of simple contracts just, you know, live in memory, they run forever, whatever the bank, the vault factory, it has data records in the same way that, oh, I'm a big enough business.

Dean Tribble (00:33:00):
I'm not gonna remember it all in my head. I gotta write it down in my books and that goes into a database or it goes into a Merkle tree or what have you. And so all that balanced technology is stuff that we're finishing up now to move all the economic contracts to use that new persistence infrastructure. And that was a significant architectural lift that, you know, is coming together. It's really cool as it comes together, but I sure wish it had been out, you know, years ago. Right? The other direction is we rolled out hardened JavaScript first version of it in 2018. And it's been used by Salesforce for app exchange, you know, parts that have been used in, in brokerage terminals that, that are built in New York, whose name I can't say. You know, so it's been used in web2 industry and that gave some battle testing that led to some incidents where mostly it was incidents problems, issues they ran into in the parts that turns out we didn't care about and didn't care about, you know, it was just there in order to be part of the overall JavaScript standard spec thing and solve a, an be an extension of solving a problem that needed solving in JavaScript. And so we did have a major design change to split those apart. So the part that heartened JavaScript is much, much smaller, much, much tighter, much more securable. And this other thing called realms had a life of its own and would proceed on largely independently supported by us in, in the standards committee, but not as part of solving this problem. And that's resulted. So now this same technology, it's at the heart of you know, the recently announced MetaMask Flask and Snap system. You know, like the Kumavis of MetaMask, when we first started working with, with MetaMask on this hardened JavaScript stuff, his comment was I wake up every morning and quietly panic about my dependencies. Oh, they the same kind of dependencies that, you know, if I had a Rust engine and I was relying on a hundred thousand libraries, any one of them can compromise security. That's a bad thing in normal applications in practice, you look at all the cystics you look at GitHub projects, 97% of the code of applications on GitHub comes from libraries that the authors did not build. That's true of any language, pretty much any system, pretty much anything that uses components. So it's true C Sharp. It's true a Java it's, it's gonna be true of Rust to the point where that system matures. So the fantasy that you looked at, every line of code of every library you're relying on. Yeah. Maybe for a medical device, not for anything else, it's just not realistic. And so unlike any other system on the planet, you know, with our hardened JavaScript, one of the things that, the reasons why Kumavis and company were so excited about it is that when you load libraries, you can load them without authority. So when you load a library to compute, you know, the mean of some large distribution of, of prices, it doesn't have the authority to read files. It doesn't have the authority to talk to the network. It doesn't have the authority to do all these things. All it can do is do bad math, but that you can check that you're expecting you, aren't expecting to do a scraping around. You're just looking for, for, for private keys and in hardened JavaScript and no other system that is available generally in other languages, it can't do that. It can't get to the files. It can only do the things you gave it. And that's why, as I said, at the beginning, hardened JavaScript actually is more securable than these other programming languages because of that, that ability. And so we made some pivots in how we did that ship, that it's, you know, again, in AppExchange and core elements of this, or in nodeJS, elements of it gone out into the standard for embedded systems, for extensible wallets in, in MetaMask, in the APIs Cosm JS for controlling Cosmo chains, et cetera.

Anna Rose (00:36:47):
Cool. I kind of wanna ask one last question about the language part, but then I also wanna, after that, I wanna explore actually the components of Agoric and how it works as a blockchain. But first I wanna ask a little bit about, I know in the presentation that you gave at the ZK Validator, cosmos privacy, scalability edition event, recently, a lot of words in that one, you did talk about like react somehow. So do you allow for, and I'm gonna sound so not like a coder here, but like, do you allow for React to also be used within your system?

Dean Tribble (00:37:21):
Okay. So the primary,

Anna Rose (00:37:23):
Do I sound not like a coder right now?

Dean Tribble (00:37:26):
Oh, no, no. You totally sound like a programmer. Yeah, yeah, yeah. Totally sound like a programmer. You know, my bet is, you know, one month of training you could build smart contracts on our system. Hey, welcome to JavaScript.

Anna Rose (00:37:37):
Right. We should take you up on this this challenge, you know,

Dean Tribble (00:37:40):
We should. Okay. I'm taking a note of that. We are totally getting you into programming with

Anna Rose (00:37:45):
Yeah. Okay. Let's do it. I've taken all the intro to

Dean Tribble (00:37:48):
You know, we have a bounty program, you can get rewards.

Anna Rose (00:37:51):
It should just be like, get Anna to code something.

Dean Tribble (00:37:56):
Yes, that's right. Cosmos run these Code With Us sessions where, where one of our developers built an over the counter trading desk in our system inside of VS code, you know, showed how to do it in an hour and a half. So, so we just have to have code with Anna sessions.

Anna Rose (00:38:10):
There you go.

Dean Tribble (00:38:11):
So reactJS. So, so the most important reason I refer to react JS is not because we're using it though. We are it's because it's the architectural example that millions of programmers understand for how our smart contract framework helps them. So experts were doing cool stuff in JavaScript for years in browsers to do interesting interactive applications. And there were even some frameworks that helped with some parts of that, but then react came out with some key architectural elements that absorbed some of the hard parts and in a way that it not your problem, right? One of the hardest things to do to make really interactive applications is what I refer to as the repaint problem, or really the incremental update problem. I displayed some stuff. I rendered it. Now I change some of the stuff and I need to update just the parts of the screen that reflect the fact that I change the zip code, right. And if changing the zip code change the amount of tax cause there's local taxes, I need to redo that part as well. And the number of bugs in user interface is attributable to not doing incremental update correctly is, you know, I don't know, 60%, 80% of it's a huge, huge problem. And, and so many systems, they just don't support it. You have to refresh the page to get the right number, you know, the right answers if you, if you do this stuff. And so react came along with a different approach to that, that solved that problem in the architecture of the framework. And it enabled the creation of components such that you could build using the components other people provided. And so now six months after react came out and it shipped with a couple of components, but people could see that they could do their own see components and that their components would plug together with other people's components in order to produce something interesting and richer.

Dean Tribble (00:40:02):
And so I, as a beginning, programmer could grab a slideshow component that could show images and let you slide back and forth and animate and do infinite, scroll off a database and all that kind of stuff, and grab a payment component and plug them together to a, a art sales website to sell my art, cuz I'm a freaking artist. I'm not. But, if I were, and I could do that without ever being able to write a slideshow component or be, or having much clue about how to do payments. And I could do that because the composition rules and the reenter, you know, and, and the rendering and how to handle mouse clicks and all that sort of stuff is supported by the framework has affordances by the framework or can tell me what I'm doing wrong. And, and give me, give me errors in a model I understand and, and so forth.

Dean Tribble (00:40:50):
So that, that is a, what I would think of as the pinnacle example of what people have referred to as component oriented programming, right? And once people see that, I mean, it's same thing that gave node JS legs. The reason why node had legs and NPM had legs is people could see that. Not only can I build components here, but people already are. And so I'm gonna be able to come and use their components. React was, there's a bunch of components that I can start with and they're all cool. And I can easily add my own. And as I start building stuff and you're building monolith, you know, some monolithic additional thing and you go, wow, that's annoying. I'm gonna pull this out as a component. And now suddenly, oh, this is reusable. I can make this available to other people and get feedback.

Dean Tribble (00:41:27):
And someone else, you know, this one is a component, but there's already one out there that's better than what I was thinking. I'm gonna throw mine away and use his that's awesome. Right. And so you get suddenly, literally exponential growth because you're, you know, every month, you know, not only you're getting experience, but you're getting to build on a, month's more worth of more programmers building components. And that attracts more programmers to build more components faster and so forth. And so it ran, you know, exponentially up to five, 8 million developers building this UI. So six months after react came out, okay, maybe it wasn't six months, maybe it was eight beginners with a few months of, of training could build a more responsive, faster, stronger, better, more international, you know a mobile friendly application in JavaScript then experts could the year before using the same language, but with a framework that gave them the right affordances with a framework and environment that in that enabled this component driven construction. And so our smart contract framework is the same kind of thing, but whether the affordances are for pricing and trading and digital assets and exchange rather than mouse clicks and re-rendering.

Anna Rose (00:42:35):
Okay. So you, but you're saying that like the, basically to build on your stack, you also are going to be able to build these components or components could be built and then built on.

Dean Tribble (00:42:48):
Exactly. So a smart contract is a JavaScript module that exports one function called start. That takes an object that lets you talk about offers coming into you. And then you write JavaScript hook saying when I get a bid offer, run this JavaScript, when the seller comes in with his good run, this JavaScript function. And when the auction ends run, this JavaScript function. And the obvious thing to do is take the bids, sort, them pick the top one, charge them and say I'm done. And then the framework handle returning the money to the losing bidders because the bidders, you know, I was inspired kind of to, to pursue this contract framework when I saw Solidity by example, to introduce brand new programmers, to Solidity where in the first simple example, it showed you how to navigate around six God, awful through which you could lose all of your money.

Dean Tribble (00:43:38):
Right? For example, the reentrancy bug. Well, if you, if you send them back their money, then they can call you back to get their money again. And you can send it back multiple times and you know, and people lost, you know, 60 million in ETH back in, in 2017, you probably don't wanna do that. You know, that's the first thing I have to learn holy crap. And many security hazards in Ethereum are because you send money to the contract and it will decide what happens to it. Right. And that's like giving your money to the used car salesman and then talking about what car you're gonna buy. Right. That, that, you know, yeah. You can do some commerce that way, but it's not really a growth, you know, kind of framework you wanna deal with. Whereas in our, a framework right back to that quid pro quo, the assets you give, go into the smart contract framework with the proposal of, I will give you these, this ETH if you give me that Atoms, right. I will give you X ETH here they are. If you give me that NFT, right? Let's say, it's, it's an auction. And now that's an offer that I'm making to that contract. The framework will tell the contract, you have an offer for this much. If you gave the NFT to this party, then you would get this much ETH.

Anna Rose (00:44:44):
If you don't money goes back automatically.

Dean Tribble (00:44:47):
Yeah. And that invokes a hook. Exactly. Why, where in, in a react, a react component, you say, you know, when this mouse click hack happens, run this JavaScript function. When this, you know, event happens, run this JavaScript function. And when you render run this thing, right, exactly the same kind of thing. When a bid happens, run this JavaScript function. When a sale offer happens, run this JavaScript function. And when you exit run this thing, that sorts and gives everything back. And the only thing the smart contract can do is what we call a reallocate, where it says, take the money from this guy, give it to the seller, take the, as from this guy, give it to that bidder. And that only works if it simultaneously satisfies the offers of all of the participants. So you can't just take money from someone you can't just, you know, upgrade a contract to take all the money and go to Tahiti.

Dean Tribble (00:45:31):
The only thing you can do is what we call, offer safety, where you can reallocate their assets, atomically, giving them what they want. So they either get what they want, or they get their money back. That's sort of the basic promise that you would like from any financial exchange kind of framework. And we provide that, and you just don't get that in any other blockchain environment, but here you get that because of the framework. And that just gives you this pervasive safety property, that, that doesn't solve all bugs, but it eliminates, you know, 90% of them or 80% of them.

Anna Rose (00:46:02):
Cool. You were kind of citing react as a inspiration or like something that you're building something in that direction.

Dean Tribble (00:46:08):
And we also use that as an inspiration for how do you, you know, how does someone set up a new program? Well, Agoric and knit new smart contract, and that will generate a UI directory that has a react initial application, a API directory. If you've got a cloud component and a contract directory to be deployed to the chain, you know, exactly the way Ruby and knit or React and Knit are one that, you know, millions of developers are used to starting a project by saying, you know, get me a skeleton that I can then enhance rather than give me a blank page and, and, and, and go from there. And so lots of inspirations in terms of, I mean, one of the nice things in JavaScript, there have been lots of experience, lots of well-trodden paths and techniques to grow exposure of a framework to millions of developers and, you know, traditional marketing mechanisms work because it's a kind of a, of mainstream market developers. And so those are the things that we're now starting to do as we get closer and closer to launch. And so one of those is, yeah. You know, let people build things the way they're used to starting off.

Anna Rose (00:47:06):
Cool. I wanna go into the blockchain itself. The L1 we talked, you know, earlier in this episode about this decision that you were, you know, originally a eyeing the L2 space, maybe you were even thinking like Dapps, then you made a decision to be an L1 to be a standalone blockchain. Well, maybe not standalone standalone. What was your decision making in that time and what kind of led you to the zone, the Cosmos world?

Dean Tribble (00:47:30):
So originally we were, we, we were doing a lot of work with Polkadot, you know, we talked to Tezos, we talked to, you know, Vitalik and ETH folks. And, you know, we knew that A. We wanted to be cross blockchain. So we were talking to everyone and we still, you know, our goal is getting everyone reached out to mainstream, not, you know, trying to of up the current relatively. I mean, it's still big, but relatively small pond of, of, of the current cryptoverse. And there were technical challenges. There were even some political challenges in terms of getting working inside of the parachain model. And it's a little bit too, you know, everyone has to march to the same beat of, of how things work and that's fine for some applications, but it's, I kind of think of that. That's like a mall, right. You know, you're gonna be at the mall, you're gonna follow the rules you open when the mall follow. And that's a way to build an economy that's really valuable. There are plenty of cool malls in the world, but that's not a broad, large scale economy when we ended up connecting with the Cosmos folk and we were in the midst of building our own platform. But when you connecting with the Cosmos folk it was, as I said, it was like we found our peeps because the general model that we've had, not just for a couple of years, but historically since the eighties is independent actors voluntarily cooperating to create an economy. That's the, that's what creates an economy as independent actors cooperating because in, you know, because there's a, win-win there, right? That's the goal is to make that easier, faster, better, stronger, automated, et cetera.

Dean Tribble (00:48:58):
And so that's the fundamental model that Cosmos had as a vision. It turns out because part of that, well, they had, and then they found one of the websites that reflects work that Mark and I did back in the nineties. So the Erlang websites that talked about, remember I mentioned, we had done secure programming languages before. It was not just a secure programming language, but it was a secure programming language in which you could do smart contracts, pre blockchain. And it was specifically about how do you do financial smart contracts in a, in, in a centralized fashion. And they were inspired by that to come up with the, the idea of the interchange. And so when we found them, we had no idea about this. And when, so when we found them, there was just a, a lot of alignment because their model is not, you build, you know, use the technology stack and build your own zone. It's use the technology stack and use and build your own zone that is connected with the interchain communication protocol to other zones. Well, the problem is of course, that they did not have the interchain blockchain communication protocol IBC but they knew what they, you know, but they knew that was part of their vision. They were starting to work on it. And so when we came in and they're like, oh my gosh, you're the people that inspired this. Well, they didn't say that. We didn't know that until we were like four months in. But we, we walked through, we had a meeting where we walked through what we were building from a protocol point of view and what they were trying to build from a protocol point of view and said, you know, great let's collaborate. And so ICF funded us. And so we, and you know, the team at AIB that then spun out and became Interchain GmbH, we worked together, we were the primary teams working together to finish the architecture and design and build of IBC.

Anna Rose (00:50:35):
So did you work closely with like Chris Goes, I guess?

Dean Tribble (00:50:39):
Absolutely. Yeah, yeah. Yeah. We, we had weekly meetings and then several rounds of architecture review with a bunch of people providing, you know, architectural review and input thinking about how to integrate with, you know, proof of work chains, how to integrate with solar machines, you know, how do you incentivize relayers all those kinds of things. And that group, there remains a biweekly architectural committee to review upcoming enhancements and, and that sort of thing for, for IBC. and so, so, so that's an ongoing activity, but fundamentally our architecture has always meant, no, we're not gonna launch in a vacuum. No, we're not gonna launch disconnected from everything we'll be launching. And now it turns out we'll be launching in a, in a connected interchange of 75 billion dollars worth of assets. Yeah. You know, that is growing every day and it turns out it's hungry for what we have for initial use case, which is this, this stable token that we came up with in order to power our economy running on our chain, turns out it's what a community needs, cuz it can be a, a stable token powered by community assets. And that's pretty cool. Cool. So we're very excited about that.

Anna Rose (00:51:42):
So you're, you know, deep in the cosmos ecosystem, IBC is now online. You are going to be working with it. Now I wanna actually understand what Agoric looks like. What is it? Is it a single, like you're when I said like a standalone L1, you were kind of shaking your head. It's like, no, it's connected. It's a, it's an L1 that's connected fair. But is it a, like, do you picture it as a single zone? Like one time blockchain that brings in JavaScript and does stuff with other zones or what, what does the blockchain of Agoric look like?

Dean Tribble (00:52:16):
So this year, yes. So that's how we will launch the launch plans are the first launch, you know, so we have mainnet 0, which is just the Cosmos layer that launch to November. And that gets our validator set list. That gives us a place to do, to do staking deployment, to get the platform hardened, to be able to, you know, pay people and build, distribute tokens, you know, run the public sale that we just did that sort of stuff. So, so our chain is actually live, but it's not running the JavaScript stack. The JavaScript stack will first launch where it runs only the smart contracts that, that have been well vetted to be non-malicious trustworthy, et cetera, so that we can get battle testing in that framework. But the first use case is a stable token. The community's excited about, and not just the Agoric community, but the extended Cosmo versus and Interchain community is excited about is a stable token that is backed by IBC assets. So it'll be backed by Build. We presume. I mean, it'll be the community that decides what everything's backed by, but people are excited about having it be backed by Atom backed by Osmo, backed by secret, backed by Akash, whatever it is because of IBC. You can bring those assets over to Agoric, deposit them into a vault, take a loan against them and Run, which is the stable token. Take that Run over to, you know, a cost to pay for execution or injective to buy a perp or whatever it is. You know, Osmo to put into a pool and it becomes a stable token that is backed by the community assets. And that's sort of the first step larger than Agoric. So we'll have the, Agoric chain running that is operate, you know, on which the smart contracts that implement that operate and they'll scale and so forth. And it does asynchronous communication internally, but all of that, from the point of view of someone running on another chain inside of Cosmos, Cosmos chain, it works.

Anna Rose (00:54:05):
Right. Interesting. This is like multi collateral DAI, but multi collateral Cosmos asset. Exactly. Run.

Dean Tribble (00:54:13):
Exactly community collateral community collateral run. That's right.

Anna Rose (00:54:16):
Okay. Okay. And you, you mentioned another token there Build?

Dean Tribble (00:54:20):
Oh, so Build is our staking token. Okay. So that is the staking token for the, the Agoric platform to be able to build the platform smart contracts and the environment. So we, and.

Anna Rose (00:54:30):
Is it BLD?

Dean Tribble (00:54:31):
LD. BLD. No, it's not BDL. It's BLD. We, we got it. We BDL, but BDL did it. Yeah, yeah, yeah, yeah, no, no build, build, build and run. So now then the second phase is permission, which starts fairly soon after the first phase is permission deployment to smart contracts. And so there'll be some people that we're already working with to do, you know, we've got NFT minting contracts in JavaScript. We've got, you know liquidity mines, you know, we're working with partners where to be able to do smart contract insurance for our smart contracts. And I don't mean just a nexus mutual kind of, of not real insurance.

Dean Tribble (00:55:09):
I mean, regulated compliant insurance that, that brokerage houses and pension funds would need to participate in a, in, in a digital asset ecosystem will be able to do on our platform because of these things like offer safety, reduce the risk and enable more safe action to smart contracts. And so smart contracts to support that might roll out in phase two. Or we may work with reference partners to build their stuff and roll out, roll it out in phase two. But phase three is the big one, you know, or I mean, all of these are big, but phase three is the permissionless JavaScript smart contract environment. And you know, what does phase four look like after that? Well, there are a lot the directions we wanna go getting more zero knowledge stuff in, so you get confidentiality on public chains, but the other is scaling dimensions where, because our model is fundamentally islands of synchronous programming, communicating a synchronously with each other, we can get horizontal scaling without it being the sharding that is sort of the, it, I'm gonna take this smart contract that used to be atomic and now spread it across multiple machines and hope it works the same right now.

Dean Tribble (00:56:14):
This is, you know, some smart contracts can be on this chain. Some can be on that chain. You know, some can be on Agoric one, some can be on Agoric two, they communicate asynchronously with each other. It's just as if they were on the same chain only except for the latency being higher. But the software's the same. The architecture's the same, the security model's the same. It used the same Build staking token because of interchange staking. It used the same Run because you know, that's portable. And so now you've got the ability to horizontally grow multiple chains, run by potentially different validators with different frequencies, potentially optimized for different use cases and so forth. And then we'll start working in directions to be able to enable core elements of the technology to run on other chains in other ecosystems, connecting over IBC and with our fine grain messaging systems. So you can have sequential islands of transactional you know, of computation and contracts running on consortium chains, running in private chains, all smoothly interoperating with the public chains. And so, yes, there's definitely a future with more chains, but for the first year or two, it's gonna be chains that are focused around that core chain that provides the bastion of enabling commerce in this model.

Anna Rose (00:57:21):
Back at Cosmoverse in the Billy from Interchain foundation kind of went up and he talked a little bit about these interchain security levels and layers. He had these versions of different levels of interchange security, and that is sort of like sharing validator sets or like sharing the security of a validator set with some of the zones. And I do wonder, like in your model, do you actually, the way you just described it, it's like new validator sets for every single chain. Do you actually envision potentially a model where you have some sort of shared security where each, and I know this gets maybe back in the shard mode, but it's like each chain would be, be actually tapping into a single validator set.

Dean Tribble (00:58:05):
So there is a broad spectrum there. The nice thing, not just at the Agoric level, but actually in general, the Cosmos level is it's largely agnostic to the execution, which means you can change that and evolve that landscape of how the validation happens over time without changing the fundamental architecture of what problem you're solving with a given chain. So, you know, right now we share validators in some important way with Cosmo and Osmosis and Secret and all those things because, you know, Figment, Chorus 1, PDP validator, Iclusion, all of those validators are validated on multiple networks.

Anna Rose (00:58:42):
ZK validator too.

Dean Tribble (00:58:44):
Yep, yep, yep. ZK you wait, what's the name of your validator?

Anna Rose (00:58:47):
ZK validator.

Dean Tribble (00:58:48):
Okay, good. Validator multiple networks, which means, you know, not only are we getting staking security, but they actually have reputational security that extends beyond the Agoric chain where if they screw us over, people on other chains are gonna know and they will lose stake as a result. And, you know, and they will lose faith in the larger extended, equal, you know? And so that's a level of sharing in the scenario where we are making additional Agoric, chains that might have the same validators just means that you at, at ZK Validator would be running one machine for Agoric one and a different machine for Agoric two, you know, and you'd use the same processes and practices. But they would be largely independent chains ex from the point of view of validators, but they would look the same from the, you know, they would look like a smooth asynchronous single platform of computation from the point of view of smart contracts and clients using the, this, this extended system.

Dean Tribble (00:59:39):
And it's just every new sub-net stood up would add, you know, another factor of two or whatever it is in terms of, of performance and scaling. Now the, the kind of thing that, that Billy was talking about is not only can we do that, but what they actually wanna do is share the security of the staking pool. And so, especially where a new zone coming up. And one of the question is if you're starting a new zone, the question is why? Right do you have such scale now that you need to have your own validator set and control your scaling is your model of consensus different so that you need a different consensus engine, right? And some of them, you know, if you're doing proof of location, that's just different than what, what Cosmo's Tendermint gives you is your model of rewards.

Dean Tribble (01:00:26):
And this is what's important for us, the model of rewards and the model of how components interact is different. And so we needed to have that, you know, we, we have DeFi woven in, you know, in JavaScript from the bottom to the top. And so that had to be a different chain. But if what you're doing is rolling out a portfolio in manager, you don't need a different chain. You're much better off focusing on writing your smart contract and running on an existing chain, perhaps until you scale to the point that you need the capacity, right? The problem is for most applications, yes, there, there are scenarios where someone could get their own chain and run in their own capacity. But, but if you're a portfolio manager, there's the advantages in running on the same chain that's running the, the exchanges that you are working with, right.

Dean Tribble (01:01:07):
You know, someone who's doing portfolio management on dexes hard to do that to Uniswap. If you're running over there on some other layer 2, it's possible, and it can even be valuable because of the gas prices. So, you know, Sommelier, and others do that, and that's a particular niche, but you can't solve all the problems by running off chain. And so instead enabling multiple people to run on the Agoric model and then migrate to their own set of machines. That's great. But if you are gonna start up a chain, you know, where you need validation, you've got a different model. You don't necessarily have to have your own validators, you know, in the same way than Polkadot you don't necessarily run on your own set of machines. You can use staking borrowing it from, you know, the deep pool of assets that are on the CosmosHub or at the, at the point they get there on the Agoric. Right. You know, the, the Agoric chain. So you can, you can use the staking from cosmos and just have validators that, that currently validate on cosmos opting to saying, yes, I will run that chain too. So I can be slashed on either chain. And now people investing in me are betting that I will do the right thing already. And I'm sorry, I'm making decisions to, to validate multiple chains. And those stakers are now providing economic security to both chains, without it being a challenge for new chains coming up. And that's pretty cool, right. That will make, you know, I mean, there's already 200 plus zones coming up in the Cosmos ecosystem, crazy, you know, having to run 200 times a hundred new machines. Totally. That seems kind of painful. Right. But, but if I could just extend the couple of machines you're already running while maybe you're running 10 or 20 to cover 200 zones that don't have the same load as the CosmosHub or as Agoric or some of the core, big chains, but can solve some key problem or their, their burst run, correlator, whatever. That's just a huge win from a overall network environment ecosystem scalability point of view.

Anna Rose (01:02:59):
Cool. Do you ever imagine there being rollups on Agoric or do you think it's unnecessary - ZK roll up specifically, like having a ZK and actually this is gonna lead me into a bridge conversation, but at first, first rollups.

Dean Tribble (01:03:16):
Yeah, yeah, yeah. So the answer is a, I'm fine with so yes, we certainly imagine it. We've talked about it. Privacy is important to commerce, right. You know, now we're running transparent blockchains and that's really useful to get stuff started, but, but for a long term future, you just gotta have privacy. I mean, you know, there, there are lots of reasons why businesses want to be able to have some parts of it private, particularly, you know, if I'm paying people, salaries you, or if I'm trying to migrate consulting arrangements, I mean, there's, there's just stuff that's gotta be private. I mean, and even from a regulatory point of view, it's gotta be private. And so if the fastest way to do that is by having ZK rollups that, you know, for certain kinds of things, man, I'm all for it.

Anna Rose (01:03:56):
Like a private ZK rollup, basically. That's what you're thinking. It could almost be like a private it part of the Agoric stack. And cuz there are private zones, but those would require bridging. Here you could maybe have it live in your smart contracts basically like live in your system.

Dean Tribble (01:04:12):
That's right. And, and I expect that the first way we get privacy is exactly IBC bridging, right? I mean that that's, that's actually, that's not a second class citizen. Part of the whole, whole point of doing this is, you know, one of the things that Agoric wants to be able to do is, I mean, we're designed from the ground up to be able to do cross chain smart contract action. So, so, you know, we're, we, we've got a, a bounty shared with Akash, which is a chain for essentially decentralized reselling of cloud execution capacity where a company has, you know, a bunch of cloud capacity in order to do close the business at 5:00 PM. But at 10:00 AM, it's just sitting on its thumb, right? It could be doing, you know, whatever mining or, or rendering or whatever job you want to do where it's only, you know, paying off some of the costs of it, but that's still better than nothing. And so Akash manages all that in a decentralized fashion. But if you wanted to have a spot market or a, a smart contract that was gonna notice that a set of machines had been rescinded and is no longer doing its job and that you wanna automatically schedule a new set of machines to pick up that workload and go on, well, that's a smart contract that could perfectly well run on Agoric, because Akash isn't set up to do that. And, and those smart contracts from Agoric would remote control allocations on Akash would then be responsible with that function. So having a smart contract in Agoric informed or, or orchestrate or manage or work with a, a zero knowledge chain you know, Penumbra or a bridge to Zcash or whatever it is, you know, that's exactly why having an economy of people that are pursuing independent aims that you get synergy from cooperating with.

Dean Tribble (01:05:48):
I mean, that's whole point of an economy. So I'm excited about having a various futures. We've talked about, about getting zero knowledge technology into Agoric, but that's not gonna stop from working well with, you know, and, and working to help enable IBC connectivity to chains that, that are taking advantage of the tech that technology earlier. Yeah. And so off chain trading, if you're doing it, you know, scalable off chain dex, just a mix so that, you know, people can use shielded pools. I mean, if you've got, you know, Z cash pools and we can bridge, you know, you take your money out of a shielded pool in an unshielded pool and then bring it across to Agoric and buy an NFT or uses collateral to get run and buy an NFT. Yes. We can see that user 47 got that NFT, but we have no idea who out of Zcash is user 47 or who out of some other, you know, zero knowledge platform as user 47. So now they've got a pseudonym to, to be able to participate in these otherwise transparent markets. That's a big step forward for privacy.

Anna Rose (01:06:45):
I wanna go back quickly to the Run token, the run kind of stable coin. This is this multi asset stable coin. I wonder like one of the questions and sort of concerns at times about out the like fully permissionless IBC model is that you could have a say you have a totally corrupted zone and it's creating crazy, crazy tokens that don't exist. And it's like just not following its own logic and it's out in the world. Could that being included in a multi, like if it's used as collateral, does it that hurt you? How are you actually like dealing with yeah. Incoming tokens?

Dean Tribble (01:07:24):
That's a great question. So first off the set of a allowed collateral is determined by governance. Our, our expectation is we will have an economic committee mostly not Agoric folk, but you know, people that, that do financial governance and understand risk modeling and all that sort of stuff that will participate in that we're working. We've got some other things in the works that I can't talk about to be able to do good risk modeling in a way that's transparent and, and, and visible to folks. So we expect that, that the collateral types that the community will support are the ones that are robust, but for each of those, you then have the risk modeling to go, you know, what's the right level of over collateralization, what's the right debt limit. So, you know, oh, here's a brand new token. They seem good. You know, they've got good security analysis, they've got a good economic model, but it's new.

Dean Tribble (01:08:14):
You know, that debt limit is 10 million where there's, you know, 500 million in Run. So our exposure is, you know, 5%. Is that what that is? No less than that, right? Let me design your software. Don't let me do your books. You know, so, so the way you bound that risk is with those built in governance parameters and, and to adjust over time, the risk of exposure. And then part of the whole run strategy is there are stability pools that are positioned to cover defaults. So if you did have, you know, a horrible spiral, like, you know we were relying on, you know, USTC and the us go came in and did bad things to them. And suddenly you couldn't rely on it anymore. Then, you know, there would be bounded exposure and, and the price falls, you know, you start doing some liquidation and, and if it liquidates too fast, so that vaults are underwater, then the default engine covers it.

Dean Tribble (01:09:11):
Worst case the bank is the one thing off authorized. You know, the, the, the vault system is the one thing that is sort of philosophically authorized to mint, more built token and sell it to cover defaults. So the chain is the bastion of the underlying Run protocol. So Run protocol is, is, was designed for enabling the growth of a large economy on the go platform. So it's exciting that there's such few huge demand for it in the interchange ecosystem. And as I said, the way that gets managed and the way that the community is able to grow that collateral basis by the community carefully, considering those risks and bounding them with appropriate economic metrics. And so even though it's easy to think about, oh my God, some chain could go rogue back to that shared validator thing. Most those chains are, you know, analyzed, looked at supported by validators that have skin in a lot of games. And part of their job is to, you know, help support that stuff. So if, if it starts to go, you know down in flames, you know, the, the, the, the immediate knowledge about that comes from the people operating the network and those validators, a lot of them are the ones that are really excited about Run because suddenly it will enable so much more interchange, commerce and interchange economy that they're some of the people that are most excited about the Run protocol. And so, you know, so this is gonna be an ecosystem thing, you know, a broad ecosystem thing. And everyone's gonna care about getting that right.

Anna Rose (01:10:38):
Cool. I have one last question, Dean, and then we're gonna wrap, thanks so much, by the way, for this amazing journey. The last question is actually about bridging kind of plays on what you just described. What we didn't talk about was like, you know, we talked a lot about the Solidity programming language, but we didn't really talk about the movement of things from a Solidity environment or EVM environment over to an Agoric environment and bridging maybe not only IBC, I know you're deep in the IBC build, but like, what are you thinking around bridges? Are you planning on having other bridges like clients live on your chain? Are you working with anybody?

Dean Tribble (01:11:13):
Yes. So IBC was inspired by our vision of, you know, independent systems connected in with, with interoperability protocols. We are very excited about all the interoperability protocol work that's happening and very supportive of lots of different of these bridge technologies. So our plan is lots of people in the Cosmos ecosystem are working on various different kinds of bridges. Lots of people in other ecosystems are working on bridging to Cosmos. All it takes is one of those to work. And then we get bridged to Ethereum assets. So Gravity Dex, Axelar, Thor chain, Sommelier you know um Wormhole we've talked to all of them. We actually have things to offer to all of them. And so we're looking at various kinds of, of partnering to get nice tight bridges with the Agoric platform, because it will provide, you know, Agoric will be the fastest place to be able to do a new kind of asset, because you can write in JavaScript and roll it out and send it over any of these bridges. We have a, a bridge technology agnostic layer in JavaScript. So it just looks like, you know, here's a person, let me hand it to you. And the fact that that goes over the wire to another chain through, you know, whether it's Wormhole or over Gravity Bridge to ETH, you know, those are all fine. Cool. So yeah, we're very supportive of all those. We we're, we're agnostic to them modular. We wanna manage the security, we wanna limit this security. So back to the, you know, how, how much are you willing to risk on Solana? Well, that's partly a you know, bringing Solana over some bridge. Well that's how much do you tRust the bridge and how much do you trust the, the Solana consensus algorithm?

Anna Rose (01:12:51):
All right, Dean. I wanna say a big, thank you. Thanks so much for coming on the show. It's been a long time since you were on this show, so yeah, it's cool to have you back.

Dean Tribble (01:13:01):
I'm so happy to be back. Thank you for having me and, and we'll have to talk after Run protocol launch because then you can talk about all the other things we get to do with it.

Anna Rose (01:13:08):
Thank you very much. So, okay. Thanks so much again, Dean. And I wanna say thank you to the podcast editor Henrik, the podcast producer, Tanya, and to our listeners. Thanks for listening.