edited by vera, cover image by turbo

For this installment of Devs on Devs, we sat down with alvarius, one of the core developers of MUD, and Dhvani, an engineer on the Tenet team. Tenet is developing an onchain multiplayer simulation environment, loosely based off of OPCraft, which alvarius and other members of the Lattice team released last year. This conversation took place this past summer, when Tenet was experimenting with a multiscale, multiphysics simulator. While the concept has evolved since this conversation was recorded, the ideas around motivations for building an onchain simulation, and anecdotes around the early development of MUD still give deep insights into what will become possible to build onchain.

ALVARIUS: Did you do any Blockchain development before this or was this your first onchain project?

DHVANI: This was the first one.

ALVARIUS: So you learned Solidity with the MUD patterns?

DHVANI: Exactly. We've never stored state in the contract. That's not normal to us. Like, we need a Store and table, because we never used the patterns where you store state in a contract.

ALVARIUS: That's cool. How did you get into programming in the first place?

DHVANI: I started programming, quite early in grade seven or eight using Codecademy. It's a place to learn to code. From there, I was like, “damn, I feel like a wizard. I can do this stuff.” And then, high school was when I really formalized it. I took AP Computer Science, and then I started in Java and then, by grade twelve, I knew I wanted to get a degree that would be coding related, either Computer Science or Engineering. And then ended up picking Engineering.

ALVARIUS: For me, it was later, maybe age 14 or 15. I started with web development, actually. So the reason is a fun side story. I had a crush on a girl. She had her own blog and was doing web design with HTML and CSS. And essentially to impress her I also did web design. And then she ended up with one of my good friends at the time who was a better web designer than me. So that must have been the reason.

DHVANI: How did you get into onchain stuff?

ALVARIUS: That was a long journey. Through very simple app development, this world of programming opened up to me, and then I had a very similar journey as as you just explained, with this feeling of, “well, this is actually the closest thing we have to a superpower.” It does feel kind of like wizardry in a sense. That fascinated me a lot. During high school, I did a bunch of random side projects with friends. We just came up with some random idea, and we just were able to implement it. It was still very web app-focused. The main reason I like the web is because you can build something and then it runs on any device. You can just have this large reach.

DHVANI: Infinite distribution, but, the cost of distribution is almost zero.

ALVARIUS: Exactly. I started studying computer science, and then I started a job as a web developer at a big tech company. I worked there for a year approximately and then decided to go back to university to do a Master's, which is free in Germany. So the main reason I went back to school was because I just didn't wanna go into a corporate job. At that point, I wanted to explore more. I was studying a little bit on the side, but mostly just exploring. And then one of the things that I ended up exploring was ZK Dungeon with ludens. That just was very fascinating to me, and it got me into crypto.

DHVANI: And were you also the game designer?

ALVARIUS: I'm way less of a gamer or game designer. The only two games that I actively played were Minecraft and Battlefield 3. When we were building that first game, the most fascinating thing for me was solving all of those lower level technical problems because it felt like I could basically finally flex my algorithms skills. In web development, you don't really get to do that. So that low level technical stuff was exciting for me, which is then what became MUD basically. The games that I’ve found most interesting are less games and more low level primitives that other people can do stuff with, like Minecraft.

DHVANI: Minecraft is a game engine and a game.

ALVARIUS: I think what I find most interesting is basically emergence. In OPCraft, the little primitives were super simple, the most basic it can get basically. What I've found most exciting was the whole thing that happened on top of it, like the Supreme Leader.

DHVANI: And emergence seems native to this technology.

ALVARIUS: I fully agree. That's the main reason why I find, onchain games and onchain apps exciting. It's this world computer where people can just deploy stuff. People keep asking me why are you building onchain games? Why do you use the blockchain for this? And then if you think about it from first principles, what we actually want to do is build this game or this reality where you have some base physics primitives and then people can interact with them and build stuff on top so we can have emergence. If you want to do that then it needs to run somewhere. So you could put it on the server, but then if you want people to extend it, then you need some kind of environment where people can deploy additional logic to your server. Then you have all these problems with things like permissioning. How do you make sure that the stuff people deploy doesn't write to other areas where they're not supposed to write? And then you have other questions. How do you make sure that there's some form of spam protection? How's the ordering happening? And after solving all those issues you end up with something that's probably very close to a blockchain.

DHVANI: You could just put the EVM on a server. But if somebody owns the server, there's a bound on the people who will participate. And so I think it needs to be neutral. It has to be neutral if you want unbounded participation in the world, and for serious things.

ALVARIUS: Totally agree. Actually, it feels way different when it runs on this neutral distributed network that will be there hopefully forever or at least for a very long time.

DHVANI: I just really like MUD as well because we've had Ethereum for a while. Already have this thing where anyone can deploy anything and anyone can call other contracts. But then if you start adding abstraction on top of it, You add structure that makes it easy for people to write to it.

ALVARIUS: And I mean it's always funny when people ask “what is possible with MUD that wasn't possible before?” MUD is built on the primitives that existed. Everything was possible, but it's just way too low level. And there's way too little abstractions to actually enable scaling.

DHVANI: With normal programming, we aren’t going to write in Assembly. If it's a program where you're thinking about storage slots, you're not gonna be thinking about your app then.

ALVARIUS: And it's great to see the first generation of native MUD development. What are you doing right now?

DHVANI: Tenet is working on this multiscale, multi-physics simulator that anyone can write to and read from. So that’s a lot of words. I’m gonna break it down a bit to give more context. Multiscale: this means that you can have different scales of zooming in and zooming out. Think of the Powers of 10 video, where you start in Chicago and then zoom out to the solar system and then zoom in on a cellular level. In the case of Tenet, you can have electrons on a low level, or you can have something higher up, like circuits, and even higher up, like a machine. Multi-physics just means you can have different properties of physics in the simulation. If you have one set of physics that deals with heat, I can add a different set of physics that deals with fluids and then they both can interact with each other.

What's the point of having a simulator? To speed up the evolution of ideas by letting you figure things out in a virtual world before trying them in the real one. Today on Ethereum, you can really only simulate money. We want to make it possible to simulate anything. And the difference from traditional simulations is that if you create something, you'll know it can be used anywhere. It has the same interface, and we have privacy. So you can have true secrets around inventions, basically.

ALVARIUS: How would you do that? Would it involve ZK?

DHVANI: I think you need ZK for the privacy, because I'm not sure how else you get verifiable computation that's also secret. So you have to use ZK or you might need multi-party computation if you wanna have interesting creations, where if you make something and I make something, we can combine it together.

ALVARIUS: It's very interesting what you said about how we only have the smallest possible programs, basically financial applications. Because it seems like ludens and I started with a similar angle. One of our first principles was to just ignore gas costs. We created a local chain with a one hundred-million gas limit. Which back then was insane because it was way more than any production chain. And removing that limit freed our minds from thinking in those limited terms.

DHVANI: And you also don't get skeuomorphic ideas. Because you'll think of ideas that aren't possible now. That's really cool.

ALVARIUS: Multiscale is the thing I want to ask about. Very interesting. So you zoom in and on the lowest level, it's basically electrons. What can you do on the low level? And then when you zoom out, how is it using the lower level?

DHVANI: Well, if you don't want people to break stuff, what we can have is different scales vertically and and then different scales horizontally. So with the scales, at the electron level, you can define your own behavior at the very bottom of what the electron should do. When you increase the scale, what it means is that you're not defining a new voxel. When you inherit that voxel, it's your child voxel, and now you inherit all of its behavior. And now as a parent, you can make your own behavior, by reading your child voxel, but also by defining your own behavior on how you should move or how you should change types. There are different implementations, but they have a common interface in the sense that (at least in our current design) everything is structured as a cellular automata.

Just to give a quick background, cellular automata have these simple rules around how different grids should respond to each other. You might have heard of Conway’s Game of Life. The ones above are made up of the ones below. So you can read any component or table value on the ones below.

ALVARIUS: So are these electrons the lowest level you can go in in your current version?

DHVANI: We picked electrons because in reality, the lowest level is electrons, roughly speaking.

ALVARIUS: Do I change how an electron works to get different kinds of behavior in the simulation? Or do I just arrange these electrons that are those building blocks basically in different ways and then that changes things?

DHVANI: So if you're not adding new physics and you're just using existing physics, you just need to place electrons down. They would just move based on however the physics are defined. But if you're actually coding the physics, or adding the physics, then you're defining two things. One is, what types am I dealing with? And then defining, every time an event happens, given the current state, what should the new state be?

ALVARIUS: So basically, when you define the physics, you define rules of this cellular automata?

DHVANI: Exactly. And it is stored as a grid with a position table and a type table. And that would tell the client where everything is.

ALVARIUS: In your client, you have a certain number of scales that you can display?

DHVANI: There's no limit on the scales. So if you're at the electrons, you wouldn't be placing 32 by 32 blocks, but something smaller. And if you're at the city level, you're not just in blocks for cities, you just place down cities. And so the client could be improved, but right now, it's just, like, the same grid for all of them and so there's no limit on the number of scales.

ALVARIUS: What's your what's your plan with this?

DHVANI: It's almost been this evolution. We were working on different ideas and then evolved into this one. We want to figure out some sort of content because it's an open world and so it's also a creative world. So what's the incentive to create stuff? We'll need some objective, and we'll test out different ones because in the same sims, we can test out different content and objectives quickly. The second thing is we need this to run on the world computer, some sort of chain. Right now it runs on our anvil node. We also customized gas up to a billion. So we do need to solve that. Those are the things that will be the next area of focus: content and scaling.

ALVARIUS: Do you have ideas for objectives?

DHVANI: With objectives, it seems like we can either go with mini games or an interesting survival world, where there's some sort of limit. You don't have a player position, because if we try to take their position, it gets janky. And so you have to be creative. So we have this one idea of stamina, which solves the problem of not having player position, and creates a form of limit.

ALVARIUS: Yeah. Enforcing position on chain is also something we thought about with an OPCraft back then. Because it was just intended as a simple tech demo, we just decided to not have it at all. Of course, that basically immediately broke the game in the sense that people figured out that they can just mine the diamonds. They knew the exact positions of diamonds because diamond positions were deterministic. It broke the game in some sense, but it also created some interesting dynamics, like the Supreme Leader.

DHVANI: It had all these properties of social emergence. I was talking to GVN yesterday, and he liked the idea of breaking things. Why don't we just take that as a hardcore narrative of the game: things can be broken. The players have the agency to say, “okay let's change the world to a different world.” If a certain scale breaks the game for a certain block, you make it easy for players to fork, and give them the tools to fix it.

To learn more about Lattice and MUD, visit our website, read our documentation, or join our Discord server