# Scaling autonomous worlds - building the foundations… and sewers for millions of inh... | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 21:50
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-uJ2nhPDvjLw
- YouTube: https://www.youtube.com/watch?v=uJ2nhPDvjLw

## Description

One tends to think of Ethereum scaling in financial terms—how many transactions per second? What’s the TVL? How much liquidity?

But in a possible future where Ethereum applications extend beyond finance, into areas like autonomous worlds, games, and social, what does scaling look like and what challenges await?

Join us as we explore challenges, solutions, and open questions in this space—how do we bring latency down despite seconds-long block time? Could we shard an app across multiple chains?

Speaker(s): tdot
Skill level: Intermediate
Track: Layer 2
Keywords: Layer 2s, Cross-L2, Autonomous World, cross-chain

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

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.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] all right my name is tiat I'm a software engineer at Lis um and um yeah I'm about to talk about bring you on our journey uh basically building the best infrastructure for autonomous worlds and mud apps okay um so so I will start by talking a little bit bringing a little bit of context uh for those who don't know what mud is and what are autonomous worlds I will then kind of describe some design patterns that we um learned about while we were fa uh essentially solving problems for mud apps uh and how basically we solve them uh and then I'll be describing uh a new system that we're prototyping uh you might have gotten a sneak peek already if you catch if you caught alvarus talk earlier um on mud so yeah stay tuned okay um so if you're not familiar with lattice uh we've been promoting a vision for launching games to basically develop properties of a thing that we call autonomous world uh who knows who here knows what autonomous world is or has an idea okay that's quite a lot of people who knows about mud all right that that's it's good uh but so we're all on the same page um I'll give my quick definition of it um essentially um whoa things are moving um so when I say autonomous worlds what I mean is like permissionless Virtual Worlds that are seated by initial teams who are then joined by early adopters who build on top of it until the plot evolves Beyond anyone's single control and then complex drama and social components emerge um and to enable worlds we've built mud on ethereum so that world Builders could have robust Primitives to implement their vision and build fully onchain gaming loops and then onchain games are well too expensive to run on ethereum Main net so we needed a cheap chain with Big Blocks and uh infinitely scalable da um so we basically um added that feature to the op stack and deployed it as a chain called Redstone and on top of redstone we're also running uh free services for mud apps like public rpcs and indexers um and actually to give you a little context this is a screenshot of cwi's public rollup dashboard um and if you look at the top six l2s um you can see except from Bas all of these l2s are mostly focused on onchain games uh so these are like all the meag gas per second that is here uh so all these rollups are ranked by meag gas per second and you can see all of them that have extremely high meag per second are basically um have onchain games deployed on it um and actually it's kind of interesting too is redstone doesn't have that much transaction per second but it's Mega gas per second is very high that means that mud transactions are actually storing a lot of data on chains so they're actually quite big so that's why we needed uh Redstone so to have a chain with very big blocks and a lot of gas and so that um mud mud apps would stay cheap so some applications um that launched on or are about to launch on Redstone um if you didn't haven't caught the eve uh talk earlier by Hillmar and Justin but I'll talk a little bit is e Frontier is a part of the E online universe so they designed an incredibly sophisticated World physics and are progressively bringing components on chain over the next few years you know they're here for the long term so build can basically Implement business logic permissionless Le on top of it um so if you missed the talk earlier recommend you go back and check it out um and then biomes is bringing Minecraft physics on chain with the with new types of creative gaming Loops um and they have very intensive requirements to enable multiplayer they're currently on Redstone mayet actually most of the the gas that you saw on the dashboard earlier is coming from biome so very excited about um this world um and while these teams develop the physics and they seeed the worlds with the origin stories and the gaming Loop um it is when people can build on top without permission and extend the world with new experiences that properties of autonomous world really emerge uh so we like to call more technical users who extend the worlds sewage hackers because they get their hands dirty and they need access to lower level infrastructure Primitives such as indexers RPC apis to power um their applications and you know it's like most inhabitants of a city they don't need or they don't concern themselves with the sewers but they're crucial part of these very dense environments if your sewers stop working you're you're pretty um okay so I'll go about over some requirements um we want to enable worlds where multi multiple players can interact with the state at the same time uh we want low friction for inhabitants uh so that they can they don't have to pay uh expensive transaction fees we want to stay evm compatible so that uh apps can be compatible with other chains and other tooling that's in the ethereum ecosystem uh and lastly we want this to be super easy for mud users to um integrate so they shouldn't have to rewrite their apps or add complex client logic if you're using mud all the tools that we built uh work out of the box okay so one of the things that we worked on was um enabling mud apps to deploy on Main net with a futureproof data availability solution so um we actually worked with optimism to u i mean we designed and we implemented a plasma da protocol uh in order not to use blobs there's actually a talk right now in the other stage where they're discussing are blobs cool uh we thought blobs are not that cool so I mean we like blobs but we wanted something that's more future proof and infinitely scalable if you had more chains um and so we worked with optimism uh and to Upstream this in the codebase and this is known in out da mode and um our specific da layer uses a plasma like design so that stakeholders can have an emergency exit hatch where they can challenge data if they believe the data is missing and they you can basically keep the chain running while you withdraw your funds uh and if you want to know more about how this system works I recommend you check the uh optimism uh specs actually a fun fact too is once we decided to Launch Stone we were doing some uh load testing and we ended up Breaking the Chain on test net um because we had too much data and uh we started with a very large block size 100 Mil in gas and uh the op stack limits were not large enough to enable this kind of payload size uh so we actually collaborated to with the opack core developers to raise this limit that was introduced in the for Network upgrade um and it was really easy to ship quickly because we control the full infrastructure um by running the chain ourselves instead of adding intermediaries like roll up as a service providers uh so it allows us to make custom changes to the services and test potential protocol protocol changes directly um so we can observe the effects on application directly uh before they eventually get upstreamed in the op stack um and when we first running El we started running dl2 chains so we we had to you know learn how to run the chain and do all that stuff and um we quickly ran into bottlenecks because our sequence or node was busy building blocks uh and handling RPC Quest so we did some basic things like separating the read and the rides um and essentially eventually the Redstone sequencer State private we exposed another one that was synced over peer-to-peer uh then that node also got a bit overwhelmed so we added another node and split them by regions um now the problem you face and actually you might have heard Ryan talk about it in indexing is you can end up with different states if you have a load balancer in front of your nodes um and there's actually really cool ways that for example optimism implemented a proxy D which helps basically keep a health check Loop so you can check that each of the nodes has consistent State and you removed uh them from the set if they they're inconsistent uh you have other goodies like caching and uh rewriting reorgs um and eventually we also wanted to have better latency inside of um different regions uh so we added you know uh DNS low balancing so you basically you can see here our user is in the south of France he gets redirected to the closest region uh which then goes to our proxy and low balancer and and a bunch of nodes um so this is things that that we um implemented another aspect and um you if you heard Ryan's talk earlier you already probably know how to implement your own indexer um but actually a common bottleneck is by mud experiened by mud application is when the state grows and users grow the initial load of the game can be um very slow especially when it's hydrated directly from a node RPC so this is sold by loading uh the initial state from an indexer database we first released an open source version of the indexer so index uh apps could index their own world and we also wanted to offer free indexing for all the mud applications um and our first indexer implementation was kind of not as performance it had limitations so we collaborated with Ryan actually in and Ryan built ended up building most of the indexer that that we're actually running now um and it can scale for a whole bunch of Worlds so um yeah okay another aspect that I learned about recently myself is how ethereum providers um like browser clients and things like that they make a lot of requests by default before sending a transaction and if you're far from the RPC server the latency can add up um some of these requests like estimate gas they're also quite slow because they run the the evm quite a bunch of times to estimate the gas um so we made some optimizations you can see here this is all the by default you can be making as many of these uh requests and so that that ends up pretty pretty slow um so we met some uh optimizations on the mud browser clients so we added a non manager which only syncs with the RPC when you need to uh we made sure that transaction context is pre-loaded so when you click you're only sending the transaction you're not doing a bunch of other things so that it feels kind of Snappy and we're also caching gas estimates so we don't actually need to call gas estimate gas every time uh and and things like that but you know um however you spread read nodes across the world if you're using an L2 at the end of the day um transaction confirmations will always be the fastest the closest you are to the sequencer and you're going to have to wait for the block time before you actually get your confirmation um so if you're running a sequence in Europe uh users in California and Japan are getting pretty awful performance um and the experience play in the game can be very different from users who are close to the sequencer um so what can we do to improve this you know what how do we scale U block building U so one way we could do this is we could have multiple chains in multiple regions maybe they could even be l3s you know or I mean that could work maybe they with optimism's interrup protocol if we want to bring block buildings very close to the user but there's going to be a lot of chains you know you you don't want to be running tons of different chains all these different regions especially when maybe your users are moving so you just want to be loading block building at the edge wherever you need to so what if we could run block building at the edge when needed just for a piece of state and uh for for example imagine you get matched with different players in your area and you start an ultra low latency game match um and so I will proof this by saying this is probably not the only solution um but this is the one we're currently validating as a prototype and so I'll I'll try to explain a little bit how this is made so if you remember the the previous here we're like actually deploying block Builders directly on the edge and we call them points of presence like um for CDN and what they do is essentially they act like a full ethereum RPC but they only pull the state they need from the Upstream in our situation um the pubs that just request the latest version of the State uh and if we need to write to that state a point of presence can then acquire a lock on it and this is handled at the mud level because we have static ways of determining you know which mud table the pup needs to write to and then only the pup can batch transaction to modify that state and then they can send the confirmations immediately without waiting for the actual chain payload to be built uh so p p Builders can send in transaction batches to the Upstream uh eventually and uh just in time before the block get built um and then no other pop Builder can modify that state so and then you know you have basic CDN stuff like the state locks are cleared you know on least recently used basis um and they're automatic cleaned up once you have more data that comes in and and your data has been stale for a while um and then these are other examples of things that you can speed up once you can run them on the edge uh for example when you're estimating the gas or you're managing the nonces and so you can have extremely size gas estimates uh by running them directly on the edge you can have uh fresh non management when you're sinking it and you can do even do uh ERC 4337 user are bundling on the edge um and so I mean this just accelerates a lot of things and we we were uh when we were testing this uh it actually ended up getting to a very very good performance actually I'll I'll show you a little demo um I if I if I press play this will work okay cool um so this we implemented this the this uh this game just to demo this prototype uh it is multiplayer every time you move the fly this is a transaction that is executed and a receipt that is sent back to the browser so you can see like all of these 20 milliseconds here um every time you're executing a transaction and getting the receipt back um and so I this is still a prototype but if you want to learn more and get to know actually test the thing yourself get a feel for it you can come to Mud day tomorrow and actually experience the all the games um and or learn more about how all these things works all right thanks for [Applause] listening chran that was a great presentation I noticed that no one had any questions in the Q&A oh it's coming okay cuz I was going to front run you guys no no no no no no no no no audience first oh man okay I'm gonna ask my question then to fill the G time Gap okay so this seems really awesome and amazing but given my background I do a lot of security research so all I see is oh my God scaling extremely quickly what are your thoughts around security I mean obviously you have have all the security Assumption of the ethereum protocol which are respected you know we're part of the super chain we're trying to do all these upgrades so everything is that is basically touching the ethereum protocol has the guarantees of Alda chains from the op stack uh and you know all of this is audited or like has is reviewed by the op stack uh team and then um on the things that we control then it's it looks more like uh web 2 security where you have your servers and your D DNS and you know TLS all that that kind of stuff so you do have different kind of areas and and we have different ways of of solving these problems that are more specific to either ethereum protocol or um basic you know Services hosted Services gotcha I have a lot more questions for offline but uh any other questions since then okay I'll go for the first one here so how are you in the super chain with a custom da I mean the differ we're not in the interrupt Set uh just yet so I guess this would be um the kind of slight differentiation um but we're still kind of so we're not part of the um upgrade set so we don't get the RO the basic rollup upgrades uh but we're in the super chain per se because we're actually using the Upstream uh protocol version of the protocol we're not running a fork um and so all the code that we run is basically um reviewed by op stack core protocols what's next on the road map for mud what features are most needed next I mean I can speak for the infrastructure part of things um yeah what we're really trying to do here is is get to this extremely extremely low latency and get those uh on Main Nets so we're trying to get you know the new indexing we're trying to get all these things available um on Redstone mainnet um and then probably the next thing that we probably will be working on is um you know integrating interrupt so optimism's uh multi-chain protocol inside of mud so we'll also have some uh exciting things like this but this is still work in progress gotcha yeah that that speaks to my question of why you joined the super chain um how do you balance the benefits of scaling um and the latency optimization against the dollar cost yeah that that's a good question um I mean one thing we've been trying to do is like move towards a more like bare metal server architecture so instead of using AWS as very expensive servers we're trying to run things uh on different bare metal providers that are like cheaper and have a lot of you know redundancy uh because they're obviously less stable so that uh essentially if a region goes down or um a server goes down if it's not as as stable as AWS it's the users don't don't really uh see the difference and then you know basic stuff like packing just adding a bunch of services run on the same machine so you have all these optimizations that you can do but yeah we're we're still fine-tuning this part actually okay we got a question that's really popular can it run Doom o h that's actually a really good question I I I think you should come to Mud day to find out about that can wow be next next question by the way that was a joke you didn't have to laugh um what's your thought on crdt in crdt plus blockchain I'm sorry I'm not the person to be asking that question I think it's it's an interesting question because it's like crdt use if you really want to do like pure decentralization and um you care about you know not having a single point of failure and having you know all the browsers be able to eventually reconcile the state and things like that so I I guess it would really depend on what your um use case requirements are um if you're trying to build a game that is even if all the latest servers go down you can still play the game then crdt could actually be a pretty pretty good solution but otherwise I'm not fully certain that you can get the the same kind of performance and latency that that we have when we have these Edge block Builders cool any other question guys I got one spicy question here oh nope someone else has another question in here um this is not a question crdt is yeah someone has a point here make what is your take on that crdt is only for communitive operations bad for games thank you for that spicy question or opinion rather what was the other take you had oh the other take I had uh was I'm curious how you actually see the difference between um ton chain and all of their you know fun mobile app games I don't know if you guys have played any of them but they're highly addictive um and you do end up earning whatever tokens in their ecosystems and they seem to be building something quite similar probably a lot less complex than what you guys are yeah I think so it's quite interesting too because what we're really focusing here is like autonomous worlds where you bring as much part of the you're trying to bring all the physics on chain so it can live without anything on the client um and then eventually can live out you know outlive the teams outlive everything and so these kind of games that are kind of addictive they're they're not really geared for this kind of you know long-term view or things like that you know they you really have the gaming Loop that's all that matters whereas here we're trying to have everything be on chain eventually and that's what mud is about really is like enabling all these very complex physics fully on chain gotcha okay thank you any other questions