# MUD : An Engine for On-Chain Games

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-09
- Duration: 48:15
- Topics: blockchain, smart contracts, distributed ledger, ethereum, Science & Technology
- Watch: https://streameth.org/watch/yt-tLGdup5wmck
- YouTube: https://www.youtube.com/watch?v=tLGdup5wmck

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/mud-an-engine-for-on-chain-games/

For the past year and a half, 0xPARC and Lattice have been hard at work building MUD — an open-source engine for building on-chain games. 
In this talk, Justin and Alvarius from Lattice will be joined by Kelvin Fichter from Optimism, to talk about on-chain games, MUD, and an exciting new collaboration with Optimism to be unveiled on the day.

Speaker(s): Justin Glibert, Alvarius, Kelvin Fichter
Skill level: Advanced
Track: Developer Infrastructure
Keywords: games,evm,on-chain

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

foreign [Music] my name is Justin and along with alvarius and our friend Kelvin from optimism we're going to go over new technologies for ancient gaming so Alvarez and I work on lattice among with many others it's a project that's been out of Zurich spark in others to in order to push the envelope of Unchained gaming we basically want to enable people to build crazy things on top of ethereum um and things like full-on Virtual Worlds worlds whose rules run on the evm and whose state is secured by ethereum people usually refer to those projects as on-chain games but we prefer to call them autonomous worlds because we think it goes well beyond gaming it's about giving autonomy and sovereignty to complex systems so the problem is building large on-chain projects is actually really hard which is why today we're going to go over two new key pieces of Technologies built by lattice and optimism in order to enable autonomous worlds and I'm going to pass it to a various to go over the first one cool so the first key piece of technology that we want to introduce today is Matt mud is an on-chain game engine or how we like to call it an engine for autonomous worlds that we develop here at lattice and when we started working on on-chain games there was no engine to build upon so we had to run through all of these very common very like General problems very non-trivial problems as well but they were common in all the games we were building so we set out to build this key missing piece of infrastructure and build mud with the goal of solving all the hard problems of building on-chain games so what are the hard problems of of building Unchained games well they've Fallen to mainly three categories the first one is how to make sure that your client and your contract state are always in sync and then the next one is how to architect your game in a way that it that makes it easy to add more content later without having to refactor the entire code base and then the third thing if you care about impact Beyond just an individual game then how do you make sure that your game is interoperable with all the other games out there so before I go into how mud solves all of these problems let me quickly go over like the previous common approach of um yeah approaching these challenges usually the the most common approach before was you have one struct per entity type on your contract like if you want to have a monster then you have a monster struct and in that struct you store all the data for that struct for that entity and then of course on the client you have to replicate that like interface in order to represent the state there and then you have getter functions for each individual like type of entity that you want to sync to a client and you implement your logic based on these specific structs and every time you modify one of these data structures you have to emit a custom event that then can be called by the client to then like update the local client state and this is already this sounds already pretty annoying but it gets even more annoying when you want to now add content because now you have to add a new struct and you basically have to edit your entire network stack in order to make it compatible with this this new struct from the event over the getter functions to like the um yeah event handling on the client you have to modify everything and then on the interoperability side basically all you have are existing interfaces like erc20 erc721 Etc which were not built for unchain games and are very limited in what they can express right so our goal with mud is to solve all of these like General problems so that you as game developers launching game developers can just focus on making a fun game all right so this is for the Y and now let's go into the how how does Matt solve these problems um mud is built around an architecture pattern called entity component system this is a very popular pattern in the traditional gaming industry for a reason but if you're not familiar with it I'm gonna give you a brief crash course on ECS in ECS an entity is just a numeric ID so in our case it's just a un256 and then you have components you have components oops you have components that store the data for this entity so in our case we could have a component that stores the data like you can think of it as a as a mapping from The Entity ID to the component value you can think of it as a as a fancy like standard ethereum mapping and then you have the systems which implement the logic so components are only Data Systems implement the logic and systems don't act on specific entity types because there are no specific entity types in ECS but rather an entity is just the collection of components that are attached to it basically and so your move system as an example doesn't care about whether it's moving a donkey or a dog it only cares about whether this entity that it is moving has a position component attached to it and then it can modify that position component and if you think about it that's actually in a way how ethereum already works today you can think of addresses as entities and then a token contract like a year c721 token contract can be thought of as a component and a system mixed together and attached to this entity to this address and if you wanted to model this in like pure ECS then you would just have a balanced component that stores the data and then a transfer system that implements the logic of transferring stuff all right so with ECS in mind how does much handle the state sync in Mata is a very Central contract the world contract and every time you add a contract and every time you add a component which is also a contract it gets registered on the world contract and then every time that component gets updated an event is emitted automatically through the world contract that means the client only has to listen to this one Central stream of events coming from the world contract and can then like keep the local state in sync basically and the great thing is with mud you don't have to worry about any of that because mud handles all of that for you what you do what you have to do as a game developer is just create a component contract um give it some ID and then create a component on the client and give it the same ID and mut handles the state sync automatically and the great thing with this General approach is also that we can provide generic indexes that help your client catch up faster and reduce their RPC load and you don't have to write any like custom sub graphs because all the data is stored in a very generic way um and that's why we can have indexes cool now to the fun part of adding content as a quick reminder in ECS entities are just a collection of components so our fighter entity here is actually just a collection of a health component and attack component and a movable component and now if we want to add more entities or stronger entities like a dragon then we can just modify those component values give it more Health give it more attack and suddenly we have a dragon another way to add more content is to modify or like recombine existing components together for example remove the movable component and suddenly you have a defense tower and the last way of adding Quantum content is adding new components every time you add a new component the number of possibilities of combining your components actually doubles so you can just recombine your components in a new way you have double the amount of entities you can now represent as an example you add a healing component now you can build a healing Shrine A Healer and a healing potion without changing any of the existing logic and then when it comes to interoperability in theory everything that you build on chain is interoperable to everything else already you just have to make like a custom integration for everything which gets obviously kind of annoying and is not scalable so in other words interoperability needs interfaces to scale and you can think of mud as an interface for those Unchained worlds you can read the state from your own world in the exact same way as you can read the state from other worlds so all those words are just by default interoperable with each other and you can think of existing interfaces like erc721 as an interface for ownership but mud on the other hand since every component is a standardized way of storing the data and we have the standardized query system basically mud is an interface for anything like you can just write a query for any world out there and just represent whatever you want basically this query this very simple query gives you all the movable attack entities owned by this address but you can get arbitrarily complex with that so this is how much solves all the problems for building ancient games but the great thing for mud is that it's actually completely genre agnostic we build two different games in-house Atlantis over the last couple of weeks two completely different genres the first one is called skystrive and it's an Unchained RTS the goal is to build your army to defeat your opponents and then steal the loot from the center of the island and then escape the loot as the first person it uses 39 components 20 systems and not a single line of networking code because mud handles all of that for you and we're actually going to play tonight at or not tonight this afternoon at the hacker basement at 4pm so if you want to check it out come there and then the other game we've built is yet to be announced it's an on-chained boxel game it features an infinitely proceededly generated world you can mine you can build stuff you can craft stuff and it only has eight components and seven systems and also here zero networking code and those two games are completely different genres but they build on the exact same infrastructure they just use different components and combine them in a different way yeah and this is much as a summary with mutts you don't have to write a single line of networking code because mud handles all of that for you adding content is completely trivial adding a new component doubles the amount of entities the types of entities you can represent and any mod world is by default interoperable with any other mud world and that is how we solve all the problems cool all right I'm gonna drop some more crazy stuff um full nodes are great so after this like short introduction to mud I want to go over two kind of like Advanced features slash mental model from what mud is so the interesting thing with full nodes is that they give you access to the entire chain directly from the node database um with a node you can do things like oh what is the counterfactual of this can I execute a transaction but slightly change the storage of that contract like what would happen if I were to make a transaction in unit Swap and have a billion die instead of like 10. um the problem is that traditional dap clients today are not full nodes they rely on things like inferior or Alchemy to serve their data and then they have to build this like complex State machine of indexers and events in order to serve the data they need to their users um as an example the uniswap client has to connect to a full node and it has to fetch the state it is interested in just in time because otherwise it would take way too long so as you like move around and uniswap and you like select different polls you have to wait every single time to know what's going on um the I don't know if you've ever read the unicewap client code but it's pretty insane just to be able to keep such a short like a simple State machine in sync and there needs to be like a lot of custom code and indexers additionally the unit swap client cannot actually simulate transactions and it doesn't know what will happen if you like execute that that single Swap so the way it actually works is you have the unit swap client and then remotely you have a full node and you have a bunch of indexers and the universal plan estimate very slow Network requests in order to be able to populate the information that the user needs so why don't we put the full node and indexer inside the client right like that would allow you to make instant queries you would be able to index the chain however you want you don't have Network delays anymore after you're synced and then you can simulate transactions right that would be amazing um and actually for like the ethereum ogs here that's how Mist was working which was the ethereum browser like five years ago but the thing is full nodes are super expensive um they require a lot of bandwidth and storage they have very expensive cryptographic data structures that are needed in order to serve live clients so it's pretty much like it's not really practical today to put full nodes in the clients and so because of that most dabs today like if you use D5 or like whatever kind of stuff usually they have ux hurting Network calls you have to wait a lot for every single thing um you have to wait for the TX to be mine in order to know what the side effects of what you have done like actually is there are services today like tenderly and stuff that allow you to simulate transactions but they add additional complexity to the code base and more often than not they need to use remote indexers which are yet another like surface of things that can possibly go down in complexity so can we do better now that we have like slightly better infrastructure than when web3 JS and ethersjs was invented is there a way to essentially have our cake and needed to um the one interesting fact about autonomous Wars or unchain game is that there are more often than not Standalone unlike traditional d-apps what that means is that the state transition function of an autonomous word almost always only depend on its own state so as an example when doc first was running on xdi Doc first could have run on a chain with nothing else but Dark Forest Dark first didn't care about the other things on xdi right that's unlike most dapps today which rely heavily on like a plethora of different services on chain that they connect to things like oracles things like erc20 contracts and so forth and again this is unlike as an example unit swap where if you were to want to simulate the transactions of like a uni swap trade you would need to know about the other smart contracts like the erc20s on each side of the pool because they could be implemented slightly differently um so one like mantle model for what murders is that it's a namespaced full node which is why we think this goes like well beyond gaming it's a way to build actually like better clients than what exists today and the reason we can build a namespace full note is because as I said earlier autonomous words are mostly Standalone so mud sinks a world the word contract that Alvarez talked about it's a namespace for data and logic so data are components and logic are systems so mud can sync the data of every single component connected to every single entity and download the evm by code of every single system and the way it does it is it does its initial sync via a general mud indexer or a full node and it keeps its state up to date via a full node or a mud stream service mud doesn't need the cryptographic data structures that are usually in a full node because we don't want to serve light clients we just trust a node remotely but what we want to be able to do is like give like build extremely Snappy applications by having the entire student logic client side so I think that is interesting with Mod is that components are self-descriptive components of on-chain schema that explains how to interpret their actual like row bytes and so the mud client can read the onshine schema and so compare that to a full node with a full node you know this the actual storage lots of of every single contracts but then you just have like 256 bits of like you don't know what that is this is why people write view functions in their contracts in order to be able to like load actually contextual data from those applications with mud what you get is a key value database of entities mapping to a bunch of components and it doesn't matter who deployed those components the client just knows what they are it knows what their name is it knows what their structure is so as an example when you sync like a mud full node so a mud client you would know that the first entity 0x0 has position 1245 and health 200. so it's way more contextual than the way full nodes are done today um it's because I mean ethereum is trying to be as general as possible whereas here we impose constraints in order to get features um this allows a client to run complex queries on components without any network delay so you can run aggregated queries like oh give me all the entities that have a position and a health with value 10. you can do crazier stuff like Aggregates and stuff like that but all of these are executed instantly in like one millisecond on the actual state so if you were to rebuild unit swap with mud today or at least the unit swap client you would be able to move around and do things without any network delay when it's synced and downloading the actual snitch subshot usually takes like less than a second so the other thing that is pretty interesting with mud is that it ships with a local evm so when you make a transaction in mode that is when you call a system what mud does is it runs an evm on that system given it knows its bytecode and it injects the easier State when that actual like EVN by code needs to write the state needs to read the state it registers all the side effects that happen so as an example if you were to like call the move system on entity one and you say move to X10 y minus 3 mud can run that into an evm and note that the side effect is that like oh no the position component of entity01 is 10-3 it also sends the transaction on chain of course and then when the transaction has been mined on chain it compares the side effects that happen on chain with the one that were predicted if they match nothing happened and so from the user specific it seems it seems like the transaction was essentially executed instantly which like gives way better ux and when it's not the case when the prediction fails so as an example if someone else kind of like Clash with our state by having their transaction execute before ORS or if we're behind the tip of the chain we just revert the side effects and apply the actual ones and but that happens like quite rarely actually this is how modern MMOs work they do prediction in Roblox all the time um so yeah with mud you can essentially read and index components without network delay client-side and you can also simulate transactions without waiting um and we think that oh sorry we think that this actual like increase in user experience is pretty insane we've seen it for games because that's what we're trying to do but I'm I can't wait for someone to build a D5 protocol mode and make it like the the snap yes swapping protocol ever um another thing I'd like to talk about is is this like concept of extending words with mud so today with like fully Unchained permission is up things like uniswap or dark phrase developers can extend the protocol via new contracts and custom client right that's the power of those applications so as an example in unit swap you can build an LP kind of like liquidity um mining program on top of uniswap permissionlessly you don't have to like phone the uni swap company in New York to ask if you can do that similarly with dark Forest you can create smart contract players or new features um however the problem is that developers that do that they need to ship new clients and indexers when they do that um so as an example if you want to build a yield like sorry not a yield agree there a swapping kind of like aggregator that finds the best prices well you need to build one inch you need to build a new client also users need to know where those new features are they have no idea that someone out there built new contracts and new features for that specific d-app um and that actually creates a clear distinction between first party code and third-party code which in our opinion like greatly hurt like interoperability and like creativity so as an example in dark first you can do something like hey um I'm team XYZ and I'm going to deploy a thing that marks some planets as rewarding and if there's captures them they get some eth that's pretty cool you can do that but now how do user know that this exists right like where are the contracts how do you like even if you had that information in your client how does your client know what to do with that data does it render a button does it trigger a Shader um similarly you probably have to rebuild all your indexer from scratch so you get a fragmentation essentially between first party code and third-party code so again can we do better um in mud the central contract is the word contract if you know the address of the word contract you know everything you know about all the components you know about all the systems you know about all the entities and the thing that is interesting with the word contract is that it's it actually has no owner um if you deploy yeah so it has no owner it's permissionless and so that means there is no difference between first party code and third-party code anymore everybody's first party so the creators of the world contract the deployers of that contract actually have no special kind of access to it they're not privileged in any mean um the word contract is non-upgradable so the rule is anyone can create components and systems so when Alvarez was talking earlier about the health component and position component and the move system anyone can register those components in those systems on the world itself and when you do that when you create new components that is like new data or new systems that is New Logic they're accessible in the client they're indexed they can be found in a debugger and they can be executed in locally VM and there's actually no difference between like what the core team deployed and what like any other people did deploy as well so the only like the rule is that all systems can read from any components so and and those components can be deployed by different teams so as an example you could write a system that runs a query on the world that queries a component developed deployed by team XYZ and a component deployed by team TTT and they can actually aggregate those data together the Only Rule is that components have to whitelist which systems can write to their states and that's really important because otherwise an attacker could deploy A system that just resets everybody's inventories so the way it looks like is you have this this like graph of components and systems that kind of like trust each other but also you have this interesting social phenomena as where users of those applications decide what is real so if you have two position components that like don't match with each other the users have to decide okay do we believe in position one or in position two and that's really what happens today on ethereum if I deploy a new die contract my die is worthless so it's all based on essentially what you think is real but it is made in like mud is architected in such a way that you never have the problem or you need to create something like oh like we need to like give or upgrade keys to Dao in order to let our players upgrade it snow this can emerge naturally essentially from the web of trust of the players themselves and this leads us into like an interesting kind of like idea of augmented reality so this is not the augmented reality you know with fancy glasses and Hardware it's more about layering Bayes rules with new interpretations so beyond the core components and systems all players believe in probably the ones that have been deployed by the core team the low level physics it is possible for anyone to create augmented reality layers that only a subset of players engage in and that permissionlessly so we're going to illustrate this um imagine a game it's a very simple game it was deployed by the like one core team it has three components position movable and resource there's three systems you can move you can pick up a resource so you can drop it and you can see there are three players there zero zero one zero zero seven zero zero five there are little characters riding horses and you have a bunch of resources on the floor what players do is they can vary resources around this game doesn't actually have any goal it's just some rules of physics essentially um and like as an example I can call move on my player and I would move my horse from one place to another no team TTT team tic-tac-toe comes in and they deploy two new components on the world because they can you know they don't have to ask anyone those two components are the stick component in the board component and they add three systems challenge accept Challenge and resolve um now all clients are aware of those new components and systems they just don't know what to do with it yet if you open your game at that time you'll see a little install box it's like hey there is some piece of JavaScript that is linked with those components and systems do you want to use them um if you do now you can play a radically different game while still being compatible with the low level rules so as an example I can take my player I can move to the gold at 0x03 I can pick it up move again and I can come next to that player at 0x07 and call the challenge system on that player that challenge system is new it was deployed by the team Tic-tac-toe and attached one eth to my transaction the other player if they're aware of that augmented reality layer can accept the challenge stick the same amount and now my like this new system is going to create a new entity 0x09 because anyone can create entities and attach the state component in the board component to it so now for the players that have the actual code that allows them to experience the tic-tac-toe augmented reality they can see your board on the floor um I know they can play Tic-Tac-Toe they can drop the resources in order to play Tic-tac-toe and someone can win they can call the resolve system and they can take the stick and destroy that entity and you can do that without clashing with the rules that all other players believe in so tic-tac-toe is just like tennis like tennis is an augmented reality layer on top of our physics I can drive in my car and look at tennis players and we're not breaching the rules like we're all like living according to the symbols but we're just like experiencing the world in different ways so it's an augmented reality and from the perspective of other players they're just like what the hell is going on why are people dropping resources on the floor on a grid but they can still coexist together other so there are a lot of augmented reality out there the main one is capitalism it was made up uh we all wear the glasses that allows us to see capitalism but I can interact with an anarchist that doesn't believe in money I can go and like have dinner with them and we won't actually experience the same augmented reality but we share the same low level rules competition is also an augmented reality the thing that is interesting with this game um is that it has it has no goal some people just made a set of interesting rules and resources but now anyone can come in and essentially puts a competitive layer on top of it um many games are also augmented realities so for the people here that have played Minecraft in Minecraft servers a lot of people build minigames you know you have to break the wall underneath people's feet and fall in the lava those minigames actually don't clash with the rules of Minecraft they're just like new systems that have been created on top um and you can do that permissionlessly you don't need a governance for the world because the world is onerous anyone can deploy new components and systems and players believe in whatever components the system they care about um and I'm gonna pass it to our friend Kelvin who's gonna drop some more cool stuff um so you want to build an autonomous World good luck good luck have fun trying just kidding of course um I'm gonna be talking to you today about the op stack uh technically we were originally hoping that this talk would be after the other talk about the op stack so just pretend pretend that you're five hours in the future you've watched the other talk uh and you know whatever time doesn't doesn't matter anymore so introducing the op stack except Carl has already done it five hours from now kinda we still need to write all the docs so if you want to use this you're going to have to dig deep a little bit uh you can talk to me afterwards about how you can actually achieve this but all right introducing the op stack I want to talk to you a little bit about basically how you can achieve this build your own system today and get really good security guarantees at the same time all right so boom what is the op stack essentially the op stack is rollups gone modular over the last year we've been designing and building this thing called Bedrock which is the next major upgrade to optimism um and while we were doing that I think we realized that the key part of building a solid roll-up client was to make it as modular as you can possibly make it and we sort of we'll talk about this a lot in the talk later today the back-to-back talk that I have with Carl but we kind of realized at a certain point that if you really want to maintain one of these things you can't allow different parts of the system to bleed complexity into other parts of the system and the classic example that we saw over the last two years was we separated execution from proving this was the big thing this is what basically optimism's evm equivalence upgrade arbitrims Nitro upgrade they all followed the same pattern which is let's build the client the way that we want to build the client and then let's make execution work on top so the end result of all of this overall this time is that we've broken up our system into a highly modular system with lots of different pieces we think that there's three simple layers that kind of follow what you think oh there we go look you've seen these things before consensus execution settlement you've seen these things before if you've heard anything about modular blockchains you kind of have an idea of what the op stack is all about except the lp stack is putting this modular Theory into practice so the real difference here is it's not just charts on a blog post about okay if you plugged in this data availability layer you'd get you get this behavior and if you plugged in this data availability layer you get this other Behavior instead it's actually concrete components that you can Implement and you can switch out to get the behavior that you want um so I'm going to talk to you about the Core Concepts the different components that you can switch out and sort of what you might do if you wanted to build a game to to use these different components and do something really interesting so the first layer that we like to break out of these different there's obviously the three the three primary layers inside of consensus we think of two sub-layers quickly here we've got what we call data availability and derivation but I'll start with data availability so you've probably heard about this you probably have a basic idea of how this works data availability is where you publish your data right so the idea is well people don't always want to publish their data to ethereum all the Roll-Ups originally were built under the idea that okay we're always going to publish our data to ethereum so let's just build our architecture under that assumption and so the op stack basically says well actually whatever as long as you kind of have an array of blobs that's what we call them they can be blocks if you're ethereum they can be blocks if you're Celestia they could be all sorts of different things but essentially what you want is an array of things where you can publish data to and ideally you have some properties about this data availability layer ideally it's somewhat immutable otherwise the whole thing is just going to keep rearging itself and that's going to be really annoying ideally the data is actually available otherwise you can't do anything with it so there's some properties that you want about this but the nice thing is the openstack basically says well whatever you can Define any data availability layer as long as it fits this basic idea that it's an array of you know byte strings you can slot it in as your data availability layer so concretely what can you do with this I think the easy example is instead of putting all your data onto ethereum you can use something like a data availability committee instead reduce your costs make your system cheaper I think this is a really good application for gaming because you basically you don't need those sort of ridiculously high security guarantees that you do when you have a basic roll up where you're just putting data on ethereum the ability to switch this out for the data availability committee or a different data availability layer all all together is really important to you know get the exact sort of security properties that you want depending on the amount of value that you actually need to secure all right derivation derivation is interesting I think derivation is one of the coolest parts of the the op stack design and essentially the idea is that derivation is how you are pulling inputs for your blockchain from the data availability layer so derivation is basically like a function that's aware of the structure of the data availability layer it's like you know let's say we're putting data on ethereum it's aware of the block structure it's aware of how data is put onto ethereum and it parses that data it pulls it out and it turns it into inputs to your layer 2 execution engine derivation is really important and it's you know generically you can understand why this is important let's say we're a roll-up you know the same thing that we're doing for unannounced game will be announced soon if you're one of these systems what you do generically is you post data to an address on layer one and maybe you have deposits and maybe you have some other sort of information and you transform all of that maybe you know if it's data posted to layer 1 by the sequencer let's say you you decompress all of that data you transform it into inputs on layer two and then you're going to execute those inputs derivation is really interesting I think there's a lot of like hidden things that you can do inside of here that might maybe aren't always obvious [Music] um one of the things that I think people can achieve with this is have in-game events or have events on your chain happen when things happen on the layer one so let's say you want to have an in-game event happen every time there's a uniswap swap event on layer 1 over a certain value what you can literally do is in your derivation function you can take our derivation function you can tweak it slightly and you can say okay I'm also going to look for uniswap swap events and then whenever there's a uniswap swap event I'm going to generate a transaction on layer 2 that makes this thing happen and the end result is that in my game fireworks go off whatever you want you can basically modify this however you want to have the state of your layer 1 Define what's going on on your Layer Two it doesn't just have to be transactions you can build amazing things with this and it can be very very stateful so you can do a lot of cool stuff here boom execution okay execution is probably what you think execution is it's your execution engine on Layer Two it's your state transition function it's the thing that takes up the inputs that were generated by the derivation layer and it takes the current state and it's going to translate that state into a new state right it's going to take that state into a new state and that state is going to be used to derive new inputs and it's going to be you know you get it right every time I make a transaction and something happens in my voxel game and the world updates that's what's happening under the hood in the execution engine the execution engine in the op stack lives behind the engine API right so what we decided to do was ethereum you know while it was going to the merge needed consensus clients and a needed execution clients right so you need a way to talk between the consensus client and the execution client and that interface between the two clients is the engine API so what we did was basically take the same API and you stick the the data availability and the derivation thing and you separate that from execution by that same exact API so it looks exactly like ethereum looks um the nice thing about this is that you can plug in absolutely anything in here you can it doesn't have to be the evm you could take the evm and maybe you can make some easy tweaks you can add a new pre-compile you can tweak a few op codes if you really want and that'll just work really easily in optimism in Bedrock we add a new transaction type we add this deposit transaction type that's really easy but it really can be whatever you want it could be Bitcoin it could be a Game Boy as long as you have a state transition function and you wrap it inside of the engine API you can do whatever you want and it should just work the whole thing should just work so if you want to build a game and you want to use an evm and you want to add a new pre-compile because you have some complicated game State function that's just too expensive to run inside solidity then you know just modify the evm if you want to run a totally different execution client all together you can also do that and it just sits behind the same API and all the rest of the stack all the roll up stuff all the transaction stuff it's just keeps working as if you didn't do anything at all right and then finally settlement settlement is this weird one it's a little fake it's you know what does this really mean I like to say that settlement is about establishing a view of your system on some other system and it's all about making claims right I'm making a claim about the state of my system onto another system and so settlement is really useful obviously in the you know in traditional roll-up settlements is really useful if you want to do withdrawals if you want to be able to move funds out of your your roll up onto let's say layer one you need to be able to settle the state of Layer Two onto layer one so that I can say okay that is the true state of Layer Two let me pull it out let me let me operate on it and maybe I'll give you a withdrawal as a result but the thing is you can do a lot of really interesting things with settlement you don't just have to make claims about let's say the total state of the system I think a really interesting way to think about settlement for gaming is that you can have a short-lived chain that plays some game let's say we all want to play a chess tournament right we can play a short-lived game and then at the end of the game we can all you know we see who wins the whole tournament and we can make a claim and we can say you know Kelvin won the whole tournament and that's one that's the claim that I'm settling and then you can have this generic proof system that will just prove arbitrary claims about the state of your layer too and so you can prove this idea that okay Kelvin won and then we can resolve that winner back to layer one and we can pay that person out and then we can throw the chain away because we don't need it anymore so we got this short-lived verifiable system right this game that we know that the whole thing ran as it should have ran there's no weird State coming out of it we prove that back to the base layer and then we can throw the whole chain away and we don't have to worry about storing it and so for short-lived you know high capacity games you can really bump up the gas limit you can do crazy stuff because you're not worried about State bloating to infinity and then you can just settle any sort of information about the state of your Layer Two back to layer one all right no sequencer no problem actually currently a very big problem but this is just an idea of basically what where we imagine this system going in the future because there's a big issue which is that every single time I talk about this idea somebody comes up to me and they ask me doesn't that mean you still have to run all this sequencing infrastructure and the reality right now is yes but we want to get to a future where the answer is no right because most people don't really want to run this infrastructure you want to focus on building a game especially let's say you just want to build something small you want to run it for for a couple of days you want to put it up there the reality is if you if you're you know I'm sure that the average person does not want to deal with the level of stuff that we have to deal with at optimism to keep the sequencer running so we have this concept that we're exploring called shared sequencing um basically shared sequencing is taking all the headache of running your own sequencer and it's deleting all of that and the basic idea is that all of these different autonomous worlds can share a single sequencer and of course when I talk about a single sequencer you can see there's multiple machines there I like to think about the sequencer as sort of a single logical entity but in the future what's going to happen is you're going to get decentralized sequencing you're going to have something that looks like a leader election where at any given time slot there's a specific sequencer and that sequencer sequencing Your Role up and then there's the next time slot and the next sequencer comes in right so the the thing with this is you could do something really really interesting if you have one sequencer sequencing all of these different chains at the same time right instead of having multiple different chains that are talking to each other the problem today is if I have let's say I'm ethereum and I have Cosmos right now I want to sort of I want to interact between a cosmos chain from a from ethereum they don't share a validator set which means that my communication inherently has to be asynchronous but if you have a single sequencer producing the blocks on many different autonomous changes the autonomous autonomous Worlds at the same time you can get this amazing property of atomic composability between all these different chains you basically have a single sequencer saying okay there's a transaction coming in on chain a and there's a transaction coming in on chain B and I'm supposed to guarantee that they can come in atomically and I could do that because I sequence all the chains at the same time so now you have different games different worlds different realities that can interact with each other they're their own States right there the validation is separated none of the validity of one of these chains depends on the validity of the other chain but they can talk to each other as if they're on one unified chain that's crazy right now now you can have I can have an action in one game all of a sudden create some simultaneous action in another world at the same exact time if those two worlds want to want to talk to each other so this is part of something that optimism is playing with that we're calling the super chain we think that this extends a little bit more than just its shared infrastructure I think that the incentive here is not just to share infrastructure it's to share code it's to share a set of values is to basically collaborate on having all of these different games and all these different worlds maybe it's not games maybe it's entirely different Roll-Ups but they basically I think there's we think that there's a strong incentive for these systems to not just be able to transact atomically but to really be able to collaborate with one another um towards some coherent Vision because you're much better joining in on this system than you are trying to build your own chains separately with your own sequencer set and you have to run all the infrastructure and you don't get to talk it you know atomically with the rest of the system so you know long live the super chain very I would highly recommend if you're interested in this how this might work in more detail come to the back-to-back talk with Carl and me later this afternoon we'll go into much more detail about how this how all this works all right where are we all right so uh the other question I get is why make it you know free and open source right aren't you basically just like letting people compete with optimism and build their own roll up and the answer is like kind of yeah right this is the idea um and and the idea basically the argument is that the reason we have to do this is because there's just no other way to do this we need you know we think that there's going to be this explosion of people who are interested in building layer twos interested in building layer threes right we're already seeing all these you know big L1 systems come in and they're experimenting on the execution layer right they're they're competing with ethereum on the execution layer they're saying we're going to build a parallelized VM and that's our advantage and if you really want to survive you're going to need to be able to compete on this stuff and we think you're going to need to be able to compete on this stuff without having to have 25 Engineers work on this problem like three years like for three years like we did and instead you're going to want the ability to have three Engineers figure out how to do this in three months and start business out of it so this is basically the argument we if you if you want to really make it possible for ethereum to continue to compete and for people to experiment on the execution layer experiment on the derivation layer experiment on all these different layers it just has to be available right if there's not a permissive license on it you can't use it if it's not if it's not modular enough if it's too hectic to try to hack in your modifications to the execution layer you can't use it so the goal is just make it as available as possible so that ethereum can continue to compete on every single layer of the stack but you can still stay within the ethereum ecosystem um and you know this is us today this is where we are this is we got lattice we got a couple other people and you know this is the world that we're imagining right we're imagining that basically everybody is building on a system like this and they're collaborating and they're working on a shared infrastructure and by working on a shared infrastructure you share audits right you can share engineering time it basically takes you a hundred times less effort to build 100 companies instead of having every single company fragment and build their own system you basically have all the freedom in the world without actually worrying about the low-level technical details about how are you going to publish transactions to layer one reliably how are you going to deal with reorgs right how are you going to make the proof work because all that stuff is extraordinarily complicated there's no reason why every single person who wants to build one of these chains should have to basically build it from scratch doesn't make any sense all right so some closing remarks here basically go nuts build something crazy you can do so much with this architecture right you can swap out the data availability layer make your chain cheaper you can swap out the execution layer build an entirely on-chain game you know you can literally take an emulator of some system you can put it into the execution layer and you can even prove that the whole emulator functioned properly you can do an enormous amount of stuff with this and the nice thing is you don't have to worry about how are you going to go build the sequencer how are you going to go build the proof and all these different things you basically get all that for free so that's the idea um where are we yeah thanks we're thanks for coming to my TED Talk um where are we right now so the code is all there it's possible to hack on this stuff the real the next goal is to take take all these modules and make really really clean documentation so it's clear what you have to change where you have to change it to make all this possible if you go in today you know lattice has been extraordinarily Brave to go in and basically hack this system together and really make it work for them and we've seen other people do it as well if you're interested in doing this you know come talk to me later and I can give you pointers but the goal is you know right now it's still a little early we're looking for people to come in help us figure out where the apis aren't clean enough right help us figure out where the documentation is in clean enough if you're if you know what you're doing and you're really interested in hacking on something new like come find me and I will try to help you get started with this whole thing and the goal is make this accessible to the average person who just you know doesn't want to under doesn't want to deeply understand how this whole architecture Works um so that's me I'm going to hand it off now all right all right cool three minutes left um announcement time announcement time so just like the op stack is meant to like essentially increase pluralism by making something free and open source and easy to use we kind of did the same thing with Mod mud is MIT licensed at soft launch today and to kind of like pave the way forward um that is an optimism have been working together over the last month and a half on an autonomous world that was built on mud and runs on the op stack so we're like pretty excited to show opicraft to everybody it's a 3D voxel game powered by mud running on a crazy to generate op chain uh yeah I even have a video well I will see if it plays but Alvarez and I yesterday were trying to build the house so yeah that's that's uh that's running on DVM guys it's it's a procedurally generated world I can't wait to see what people will do with that you can deploy marketplaces oracles extend it build augmented reality tennis capitalism whatever you want um it's going to be open source soon it's playable today um let's let's let's let's actually see how we built the house I remember it was quite quite hard given we didn't really have consensus on how to how it should look like yeah okay cool we did it um opicraft is gonna be soft launch and playable at the autonomous World Arcade at 4 pm today at the hacker basement so if you want to play it um come there additionally we're going to have a tournament of skyscribe which is the RTS that was built with Mod uh we have playlisted it weekly for like the last month people really like it there are Starcraft players that don't even know that it's running on chain they just like the game so yeah we're gonna try to hit 64 players so come along as well hacker basement 4pm so what about the other stuff well mud is actually already available we just don't really talk about it because it's not very documented it's like the op stack it's a mud.dev um the code is on GitHub um we have a bunch of teams building stuff with it but it's it's yeah talk to me if if you're interested um the op stack is going to be announced soon by Carl at 1 30 pm on the main stage um and yeah that's us thank you guys