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