[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