►
From YouTube: Understanding L2: Ordering and Execution
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 IPFS and more.
https://archive.devcon.org/archive/watch/6/understanding-l2-ordering-and-execution-aka-everything-youve-always-wanted-to-know-about-sequencers-but-were-afraid-to-ask/
Overview of design patterns in handling ordering and execution; will cover separation of roles between sequencers and validators, tradeoffs in different ways handing execution & ordering, current approaches — i.e., what various L2 rollups are doing in production, what is and isn't possible in principle.
Speaker(s): Daniel Zachary Goldman
Skill level: Advanced
Track: Layer 2s
Keywords: Layer 2,Decentralization,Ordering
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
Hello,
everyone
thank
you
for
coming
or
for
staying.
Those
of
you
who
stay
at
past
Patrick's
talk,
I,
understand,
I,
don't
have
his
Celebrity
Status,
but
yeah
I
will
be
talking
about
sequencers,
Layer,
Two
sequencers
and,
more
generally,
the
principles
of
ordering
and
execution
it'll
be
sort
of
a
survey
of
the
design
space.
A
There
we
go
cool,
so
the
stuff
that
we'll
be
covering
stuff
we'll
be
covering
I'll
start
with
sort
of
an
introduction
into
sort
of
the
motivation
and
design
rationale
of
kind
of
what
sequencers
are
and
why
we
even
have
them
to
begin
with.
On
Layer
Two,
we'll
talk
about
the
current
state
of
sequencers
in
the
layer,
2
World.
A
Basically
that
they're
centralized
but
they'll
be
a
little
more
to
say
than
just
that
and
then
focus
on
ways.
We
can
sort
of
improve
this
state
of
affairs,
trust
minimizing
them,
decentralizing
them
sort
of
limiting
sequencers
power
in
various
other
ways,
and
then,
if
there's
time,
we'll
sort
of
wax
theoretical
about
how
these
Concepts
could
apply
to
layer,
one
to
what
extent
they
do
to
what
extent
they
don't
but
we'll
see
how
things
go.
A
So
the
Baseline
starting
point
for
what
a
layer
two
is
is
we're
trying
to
scale
ethereum
while
not
introducing
new
trust
assumption
so,
inheriting
security
from
ethereum?
That's
our
starting
point.
The
scaling
part
is:
we
want
to
improve
the
status
quo
of
what
ethereum
is
like
to
use
in
in
some
other
ways,
there's
all
sorts
of
ways.
A
You
can
use
a
lot
of
the
same
tools
it
feels
very
similar,
but
the
key
the
kind
of
key
trick
that
Roll-Ups
use
as
layer
twos
is
they
require
that
you
publish
transaction
data
on
layer,
one
itself
and
by
doing
so
in
a
roundabout
way
that
I
won't
get
into
that
is
sort
of
how
we're
doing
that's.
How
we're
able
to
claim
that
these
things
are
trustlers
that
they
inherit
L1
security,
so
be
a
layer
two
magic.
A
We
can
sort
of
enforce
the
safety
of
the
layer,
2
Tran
of
the
layer,
2
Chain
after
data
is
published,
but
essentially
all
we're
doing
is
publishing
data
as
far
as
layer,
one
is
concerned,
so
all
of
the
other
work
that
goes
into
processing
a
transaction
validating
it.
Updating
the
state
that
happens
in
a
separate
environment,
we're
not
using
layer,
1
resources,
so
we
can
make
things
cheaper,
so
long
story
short
by
publishing
data
on
layer,
one
we
get
trustlessness.
A
We
need
that
yeah
we
get
cheaper
transactions,
meaning
that
that
the
other
thing
we
said
we
wanted
or
top
of
the
list
of
things
we
wanted
was
fast
transactions
right,
so
do
rollups.
Give
you
fast
transactions,
it
turns
out,
is,
is
kind
of
a
loaded
question
right.
So
if
you,
if
you've
used
any
Roll-Ups,
you've,
probably
noticed
it's
faster
than
using
layer
one,
but
it
sort
of
depends
what
we
mean
by
fast
transactions
and
even
right
here
with.
What's
on
this
slide,
we
can
see
we're
gonna.
A
We
have
a
bit
of
a
contradiction
here
right
by
fast.
We
mean
faster
than
layer
one,
but
what
I
said
is
that
the
requirement
of
Roll-Ups
is
that
we
post
data
on
layer,
one.
You
can't
go
faster
than
layer,
one
by
posting
data
on
layer,
one
because
that's
a
circular
problem,
or
perhaps
the
Triangular
problem,
I'll
I'll,
be
honest.
The
slide
probably
isn't
necessary,
but
I
really
wanted
to
include
a
trilemma
somehow.
So
this
is
a
new
trilemma
I.
A
Don't
expect
it
to
catch
on,
but
this
is
another
way
of
thinking
about
the
sort
of
situation
we're
in
with
Roll-Ups
right.
We
have
this
nice
feature
of
open
participation,
that's
kind
of
directly
Downstream
from
the
fact
that
we
publish
data
on
layer
one
so
we
can
have
trustlessness.
But
that
means
we
can't
quite
have
fast
finality.
We
can
only
have
two
of
these
things.
There's
other
L2
designs
called
channels
which
give
us
fast
finality
and
trustlessness,
but
those
the
ux
is
very
different.
A
They
don't
have
the
flexibility
of
Roll-Ups
and
so
on.
So
we
kind
of
have
to
decide
where,
in
the
design,
space
we're
going
to
live
and
in
fact,
by
the
way,
if
you,
those
of
us,
the
arbitrary
emojis
in
the
crowd,
who've
followed
our
first
test
net
release.
It
was
actually
you
know
it
had
no
notion
of
fast
transactions.
A
It
was
entirely
like
that
diagonal
line,
the
one
that
says
roll
ups
right
and
as
we
put
that
out,
one
of
the
questions
we
kept
getting
was:
okay,
it's
Layer
Two
are
we
gonna
get
fast
transactions
and
we
kind
of
just
said:
no,
that's
not
really
possible,
but
there
was
clearly
demand
for
it
right.
So
we
kind
of
reached
this.
This
point,
this
kind
of
Middle
Ground
settlement
where
we
said
okay,
what?
If
we
can
provide
a
fast
path?
A
That's
trusted,
but
it's
optional,
and
we
were
not
the
first
layer,
two
team
to
come
up
with
this,
or
do
this
by
any
means
pretty
much
all
I'll
do
is
do
this.
We,
in
fact
we
were
actually
came
around
to
this
idea
later,
and
the
idea
here
is
you
you
can
imagine,
so
you
have
a
situation
where
there's
some
party,
a
user,
can
trust
them.
The
Trusted
party
says
I
promise
to
include
your
transaction
later
and
then,
hopefully
later
it
does.
A
That's
basically
what
it
comes
down
to
the
sort
of
version
of
this
that
doesn't
work.
The
naive
solution.
Is
you
let
a
user
trust,
whoever
they
want
whomever
they
want.
So
if
the
user
just
decides,
I
trust
this
random
party
that
party
promises
to
include
their
transaction.
Even
if
the
party
is
trustworthy,
this
doesn't
quite
work
because
that
party
can't
really
predict
the
future
and
even
if
it
thinks
it
will
include
your
transaction
in
a
given
order,
someone
else
kind
of
might
get
there
first.
A
A
So
the
sequencer,
in
other
words,
is,
is
literally
this
party
that
we
give
the
ability
to
directly
post
transactions
into
L2.
Everyone
else
kind
of
has
to
wait.
So
the
sequencer
has
this
narrow,
short-term
view
of
what
will
happen
on
L2.
Therefore,
it
can
give
trusted
trusted
kind
of
soft
confirmation
transactions.
A
We
call
them
so
just
sort
of
recap
that
for
those
who
just
saw
Patrick's
talk,
this
is
a
bit
redundant,
so
I'll
go
quickly,
but
when
we
introduce
a
sequencer,
the
sort
of
life
cycle
of
a
transaction
looks
something
like
this:
the
normal
in
the
sort
of
normal
State
of
Affairs,
the
user
kind
of
gives
their
transaction
off
to
the
sequencer.
The
sequencer
immediately
gives
This
Promise
totally
trusted
that
says.
A
I
will
include
your
transaction
later
at
some
point
later
in
the
case
of
arbitrum,
usually
every
few
minutes,
It'll
post
a
batch
of
transactions
on
chain,
and
at
that
point
the
sequencer
is
kind
of
out
of
the
picture
once
it's
on
chain
we're
in
full
roll-up
mode,
full
trusted
mode.
It's
committed
to
this
particular
ordering
and
as
far
as
a
user
is
concerned,
your
transaction
is
as
finalized
as
a
layer,
one
transaction
right,
because
all
of
the
data
is
available
there.
Anybody
can
execute
it.
A
Anybody
can
see
what
the
final
state
will
be,
the
actual
explicit,
explicit
claim
or
commitment
to
what
that
final
State
actually
is
happens
later
and
the
sequencer
is
not
involved,
and
that's
that
third
step
there.
The
validator
asserts
the
state,
but
there's
no
rush
to
do
that.
That's
really
just
so
that
we
can
communicate
back
to
layer
one
and
process
withdrawals,
but
from
the
layer
if
you're,
just
interacting
on
Layer
Two,
once
your
data
is
on
chain
you're
done.
A
So
that
gives
us
this
way
that
we
can
get
this
nice
fast,
low,
latency,
fast
transaction
path
trusted
if
you
want
to,
but
it's
optional,
and
that's
very
important,
so
just
to
drill
that
point
home,
because
you
should
be
suspicious
when
I
start
saying
it's
optional.
What
does
it
mean
that
using
the
sequencer
is
optional?
Well,
if
in
the
sort
of
normal
case
the
system's
working?
A
Well,
if
the
sequencer
gives
you
this
fast
promise,
you
can
just
ignore
it
and
say
screw
you
I,
don't
care
what
you
say:
I'm
going
to
wait
for
you
to
post
on
chain,
so
it
takes
another
few
minutes,
and
then
you
get
the
full
sort
of
trustless
finality
in
the
unhappy
case
where
the
sequencer
just
goes
Rogue
and
isn't
even
answering
anything,
there
is
still
a
way
that
you
can
do
anything.
You
want
on
arbitrum
there's
this
sort
of
alternative
path.
A
Basically
long
story
short,
it's
a
lot
slower,
I
think
Patrick
talked
about
this
well
I'm
gonna!
Stop
talking
about
him,
but
it's
on
my
mind
but
yeah.
The
point
is
the
system
can
work
in
a
sort
of
slower
way
and
a
slightly
more
inconvenient
way.
It
can
work
without
the
sequencer
entirely.
So
it's
entirely
optional
and
that's
why
we
can
still
call
this
thing:
a
layer,
two
and
and
and
sleep
at
night.
A
So
I've
just
been
talking
about
the
sequencer
like
it's
my
friend
or
something,
but
you
know
what
actually
is
it?
And
basically
you
know
it.
We
just
Define
the
sequencer
as
what
as
this
entity
that
can
give
these
fast
promises
that
has
all
the
properties
that
I
had,
but
you
might
ask
you
know
how
does
it
decide
which
transactions
to
include
who
controls
it
in
what
order
of
these
transactions
go
and
so
on?
A
And
you
know
basically
the
design
space
for
what
the
sequencer
is
is
pretty
open
it
could
it
could
be
anything
right,
it's
going
to
be
controlled
by
some
smart
contract
you
could
swap
in
whatever
sort
of
mechanism
you
can
think
of,
with
the
one
caveat
that,
because
the
whole
point
is
to
get
fast
transactions,
whatever
mechanism
we
use
can
involve
interacting
with
layer
one
because
that
just
defeats
the
whole
purpose
at
least
the
way
I
see
it.
The
way
we
see
it,
other
people
would
describe
it
differently,
but
yeah.
A
A
Is
that
they're
centralized
somebody
did
something
Fancy
on
a
layer,
two
that
I
don't
know
about.
You
can
yell
at
me
afterwards.
I
apologize,
but
generally
speaking,
sequencers
are
centralized.
That's
the
status
quo
and
you
know
we
get
asked
about
this
a
lot.
It's
probably
the
most
frequent
question
that
has
to
do
with.
Like
you
know,
Progressive
decentralization
and
decentralization
roadmap
is
like.
When
are
you
decentralizing
to
see?
And
it's
it's
not
a
bad
question.
It's
a
good
question.
A
It's
a
good
thing
to
ask
about,
but
I
think
often
it
comes
from
a
bit
of
a
misunderstanding.
So
this
kind
of
there's
kind
of
two
things
to
say
to
this.
This
issue
of
centralized
sequencers
and
the
first
thing
is
it
might
not
be
as
bad
as
it
initially
appears,
specifically
centralized.
Sequencers
I'm
suddenly
nervous
someone's
gonna
like
screenshot
this
slide.
If
you're
going
to
screenshot
this
slide
screenshot
the
next
one
too.
A
That's
all
I
ask
okay,
because
the
next
one
is
very
important:
I'm
not
claiming
centralization
are
fine,
but
the
first
half
of
the
answer
is
the
power
that
a
sequencer
had
is
very
limited
and
circumscribed
right.
It
can't,
for
example,
simply
steal
money
from
the
system
and
it
can't
lock
up
users
funds
forever,
so
so
other
parts
of
the
system
are
sort
of
more
important,
even
a
centralized
sequencer.
Arguably,
could
you
know
you?
Could
you
could
argue
that
an
L2
could
just
have
a
centralized
sequencer
for
good?
A
That
wouldn't
be
the
end
of
the
world,
and
the
other
thing
that's
worth
saying
here
is
that
you
know
again
on
just
about
every
L2,
certainly
arbitrum
included
in
the
current
state
of
affairs.
They
all
sort
of
have
more
fundamentally
centralized
Parts.
Even
if
we
said
hey,
we
decentralized
the
sequencer.
If
we
didn't
take
care
of
those
other
things,
it
sort
of
doesn't
really
give
you
anything.
You
can
read
more
about
that
on
our
docs
or
l2b,
but
you
know
we
don't
want
to.
A
We
don't
want
to
mislead
by
emphasizing
one
thing
and
not
another,
so
those
other
things
contract
upgrade
ability.
The
power
validators
have.
Those
are
the
things
that
you
you
know.
If
you
want
to
spam,
our
Discord
about
something
those
are
the
more
important
things,
don't
spend
more
Discord.
You
know
what
I
mean:
okay,
important
follow-up,
obviously
having
a
centralized
sequencer
is
not
ideal.
Looking
at
the
time
I'm
going
to
try
to
speed
up
a
little.
So
what
can
a?
What
can
a
decent?
What
can
a
centralized
sequencer?
Do
that's
bad!
A
Well,
even
if
it's
honest,
honest
mistakes
happen
right,
so
even
an
honest
sequencer
could
have
downtime
because
of
infrastructure
failures
and
server
issues,
and
that's
bad
because
it
sort
of
slows
the
whole
system
down.
It's
very
inconvenient,
I'm
gonna
skip
over
one
thing
in
there.
The
juicier
stuff
is
what
if
the
sequencer
is
actually
malicious,
it
just
turns
evil.
What
can
it
do?
Well,
it
can
equivocate.
In
other
words,
it
can
make
one
of
these
promises
and
then
not
make
good
on
it
later.
A
It
can
make
inconsistent
promises
to
different
users
right
these
fast
transactions
are
trusted.
It
can
violate
that
trust.
It
can't
censor
you
technically,
but
it
can
temporarily
censor
you
right.
So
if
it
stops
processing
your
transaction
you'll
be
able
to
get
it
through
eventually,
and
we
like
emphasizing
that
fact,
but
the
also
important
fact
is,
there
is
a
short
window
of
time
that
you'll
have
to
just
wait
and
that
also
could
suck
right
being
unable
to
transact
for
some
number
of
hours
might
be
a
real
problem.
A
The
sequencer
can
do
that
to
you
and
then
finally,
the
kind
of
elephant
in
the
room
here
is
Emmy
V.
Okay,
so
all
I
want
to
say
here
there's
plenty
of
other
talks
about
mov
people
who
you
know
have
more
and
more
interesting
things
to
say
about
it,
maybe
than
I
do
I'm,
not
an
expert
I,
don't
even
know
what
the
m
stands
for
it's
unclear
at
this
point.
It
was
minor.
Now
it's
maximum
I
learned
when
I
was
procrastinating.
A
Has
this
side
effect
that
the
sequencer
has
control
over
transaction
ordering,
which
means,
if
it's
economically
interested
it
might
use
this
to
extract
value.
Whether
this
is
a
you
know,
a
bad
thing.
We
need
to
fix
or
an
opportunity
to
take
advantage
of,
is
sort
of
a
philosophical
debate,
but
we
can
say
this
is
the
case
with
sequencers
right.
We
have
this
power,
we
need
to
at
least
think
about
it
and
yeah.
A
The
way
we
think
about
it
is
is
in
terms
of
sort
of
minimizing
it,
so
I'm
going
to
sort
of
run
through
some
of
the
some
of
the
strategies
that
can
be
used
to
sort
of
improve
this
bad
situation
of
centralized,
sequencers
and
they'll
all
involve
improving
kind
of
one
of
these
one
of
these
four
things
that
maybe
equivocation
blah
blah
Okay.
So
the
simplest
thing
that
we
can
add
to
sequencers
to
make
them
better
a
little
bit
is
the
sort
of
crypto
economic
penalties.
A
We
can
require
sequencers
to
be
staked
and
we
can
say
now
if
they
particularly
equivocate,
basically
when
they
give
these
off-chain
promises,
they'll
be
signed,
so
think
of
a
sign
promise,
and
then
users
can
use
that
to
prove
that
they
equivocated
and
if
they
equivocate,
we
can
just
slash
the
sequencer.
So
that's
cool.
This
helps
with
the
equivocation
problem,
not
the
other
problems,
and
in
fact
this
could
be
applied
even
to
centralized
sequencers
just
as
easily
really
any
sequencer
mechanism.
This
could
and
probably
should
be
applied.
A
A
thing
to
note
here
is
all
we
can
really
do
in
this
case
is
punish
the
sequencer.
We
can't
sort
of
rectify
the
situation
for
users
and
that's
because
if
the
sequencer
is
equivocating,
you
know
each
of
these
claims
are
sort
of
internally
consistent,
they're,
just
inconsistent
with
each
other.
So
it's
not
really
clear,
which
one
is
the
more
valid
one
to
take.
A
You
know
either
way
if
we
simply
took
one
we'd
be
screwing
over
the
other
user
unfairly,
but
all
we
really
can
prove
is
that
the
sequencer
did
something
wrong.
So,
okay,
we
have
this
like
provable
cost
to
equification
for
the
sequence,
something
in
terms
of
particularly
the
media
problem
shout
out
to
shutter
here
who's
working
on
this.
A
This
strategy,
I,
probably
should
have
put
their
logo
bigger
or
something,
but
there's
this
idea
of
threshold
encryption
so
and
sort
of
using
threshold
encryption
to
to
minimize
the
Mev
that
a
sequencer
can
abstract
can
extract,
and
the
idea
here
is
when
a
user
instead
of
Simply
passing
their
transactions
onto
the
sequencer
directly
they'll
be
the
step.
Will
they
pass
it
in
this
encrypted
form
and
they
encrypt
it?
There's
sort
of
this
network,
they
call
them
Keepers,
which
is
kind
of
cute.
A
They
do
this
distributed
key
Generation,
so
you
encrypt
your
transactions,
give
it
to
the
sequencer
the
sequencer
commits
to
an
ordering
blindly,
it
doesn't
know
the
content
of
the
transactions
commits
to
it
off
Chan
right
and
then
only
after
it
commits
to
them.
Do
we
sort
of
reveal
the
contents
of
it
so
now
the
sequencer
can't
easily
extract
value
because
it
doesn't
know
what
it's
looking
at.
So
this
is
cool
and
there's
you
know
some
added
levels,
I
mean
so
like
some
potential
concerns.
A
Let's
say
the
the
parties
that
are
in
charge
of
this
distributed
key
generation.
The
idea
is,
you
distribute
it
so
that
they
can't
easily
collude,
but
if
they
do
collude
they
could,
for
example,
reveal
the
contents
of
the
transactions
the
sequencer
before
you
want
to
also
if
they
sort
of
don't
reveal
keys
in
time.
Things
like
that,
there's
certain
ways
that
they
can
delay
delay
things
further
and
remember.
A
This
was
kind
of
all
about
improving
latency,
so
we
do
want
to
take
latency
concerns
seriously,
even
in
the
sort
of
normal
case
when
you're
doing
the
threshold
encryption
stuff,
there's
rounds
of
communication
that
are
required.
So
it's
inevitably
going
to
add
some
latency.
So
that's
that's
one
concern
in
our
eyes,
but
yeah
cool
stuff,
so
I
mean
these
two
techniques.
So
far
again,
you
could
apply
these
to
a
centralized
sequencer.
We
haven't
really
talked
about
decentralizing
it
just
limiting
its
power.
A
Now,
let's
get
to
some
ideas
for
more
properly
decentralizing
it.
So
one
design
space,
let's
say,
is
that
of
Mev
auctions,
as
it's
known
proposed
by
some
of
the
folks
at
optimism,
along
with
a
few
others.
Some
years
ago,
I'm
not
claiming
but
I'm
gonna
describe
it
sort
of
in
the
abstract
I'm
not
claiming
this
is
their
plan
or
anything
like
that.
Just
sort
of
talking
about
the
design
space.
So
the
idea
here
is,
you
can
imagine
at
any
given
time
we
can
point
to
who
the
sequencer
is.
A
It's
still
one
specific
party,
even
a
centralized
party,
but
every
so
often
over
time
we
hold
an
auction
and
you
can
buy
the
right
to
become
the
same
okay
and,
and
so
in
that
sense
it
becomes.
You
know
in
the
big
picture
permissionless
now.
Why
would
you
want
to
be
a
sequencer
seems
like
a
thankless
job?
The
answer
is
by
being
a
sequencer,
you
have
you,
have
the
power
and
the
ability
to
profit
by
extracting
it
by
extracting
nav.
So
this
this
design
kind
of
leans
into
the
Mev
thing
and
kind
of
says
yeah.
A
A
It's
not
as
though
you
know
it's
not
as
though
these
potential
sequencers
are
sitting
looking
at
transactions,
seeing
ways
to
extract
value
from
particular
transactions
and
then
bidding
on
the
rights
to
order
them
it's
more
like
they're
bidding
on
their
future
potential
for
ordering
they're
taking
a
bet
on
their
own
Mev
powers
in
the
future.
They
can't
really
be
frequent
for
a
few
reasons.
A
These
these
auctions,
you
can't
have
frequent
sequencer
turnover,
the
main
reason
being
that
we
sort
of
at
any
given
point
have
to
know
who
the
sequencer
is,
so
that
it
can
give
these
fast
transactions
right.
Otherwise,
again
it
sort
of
defeats
the
whole
purpose.
So
imagine
on
the
order
of
maybe
hours,
maybe
days,
I,
don't
know
we
hold
these
auctions,
so
I'll
talk
about
why
you
know
myself.
I'll
just
speak
for
myself,
but
generally
I'll
set
that
you
know
at
off-chan.
Labs
are
sort
of
resistant
to
this
design
space.
A
If
you
know
if
it
depends,
because
it
depends
on
the
ability
to
order
transactions
and
extract
Mev.
This
is
sort
of
inherently
at
odds
with
the
other
thing
that
we
want
sequencers
to
do,
which
is
give
low
latency.
Simply
because,
if
you're,
you
know,
you
need
some
time
to
figure
out
the
optimal
order
of
transactions
to
extract
value
from
them.
So
there's
some
tension
there
in
practice.
Maybe
that
won't
matter.
Maybe
they
only
need
a
few
extra
seconds,
but
It's,
not
nothing
right
and
again.
A
The
way
the
way
I
kind
of
see
it
latency
is
is
the
name
of
the
game
with
sequencer.
So
so
that's
one
thing,
because
these
auctions
sort
of
have
to
be
infrequent
like
I,
said
and
they're.
You
know
you
have
this
temporary
centralization.
There's
some
concerns
about.
You
know
some
random
party
coming
in
and
censoring
transactions
griefing
them
right.
A
The
other
practical.
The
thing
of
the
thing
that
we
would
probably
expect
is
that
you
know
there'll
be
a
single
party
that
just
keeps
winning
the
auction
again
and
again,
simply
because
you
know
some,
you
know
whoever
sort
of
best
optimizes
for
this.
You
know
there
will
be
some
party
who
does
that
right,
so
it's
open,
but
but
you
might
get
a
sort
of
practical
centralization.
A
But
again
the
sort
of
the
bigger
thing
is:
is
this
question
of?
Are
we
really
comfortable
with
leaning
into
the
idea
of
extracting
NBC
or
introducing
new
parties
that
have
this
Mev
power
versus
minimizing
it?
So
real
I'll
try
to
just
get
this
in
before
I
stop
and
we're
almost
done,
but
I
want
to
talk
a
bit
about
sort
of
where
our
heads
at
at
off-chain
Labs
in
terms
of
decentralizing,
the
sequencer.
A
A
But
it
has
this
special
property,
which
is
the
ordering
of
transactions,
is
sort
of
enforced
within
the
consensus
itself.
So,
unlike
you
know,
a
lot
of
bft
leader
selection,
algorithms,
where
there's
a
leaders
chosen
in
that
party
kind
of
has
full
control
over
what
to
propose
in
this
case
that
control
is
distributed
and
we
we
enforce
Fair
ordering
what
we
mean
by
Fair,
ordering
it's
a
little
hard
to
formalize.
But
it's
something
like
you
know.
A
You
have
transaction
A
and
B
and
if
a
super
majority
of
sequencers
kind
of
witnessed
transaction
a
coming
before
transaction
B,
then
as
long
as
the
super
majority
is
honest,
that
will
also
be
the
result
so
and
yeah
some
nice
research
has
been
done.
Some
nice
progress
has
been
made
into
sort
of
improving
the
style
of
algorithm.
The
initial
ones
were
just
practically
required.
A
lot
of
network
level
communication,
so
they
weren't
usable,
but
the
latest.
This
thing
called
CMS,
is
kind
of
the
a
nice
breakthrough
which
makes
it
viable.
A
So
this
does
introduce
an
honesty
assumption.
They
have
a
fixed
set
of
parties
where
we're
assuming
an
honest
super
majority.
Again
any
sequence
or
solution
is
going
to
have
some
centralization
in
it.
It
can't
truly
be
open,
but
that
is
a
definite
downside.
The
more
interesting
downside
here-
and
this
is
some
of
the
pushback
that
we
got-
has
to
do
with.
Okay,
we've
taken
power
away
from
sequencers,
but
now,
if
you're
a
power
user
who's
trying
to
extract
nav,
what
sort
of
what
role
does
this
create
for
you?
A
And
what
are
you
capable
of
doing
so,
just
because
okay,
so
we
have
Fair
ordering
there's
still
this
question
of
what
exactly
is
the
ordering
that
we're
enforcing?
And
initially
we
were
thinking
fifo
first
in
first
out
right,
the
order
that
the
sequencer
sees
them
is
the
order
that
they
that
they
sort
of
give
the
receipts
and
publish
transactions,
which
is
what,
which
is
what
the
centralized
sequencer
does
now.
A
If
you
trust
me
the
the
issue
here
is
now,
you
can
imagine
a
power
user
who
sees
an
Arbitrage
opportunity
or
something
if
they
want
to
get
there.
First
now
they're
incentivized,
to
have
like
direct
Network
level,
access
to
the
sequencers,
like
literally
set
up
servers
geographically
close
to
the
sequencers
and
have
fancy
Hardware,
so
they
can
communicate
clearly,
which
is
which
is
sort
of
all
exogenous
to
the
system.
A
It's
it's
not
really
something
we
want
to
incentivize
it's
it's
sort
of
benefiting
users
in
this
weird
way
and
probably
a
pull
towards
centralization,
because
someone
will
optimize
that
best.
So
we
can
do
better.
So
this
idea,
the
top
of
the
slide,
is
cut
off.
But
very
recently
we
got
this
proposal
from
some
of
the
folks
at
at
flashbots,
particularly
Shin
AKA.
I.
A
Guess,
sexy
son
is
how
you
pronounce
it,
but
the
idea
here
is:
we
have
a
sort
of
hybrid
ordering
policy,
so
we
can
keep
our
Fair
ordering
algorithm,
but
we
don't
enforce
the
fairness
at
the
transaction
level.
We
enforce
it
in
these
sort
of
chunks
of
time.
We
can
imagine
discrete
intervals
of
like
half
a
second
I
think
that's
the
rapid
up
music
anyway.
This
is
a
really
interesting
topic.
It's
all
very
new
and
fresh,
so
I
recommend,
if
you're
a
researcher
or
interested
person.