►
Description
Optimism Co-Founder Ben Jones (https://twitter.com/@optimismPBC) and NEAR Co-Founder & CTO, Alex Skidanov (https://twitter.com/AlexSkidanov) do a deep dive on Optimistic Rollups and scaling Ethereum smart contracts.
Optimistic Rollup is the design that the Plasma Group created during its research and development stage. But how does this achieve Layer-2 scaling on Ethereum? Ben Jones explains in the 35th episode of the Whiteboard Series.
------- About Whiteboard Series ---------
The Whiteboard Series with NEAR is a set of video interviews with Founders who are building scalable solutions for Blockchain. We deep dive into their story, what they're developing and how it is helping the ecosystem.
Follow the latest from NEAR Protocol on,
Website: https://near.org
Discord: https://near.chat
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/nearprotocol
#WhiteboardSeries #Blockchain #FutureIsNEAR
A
Good
and
today
we're
going
to
be
talking
about
optimistic
roll-ups,
Ben
was
previously
on
whiteboard
sessions.
Maybe
a
year
ago
we
were
talking
about
plasma
cash
flow
and
which
was
another
layer
to
solution,
but
since
then
optimistic
roll-up
started
a
starting
started
getting
popular.
So
let's
talk
about
them
so
Ben.
Would
you
like
to
I
guess,
introduce
yourself
again
in
case
people,
didn't
watch
the
previous
episode
and
talk
a
little
bit
about
what
optimistic
roll-up
are
what
the
what
problems
they're
trying
to
solve
and
how
they
work.
Sure.
B
Thing
sure
thing
and
that's
right:
yes:
I
am
here
back
to
back
I,
guess
now,
back
at
the
near
whiteboard,
talking
about
more
stuff
yeah,
so
I'm
Ben,
I
work
at
a
team
called
optimism
and
we're
building
a
product
called
optimistic
aetherium
and
it's
a
scaling
solution
that,
like
Alex,
said
uses
at
its
backbone.
A
tech
called
optimistic
roll-up
and
the
goal
is
to
scale
aetherium
and
particularly
our
goal
is
to
scale
aetherium
smart
contracts
so
Alex
when
we
were
when
we
were
last
chat
chatting
on
the
on
the
you
know
near
channel.
B
B
B
So
we
have
this
thing
called
layer,
2
right
what
a
weird
way
to
write
layer,
2
layer
2
refers
to
a
suite
of
designs
and
applications
that
you
know
arguably
started
with
payment
channels,
even
not
as
early
as
Bitcoin,
and
they
utilize
something
called
optimistic
execution.
This
is
one
way
to
frame
what
they
do
right.
So,
let's
just
let's
just
write
that,
of
course,
I
am
biased
towards
this
particular
choice
of
words
since
I
work
at
a
company
with
an
M
at
the
end
of
optimist.
B
So
you
know
I
like
this
word
a
lot
but
like
what
is
optimistic
execution
right.
Well,
we
have
this.
This
blockchain
thing
right,
we'll
assume
the
readers
are
familiar
with
that
and
the
idea
is
you
know
these,
these
black
chains
have
it
limited
throughput
right,
so
you
know
if
we
have
some
chain,
you
know
argue
with
me
about
whether
I'm
pointing
my
arrow
is.
The
right
way
right,
there's
this
thing
at
the
end
of
the
day,
this
this
consensus
system
is
still
a
computer,
and
you
know
this
from
this
state
machine.
B
You
know
and
it's
replicated
and
the
way
that
we
replicate
it
and
achieve
a
consensus
on
it.
Right
basically
like
restricts
us,
so
you
know
we.
We
can't
like
just
like
pump
infinite
things
into
this
blockchain
right,
it
won't
work.
So
what
do
we
do
in
the
naive
model
of
black
chains?
We
can
think
of
the
blockchain
as
like
a
ledger.
B
You
know
accounts
or
whatever
we
want
to
call
it
right.
So
this
is.
This
is
one
model
to
think
of
a
blockchain,
and
so
you
do
your
payment's
and
you
put
them
on
the
ledger
and
it
updates.
Who
has
what,
based
on
how
much
you
know:
Alice
is
ping
Bob
or
whatever.
So
optimistic
execution
is
the
idea
that,
unfortunately,
this
ledger
is
very
limited.
So,
instead
of
making
it
a
ledger
of
accounts,
what
if
we
could
make
it
a
ledger
of
disputes?
B
And
really
you
might,
you
might
even
say,
settlement
in
a
general
case,
but
it's
interesting
to
think
of
this
as
just
disputes.
So
the
idea
is,
you
know
perhaps,
instead
of
Alice
paying
Bob
five
dollars
by
submitting
a
transaction
to
the
ledger
of
accounts
and
saying:
hey
decrease
my
account
by
five
dollars,
increase
Bob's
account
by
five
dollars.
Maybe
there's
a
scheme
in
which
Alice
can
just
simply
say,
here's
a
little
update
and
here's
what
Alice
has
now
and
here's
what
bob
has
now-
and
you
don't
have
to
actually
check
me
on
this.
B
B
B
Talk
about
them
very
briefly:
okay
cool,
so
one
of
them
is
called
the
State
Channel,
as
I
mentioned.
This
is
one
of
the
earliest
ones
and
in
a
state,
channel
Alice
and
Bob
commit
some
money
into
an
escrow
and
they
sign
off
chained
messages.
So
so
you
know
it's
hard
yeah,
it's
hard
to
figure
out
the
best
way
to
draw
this,
but
Alice
and
Bob
are
going
to
submit
some
money
into
an
escrow
right.
So
there's
Alice,
there's
Bob
right.
They
put
some
money
into
an
escrow.
B
B
Oh
thanks
thanks
so
much
so,
let's
say
that
Alice
and
Bob
put
some
money
into
an
escrow
right.
This
is
sort
of
the
part
that
occurs
on
Shane
and
then
we
can
do
some
things
that
are
off
chain
right.
So
if
we
say
off
chain
over
here
so
off
chain,
basically
Alice
and
Bob
can
do
these
cryptographic
io
u--'s
right.
B
They
send
back
and
forth
some
io
u--'s
right,
Alice,
says:
okay,
I'm
gonna
pay,
you
a
dollar
now
and
then
Bob
says:
okay,
I'll
pay,
you
three
dollars
at
a
different
time,
right
and
so
on
and
so
forth,
and
the
property
is
that
even
if
there's
a
lot
of
iU
I'll
use
pass
back
and
forth
at
most,
even
if
there's
a
large
number
of
these,
only
one
of
them
ever
has
to
go
back
into
the
escrow
contract
right.
So
here
let's
do
I
love
colors.
B
So
let's
try
to
get
some
colors
in
here,
only
one
right,
so
in
a
state
channel.
This
ESCO
contract
only
needs
the
most
recent
two
sort
of
IOU
state
right,
the
most
recent
set
of
affairs
to
be
able
to
resolve
how
much
money
at
a
later
point
in
time,
Alice
and
Bob
get
out
right,
and
so,
hence
we
have
done
some
scaling
right
because
Alice
and
Bob
transacted
several
times
and
the
ledger
did
not
make
an
update
on
the
order
of
the
number
of
those
transactions
it
made
enough
on.
B
We
can,
theoretically
do
an
infinite
number
of
transactions
per
second
right,
like
Alice
and
Bob's.
Ability
to
pass
these
io
u--'s
back
and
forth
is
only
bounded
by
you
know,
things
like
their
computational
power
and
network
latency,
but
they
can
just
send
one
sent
transactions
back
and
forth
all
day.
Long
right.
It
wouldn't
be
a
very
meaningful
scaling
solution,
but
it
would
be
very
high
number
of
transactions
per
second
right,
yeah.
A
B
Nice,
nice
yep,
so
payment
channels
are
so
really
cool
and
if
you
even
get
a
little
crazy,
you
know
you
don't
have
to
just
do
a
payment
on
this
channel.
You
can
do
things
like
playing
a
chess
game
or
some
you
know,
turn-based
application
or
a
poker
game
things
of
that
nature.
So,
unfortunately,
the
problem
with
payment
channels
is
that
Alice
and
this
escrow
contract
right,
where
Alice
and
Bob
put
money
into
right,
was
only
al.
A
B
What
we
really
like
in
the
etherium
world
is
this
crazy
ability
to
have
these
money
Legos
right,
where
we
could
deploy
all
of
these
crazy
smart
contracts,
and
they
can
talk
to
each
other
in
weird
ways
and
do
crazy,
awesome
things
right
and
the
problem
with
this
is
that
the
set
of
features
that
you
can
do
with
such
a
limited
participant.
That
is,
you,
know
similarly
limited
right.
B
B
Optimistic
roll-up
right
is
a
scaling
solution
that
allows
you
to
scale
up
in
the
you
know
in
the
number
of
disputes,
not
in
the
number
of
in
the
amount
of
computation,
and
it
allows
you
to
do
so
with
pretty
much
identical
properties
to
aetherium
itself,
and
so
that's
what's
super
exciting
about
it,
and
particularly
the
property.
Is
that
the
data
availability?
B
A
B
A
B
A
B
Scroll
up,
okay,
so
here's
like
the
simplest
possible
possible
way,
like
you
know,
like
you,
know,
MV
oru,
Minimum
Viable
or
you,
and
in
fact
this
I
will
hide
a
particular
detail
here,
which
involves
a
sort
of
the
stateless
execution
nature.
So
there's
stateless
clients
and
you
get
a
lot
of
performance
benefits
by
doing
that,
but
actually
the
the
minimum
sort
of
viable
version
of
this
and
all
described
here
was
actually
I
think
we
can
lend
credit
to
but
Alec
in
2014.
B
He
called
this
a
shadow
chain
which
is
a
you
know,
honestly,
in
some
ways
a
cooler
name.
Then
then,
or
are
you
I
cut
it
I
kind
of
dig
shadow
chain
but
I?
Also
like
are
you
especially
since
optimism
is
the
name
of
my
my
team?
Okay,
so
here's
a
simple,
optimistic,
roll-up
contractor
shadow
chain
right.
So
let's
define
a
data
structure
which
is
called
the
transition.
B
Right,
so
a
transition
is
a
transitions,
a
tuple
of
TX
and
state.
Now
the
simplest
way
to
have
a
roll-up
chain
is
you
have
a
array
of
transitions
and
anyone
can
call
propose
new
trend.
This
is
you
know,
extremely
simplified,
but
it'll
get
the
basic
idea
across
propose
new
transition
right-
and
this
will,
you
know,
obviously
accept
a
you
know:
TX
state
right,
it'll
accept
this
transition
object
right
and
this
will-
and
this
will
append
to
a
so.
This
will
append
to
a
list
of
transitions
right,
so
I'll
I'll
called
T
0.
A
B
Is
correct:
yeah,
that's
a
totally
good
point,
so
this
is
like
very,
very
naive
implementation,
so
you're
absolutely
right
in
the
scenario
in
which
anybody
can
call
propose
new
transition.
This
would
be
a
very
unfortunate
roll
up
scheme
because
you
would
have
this
race
condition
and
you
would
probably
end
up
with
the
property
that,
like
only
one
person,
would
be
able
to
sort
of
make
a
valid
thing.
You
know
admission
proposal
per
block
and
it
would
just
happen
to
be
the
the
you
know.
B
The
person
who
paid
the
most
gas
right,
the
person
who
wins
the
prior
to
gas
auction,
so
you're,
absolutely
right.
So
one
simple
way
to
remedy
that
is
to
imagine
that
a
single
party
is
allowed
to
propose
these
new
transitions
right,
and
that
would
be
a
simple
way
to
resolve
this.
That
single
party
knows,
do
you
know
the
exact
ordering
and
the
states
that
are
coming
down
and
they
can
propose
it
right.
A
B
Course
that
would
have
a
problem
that
would
have
that
person
went
offline
right
and
then
and
then
that
person
would
disappear
so
a
better
way
to
so
a
better
way
to
do
things.
You
know
I
mean
well,
maybe
maybe
just
to
finish
this,
this
analogy
very
quickly
right.
There
would
be
one
other
function
here,
which
would
be
prove.
B
B
So
what
the
last
thing
to
do
after
we've
started
putting
you
know
this.
This
array
of
transitions
on
chain
is
would
be
to
prove
that
a
transition
is
fraudulent
right.
So
how
would
you
do
that?
You
would
check
that
you
know
for
index
I
right,
okay,
let's
just
let's
just
use
I
for
the
simplicity
of
writing,
so
you
would
check
that
TR
I
minus
one.
Oh
sorry,
actually
let
me
rewrite
that,
so
we
would
prove
that
I'll
scroll
down
a
little
bit
nice.
B
B
T,
our
I
minus
1,
dot,
state,
comma
T,
our
I
dot,
T
X
is
not
equal
to
TR
I
dot
state
right,
so
there
would
be
the
basis
of
a
frog
proof.
You'd
say:
hey:
this
person
lied,
they
put
down
a
a
transition
and
they
said:
if
you
apply
this
TX
to
the
head
state,
then
you
will
get
this
new
head
state
right,
and
so
we
can
prove
that
this
is
not
the
case
right
and
maybe
we'll
even
maybe
even
we'll
go
we'll
get
a
little
color
color
get
up
in
here.
B
B
B
This
exactly
right
exactly
right,
exactly
right,
so
that
that
is.
That
is
definitely
the
case
is
that
this
state
is
going
to
get
very,
very
big
over
time
and
and
notably
right,
notably
the
the
array
of
transitions
that
we're
storing
here
is
being
stored
on
chain,
and
so,
if
we
said
that
would
be
like
storing
instead
of
the
difference
in
this,
you
know
we,
maybe
you
could
improve
by
storing
the
difference
in
the
state
right,
but
you're
still
storing
them
in
the
night.
B
A
B
Is
a
that
is
correct,
and
actually
that
is
where
the
term
roll-up
comes
from
so
which
actually
came
from
ZK
roll-up,
so
you
do
there.
There
are
basically
two
things
you
you.
What
you
end
up
with
is
a
hash
of
the
transaction
and
a
hash
of
the
the
state
and
in
fact-
and
in
fact
of
course
you
can
do
it
as
an
accumulator,
so
it
doesn't
have
to
be.
You
know
a
linear
number
of
hashes.
You
can
have
it
be
a
logarithmic.
B
B
It's
a
large
number
of
transactions
are
submitted
all
at
once
and
you
store
a
miracle
root
of
them
because
you
might,
you
might
have
100
transactions,
but
you
only
need
one
particular
transaction
that
where
things
were
fraudulent,
so
you
store
Merkle
groups,
and
this
is
colloquially
known
as
roll-up
right,
and
so
this
is
what's
done
on
CK
roll-up.
This
is
what's
done
in
optimistic
grow
up,
and
the
idea
is
that,
even
though
we
only
store
the
hash
of
the
transaction
on
chain,
it
only
the
hashes
in
the
state
within
the
chain.
B
History
is
the
entire
transaction
right,
because
anyone
who
wants
to
come
to
the
chain
later
on
and
verify
needs
to
be
able
to
get
this
transaction
in
the
first
place,
to
verify
that
the
hash
is
correct
right.
Otherwise,
it
wouldn't
know
if
the
the,
if
it
should
reject
the
block
or
not,
and
so
even
though
we've
removed
the
transaction
from
the
state,
it
is
still
there
in
the
history
all
the
full
nodes
had
it
and.
B
B
Oh
well,
you
still
have
to
put
the
transaction
data
on
chain
that
doesn't
sound
scalable
to
me
right,
there's
sort
of
two
reasons
to
think
that
that's
scalable
one
is
exactly
what
you
said
is
that
it's
much
cheaper
to
store
a
piece
of
data
in
the
chains
history
than
it
is
to
store
it
in
the
actual
head
state
of
the
machine.
The
other
reason
is
that
Moore's
Law
has
continued
following
bandwidth
where
it's
beginning
to
drop
on
execution.
So
this
is
a.
This
is
actually
what's
nice
on
computation.
B
Rather
so
this
is
kind
of
a
nice
property
is
that
it
seems
like
Moore's.
Law
is
continuing
for
bandwidth,
which
is
the
only
cost
factor
that
goes
into
the
this.
This
property.
You
know
the
cost,
whereas
execution
is
falling
off.
So
we
keep
the
execution
off
chain,
but
we
keep
the
bandwidth
on
chain.
We
can
keep
following
Moore's
law
right.
A
All
right
and
so
here
so
let
me
quickly,
I,
don't
know
if
you
were
going
to
talk
about
it
next,
but
I'm,
trying
to
see
how
these
signatures
of
this
methods
will
change
once
we
do
not
have
the
entire
list
of
transitions
right,
but
rather
they
have
hashes.
So
if
I'm
proposing
new
transition,
my
transitional
contains
the
immortal
route
of
the
states
right.
That
will
be
the
result
of
applying
the
transaction
right.
A
B
B
Right,
a
subset
with
the
witness
and
one
thing
one
important
note
there
is-
is
that
concept
people,
often
when
people
are
learning
about
that
concept.
There's
a
point
a
moment
time,
which
is
that
concept
really
clicks,
which
is
that
this
is
very,
very
similar
to
what's
called
the
stateless
client
in
aetherium
and
maybe
a
little
bit
more
broadly
in
crypto
now
right.
B
A
A
A
Internally,
this
method
will
compute
will
in
into
the
list
of
the
transitions
right.
It
will
append
the
a
lot
of
house
of
transactions
right,
maybe
more
color.
It
may
be
something
else
you
can
and
the
state
route
I
guess
it's
a
it's
a
tuple,
yeah
and
so
effectively.
So
no
transactions
well
I'm,
not
I'm,
not
that
that
that
familiar
with
the
theorem,
but
my
understanding
that,
just
by
calling
this
method
the
transactions
already
in
the
history
right,
because
this
some
sort
of
a
cold
data
right.
A
B
B
A
A
B
B
Roll-Up
called
unipeg:
we
did
that
at
Def
Con
last
year,
there's
a
very
separate
conversation
to
be
had
about
what
it
takes
to
build.
So
there's
like
a
big
there's,
a
big,
separate
question
here,
which
is
this:
this
function
executes
TX
right.
What
does
it
look
like
because
to
really
take
advantage
of
this
solution?
The
applications
built
on
top
of
it
have
to
fit
within
this
execute
TX
function
right,
and
so
you
know
in
our
case,
where
we're
building
this
as
a
layer
on
top
of
a
cerium.
It
becomes
a
very
interesting
problem.
B
That
is
like
application
developer
friendly
right,
because
the
cool
thing
about
this
system
is
that,
because
you
know
you
basically
have
three
properties
right.
One
property
is
that
you
have
the
avail,
an
available
head
state
right,
and
the
reason
for
this
is
because
all
of
the
transaction
data
is
available
for
in
the
chain
history,
and
so
anyone
who
wants
to
can
compute
the
head
state
from
the
available
transaction
data.
We
have
another
nice
property
which
is,
which
is
that
that
it
is
live.
B
At
least
you
know
as
live
as
the
l1,
and
we
have
a
property
that
it's
valid,
because
we
know
that
we
can
go
and
submit
fraud
if
it's
invalid
and
correct
it
so
that
it
is
and
those
three
those
three
properties
are
basically
exactly
the
properties
of
a
smart
contract
system
right
and
now
again
that
was
how
I
started.
This
was
by
saying
what
payment
channels
are
good
for
one
thing,
but
we
need
another
one.
B
So
a
lot
of
the
work
that
we've
put
in
over
the
past
I
know
how
many
months
has
it
been
now
five
months
is
building
this
thing
called
the
ovm,
which
is
a
EVM
contained
container,
so
it
allows
you
to
run
evey
and
EVM
transaction
as
your
execute
T
X
function,
which
turns
out
to
be
a
separate,
very
hard
problem.
So
we've
had
roll-ups
without
that
for
a
while
and
EVM
roll-ups
are
coming
very
soon,
it's
very
exciting
and
some.
B
Actually
don't
know
if
there
are
any
optimistic
roll-ups
running
in
production
today,
I
don't
think
there
are,
but
although
all
the
ones,
the
majority
of
work
has
been
done,
interpreting
things
like
a
state
channel
I
mean
a
payment
system
right,
and
so
you
build
a
very
simple
payment
machine.
We
did
a
demo
with
with
it
which
used
the
unit
swap
functionality,
and
we
simply
hard-coded-
and
you
know,
swap
transition
function
that
we
had
to
write
mm-hmm.
A
B
It's
not
as
naive
as
Oh
a
theorem
is
incomplete,
so
we
implement
the
EVM
in
a
theory,
oh
yeah.
That
turns
out
to
be.
You
know
a
very
difficult
task:
yeah
yeah,
so
the
ovm
work
just
a
little
bit
differently
it.
Instead,
it
just
adds
a
container
contract
which
sort
of
enforces
that
another
contract
is
running
in
a
sandboxed
environment.
B
A
A
B
B
Below
there,
so
the
simplest
way
to
remedy
this
problem
of
well,
who
has
the
responsibility
to
submit
these
to
submit
these
transactions?
And
why
should
we
trust
them
to
not
halt
our
coins
or
censor
our
transactions
right?
The
simplest
way
is
to
split
the
function.
The
proposal
function
into
two
functions,
so
you
have
proposed
T,
X
right
where
you
you
know
you
send.
B
You
know,
maybe
a
batch
of
transaction
things
right
and
then
you
say,
propose
you
know
state
route
right,
SR
and
that
would
be,
and
that
would
be
a
batch
of
you
know,
of
state
routes
or
maybe
just
one.
Maybe
you
append
them
one
at
a
time
and
that
that
is
how
that
is
like
at
its
core.
The
way
that
you
the
way
that
you
enable
this
right.
B
Yeah,
so
there's
there's
a
few
different,
there's
a
lot
of
different
models
that
you
can
go
by
generally
state
route
proposal
because
it
costs
gas
to
prove
fraud.
State
route
proposal
should
be
bonded
right,
so
there
should
be
some
money
associated
with
state
route
proposal,
and
so
maybe
you
say
the
person
who
made
that
bond
you
can
make
the
bond
to
be
at
the
time
that
you
propose
the
state
route.
You
can
even
have
a
state
route
proposer.
B
That
is
the
person
with
the
highest
bond
right
and
so
that's
you
know,
that's
one
note
associated
with
state
route
proposal
in
principle,
though
it
can
be,
anyone
and
anyone
who
proposes
an
invalid
state
can
be
can
be
penalized,
and
so
one
one
important
note
here
right
is
that
an
invalid
state
route
does
not
affect
the
chain,
the
the
the
liveness
properties
of
the
chain.
Right,
so
let's
say
like
here:
let's
say
we
have
like
these
two
chains
and
the
top
chain
is
a
chain
of
texas
right,
so
we
have
like
TX
0
right.
B
You
know,
then,
you
can
like
add
a
new
one
right
and
then
we
can
add
another
one
and
another
one
gets
added
on
right.
Well,
let's
say
over
here
like
State
Route
is
proposed
here
and
then
State
Route
is
proposed
here
and
then
State
Route
is
proposed
here
and
it's
like
it's
red.
We
don't
we
it's
a
bad
state
route
proposal
right,
everyone,
who's,
honest
who's,
watching
the
transactions
knows
that
it's
invalid
and
knows
what
the
real
state
is
going
to
end
up
being
resolved
to.
A
B
I
think
in
in
practice,
there's
a
few
practical
considerations
here.
So
one
of
the
practical
considerations
is
that
the
ability
to
have
a
lie
can
party
that
aggregates
many
transactions
and
submits
them
all
at
once
is
like
a
very
useful
service
provider,
and
it
also
affords
some
gas
benefits
because
it
can
amortize
some
of
the
gas
costs
as
well
as
as
well
as
there's
other
crazy
things.
B
So,
in
the
long
term,
what
you'll
be
able
to
do
is
use
BLS,
signature,
aggregation
and
you'll
be
able
to
aggregate
a
bunch
of
users
transactions
to
have
only
one
signature,
and
so
then
in
roll-up
gets
really
cheap
because
you,
you
amortize,
the
cost
of
you
know
what
would
normally
be
a
65
byte.
You
know
ECS
a
signature,
so
this
service
provider
and
kind
of
needs
to
be
there,
and
it's
very
useful,
so
pragmatically
speaking,
usually
will
have
the
that
person
be
just
one
that'd,
be
just
one
person
with
the
property.
B
A
That
makes
sense,
oh
so
so
so
one
thing
I
wanted
to
discuss
briefly
was:
it
was
like
slightly
orthogonal
to
everything
we
discussed
before
I
was
I,
was
I
wanted
to
discuss
sort
of
the
future
with
multiple
optimistic
roles,
but
if
there's
something
else
fundamental
we
didn't
discuss
yet
we
should
probably
do
that.
First
sure.
B
Yeah
I'll
talk
about
well,
there's
a
couple
other
other
interesting
things.
So
one
one
one
interesting
note,
and
is
that
if
we
stay
here-
and
you
know
look
at
these
state
routes
right,
these
state
routes
have
a
have
a
they
have
a
cost
right.
There
are
32
byte,
hashes
of
call
data,
and
so
there
are
more
complex.
There
are
more
complex
dispute
games
that
you
can
build
that
basically
allow
you
to
optimistically
skip
state
routes
in
the
middle.
A
B
B
We
both
disagree
about
the
state
route
here,
let's
see,
if
we
disagree
about
the
state
route
in
the
middle
and
then
we
both
say
what
we,
what
we
think
it's
going
to
be
in
the
middle
and
we
say:
okay,
we
agree
about
the
middle
one,
so
it
must
be
one
of
these
two
guys.
So
what
do
you
think
for
this
one?
And
you
eventually
find
exactly
where
the
source
of
the
dispute
really
is.
So
that's
one.
That's
one
other
interesting
optimization,
but.
B
Does
it
has
become
interactive,
yeah
and
so
there's
like
it's
definitely
very
nice
to
have
a
system
that
is
not
interactive,
but
it
is
something
you
can
do
another
property
that
I
will
shout
out.
That
is
unique.
That
is
somewhat
tangential,
although
we
find
it
conceptually
easier
to
think
about
it
at
the
at
the
add
the
at
the
roll-up
level,
but
really
you
can
think
of
it,
you
could
implement
it
on
the
application
level.
B
Is
one
really
nice
feature
about
having
a
single
sort
of
person
who
is
going
to
roll
up
these
transactions?
Is
that
that
person
has
strong
private
knowledge
about
what
the
state
is
going
to
be,
and
it
has
knowledge
of
that.
You
know
in
in
like
basically
an
instant
latency
right
as
soon
as
it
makes
the
decision
of
how
it's
going
to
post
some
transactions.
It
knows
what
the
future
state
of
the
system
will
be.
Mm-Hmm.
A
B
So
this
is
a
nice
property,
because
if
you
trust
that
person
or,
and
especially
in
some
applications,
it's
especially
useful,
if
you
that
you
can
believe
that
this
person
will,
you
know,
makes
me
be
sign.
A
tribute
Abul
promise
that
they
will
include
your
transaction
and
they'll
go
do
it,
and
this
gives
you
some
really
nice
user
experience.
Of
course
it
comes
with
the
problem
of.
B
It
comes
with
the
problem
of
censorship
that
we
talked
about,
where
how
do
you
prevent
this
party
from,
for
instance,
not
including
your
transactions
and
then
you're
unable
to
withdraw,
and
so
what
you
can
do
is
you
can
have
a
slow
q,
u--
e
and
egg-like
canonical
transaction
chain.
So
this
is
this
is
what
we
do
at
our
implementation
and.
B
On
the
layer,
one
exactly
right
exactly
right
and
we're
building
up-
and
you
know
maybe
let's
say
we're,
building
up
this
canonical
TX
chain
here
now.
What
you
do
is
you,
you
implement
a
small
time
delay
between
the
time
at
which
the
a
transaction
was
put
into
the
slow
queue
right
and
then
it
must
be,
and
then,
after
this
time
elapses,
it
must
be
moved
into
the
canonical
transaction
chain.
There's
no
other
valid
action
other
than
moving
it
into
the
canonical
transaction
Shane.
B
But
in
the
meantime,
in
the
meantime,
you
know
in
this
short
period
of
time
in
which
it
sits
in
the
queue
you
can
have.
One
party
which
we
call
the
sequencer
and
that
sequencer
can
insert
transactions
in
front,
and
this
allows-
and
this
allows
the
sequencer
to
continuously
provide
instant
promises
and
have
private
knowledge
of
exactly
what
the
state
will
be,
while
still
maintaining
the
censorship
resistance
properties
via
this
sort
of
escape
hatch,
slow
queue
mechanism
right.
So
you
can
get
crazy
with
these
sorts
of
designs.
So.
B
That's
right,
that's
right
and
and
of
course,
they
pay
a
non
change.
It's
still
a
rollup
transaction
right,
so
they
other
than
this
like
amortization
cost
that
we
were
talking
about
those
costs
are
very.
Very
those
cost
will
be
very,
very
similar,
so
yeah
in
the
worst
case
they
can.
They
can
push
them
into
the
other
chain
yeah,
and
that
gives
you
some
really
nice
UX
for
a
lot
of
applications.
Yeah.
A
And
so
I
guess
another
question
they
have
is
because
all
the
transactions
still
end
up
on
the
etherium
blockchain
right
I
think
there
are
two
interesting
aspects
to
it.
So
one
of
them
says
that,
while
the
first
optimistic
crough,
which
comes
the
theorem,
will
scale
quite
a
lot
right,
you
can
note
you
cannot
scale
it
so
effectively.
All
the
optimistic
hopes,
combined
collectively
will
of
the
scale,
be
the
same.
A
The
time
to
say
is
that
with
the
so,
for
example,
with
the
state
channels
right
you
mentioned
at
the
beginning
that
it
is
in
theory,
it
can
scale
infinitely
right.
So
if
we
open
1
million
state
channels,
it
will
be
one
half
times
more
more
transactions
per
second
right,
then,
a
single
state
state
channel,
while
with
the
optimistic
roll-ups,
no
matter
how
many
optimistic
roll
ups
turn
from
from
different
entities,
potentially
right
operate
on
the
theorem,
they
collectively
have
the
same
throughput
as
a
single,
optimistic
roll-up
would
have
on
the
theorem
right,
yeah
yeah.
B
So
the
that's,
correct
and
I
try
to
live
to
this
earlier
by
saying
that
we
should
be
optimal
like
what
are
the
bounds
of
that
of
that.
What
what
aren't?
What
are
those
limits
right?
There's
limits
aren't
very
large
right
like
if
we
look
at
like
high
powered
data
availability.
You
know
sort
of
engines
like
you
know,
ease
to
right
as
an
example.
Well,
I,
you
know
the
last
time
we
did
the
numbers.
You
know
you
get
like
100,
100k,
TPS,
pretty
easily
right
and
I
hate.
B
B
A
B
B
A
And
another
interesting
thing
is
so
assuming
that
for
a
while
up
to
mystic
ropes
are
going
to
run
even
the
thin
one
point
all
right.
If
we
do
like
very
quick
computation,
it
seems
that
so
let's
say
majority
of
computation,
most
optimistic
roll-up,
then
a
theorem
block
size
will
increase
dramatically
right.
So
today,
when
everything
is
like
20
kilobytes
right
and
then
it
would
become
the
content,
kilobytes
or
200
kilobytes
per
block.
B
So
I
mean
currently
currently
like
aetherium
is
lobbying
to
bring
to
like
so
I.
Don't
know
how
many
months
ago
was
now
could
have
even
been
closer
to
a
year
than
then
measuring
in
months
ago
now,
but
recently
actually
lowered
the
cost
of
called
data
way
down,
particularly
to
support
roll-ups,
because
because
it
was,
it
was
considered
and
it
seemed
like
call.
Data
was
overpriced
and
that
we
weren't
gonna
kill
the
uncle
rate.
If
we
do,
this
I
see.
B
Smart
people
didn't
think
about
it
and
there's
even
proposals
to
lower
it
further
another
and
like
another
and
other
obvious
step
that
you
can
take
is
you
can
basically
add
a
you
know,
a
new
opcode
to
the
EVM
or
like
a
new
pre-compile.
However,
you
want
to
think
about
that.
Allows
you
to
simply
check
the
availability
of
data,
and
that's
all
that
you
can
do,
and
you
know
maybe
it
automatically.
A
So
there's
one
interesting
topic
which
many
many
proponents
of
ZK
roll-ups
bring
up
right,
that
if
you
have
quite
a
quite
a
bit
of
assets
in
the
optimistic
crawl
up,
it
might
become
reasonable
for
for
the
miners
to
get
involved
and
stop
censoring
the
disputes
right
for
sufficiently
long
until
until
there
is
a
until
the
dispute
period
ends
right.
So
so
is
it.
Is
it
a
valid
concern
and
are
there
any
ways
to
get
around
it.
B
B
You
can
do
about
this,
particularly
on
each
one
now,
outside
of,
like
you
know,
governance
concerns
so,
like
you
know,
if
I,
if
I
miss
food
period
is
gonna
end
up
being
a
week,
if
the
Assyrian
chain
was
51%
attack
or
censorship
attacked
for
a
week,
would
there
you
know?
Would
there
be
a
governance
saying
where
you
know
people
decide
to
fork?
Who
knows
you
know
hard
to
say
in
in
East
2.0,
like
user,
you
know
user.
B
You
know
soft
Forks,
for
you
know
for
like
sort
of
subjective
realizations
of
censoring
or
is
going
to
be
a
part
of
the
part
of
the
protocol
and
the
you
know
social
consensus
around
what
Paul
so
we're
helped
there
with
having
said
I'm
a
huge
fan
of
zero
knowledge
groups
like
if
there
was
a
zero
knowledge
EDM
that
I
thought
was
a
short-term
Bible.
I
would
be
jumping
all
over.
B
That,
like
our
goal,
is
to
be
very,
very
pragmatic,
we're
not
tied
to
optimistic
roll-up,
because
it
is
the
scaling
solution,
we're
tied
to
it,
because
it
gives
a
reasonable
set
of
properties
that
we
think
are
worthwhile
and
it
does
it
today.
So
if
you
know
when
ziran
windsor
knowledge,
proofs
start
going
crazy
and
are
way
easier
to
develop
on
and
so
on
and
so
forth,
we
totally
should
have
more
zero
knowledge
groups.
You
know,
I'm
a
huge
fan,
huge
fan,
awesome.
A
And
the
last
question
I
have
is
certainty
in
terms
of
optimistic
roll-ups
appearing
in
production.
The
other
thing
is
going
to
be
more
like
a
single
chemist
acrylic,
which
has
multiple
contracts
which
interact
with
each
other
within
a
single
state
right
within
a
single
VM
or
like
I.
Don't
know
how
to
like
with
a
single
container
right,
or
do
you
envision
it
more
like
multiple,
optimistic
ropes
that
have
a
way
to
communicate
between
them,
and
if
the
latter,
then
how
the
communication
will
happen,
it's.
B
A
really
good
question-
and
there
are
limitations
after
which
you
know
verifier
costs-
are
going
to
get
so
large
that
if
users
aren't
willing
to
accept
those
verifier
costs
or
they're,
not
willing
to
accept
that
there
exists
out
there,
one,
you
know
honest
verifier,
then
you
they
and
you
may
need
to
to
to
spread
them
out.
So,
especially
in,
like
you
know,
super
quadratically,
crazy,
sharded
systems,
where
the
amount
of
available
data
is
just
insane
and
that
computation
is
insane
then
you're
going
to
need
multiple
roll-up
chains.
B
In
the
short
term,
we
have
pre,
have
put
a
strong
emphasis
on
making
a
rollup
chain
that
supports
contract
deployment
and
supports
the
sort
of
money.
Lego
features
that
we
see
on
a
cerium.
The
only
other
thing
I
was
going
to
say
is
those
like
tools
like
I,
actually
think
you
guys
at
near
are
doing
a
great
job
of
like
I.
B
Think
you
guys
have
an
async
await
for
cross
shard
communication
or
whatever,
like
asynchronous
communication
between
apps
in
the
decentralized
context,
is
going
to
be
super
important,
but
it's
not
there
yet
I,
don't
think
so.
I
would
say
that
one
other
one,
one
thing
that
has
less
whiteboard
II
to
call
out
is
that
this.
This
screen
that
we
have
right
here
actually
with
this
sequencer,
is
related
to
a
really
cool
sort
of
economic
construction
that
we're
working
on
called
neva,
minor
extractable
value
auctions,
mm-hmm.
A
B
Basically,
the
idea
is
that
this
purpose
sequencers
ability
to
order
transactions
the
that
privileged
position
in
addition
to
enabling
you
to
give
out
these
sort
of
low
latency
promises
of
what
you're
going
to
decide
the
state
is
that
prioritized
position
is
like
very
valuable
and
more
normally.
That
value
goes
to
minors
and
frontrunners,
and
we're
super
excited
that
in
layer
two,
you
have
a
nice
clean
way
to
actually
be
able
to.
B
Basically,
you
know
sell
that
that
right
off
and
repurpose
that
to
do
something,
that's
much
more
useful,
like
public
looks,
Goods,
funding,
right
or-
or
you
know,
I
know
you
guys
are
doing
cool
stuff
with
like
giving
out.
You
know,
rewards
to
people
based
on
the
gas
that
their
contracts
used.
So
we
think
that
being
able
to
sell
off
the
right
to
be
a
sequencer
is
an
awesome
way
to
like
monetize
get
rid
of
something
that
users
see
is
a
downside
by
turning
into
a
good
thing.
So
that's.