►
From YouTube: MUD : An Engine for On-Chain Games
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/mud-an-engine-for-on-chain-games/
For the past year and a half, 0xPARC and Lattice have been hard at work building MUD — an open-source engine for building on-chain games.
In this talk, Justin and Alvarius from Lattice will be joined by Kelvin Fichter from Optimism, to talk about on-chain games, MUD, and an exciting new collaboration with Optimism to be unveiled on the day.
Speaker(s): Justin Glibert, Alvarius, Kelvin Fichter
Skill level: Advanced
Track: Developer Infrastructure
Keywords: games,evm,on-chain
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
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.
A
We
basically
want
to
enable
people
to
build
crazy
things
on
top
of
ethereum
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.
B
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.
B
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.
B
So
before
I
go
into
how
mud
solves
all
of
these
problems?
Let
me
quickly
go
over
like
the
previous
common
approach
of
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.
B
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
yeah
event
handling
on
the
client.
B
B
B
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.
B
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.
B
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.
B
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.
B
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,
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.
B
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.
B
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.
B
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.
B
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.
B
B
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.
B
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.
B
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.
B
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.
A
Cool
all
right,
I'm
gonna
drop
some
more
crazy
stuff.
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
with
a
node.
You
can
do
things
like.
Oh,
what
is
the
counterfactual
of
this?
A
A
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
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.
A
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.
A
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
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.
A
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.
A
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?
A
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.
A
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.
A
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.
A
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.
A
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.
A
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.
It's
because
I
mean
ethereum
is
trying
to
be
as
general
as
possible,
whereas
here
we
impose
constraints
in
order
to
get
features.
A
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.
A
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.
A
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.
A
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.
A
A
They
do
prediction
in
Roblox
all
the
time
so
yeah
with
mud,
you
can
essentially
read
and
index
components
without
network
delay,
client-side,
and
you
can
also
simulate
transactions
without
waiting,
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.
A
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
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.
A
Similarly,
with
dark
Forest,
you
can
create
smart
contract
players
or
new
features.
However,
the
problem
is
that
developers
that
do
that
they
need
to
ship
new
clients
and
indexers
when
they
do
that.
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.
A
They
have
no
idea
that
someone
out
there
built
new
contracts
and
new
features
for
that
specific
d-app
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,
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.
A
A
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
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.
A
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
the
word,
contract
is
non-upgradable,
so
the
rule
is
anyone
can
create
components
and
systems.
A
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.
A
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.
A
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.
A
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.
A
So
we're
going
to
illustrate
this.
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.
A
It's
just
some
rules
of
physics
essentially
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.
A
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?
A
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.
A
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.
A
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.
A
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
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.
A
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,
and
you
can
do
that
permissionlessly.
You
don't
need
a
governance
for
the
world,
because
the
world
is
onerous.
A
C
So
you
want
to
build
an
autonomous
World.
Good
luck.
Good
luck
have
fun,
trying
just
kidding.
Of
course,
I'm
gonna
be
talking
to
you
today
about
the
op
stack.
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,
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.
C
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,
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.
C
Over
the
last
year,
we've
been
designing
and
building
this
thing
called
Bedrock,
which
is
the
next
major
upgrade
to
optimism,
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.
C
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.
C
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.
C
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.
C
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.
C
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.
C
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.
C
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.
C
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.
C
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.
C
That
might
maybe
aren't
always
obvious
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.
C
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.
C
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.
C
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.
C
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
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.
C
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.
C
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.
C
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.
C
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.
C
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.
C
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.
C
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.
C
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.
C
C
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.
C
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.
C
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.
C
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.
C
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.
C
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
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.
C
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
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.
C
This
is
the
idea
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.
C
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.
C
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,
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.
C
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?
C
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.
C
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.
C
Where
are
we
yeah
thanks
we're
thanks
for
coming
to
my
TED
Talk?
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.
C
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.
A
All
right
cool
three
minutes
left
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.
A
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.
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
that's
running
on
DVM
guys!
It's
it's
a
procedurally
generated
world.
A
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
it's
going
to
be
open
source.
Soon,
it's
playable
today,
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.
A
Yeah,
okay
cool
we
did
it.
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,
come
there
additionally
we're
going
to
have
a
tournament
of
skyscribe,
which
is
the
RTS
that
was
built
with
Mod.
We
have
playlisted
it
weekly
for,
like
the
last
month,
people
really
like
it.
A
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.