Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Tim Galebach: Uqbar – Smart Contracts on Urbit

Episode Date: April 14, 2023

Building a truly decentralised, peer-to-peer network, based on a built-in identity system, limits the ecosystem’s interoperability with the outside world. Onboarding developers and users to Urbit was only the first hurdle. On-ramping crypto was a whole different & daunting task. Uqbar set out to build an execution layer on top of Urbit, enabling smart contracts, which would ultimately settle, via a ZK rollup, on Starknet.We were joined by Tim Galebach, founder of Uqbar, to discuss the different design choices involved, from Hoon programming DevEx to a hybrid ZK-optimistic rollup.Topics covered in this episode:Tim’s backgroundUrbit explainedHow Uqbar took shapeIntegrating crypto in the Urbit stackHoon’s usability and DevExAI-enabled UqbarUqbar interoperabilityRollup vs. L1 approach for UqbarHybrid ZK-optimistic rollupGetting from programming in Hoon to ZK proofsUse cases for Uqbar & UrbitEpisode links: Tim Galebach on TwitterUqbar on TwitterUrbit on TwitterUqbarThis episode is hosted by Brian Fabian Crain & Meher Roy. Show notes and listening options: epicenter.tv/491

This is Epicenter, episode 491, with guest Timlock Miptef from Uqbar. Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Brian and I'm here today with Meher and Roy. And today we're going to speak with Timlock Miptef, who is the founder of Uqbar. Uqbar is a ZK. roll-up, an Ethereum ZK roll-up that's built on orbit. And, you know, probably a lot of people are going to be like, what that? hell. So we're going to like uncover all that and you know get to the bottom and hopefully you'll come away with an understanding of what all of us up to it, which is pretty exciting. So thanks

so much for joining us, Tim Luck. Yeah, it's great to be here. Thanks for having me, guys. Cool. Well, maybe she'll also make a brief disclaimer here. So Meher and I, of course, are the co-founders of course won and we have invested in a lot of Akbar and also personally and have been sort of involved in partnership with them as well. So when I mention that. Not that much though. A little bit, a little bit. You get just a minor, minor disclaimer.

All right. So let's get into it. I'm actually one thing I'm curious about is did you first get involved in crypto or in orbit? And what was sort of this journey that you had into this? into this world. Okay. So the answer, it's actually like a better question even than it sounds, because I think the answer is first into crypto for sure. So I was like one of the people who bought Bitcoin near the top in 2013 at the end and was like sort of into it, sort of around.

And like I remember actually in 2016 getting back in and like investing in it then and actually listening to Epicenter at the time. I remember taking like random walks around. I think it was in Estonia or something, a small town. Listening to Epicenter trying to sort of of boot myself back up on where crypto was at then. And as that year went and through like the I CO boom, I was like programming in solidity doing a lot of stuff there. And I think I actually remember encountering Erbit then, sort of looking it over and doing the thing that I sometimes do, which is something I try to stop myself from doing, which is sort of dismissing it too fast for a simple reason or dismissing things too fast for a simple reason. So I looked at it and I was like,

oh, this is cool. I see what they're trying to do in terms of having this, you know, global peer-to-peer network that can coordinate easily. But I can probably just do that with Ethereum. Like, I think this was at a time before, like in 2018, if you remember, Ethereum just had all these scaling issues that were unanticipated, like with plasma and stuff like that. And people ran into a lot of challenges there. And, but in 2016, 2017, it was like, okay, probably we'll figure this out. This will be great. I think also at the time, the challenges of kind of stitching together peer-to-peer apps with lots of pieces weren't known. So with all that, I was like, I get what Erbett's going for, but, you know, I think Ethereum is

new. It's like seems to be on track to solve those things. If not it, some other similar like blockchain system. And so I basically just put Erbett to the side to then and did not look at it again until I think it was late 2019. Must have been October or so. Okay, cool. And then you joined, and then you joined Clon as well.

Like, what's the story of how you ended up? at Tlawn. Yeah. So I got back into Erbit or checked it out again, not even back in. I wasn't in at first in late 2019 because one of my friends who was friends with Robness Rickfer, one of the main core developers at Tlaan was like, oh yeah, I'm hanging out with, you know, Ted, Robness Rickfer. He's really into Erbit and doing it, but I think it's stupid and it's not going to work.

So then I checked it out again at that point just to see where it was. I had more free time. And I was just like an outside community member. I started, I got really into it in. May 2020 during like the COVID stuff when I had a lot of free time. I started first figuring out how their sort of assembly language knock worked, wrote a tutorial about that, then decided like, okay, I want to write a tutorial for how to just write programs on the system in general because there wasn't anything like that. So did that on my own as a community member. At this time,

there were probably like four or five community programmers who weren't working for Tlawn in Erbit. It was very small. I kept doing that over the summer. than coin wallet in late 2020, mid-2020, something like that. And after I sort of finished up with that in the beginning of 2021, I joined what became the Erbit Foundation. So it wasn't exactly Tlawn. I was working for like Josh, who's now the head of the Erbit Foundation, kind of was like, do you want to come with me and sort of be, I guess, more or less technical director of this

new foundation where you sort of, you know, figure out things in the ecosystem. like help people on board, show them how to program it, figure out what kind of technical resources to make. And so I did that for most of 2021. And I think the biggest sort of achievement of that time was like up until then all the people who knew how to write Erbit practically or most of them were working for Tlawn. And it was very much like in order to program Erbit, you had to become a Tlawn employee or very closely affiliated and kind of be taught the secrets. And I think what we did successfully is we were able to. to kind of prove the hypothesis that you could onboard programmers to Erbett fairly straightforwardly, and there wasn't anything overly complex about it, which people definitely worried about before then. So yeah, I never worked for TLAN, but I guess at that time the foundation and Toulon were so close

and the foundation was just splitting off that, you know, I may as well have. I was on like their, you know, all hands calls and things like that. But we were very much trying to make this like outside thing that would be able to successfully onboard people without them needing to go and work for Tlaan. And I think, looking back, it's just a very proud achievement. It worked. Like, you know, the foundation became its own thing soon after I left. People keep learning it. There's way more, you know, when I started, there were a few, like five, urban programmers not in Tlawn. Now there's probably a couple hundred. So yeah, that was what I did. And I was, yeah, pretty happy with how it all went, like more so than most things go in life.

You know, so we've done a few podcasts about Erbit. We did the podcast, actually a long time ago in 2017, I think. Meher and I did the podcast with Galen, which is sort of how we, you know, learn about orbit and got kind of involved a little bit. And then more recently, we did one, I did one with Josh that you just mentioned, who's the executive director of the Erbit Foundation, and then also did one with TILA a toll boss and with who you mentioned, Ted, who's the technical director of the foundation. So with that being said, still, most people write in crypto don't really understand Erbit.

They're confused. So how do you explain Erbit? There's kind of two directions that you can come out of from. One is sort of taking Erbit and saying how this has good features for crypto. and how it works well. I actually prefer the other direction, which is you take crypto and you start to say, okay, why do we not have very rich like daps? What's standing between us and there? And what do we wish we had to make better ones? And I think as you do work through that, you almost start to independently invent Erbit, like, you know, Liebniz and Newton, like both doing calculus like on the side. You can actually

sort of reinvent Erbit in this way, which is you say like, okay, we don't have great daps. Why is that? Well, let's look at what kind of DAPs are successful. Definitely, like the biggest successes are things like swapping and lending by far, like AVE, Uniswap, things like that. We could also look at NFT, like trading protocols like OpenC or Blur. And in all these cases, almost all of the interesting action is happening on chain. Like Uniswap is like amazing because they were actually able to take something that people thought had to be done mostly off chain and get it all on chain.

similarly with like the lending protocols and how they handle, you know, liquidations and things like that, which is very, very cool. The thing is in all of this, they're trying not to have heavy off-chain components, which I think if you talk to people in Ethereum and crypto in general, like in like the Cosmos ecosystem, like probably seven, eight years ago, they would have said, you know what? We all know that like blockchains have this limited capacity. So we're expecting going forward that we'll find ways to do lots of action off-chain and then settle the main things on And to some degree, if you even look at the successful L2s, they've done that, where they've been able to do that somewhat.

But in general, for applications, it's very, very hard because the problem at the end of the day is if you want your application to be decentralized, not even for religious reasons or like, you know, privacy reasons, but just for, you know, if you do a centralized service, it's easy to shut down. You can't offer all the features you want. It's harder to iterate on. If you want to do a decentralized app, you now have to distribute this app to all of your users and keep them up to date. in the right versions, handle all this stuff. And if you don't do that or it falls apart at all, it's just kind of gross. And so because that's so hard, I think people thought it's hard like, okay, some whiny engineers need to work harder for three or four months.

But it's hard like stuff takes years or just doesn't happen at all. And so if you want to solve that, when I say that you would sort of reinvent Erbit, you start to think of things like, okay, I need to have some kind of operating system. that I can guarantee or some kind of virtual machine that all of these, you know, spread out peers are running so that at least when I deliver them software, I know they're talking to each other in the right way. They can handle versions changing well. They can get it distributed cleanly. They can know who the other peers are and their networking IDs, not just their like crypto IDs. And you start to go sort of further and further and you end up basically reinventing Erbit, which is a peer-to-peer operating system that's just trying to make it so that you, you can predictably say what all these different nodes in your network are running and how you can deliver software to them. And so I think kind of the proof of that is it took us a while, but as we've built out with Uqbar, this kind of crypto layer on top of orbit, where you can start to like actually realize this and be like, okay, we're, you know, we're having applications,

we're delivering them easily to people. We're letting them compose off chain and then do their high value things on chain. It actually is working, like better. even maybe than we would have thought. So if we kind of step all the way back and say how I would explain it to people, it's that if you actually want to have cool, rich daps that kind of drive the new meta of crypto, like the new narratives that push people in, you need to take a step back and engineer something a lot like a peer-to-peer operating system. So if someone in the last five or six years had built something like Erbit in another language

or in sort of another stack, I actually probably would be looking at it. And we would probably be hedging our bets in Ukbar and, like, developing on that thing as well or making sure we knew it. The thing is no one's like, no one's done it. It's like a daunting project that's hard to do. And at the point where someone starts doing it, I will take it very, very seriously. I just don't think it will happen until Urban and Ukbar prove concept enough that that becomes like economically desirable, like where investors are think, okay, we just saw that work. Now we're going to, you know, throw, we're fine to throw money at you. I'm actually curious if you could take a practical example of what you're saying.

Like let's imagine a DAP that does X and then we put something on the blockchain and be like, okay, what are the constraints that emerge? And why do we need sort of an off-chain operating system? Is that possible? Yeah, absolutely. So I'll take an example that I don't think is super. advanced or exciting or just like the start of what we can do. But when we were playing around in November, December and wanted to be like, okay, what can we show people for what this is doing? We're like, okay, let's make a poker game. And what does that involve practically if you want to

make it peer to peer? You need to have, let's leave aside mental poker for now or some advanced algorithm. Let's say you want to have a server that kind of decides timeouts in the game, who won, etc. You want at least two players who connect to that server. You want them to be able to put money in escrow before each match. And you want it to get paid out appropriately. So suddenly you're looking at all these operations that sound easy, but everything I said there hides a lot of complexity, which is first deploy the server. If you want it to be running all the time, you would have to maybe deploy it to like a cloud service or something like that, configure it, make sure it's running. then have that connect to a blockchain, be able to take events coming in from people who say,

here's like the money that I want to put up and lock it until the end, have like those people read those events. And this is all doable in, you know, a basic Web 3 format. But when you start putting all the pieces together, the friction gets quite bad, both from, okay, this server isn't working. I want to make my own. Let's go deploy that. Oh, now I'm following all these instructions for how to deploy it in the class.

That's actually quite complicated. With Erbit, it's literally like, you know, push a button to say install the hosting software, push another button, and now it's running. And so when we actually had one go down and I wanted to start up another one for our test games, it was actually like remarkably easy and just sort of slots in. Then you go to everything about, you know, we want to deliver updates easily. Erbit lets us handle that to all the peers so they can stay synced. And then we can even start doing, and then even the wallet interactions, where you're like,

okay, I need to send money to the escrow, then have it be detected, have that come back. That's something that you want to have done pretty seamlessly. And by putting it inside orbit, we're able to have that happening all, you know, on our back end, when the action happens, you can spit it out. And the end result at the end of the day is you have something that just works. Now we're expanding that a lot to actually a use case that I think is much more practical and close to home, which is we wrote, we have chat and we're expanding it now to, I guess, something that is, it basically becomes Dow tooling, but in a very full featured way, where you're like, when you say what is a group of people, excuse me, in urban, it's traditionally been, okay, I have one server and that server keeps a list of who's in the group and you do that. But there's no reason that can't be an on-chain entity, that it couldn't be like a Dow or some kind of group that records its various permissions or members or things like that on-chain. The only thing is you have to be able to easily query that.

You have to be able to update it, let all that stuff happen. And we're going to release that pretty soon. But in a format where you can basically say my Dow is an on-chain thing. But all of this off-chain stuff like chat, documents, like blogs, people are sharing, sending money, doing applications that involve assets sort of just works based on the permissions of that Dow. So I think those are some of the concrete examples, but I think the coolest thing about it is that all of them extend very, very easily. And it's almost like all the stuff that is either a sort of a programmer who hasn't done Web3

and thinks stuff should be doable, now it is, stuff that you intuitively think, or as a user, where users will often think this stuff about, okay, I have. all these things, why can't I combine them? Like I have a chain that could store this Dow state. Why can't that also integrate easily with, they would think like, you know, my telegram groups and manage permissions there or do things like that. And now it can. So I think that that's really the main answer is all the, like we can keep giving these concrete examples, but they extend easily. And all the stuff you think you should be able to do kind of naively, you can. So in your personal story, you told about the time when you dismissed Erbit,

and then you revisited Erbit again, work with the Erbit Foundation. And then how did you end up at the idea for Akbar and how did you end up finding the team for it? Yes. So this part is the idea was actually very straightforward. because all of 2021, I was dealing with people coming to Erbit and saying, I want to learn how to build the system and I want to try to do this kind of project. Actually, I was just describing the poker game that we did in Uqbar. That was actually the apprentice project of the guy who's now a lead developer.

He came and was like, okay, I want to see if I can quickly make a poker game on Erbit. And just taking that as an example, what happened is he was able to do it very quickly, handling all those peer aspects I talked about. But, you know, poker is kind of boring without real money. the kind of step that he got to was, how do I have there be real, like, you know, real money in here? And the answer was, you have to do all this kind of gross stuff interopping with, you know, an outside blockchain. And that was not an isolated case. I would say like probably 90% of the projects people did when they came to Erbit sort of spiritually wanted to be crypto projects. They wanted to have, especially because when you're dealing with these like decentralized applications, you very,

very, very often want them to be able to coordinate on some piece of state or have some kind of economically meaningful thing, update, something like that. And so people over and over again wanted that. And the answer was always, you could do it, but we've kind of sold you on this, like, amazing operating system that integrates everything inside it, except for crypto. That's not like integrated. You have to kind of go through this sort of gross process all over again. And so it became very, very clear that Erbit needed a, also like an integrated crypto system. And the question was, I think it was obviously desirable. There were questions over how to achieve it. But we basically started the project by finding everyone in Erbit who was interested in that idea and was good at stuff

and saying, you know, we probably have a job for you if we can, you know, raise money against this idea. And because I think a lot of the people who were in Erbit at the time got that, it was this very almost like funding of early ETH thing where a lot of people sort of saw the desirability of this were in like a community and decided to you know get in on it. And so we were able to fund it based on them sort of understanding urban and what it would need. And then there were a number of people around. We hired like, I'm trying to think how many on our team like most of our dev team is people who I was working with as like sort of new programmers to Erbett during that year or who I onboard it. And same with people on our like business team where people who got interested in it

from other, you know, from the like something is going on here and I want to be in on the community aspect. So and then we had some really great people who had been heavily involved like working at Tuan like Tachrite Sokripe like Logan Allen who worked with us like part time to onboard all of our people and kind of get them really up to speed in writing who. in writing Erbit programs. He did a great job and has since gone on to sort of take the crypto side and that side even farther by starting a ZK-oriented Erbit company that's doing really well. I'm Zorp.

And yeah, it was just this like, I think we kind of collected everyone who was talented, interested in crypto, just getting into Erbit and wanted to sort of be in on that. And at that point, we were like, okay, we have some team. We have some money. now we sort of have to figure out how all this will work. And that was sort of its own. We've gone through a lot of different sort of changes and ideas since it started. Well, let's get a little bit into the details here, right?

So because you're basically saying like, okay, in Erbite, right, you have a lot of things that are just part of the stack, right? So you have, you know, identity messaging. A lot of things are just like in their software distribution. And I was saying, okay, the goal of work for making crypto part of the stack as well. Like, what does it mean? Because in the end, right, these other things are actually part of the core orbit, like, operating system. Whereas Uqbar is something that's building on top.

So what does it mean to sort of, you know, make crypto. It's like, yeah, this part of the orbit stack where there's like fundamental primitive that's like easily available for people building urban applications. I've thought about that a lot because you definitely ask yourself while you're doing a project, like, is what I'm doing necessary? Is definitely a big thing? And so when I was giving the stories earlier about people wanting crypto in their apps, but not having it, that was sort of to motivate that. But practically, how you make it a part of it is you make sure that everything Uqbar does as a chain.

And I'll explain this in sort of high level technical where it's easy to understand. but just even without technical to start. Everything it does is like erbit native. So let's say you have a, I think most people in your audience would be familiar with like L2 sequencers. So you have this machine sitting there that's taking transactions

and then settles them with whatever chain it's, let's say, rolling up to, right? So Uqbar has a sequencer. We have it set up actually so you can have multiple sequencers. It's actually pretty similar to, you know, how Arbitrum has proposed doing multiple, you know, multiple chains that interrupt. So it has its sequencer.

And that sequencer has to interact with Ethereum but no one else inside the urban network has to interact with Ethereum. Everything that that sequencer does is like, you know, an airlock that's sealed off tight. And you can send it in and all the interactions you do with it sort of produce urban native data, urban native events that are easy for orbit programs to handle. So that doesn't mean that we're exclusive, like someone else could go and make something like Uqbar. So we're not exclusive in the way that's something in the kernel. You can actually imagine a version of Erbit where they basically built Uqbar as like a core part of the operating system.

I don't think that would be the best design because you may as well, there's no technical reason for it. And so you may as well compete on that layer. But we do have to compete with anyone who wants to do the exact same thing as us in their own thing, although we do have like, you know, business licensing on the code so they wouldn't be able to just copy us in most cases. They could try to make a really good layer for calling out to like, you know, Ethereum or Cosmos or Ethelayer 2s or something like that. They absolutely could do that. It's hard. It's like a lot of engineering.

So I think what makes us crypto on orbit is that we're the only people who are doing it particularly seriously right now and who have anything remotely well engineered there. And we're also doing all the engineering such that from a developer's perspective, you don't have to think about how it interacts with like, let's say, like, Ethereum. or anything like that. Everything is like fully contained inside orbit in this model. Right. So basically a developer can write their application, right?

So in, in, in, in orbit there's a programming language called Houn. Right? So it's this sort of the main development language, is this functional language. So and you can build your urban application in Hune. And so basically where you guys are then offering is that as I'm writing this application, I can write some sort of smart contract logic, in that application in HUN and then it will sort of like, you know, can like create a transaction.

It can, you know, and it will send that transaction to the sequencer, which is again, just a orbit, it's just on orbit, right? So just sending a message to basically a particular ship on orbit. An orbit note. An orbit note. Yeah. And then that orbit node kind of sequences it and in the end it settles to Ethereum. so you have sort of the security of Ethereum. And at the same time, yeah, you can kind of access that smart contact functionality

from within normal urban app. That's right. And we could get more into the orbit app side because there is this question of why are you doing all this work so that you can, let's say, write smart contracts and HUN and integrate them with urban apps. Like what's the win there? I think we've sort of touched on that. But that's another big part of the story where I guess the way I would say it is right now when you develop, let's say, Ethereum contracts or EVM in general, you use something like Hard Hat or something like that.

And you get this full environment that lets you do all this testing and stuff for your on-chain application. So we talked like, you know, maybe 20 minutes ago about how for just on-chain stuff, the current paradigm works pretty well. You can make some pretty cool apps that work that work well. And I guess the one way you can think about what we're doing is trying to extend that feeling of being inside, you know, Hard Hat or the found, what's the Rust one? Like foundry, like something like that. And extending that to your entire application so that when you want to test your, you know, full application and say it's getting, you know, events coming in from other peers or starting them up, having the blockchain events coming into is also part of that. So really trying to unify everything into this whole. And we wouldn't be able to do that if we weren't writing it.

it, you know, as one urban application. If you didn't have that, if it was just the Ucbar chain and then you were writing with all in JavaScript or something, that would be very hard. And if it was just urban apps and you had to interface with them in like, you know, native EVM form, that would also be very hard. And the reason we know that's hard is that urban people have wanted to do this for a while and like, they haven't. And blockchain people have wanted these kind of, you know, very rich apps for a while and also have had a very hard time doing them. Whereas we're starting to find this intersection to be like a lot easier and sort of, you know, more fun to write. Let me dig into this a little bit. So our story starts off with kind of just observing that,

for example, if we wanted a poker, poker app, the hard thing about building a poker app on Ethereum is, well, if financial logic, there's a natural house for that financial logic, but poker also requires It's a game of incomplete information. I need to have some secrets from you. And secrets are not naturally supported on the blockchain. So I need something with privacy and lacking. And what might be something with privacy? Well, you might say that, OK, the user's browser is something

that has privacy. So we could have the application run on two users' browsers. and then they settle on Ethereum. Maybe somebody could imagine something like that. Yeah, I think even, you know, Virtue Poker or True Poker, we're pretty much doing things like this. Like, I don't want the people in our audience to scream at us. Like, I know what mental poker is.

You absolutely, there are ways to solve it. I think Mayer's point is more about the logistics. Yeah. Yeah. But of course, like, when you start to do that, you come to the realization that you are almost trying to use the browser as kind of like a computer, right? You're trying to do your networking between users, between two browsers.

And then what if you had a persistent, long-lived computer rather than a browser to represent the user? And that's kind of that's kind of, orbits jump. In fact, if we go back to the beginning of the discussion where we said you almost independently reinvent urbit, you're about like, you know, 10% of the way to reinventing Erbit already because you start to say, yeah, this would be great.

Okay, I'm going to put like, you know, the applications living in my user's browser. Okay, now they need ways to talk to each other. Okay, we'll make like, you know, a stack for that. They also need to be able to know like the identity of the other one and like encrypted and make sure they're doing that. Man, my app also might have some like software updates over time. Like I better make sure they're running the same version of the operating system. And what you do is, I'm not saying this in a bad way.

you actually absolutely could make sort of a version of something like Erbit or an OS that lived in browsers. This is basically what people want to do with Wasam. It's just that no one's done it. And so like Erbit is the only thing out there that is in a form that can be used. But you're absolutely right that you start to go down this road of needing to maintain the software, deploy it somewhere, have places that can talk to to to handle identity, networking between the things. And that's all the stuff that Erbit is giving us for free. And then what we need to make sure we can do is in that model,

also have it be as clean as possible for those, let's say, in browser programs, to talk to the blockchain and do that cleanly. Because right now, Erbit is the sort of sealed off thing where it can do all of that stuff and solve all those problems, but it doesn't have, like, without Uqbar particularly clean ways to talk to the blockchain. And so that's been a barrier for, you know, on the Erbitt side, it's been logistically difficult to develop those kinds of programs. Yeah.

And then now the next step you're taking is really that the development environment that works to develop applications in natively in orbit should be the same as the development environment that you use to build your smart contracts running on a blockchain on urban like that's the that's the that's the unification you're trying to do because in the end what you want is for the developer to to have very little difference between something that is on blockchain and like something that is that is that is exactly and we can even go further which is in terms of what we're developing internally which is we we want the blockchain to be inside orbit we want the program to be an urban native program and we even want the testing and orchestration of those like let's say if you're testing and you want to you're testing a poker game you need to have three or four different fake peers running fake nodes running to test it and keep doing them. We also want to get that running inside orbit. So right now it's run, if you're actually building an urban program, the way it looks is maybe you fire up four different terminal windows,

and each of them is one of your nodes, you know, your sort of fake nodes that you're testing with, and you have to cut and paste commands into them to get them into the right states as you develop it. And so one insight we had, which is not unique to us. Taun had started some work on this a while, but never took it that far, was what if we put all of that inside orbit? What if we have in, you know, an erbit program that can create four or five, whatever, different erbit like nodes and an urban blockchain, an hookbar blockchain inside, and run, you know, sort of run all this stuff and let you sort of automate that app development process. So again, it actually feels very much like, you know, for any of our EVM developers here, if you use something like hard hat, where you fire

up a local node and run stuff against it and then reset it, it feels like that, but for everything in your application, where you're almost simulating this, you know, galaxy, of different peers who you put into whatever states you want and run through a program. And then the next obvious step after that that we've just started to look into is sort of further powering that up at the next level, will be to like, you know, integrate like AI assistance with it is like a very obvious next step because the thing we haven't, that you haven't asked me yet is, but isn't sort of who and weird and how will you get developers to use it? And so there are some answers to that even without that.

but we're seeing some really promising avenues with training like LLMs to know, basically to know Houn better and kind of let people do it the lazy way rather than having to take this sort of religious journey into a new programming language. Okay, great. Exactly. I wanted to ask about that question, right? So because HUN is something that when people see it first, it looks really weird. It doesn't look like any other programming language.

So a lot of people, you know, including let's say a course one, right? But basically, uh, Houn looks like very strange. And, uh, for people, one of the most common objections, you know, we get is like people see that and it's like, well, people are not going to want to learn this thing, right? So you really have to do something that's more close to programming languages that developers already know. Uh, that's the only way to get like mainstream adoption and get like, you know, hundreds of thousands of developers building on it.

And of course, you have like solidity, which is kind of like JavaScript similar. And so that's a very common objection. And then of course, you have a lot of people in orbit that are like, no, who's the way? And like once you learn it, there's no going back. And it is the one, you know, the one true thing. Even if in orbit, right, there's a little bit of like division

where you had like, I guess the project, Holium, right? There's now been trying to get more like JavaScript into orbit. So what's, was your, thought on on hun and sort of its suitability for application development, mainstream adoption, and smart contract development. Okay. So we can use the stuff we've talked about already to kind of frame this. So first of all, I'm kind of an urban atheist. I'm not religious about it. I'm doing this in a very sort of 20th century empirical scientific sense where I'm using it because it has specific properties that I want. And if there's principles, I sort of like them because they

help me develop better. I'm not, you know, religiously, intellectually, intellectually married to like having to have weird characters on the screen. That doesn't, you know, it's like sort of, it's a fun thing, but it doesn't matter to me that much. So if we start out, like, why are we using Hoon? The first reason is that, like, practically right now, that's the only way to get access to the urban operating system. And as we said earlier, the urban operating system is the only thing that has these properties that we need in order to cleanly build these systems. But then, as Brian said, that leads into the next question of, okay, you can have all your reasons, but will people use it?

So I think there's two angles to come here from that are very, like we have a lot of empirical evidence as to how this goes. So the first angle we can go from is have people become more likely to learn Houn over time? And as I said, I think people don't really appreciate this. who are in Erbit, because a lot of them either have come in the last two years or when they were there earlier, sort of weren't directly involved with education. But I can tell you for a fact that if we were talking about June 2020, I would have long conversations with people.

And the subject of those conversations was, is it possible to teach normal developers to use Hune or is it just too hard and too weird? And my hypothesis was it's not too hard as just being taught badly. And some people thought it was sort of, you know, too hard and they had to go through the secret, like, cult, like, initiation to want to in the first place. And the, it's not too hard people have won hands down convincingly. So we now have, like, you know, when the foundation runs people through Hoon School, there'll be like 100 to 200 people doing that, a pop. There's way more, you know, Hoon repos on GitHub than there were. There's far more Hoon programmers, like, than there were.

There's not even enough jobs for them, like, necessarily. There's probably not as many companies. there are them. And the biggest issue people have now is like, I think because it's missing stuff like crypto, it's almost like, okay, what do they build once they have this? So that's one angle is that I think Houn is not particularly hard to learn, but you are correct that it's still a new language and what's the point of learning a new language and you have to convince developers to do it. So I think there's, again, two aspects there. The first one is, if we think about right now for sort of non-EVM L2 stuff or even L1s, there's a couple

projects and they're very, very successful. If we take like obviously like you have Solana, which uses Rust. Now that's already an existing language. They get to onboard people who know that. But then you have Starkner, which has, is probably sort of the most nerd sniping, developer attracting like projects. like, you know, in crypto. It's like very like they get a lot of developers and sort of organic attention and people

wanting to do it, even though the language is way harder than Houn, especially to reason about doesn't look like they've made it some superficial things to make it look different, but it's very hard to think about. And people still use it. And they still will do it because it lets them do something that they want to do. And I think Uqbar is very much in that vein of if we can let you do the types of apps that we think we can, you'll go through. the work of using Houn. That said, so that would have been my answer until about, you know,

March 15th or 20th or something like that. And now because we're living in like the singularity, like GPT4 came out, everyone's on what it can do and can see how this is going to head for other like, you know, LLMs and people have been making a ton of progress in, you know, training non-GPT LLMs and doing like LMA and things like that. And it's very, very obvious that, if we put the work in, we will be able to have computers that make it much, much easier for you to write in Hoon and let you get in, like, sort of have a superficial understanding of it, but be like, do this for me or show me how this is done and things like that. And I think, so we start, basically we start with this thing of, can you learn Hoon? Yes, it's possible to learn whoon.

And it's not particularly hard as languages go. Do you have desire to? We've seen that if there's enough, like, economic reason, there's like, because we're providing enough. applications that you can build that will be there. And then can we make that as easy as possible? And the main worry now is that like, you know, I guess it's interesting. I think actually the main competitor of sort of Bukbar type stuff now is actually super powerful LLMs that let you take all the stuff that Mayer was saying is hard and like gluing together things or putting in their browser and just make it. Like essentially, I think the only way to sort of make that stuff go really well as like maybe maybe even a GI or something like close to it and we can see a path to that now but

you know before the computers kill us all there will be this beautiful moment of being able to use hoon like very very easily and i think we're sort of explicitly targeting like i guess 2024 should be the year and then 2025 will all be dead so it'll be fun though we'll be programming in hoon and rich but then dead soon after so this is one thing i didn't think i was going to this has not actually been on my mind for a while, but I have thought about it a little bit in the past. So the topic of like AI, and if you have like AI becoming like super powerful, to me it feels like because in orbit, you know, you are kind of like owning your own like network identity.

And because you have this sort of like governance structure. Because in urban you have to the Senate, right? Basically, you have a bunch of nodes like 256 notes that make up this galactic Senate. And they are basically like a doll, like a governance council, right? And there's a people who own basically as cryptographic identity and then can make some decisions. So one thought I've had with regards to AI is that this feels like something that could be a pretty resilient structure that like, you know, human beings could keep control off, even in the face of like AI becoming like super powerful. So I'm just curious, like, what are your thoughts of like AI becoming, you know, AGI and those kind of things and like

how that will sort of like interplay with orbit as a as a network and as an alternative to the internet? So there's so many possible futures there that it's hard to catalog them. I think the only thing that's clear now is that absent maybe massive government or self-imposed, like, private restriction, AI is going to get very powerful. I was, and like already, especially in the area of programming, is much more than people thought. So then you sort of play that out. And I think there's like these different futures where, you know, maybe very powerful models are out there, but they're only owned by a few corporations in the U.S.

And so then maybe Erbit plus crypto becomes this platform for people who want to, you know, access powerful AI models outside of that or have them like, you know, interact in that way and run sort of these alternative economies like outside of that. If, you know, AI is restricted heavily, which is very possible in terms of like, you know, size of training runs, like GPUs being restricted in some ways, not at all inconceivable. Well, you know, then I think Erbit has this, and especially Uqbar has this massive role to play where because, if AI is restricted, it's very hard to make all these systems work together. AI enabled Uqbar would be one of the best ways to have a large computer system that does work together, you know, for economic purposes, rich applications, easy for developers to make, all of that stuff. And, you know, then you do have like sort of these weird futures, like where AI gets super powerful, models are out there.

there for everyone. You know, in that, in those cases, I don't even know how, like, if humanity survives, we'd have to, you know, we'd have to see. But I think there's a broad range of outcomes where AI assisted Erbit is very, very powerful for letting people, I guess, like, access the, you know, the products of the products of models to assist their programming and also to, like, make throwaway programs that operate. like in their orbits and orchestrate their stuff related to, you know, crypto applications, things like that, and then possibly things like training.

But it's when there's this much uncertainty, I think the main thing you have to do is make sure that you're, you kind of lean into the power and make sure you can do enough in all of those scenarios. And so I do know like at Uqbar, we're taking this very, very seriously as a kind of bull case for urban in general and especially for like Uqbar with crypto being on orbit. And just trying to make sure that, I guess there's this thing you could do of like making excuses where you're, where you say like where people fall back into sort of urban pure like purity thing

of like, okay, we're urban, we don't use AI. And to me that's, we just, you know, do handcrafted artisanal programming like, you know, ourselves or something, right? To me, that's a lot less interesting than saying we have this really powerful integrated system. The biggest barrier to its adoption was that the programming language is a little bit weird. Now we have machines that can just knock that out for us. And so that's a little bit scary because you're definitely going in the direction of making some very powerful systems. But, you know, I don't think there's sort of any other way to go.

From your description, it feels a lot like the bookbar system can be thought of in the best case, as similar to Apple, right? All of us have this experience that when you bind to the Apple ecosystem, you get one device and then the next device becomes Apple, and then you're kind of trapped into like 10 devices inside the Apple ecosystem. And if God forbid you ever need an Android device and interoperability is going to be really bad. So do you think that that's kind of the future for, when it's successful that if I'm an orbit user and I'm an Upbar user,

I'll have a very good experience when I am interacting with just Upbar, having all my finances there, etc. But if you consider the other cases, which is like a developer that's kind of, I don't know, building on the Cosmos SDK and trying to ship the trying to ship the Cosmos SDK application to a user that is on orbit. That interoperability may be very weak. Okay. All right, because there's a few different cases embedded in your question.

And so we should, like one is, like, sort of, if Uqbar is successful, does it sort of take over lots of computing? And then the other one is if there's stuff outside of Uqbar's exact, settlement system. How does it work in that? And so those are pretty different. Let's start with the second one, which is the Cosmos SDK developer who has, I don't know, maybe like an EVM compatible app or something like that done on it using like their own consensus system, right? I think in that scenario, what happens is because they're only building the consensus portion and the blockchain portion on Cosmos, a world in which Uqbar was very successful would be one in which developers were very

used to developing these urban applications in which users were very used to like installing and using them. And we could try to imagine, but let's imagine that like for whatever reason that developers, Cosmos SDK application has become very popular, like running outside of that. I think it's very likely that someone will, which might even be us, will make a very strong, let's say, EVM compatibility layer where if someone has substantial assets and or like interactions, they need to do with an outside, an outside chain, that they can do it, actually in a similar way to how Uqbar does, which is, you know, you have some kind of like, you know, node reading that chain. You can do read and write or some kind of like graph style indexing through there.

And I think there would be a lot of economic incentive for that to get built. But I do think that it is the case that in that world, unless the double, unless the developer was like deploying something that really needed its own consensus or that was like a legacy application that needed to get deployed there. In that world where Uqbar was that successful, they would probably deploy it on, you know, in Uqbar town. That said, I do think that like sort of already written and audited EVM type code will be with us for a while. And so I would expect at some point there will be some like compatibility layers that make that ingestible in where maybe you're not writing new contracts and deploying them, but you are getting other ones.

Now, the other one, though, you correctly, you know, got our goals, which is, if Uqbar is successful, it will accrue lots of network effects, like sort of Apple style. We try to mostly have, in terms of our economics, have the way that we monetize that most be them, like people transacting on the, like, you know, using the Uqbar chain. and we try to make everything else like very, very open, like the application. So, you know, while I, you know, while becoming Apple would be a great outcome financially,

I think we do have a bit of a different ethos because we have a different way to monetize. And so everything we've done so far in terms of like, you know, chat stuff, the things we're doing with Dow's, social like groupings, things like, like social applications coming out. We've made all that open because the entire goal is just for people to use Uqbar in a way that, And also, you know, I guess to some degree that would also, if we were settling on it, then

flow through to Ethereum somewhat as well. We'd see which assets were used on the thing. But we are trying to build very, very strong network effects in Uqbar and have that be the place where you go and have that also make urban apps, like sort of the go-to apps. And this is why I sort of mentioned the AI angle, because I think without that to assist developers and also to make it easy for, like really easy for users to make these sort of throwaway programs that can just operate on all these, you know, Uqbar-Ur-Urbit APIs in their life, I think it's a little bit, it's harder to imagine that future happening. Obviously, until recently we were trying to make

that future happen. But I think AI really increases the odds that we can, you know, that we can do such a thing. So I've always imagined, right, that the way Erbid would work is that Irbit as a whole would be this sort of like Apple-like system, right? Because you have this fundamental thing like networking, identity stuff that's like unified and everything kind of worked together like that. But then I think what we have seen interestingly is that actually, and I don't, well, so you have like some companies that now have built more of, and I think pursuing more of a philosophy of this kind of like, you know, vertically integrated stack that like all works well.

with each other. And, and, you know, for example, there's a whole bunch of different chat apps on, on Urban Now, and they're like, you know, separate chat apps, right? So if I'm, like, messaging, you know, with you, they mark, right? And then on one app, then it's going and I'm messaging the same username, right? Like you on another app, then it's like on separate conversations. So where do I think that's going or how do I want it to, how do I want it to go? Yeah, I mean, my, actually, I would sort of say that like my impression of Vukbar is much more that is much more trying to be this like thin transaction layer of like, you know, basically covering like the smart contract portion and then sort of, you know, because I think that's the other, that's a little bit the other approach.

Right. You can say like, okay, we're going to try to build like some, some component and then, you know, lots of other people can build and stuff versus like. like building this kind of vertically integrated full stack thing, that ends up being a sort of like walled garden a little bit. Yeah. So we're very uninterested in the walled garden. We very much like that vision of urban as this like open system that a lot of, you know, that a lot of different applications can build on and compose. And one reason we're sort of, we try to make our own programs that maybe look a little bit vertically integrated when we sort of don't see something out there.

that does what we want. So like, we did do our own chat that we use just because there wasn't anything else like that good out there. And I think when we dropped the next version of like where it includes groups like on chain, Dow type structures, I think people will see that. But our goal is not to be like, you know, a vertically integrated chat company. We're mostly just trying to, I think we see this moment in Erbitt's life where a lot of these primitives, protocols haven't been made. And instead of like trying to round people up and make a standard and tell them they all have to follow our standard, we've just been like, okay, let's try to get the best thing out there that we can. If people start using it and we can build on it easily, that's great. We do try to

leave them so that they're very, very open. So actually a great example of this is we have like multiple other projects now building with our chat primitives with some of our social graph and like grouping primitives. and we actually do work to sort of support them and make those happen because it's not, again, it's not really interesting to us to have that be in there. It's just that we think that that base layer of primitives extends beyond just the chain. And we have to do a little bit of work to get other stuff out there, which actually, it makes sense if you think about what we've been saying this whole time, which is that we just want richer DAPs.

If they're not there, we have to show people then. And we're seeing a lot of people get interested specifically. because of things that we've made and then want to build richer Daps and that's mostly what we want. But in the, that's the short term and maybe medium term. In the medium to long term, I want, you know, erbit to be its own kind of walled garden, but for that inside that walled garden to be very, very open and for that to be this like, you know, universal computing system, which isn't, it's not that crazy to think about because everything else is so centralized and hard to build on and compose, which is sort of

another topic we could hit if necessary. Yeah. I mean, the fascinating thing in a way is that you can have both, right? You can have people built like a vault garden type system on orbit, which is going to happen. And then you can have others built kind of open system and everything runs on the same OS. I think the walled gardens,

they'll be under pressure, including the ones that like, you know, the things we're making that are internal. I think at some point, some of them will get popular. they'll become open standards. People will build their own, like, let's say, front ends for accessing, you know, the chat apps that are dominant, those. We're just so early that people in Erbett have tried to do it. Like, for a while it was like this social thing where someone would start building maybe

a new app, like in chat. And people are like, oh, but don't you know, Tuan is making that or this other group is or something like that. And after a while, we're like, this is stupid. We're so early. It's just people like, you know, a couple hundred people fighting over this. Let's just like build it. to let that process happen.

So let's talk about another topic. So it's kind of like another big topic. So you guys decided to build a roll-up. I guess another path would have been to build basically like a sort of layer one orbit chain. What was the reason why you guys decided to go the roll-up path and not to build a L-1? To pump my eathbags.

No, the reason was it lets us, when we understood our core value proposition better, which is about this like being able to enable these very rich applications, better experiences for developers and users, you start wanting to focus everything on that as long as possible. And if we did our own chain with our own consensus, initially, we would have a couple issues right off the bat, which are fine and other chains kind of validly want to do those right off the bat, but for us they weren't as interesting, which is one, you have to build your validator set and get that, you know, get that all going.

And another is that you do have to bridge if you want to get in assets from other ecosystems. And so, which again, it's fine. It's a valid choice. I have, there have been a number of issues with security of that. And there's so there's challenges in doing it. but it's, you know, people do it. And it was just, we didn't want to, if we don't do it as a roll up initially, then we have to spend more money and like take longer because we have to do all that stuff.

We have to set up like things, facilities for bridging. We have to set up, um, and be confident in sort of the game theory and security there. Uh, we have to like build validator sets and figure out like, you know, the economics of that plus like, you know, finding them. And the valid, like, the validator. approach lets us, sorry, the roll-up approach lets us just focus on, okay, let's have this sequencer or a set of sequencers that are running and that we can sort of just keep out of our mind while we're doing it, which has been great the last few months to be able to sort of hold that steady

as we iterate on other things. And I guess also I did have this kind of feeling back in early 2022 that roll-ups were going to get hotter and alt-L-1s were going to lose. some of their premium just for purely sort of technical, uh, economic reasons, which I think is like most, you look at the, you know, the fully diluted valuations of, uh, the top like L2s or things that try to pretend their L2s like Polygon.

Um, you know, they've generally done better than Solana Avax like, you know, Luna, rest in peace. Um, so, yeah. And I think, um, in terms of the base layer and getting that right, I do think like Ethereum is doing really, really good work there. And I don't want to, you know, mess with that for the moment.

Now, of course, there's the moment that will come along in every successful L2's life, like down the road, which is, okay, now you do have a lot of money on here. You are very successful. You very easily could build, you know, a validator set out of, you know, what your token is. Does it make sense for you to keep rolling up to Ethereum? And I think anyone who says they can answer that, like, you know, one way or another right now is lying. And I think we absolutely could see, for example, like, you know, arbitrum or, well, optimism has their own stuff or they probably wouldn't. But like, you could use, Starknet, have that decision down the road and make that in that direction.

We're, it would be a, it would be a nice problem to have to, to think about where I think we would be doing really, really well. and the first goal is just to get maximal like Uqbar and urban adoption without distractions. So I'm actually really happy that the sort of base roll-up architecture has been, I guess, like worked out enough now that it's kind of boring. And there isn't my, you know, I've gone over the various, you know, the literature, seeing what people are doing. And there's nothing very new or interesting in most cases, which is great. It's like somewhat commoditized and we can sort of just go to it slowly while knowing

that'll be there as an option. And then if we're super successful, we can have those discussions down the road as will everyone else who is, you know, very successful with an L2. So in going down the roll-up path, of course, the massive branch point is between optimistic roll-ups, which ensure their security through game theory, and ZK roll-ups, which ensure their security through zero-knowage cryptographic proofs. you've chosen the ZK roll-up path. Sort of. Sort of. Okay. So, yeah, so tell us like what path you have chosen and kind of what are the major technical decisions or business decisions you have taken on that path.

ZK roll-ups, in my opinion, are obviously desirable in the long run because, as you said, you don't have to secure anything with game theory, which gives you a lot more options for things like data availability. It's a lot safer to do various, let's say, like, Validium-type schemes where you're not writing the data to layer one Ethereum or whatever layer one you're doing if you're using ZK. Because now you have like sort of two pieces of game theory to get right there. If you're trying to do an optimistic roll-up that uses validiums, it's very hard and generally it hasn't been done. That said, ZK stuff is advancing very fast.

And if you put too much work into getting it all, all right right now, you can put in a lot of work and then find out that like one year later, you wouldn't have had to put in nearly as much work for the same result. And so you've basically wasted a lot of time and money for something which isn't really our core value proposition, which is, you know, creating this like developer user ecosystem natively on urban. So the best balance we found for that so far is to have a progression that's kind of as rapid as we can make it. So first part of the progression is, you know what? Our value proposition is making this like urban developer user ecosystem.

We'll start our roll up on test net in proof of authority mode. Like we just say this is the state and this was the state transition. Then, but while we're architecting that, it's not like a dumb proof of authority where you just like write this new state and that's it. You also make sure to implement data availability at the same time. And also, you know, the various sort of mechanics and making sure that, you know, deposits and withdrawals work right and can be proven and so that you can switch that to an optimistic mode now if you go to an optimistic mode then you have the question of like do you turn your fraud proofs on like optimism still hasn't done that um our beatram has but with permissioning but optimism

is still proof of authority like just trust me bro but just billions of dollars um which is which is fine i actually get their reasoning which is that their main value proposition is being this thing that can become an optimistic roll-up and that like people trusted enough to be like, it's basically an Ethereum side chain that people like the tooling on. And that's good. It's working for them. The thing we can do next, though, a lot of progress being made on sort of urban-native ZK proofs.

We did that internally in Uqbar. And then some of the guys doing that spun out to form Zorp, which is a separate corporation doing ZK proofs of like knock and hoon code. And their stuff is going really, really well. and we talk to them a lot, work with them closely, and we'll probably be able to jump from, instead of going from proof of authority to optimistic,

it's very likely we'll be able to jump straight to, I guess I would say, optimistic ZK, where it's optimistic, but instead of having a long challenge procedure for resolving a fraud proof, you just submit a ZK proof for the fraud proof. The reason you can do that when ZK might not be ready yet

is that if you're doing a typical ZK rollout, you have to prove every transaction. And so you need some, they need to be fast. If you need to be doing those and like whatever it is, like a second per transaction, a tenth of a second per transaction, proving them fast enough. If you do this optimistic ZK thing, you only need to prove the batch when there's a problem. And so in that case, like if someone flags it and there's a problem, you actually could take like three hours to prove the batch of like, let's say,

100 transactions or 1,000 transactions. And it's totally fine. In fact, it's a lot better from a game theory perspective because you, then only need one on-chain transaction to prove it. So it's very, very likely that when we launch Uqbar on Mainnet, it will probably be proof of authority, but ready to turn immediately to a ZK optimistic system. And then from there, it's literally just a matter of

marching through the optimizations to get regular ZK fast enough, which we're pretty optimistic on, but we're extremely optimistic on optimistic ZK. So this is all very pragmatic, and it's just focused on how fast can we get people interacting with our core value proposition, which is this sort of erbit ecosystem where you're doing stuff on it for real money. And we're probably more limited even by audits than by ZK or optimistic. And so what we'll probably do is that system I was talking about throwing out on Mainnet,

probably early this summer. We'll probably have a deposit limited where it can only take a certain amount of Ether. their ERC 20s, just so that, you know, people don't put in hundreds of millions or billions of dollars of TVL and then something happens and then Gigi Uqbar. I think we'll, you know, try to have it be like, okay, you should be responsibly putting on like, you know, a couple thousand dollars or something or whatever you can afford to lose. But yeah, that's sort of the way that we think about that. And the way to sum it all up is you have the technology and the game theory plus technical

primitives. And you want to make that sort of maximally. accelerate your core value proposition. And so when I see other L2s that are making decisions, like we said with optimism of not enabling fraud proofs yet, I actually don't hate on it at all. And I get exactly what they're doing, which is they can kind of see where things are going. They've also thought of, you know, going from optimistic to optimistic ZK, which makes sense. And they're just trying to like, you know, have that make sure they do have a plan at least in the long run to have it intersect. So, you know, our situation is very similar.

It's just we'll probably get to something secure or maybe faster. minus audits. I have a question here in terms of like the finality. So if this optimistic ZK, if let's say in your example, say, okay, maybe you can take three R. I mean, I guess there's like some time needed for somebody say, hey, there was an issue with this transaction. And then sometime needed for like someone to create the proof and submit it.

And then that is kind of like whatever window you have to. sort of be able to live with that until you have finality? Or like, how do you think of this sort of like, you know, the finality time that guarantees of... So obviously pure ZK is the best because you can just be final once you're on, within whatever the batch time is that you're doing it. For optimistic, people usually have done a week. The reason is that you often have to do multiple challenges, like the way Arbitrum does it, is like a bisection thing where TLDR, you could maybe have to do 15, 30 different transactions

to sort of complete the fraud proof. And so you have to make sure there's enough time not just to find the fraud, but to get through all the transactions in an adversarial environment where someone might be doing the calculation of I'm fine to DOS the Ethereum network with this many transactions and pay this much money because I'll be able to withdraw more than that from the roll up if it gets through in that window. If you have this optimistic ZK, you only need one proof. And so that should reduce the finality window by a decent amount because you don't have to calculate it.

You don't have to worry about them dosing it for like 15 to transactions. You only need one transaction to get through. But off the top of my head, it would probably be more in like the one to three day range for finality on it. but even that would be a little bit of a stopgap while we go to full ZK because I just don't really like the sort of multiple time finality.

That said, within Uqbar, if you're talking about transferring from one Uqbar, like let's call them shard, we call them towns, to another, you can get faster, like as long as you sort of trust that the main thing on chain won't get rolled back, you can let those shards talk to each other pretty rapidly because you don't have to worry about if one gets rolled back,

they all get rolled back. But again, another good reason to get to ZK as soon as possible, but also worth keeping in mind that even if we got there tomorrow and had a full ZK system, we would still have to audit the rest of the system. So it's not sort of worth it to, we're trying to like make everything go together a little bit later in the year, early next year. So we can stitch a few things that you have mentioned together. Earlier in the episode, you talked about how the developer experience of

Upbar and Erbit will be the same or similar, which means people will be able to write smart contracts in Hoon and deploy them to Upbar. And then later you mentioned that eventually you would like Uqbar to be a ZK roll-up and in the short run an optimistic ZK roll-up where if something goes wrong on Uqbar it can be proven on Ethereum that something went wrong. So if you put these two things together, it feels like the essential primitive that you need is for a developer to be able to write a program in Houn and then have that program be executed somewhere and then generate a zero knowledge proof for the results of that program's execution because absent that primitive

uqbar could neither be an optimistic zK roll-up nor be a full zK roll-up in the future so how and this is like a novel challenge right like you have you have the whole language so you You want a program in Houn, you want to execute it somewhere, you need to generate a zero-knowledge proof that the program's execution resulted in this particular result. So how are you solving that problem, that primitive? So specifically, like, just executing the zero-knowledge proofs. You have a transaction in a new bar and you need to do it. Meaning how do you generate the proof and how do you verify the proof and how are you attacking

the problem of building or developing a proof generated? Yeah, the answer is sort of boring, unfortunately, which is for verifying the proof, there's pretty standard stuff that you can roll with whatever system you're using to put it on, to deploy it on Ethereum and have it verify that. For generating the proof, this is where we did a lot of initial feasibility research and then have some of that internally, but Zorp, this other urban company has made such fast progress on specifically proving erbit programs of actually any kind, not just Uqbar transactions, but since Uqbar transactions are Erbit programs, they get those.

And they've made such fast progress on that that we actually can just, we've been, you know, negotiating a deal with them, contingent on them getting it working, which seems, I think we're going to be demoing the first version on today's Wednesday, I guess, on Friday. But literally, you throw in an Erbit program, it spits out a proof. You throw in, you know, a thousand Uqbar transactions. It spits out a proof of those that you can use for this validation. And so while that answer's boring, the implications of it are really interesting, which is that not only will Erbit be this place where you can write these rich applications that interact with the blockchain, there's one other thing that's sort of catnip or nerd snipey to blockchain programmers and people around that, which is the

ability to do easy zero knowledge proofs. And we will likely have the ability to, not just for your on-chain Uqbar transactions, but even stuff that happens off-chain that you want to prove, you know, make these proofs that something was done right. So an example of that off-chain would be, and also you can verify on Uqbar. So we can deploy not just a program on Ethereum that can verify proofs, we can deploy a program on Uqbar that can verify these zero knowledge proofs. And so what that would look like is imagine, I don't know, you have like a game world that someone enters and puts in assets in order to like do fights or something like that. And at the end of it, they just, they need to like run a proof, run a prover on all of the

actions they took and the code that happened and prove they followed the rules of that game world. And then they can, you know, withdraw more assets potentially or lose some, you know, depending on how it went. And I think there's this whole world of verifying computing, completely off-chain stuff that happens, and then using that to trigger on-chain events, but having that be at consumer scale that we're really, really excited about. So there's actually these like, the blockchain aspect is actually maybe the most basic and simple, which is literally we license. You know, I think from them, we probably do some kind of license where it's open for people to use as long as they just use.

it for Uqbar so they don't have the, you know, starkware problem of not being able to access the Provers. But then they have this whole other world of, you know, they can go and, you know, license proving or do proving that lets them do all of these arbitrary off-chain interactions that they can prove on-chain that they followed some set of rules in order to unlock, like, in order to unlock things. And so we're very excited about that. It's definitely something we want to market really heavily as this additional capability of urban programs, but it were sort of just, we didn't know until very recently that it would happen. Basically, the timeline was, it must have been March, maybe 13th, 14th.

We had the conversations with Zorp, where we saw how far stuff was getting and how this would be a thing that we could also offer to Uqbar developers. You know, then we're thinking about that. Then all of the GPT4 stuff hit, and we had to also think about AI at the same time and figure out like that strategy. But I don't want to downplay the ZK side. It's like one of the most interesting things happening on Erbett and like in Uyghbar. And we think that, you know, kind of if you liked Stark what like Starknet, like you'll love,

you'll love this because you can everything you learn in terms of writing Hoon programs or having a computer right for you, you will soon be able to just prove in ZK and it's really wild. And people aren't don't really know about it yet and we'll probably just have to show them in order for them to believe it because it's kind of a wild claim. So in the rest of the ZK ecosystem, there's broadly, broadly like, I'm not talking about Upbar or ZR. There's broadly two approaches to building smart contract capable ZK system. So one approach is that you develop your own virtual machine, which is different from the Ethereum virtual machine, has a different set of instructions. but you architect those instructions in a way that creating zero knowledge proofs is easier,

and then you have some kind of domain-specific language built to utilize that virtual machine. So the most famous example of this approach is Starknet, which virtual machine is different, and then the domain-specific language on top of it is Cairo, which is different from solidity. And then, so that's kind of one approach. And then the second kind of approach is all of these projects that are trying to build a ZKEVM of sort. So this would be polygon, but then there are other projects as well, maybe three or four of them that are trying to build a ZKEVM in which the virtual machine, the instructions of the virtual machine are the same as Ethereum. and you're trying to develop a kind of cruiser that can kind of reuse those instructions and build the proofs. So given that there are these two approaches, and you may just end up buying the technology of Zorb,

what camp do you belong in and what kind of constraints does that imply for the future? We're very obviously in the alt VM like Starknet type approach where we're not making our smart contracts EVM because we have a good reason not to, which is that we want them to be maximally integrated in orbit. So that's that decision sort of already made for us. And then the fact that parties like ZORP are making a lot of progress on proving those native orbit transactions makes everything pretty smooth. In terms of ZK EVM, I think it's important. to just say how I think about the EVM in general, because it's been very successful. It's very widespread. There's a lot of audited code that runs on it for large amounts of money.

And I think about it. It's going to sound negative if I say this, but I mean it in a very positive way. It's a lot like COBOL, where you have like lots of, and Fortran, where you have like a lot of code that runs billions, trillions of dollars that runs on COBOL, still like for banks. they know it works. They use it. It's hard to find people who want to like program on it or do it, but it's, you know, it's there. And that's going to be with us for some amount of time.

And I think that the EVM is very similar. And so I think that steps towards having given that we're going to have EVM code with us for some time managing billions of dollars, whether it's on, you know, Ethereum, Cosmos, obviously Avalanche did that like heavily. But everyone who uses the EVM wants access to those programs. given that we need ZKVMs because this is better than the optimistic setup. And those projects are all making great progress there. And I think it will eventually work.

I think we could see things even like successful or wealthy optimistic projects like optimism or Arbitrum switch to ZK because I think it's getting very commoditized. I would actually expect to see that. Polygons sort of leading the way there in terms of just trying to go directly to that. So for us, like, it's just a different universe. I think the most likely universe if Uqbar wins and if EVM code is still running is that we'll have, we'll probably sponsor or work with some projects to make a clean interface for ingesting EVM data from the most popular L2s or L1s into Erbitt like Uqbar programs. And, you know, then people, you know, if they have some multi-sig with like, you know, tens of millions of dollars that they just for what they want to have on NOSUS, you know, They can do that.

But as far as we go, there's no reason for us to, it would be, it would be a lot more work to make our thing EVM compatible and ZK provable in the EVM. And at the end of it, our payoff would be that people had to write, you know, solidity or similar programs insider, but which we, you know, don't really want it all. So, you know, we want to have our own thing, get maximum adoption for our alt VM settling to Ethereum and then later on do the work to be, you know, be able to ingest and write to EVM contracts on other chains for sure, which I guess also sort of addresses your question from earlier about the poor, you know, Cosmos SDK developer with a popular chain who has his thing. That's sort of

the answer for him is that if it's EVM compatible, we would likely do the work to make it, you know, ingestible from his as long as he used like standard tooling. And so this alt-alt VM that your stack is based on, is it the same alt-vm? as StarQuare or? No, no, no, no. No, that's an erbid, no? It's orbit, yeah. It's just like a normal RVM is an orbit program.

It's like maybe a thousand lines of code. It's not very big. It sits there. It takes in transactions that are orbit data in the normal form. It processes them with an engine written in orbit, and it spits out orbit data on the other end that we can then serialize for posting data availability. on a validity or to Ethereum.

And because of that, that's why we're able to take, like, let's say, a ZK proving solution that wasn't developed for Uppar in particular, like Zorps, which is just for proving Erbit code in general, and say, we have Erbit code, prove this. And it should, you know, should just work. The only, for people who want to get really technical, I don't want to bore your listeners, but Erbett has these things called Jets, which basically, if you have some piece of code, it processes them faster using maybe essentially a foreign function interface. And in those cases, you have to decide on what your set of jets is for the ZK Prover

beforehand and sort of say, I'm proving a transaction assuming the existence of these jets. But I don't want to go too far in there. The basic message is you have, you know, our engine, RVM is just Erbit code. and we prove urban code. When we were using Starkware's products back in the summer, what we were doing was using them to essentially write urban interpreters. So we would write a program in Cairo in Starkware's language that would take in Erbit code and prove and generate proofs

that it was done right according to Erbitt's rules. But cutting out the middleman to some degree and having a more native system for it is probably going to be beneficial. If we had to go back to that, we could. but it's unlikely at this point. Cool. So one question, sort of as we get towards the end, so one question I'm curious about,

when it comes to use cases that you want to see people build and that, like, you know, you're most excited about and that you think would be, you know, the things that will really leverage Uqbar and Erbates capabilities, you know, the best and that are kind of going to be the things that can really, like take off in the next year, two years. Are there particular things you have in mind?

Do you have a sort of list of like things I want to see built? Yes. I want to say that we need to see them develops to like kind of make our imagination go further. But I think everything in the world of social, but social meaning everything like related to, you know, networks where you're posting information. and having stuff come in and communicating with people, Dow's are an example, discords,

everything in there we want to ingest. Everything like then that can, in the social plus like game type world, I think is really interesting. Like, and we're actually talking with some like game projects to onboard them because it's one of the best things that we can provide is this like,

you know, just sort of full crypto, plus social, plus chatting, et cetera, integration into there. I guess one way I would say it is that right now a lot of urban people just for coordinating their development use stuff like gather. town where they can go on and like chat with each other and have like some environments to like go play with. I'd like to see stuff like that, but much, much richer.

I'd like to see things like what people use Twitter, Discord, other social for, but much, much, much richer and Dow-like. in it. The thing that we're not going for as much from the start is the typical thing that people do when they launch a chain, which is try to, you know, copy, like, you know, make some AMM clones and go a lot of liquidity. Yeah. Yeah. Clones and like does it. And we have one guy who's like has clone, like made an AMM just like, you know, for the hell of it. Because like, we can. And it's on there. But we're exactly interested in getting people doing these much more social type. game type applications, seeing how those actually integrate with crypto in like a richer environment.

And then once there's demand for it doing the liquidity type stuff, because I think it's, yeah, it's a thing we want to be doing eventually, but it's not the new interesting thing in crypto. The other way of saying that is that everyone in crypto sort of knows that just doing uniswap clones is kind of a dead end and not very interesting. And we're trying to create, you know, this new, this new meta, like, there's like just much, much richer set of things that you can do. And we don't even know fully what that looks like, but we have, it's also not just a blank slate. So we're like, okay, I wish we had chat so that we can do these things and see where it goes.

Then once we had chat, we're like, oh, now we actually can do basically groups, Dow's, discords, like things like, much more like that with crypto. And then I think we'll see what the next thing is after. But there's some other projects that we're working with that will add those. I think one that we were interested in was like what portal was doing, which was trying to make like a discoverability thing for everything in all the content in orbit. And that has a lot of obvious crypto integrations.

And so I think like in terms of incentivizing people to do stuff for it, you know, limiting things in various ways, letting people collect assets. And so I'm interested to see how that goes. But just in general, I guess the idea of making those applications, but then letting people extend them easily is something we haven't seen a lot since the, I don't know, probably since the late 2000, like Facebook, like Twitter, open API's phase when people could just sort of build whatever applications they want integrated into those and we want to bring that back to some like to some degree.

Cool. Fantastic. Maybe like final question. What's the what did the timelines look like? Where yet right now what are the main milestones coming up? Right now we are in the process of finishing our main engine integrating it with ZK at least for optimistic ZK and doing the basic version of the roll-up. We have a very basic version on TestNet but even need to add stuff like withdrawals. We also, we talked about a little bit about which we call Ziggurat, which was basically the thing that's going to let you pull together all of, you know, developing for lots of urban nodes at once, checking that against the Uphbar chain, doing all of that.

That will be out in users' hands probably later this month or in May and then we'll start iterating it fast based on that. We would like to then go to Mainnet probably in June or July. where you're sort of doing stuff for real money, but deposit limited and start doing, you know, audits of our code around then, having people get familiar, auditors get familiar with our Hoon engine, also the on-chain, the on-chain portion. And as the summer, you know, as the summer goes, we'll be doing more experiments with AI to, like, enable Hoon programming.

But, and in terms of having, like, the actual chain launched with, like, sort of full tools and everything working, that'll be, like, probably the, alpha beta version over the summer. And then as the year goes on and we do audits, we'll get closer to doing stuff like potentially lifting any caps on the amount of deposits, really going after developers very hard, things like that. So I would look for some action if you're sort of really into, if you're into urban development already or want to get into it this spring, like around May. And then the real, you know, hardcore lots of apps are coming out. out and we're moving closer and closer to, you know,

no training wheels over the summer and fall. Cool. That's exciting. Yeah. I mean, I think a lot of things going, yeah, a lot of things going on in Erbit, a lot of things going on in Oak Bar, things moving fast. So I think it's going to be pretty mind-blowing. I think the sort of experience, the user experiences people are going to be able to like enjoy in this world, you know, in sort of, I think, you know, next year, maybe towards the end of this year or some things, but, I think definitely next year it's going to be something where I think a lot of crypto people will go and be like,

that's what I expected it should work like. And that's what I've been kind of waiting for. One thing we say internally, that's it's very much like, Uqbar can make ICOs great again. In the sense of like when people were saying all these things over, you know, 2016, 2017, it was based on this idea that we have this global consensus engine. and we can do all these crazy things with it. And for a variety of reasons, obviously, there were like, you know, the issues with, you know, scams and things like that. But also there were like people who were trying to do ambitious things

and they were just too hard then. And I think they're now finally in reach. And so, you know, ideally we could make another ICU boom happen and everyone will be happy with us. But like, that's kind of the vibe. Perfect. Cool. Well, thanks so much for joining us, Tim Luck.

It was really great to have you on. It was great to talk about Upbar. I'm super excited about the project. and where it's going to go. Yeah, thanks for having me, guys. It's really fun. Great questions. And thanks for the listeners for tuning in.

We're going to be back next week. And have a great week. 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. dot 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 they're 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.