►
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/updates-on-proposer-builder-separation/
In this talk, I will discuss updates on PBS and economic models for validators, builders, searchers and users.
Speaker(s): Barnabé Monnot
Skill level: Intermediate
Track: Cryptoeconomics
Keywords: proposer builder separation,cryptoeconomics
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
Today,
I
want
to
talk
about
proposal.
Builder
separation
give
some
updates
in
a
sense,
Visa
update,
because
it's
something
we've
been
working
on
for
some
time.
I
am
the
team
lead
of
the
robust
incentives
Group,
which
is
a
research
team
at
Via,
theorem,
Foundation,
looking
at
mechanism
design,
game
theory,
economic
modeling,
these
fancy
stuff.
A
Something
we
definitely
have
learned
to
appreciate
more
in
the
last
years,
as
blogspace
got
scarce
and
has
gas
fees
got
more
expensive?
Is
that
we're
all
learning
what
blog
space
is
capable
to
do
so
when
we
think
of
it
as
an
economic
good,
we
try
to
understand
what
its
properties
are,
how
to
sell
it
and
how
to
provide
for
it
as
the
protocol,
so
as
V
ethereum
protocol.
A
Indeed,
because
block
space
is
so
valuable
and
because
some
people
got
so
good
at
providing
it,
it
has
happened
even
before
proof
was
taking
proof
of
work,
but
parts
of
the
block
would
be
constructed
by
people
who
have
specific
expertise
in
making
the
best
use
of
a
valuable
blog
space.
So
we
call
that
Mev
gef.
This
was
provided
by
flashbots
and
in
this
Mev
Gap
Network
Searchers,
who
have
these
very
sophisticated
players,
submit
bundles
to
at
the
time
what
were
trusted
block
producers,
essentially
mining
pools
who
were
producing
the
blocks.
A
A
So
how
does
that
look
today
in
proof
of
stake?
It
looks
very
empty
because
I'll
add
more
to
it,
but
today
you
have
essentially
two
options.
There
could
be
more
in
the
future.
You
could
decide
to
forego
this
smart
network
of
capable
block
Builders
and
build
your
blog
locally,
just
grabbing
transactions
from
your
local
mempool.
A
So
in
proof
of
stake,
the
con,
the
clients
are
divided
into
there's
the
consensus,
client
and
the
execution
engine
you're,
just
listening
passively
to
user
transactions
and
including
them
into
your
blog
or
you
can
summon
this
much
more
complex
external
network
that
involves
many
parties.
So
let's
talk
a
bit
about
them.
I'll
go
from
right
to
left
as
I
feel.
This
is
probably
the
more
intuitive
way
to
go
about
it.
So
users
send
their
transaction.
They
are
public.
They
are
broadcasted
around
the
network.
A
The
Searchers
pick
up
some
of
these
transactions
and
make
these
valuable
bundles.
They
forward.
These
bundles
to
builders
and
Builders
are
responsible
for
making
whole
blocks,
and
these
whole
blocks
are
vent
forward
to
relays
and
the
relays
act
as
middlemen
in
this
market.
Between
proposers,
who
are
the
bonded
validators
in
proof
of
stake
and
Builders,
why
we
need
this
intermediary
is
again
because
these
opportunities
that
Searchers
found
they
are
kind
of
private,
and
so
we
don't
want
to
reveal
them
too
soon
to
the
block
producer.
A
My
Boost
is
a
little
piece
of
software
that
you
can
run
next
to
your
node,
so
that
you
talk
to
this
network
of
relays
and
once
the
relay
says,
I
have
a
very
juicy
blog
for
you.
If
you
use
it,
I
will
pay
you
a
certain
amount
of.
If
you
sign
that
block,
or
you
sign
that
block
header
as
a
as
a
Blog
proposal
via
this
Builder
API
a
bit
more
detail
on
on
this,
we
can
really
separate
it
in
in
three
phases.
A
A
In
the
second
phase,
the
beat
selection,
The
Proposal
listens
to
these
streams
of
Beats
from
the
relays
by
default
to
the
MAV
boost,
selects
the
higher
speed
that
the
proposal
has
received,
and
at
that
time
the
proposal
signs
the
beat
with
the
builder
API,
and
they
can
no
longer
make
another
block.
They
they
don't
know
the
full
content
of
their
blog,
but
if
they
were
to
make
another
block
themselves
now
they
would
have
signed
two
different
objects
and
they
could
be
slashed
for
it.
A
In
the
third
phase,
the
relay
receives
the
signed
bead
from
the
proposer,
and
at
this
stage
it's
confident
that
it
can
release
the
block
to
the
rest
of
the
network
and
there's
not
going
to
be
a
copy.
That
is
being
made
a
few
numbers
that
I
got
from
a
few
days
ago.
More
and
more
validators
seem
to
choose
to
use
these
external
block
building
facility,
which
today
leaves
pretty
much
totally
out
of
the
protocol
50
as
of
I.
A
Think
that
was
Saturday
plus
both
flashbots
still
operates
the
dominant
relay,
so
83
percent
of
the
blocks
which
are
received
and
signed
by
proposals
have
been
relayed
by
flashbots
and
there
seems
to
be
seven
active
relays.
Some
of
them
are
all
run
by
the
the
same
entity
and
the
let's
say
satisfy
different
trade-offs
that
the
blog
proposals
may
have
when
they
want
to
to
summon
this
external
network.
So
what
is
PBS?
This
was
sort
of
an
intro
in
what
I
described
before
you
can
think
of
this
as
PBS
PBS
is
more
of
a
philosophy.
A
So
it's
proposal,
Builder
separation
and
it's
the
idea
that,
as
the
protocol
gets
more
complex
and
has
the
roles
of
block
proposals
become
more
valuable,
it
may
not
be
possible
for
the
blog
proposal
to
do
everything
and
so
parts
of
what
the
blog
proposal
does
could
be
outsourced
to
to
third
parties
outside
of
a
protocol.
These
days,
I
think
of
PBS
as
kind
of
two
different
things
that
we've,
maybe
wrongly
put
together
so
I
call
it
the
proposal.
A
Builder
separation,
separation
on
the
first
side,
I
think
of
PBS
as
a
market
structure,
or
a
way
of
organizing
the
duties
of
The
Proposal
with
respect
to
the
protocol.
So
again,
there
are
duties
that
the
blog
proposal,
especially
the
average
block
proposal
who's
taking
from
home,
can't
or
won't
do,
for
instance,
making
these
execution
block
that
contain
the
valuable
block
space
in
the
future,
making
dong
sharding
blocks,
which
will
contain
a
lot
of
data
and
require
a
very
high
bandwidth
to
to
propagate,
maybe
even
further
into
the
future.
A
Once
we
have
statelessness
Computing
the
block
witness,
if
we
want
stateless
blog
proposals
that
might
not
be
possible
for
them
and
even
further,
we
might
require
validity
proofs,
along
with
execution
block,
to
show
that
the
execution
is
correct.
So
that
would
rely
on
enshrining
some
ZK
evm
into
the
into
the
protocol.
And
so
it
seems
to
me
that
the
protocol
is
becoming
more
and
more
complex.
Is
asking
more
and
more
things
to
the
to
the
proposal,
and
so
maybe
it's
a
good
idea
to
think
of
ways
that
we
can
organize
these
markets.
A
The
second
half
of
the
separation
is
is
not
really
the
organizing
principle,
but
it's
really
the
shape
of
the
market,
so
I
think
our
first
half
a
bit
as
the
legal
system.
It
defines
who
are
the
players
and
the
second
half
is
more
of
a
business
logic.
What
exactly
is
being
sold
and
one
of
the
contracts
that
the
proposal
enters
into
with
these
third
parties
today
for
PBS
when
it
comes
to
the
execution,
block
and
block
space,
the
allocation
mechanism
is
a
whole
block
auction.
A
So
the
proposal
sells
off
their
entire
rights
to
make
a
block.
The
current
design
allocates
the
right
to
make
the
exact
block
to
such
a
third
party,
as
we've
seen
in
MAV
boost
being
a
bit
more
precise
about
it
may
boost
the
allocation
mechanism.
Again.
Is
this
whole
block
auction
and
the
market
structure
of
map
boost
places
the
relays
as
kind
of
brokers
who
broker
these
deals
between
the
proposal
and
between
the
builders
but
relay
they?
A
We
expect
them
to
to
guarantee
the
validity
of
the
good,
but
they
are
not
protocol
actors
and
we
could
fail.
These
are
a
few
ways
that
they
could
fail.
For
instance,
they
could
receive
a
Blog
from
a
builder
and
fail
to
properly
validate
that
it's
a
valid
block.
This
has
happened
before
we
really
could
also
not
validate
properly
that
the
bid
made
by
the
Builder
actually
corresponds
to
what
is
being
paid
to
The
Proposal,
and
it
could
also
fail
Midway
into
the
deal
and,
for
instance,
deliver
the
block
late
or
not
at
all.
A
In
which
case
the
proposal
doesn't
have
the
opportunity
to
to
propose
the
blog
themselves
and
misses
out
on
some
of
the
rewards.
So
this
is
kind
of
the
idea
of
in
protocol.
Pbs
is
moving
this
systemic
part
of
a
system
into
the
protocol,
so
in
the
in
protocol
PBS
design,
the
protocol
becomes
the
broker
and
is
the
one
that
guarantees
that
if
deals
go,
south
The
Proposal
is
still
compensated
for
it.
A
So
the
Builder
in
this
case,
whenever
we
make
a
bid
that
bit
is
binding,
even
if
they
deliver
an
invalid
block
or
if
they
don't
deliver
it
at
all,
they
would
have
to
pay
the
proposal
up
to
the
bid
that
they
had
made.
So
a
bit
more
detail
on
this
again
we
can
use
the
same
framework
or
division
to
to
understand
this
Market
in
the
bidding
phase.
The
builders
send
directly
the
Beats
to
the
proposer.
A
For
instance,
there's
a
couple
here:
five,
seven
eight:
if
at
the
beat
selection
phase,
which
is
slot
1
The
Proposal,
selects
a
bit
and
makes
a
beacon
block
that
commits
to
the
bit,
which
you
can
see
in
green
below.
So
seeing
this
once
the
proposal
makes
a
beat.
So
this
is
part
of
a
consensus
rule.
Whenever
the
proposal
makes
a
block,
you
have
a
row
of
a
testers
which
is
a
very
large
set
of
stakers
who
vote
to
say.
We've
seen
this
block
and
this
block
should
belong
to
the
chain.
A
That's
Slot,
2!
At
the
delivery
stage,
the
Builder
releases
the
Builder
block
that
contains
the
the
payload,
and
once
again
you
have
a
row
of
attesters
that
makes
the
Builder
block
safe
right
now.
What
I
describe
is
really
the
vanilla
version
of
in
protocol
PBS,
but
of
course
you
may
as
a
proposal,
your
only
value
may
not
be.
You
just
want
to
maximize
the
amount
of
e
that
you
get
and
you
might
want
to
add
some
constraints
over
the
block
that
is
being
made
so
that
you
don't
entirely
remove
your
input
from
the
Block
production.
A
One
way
to
do
so
is
inclusion
list,
so
an
inclusion
list
is
a
list
of
transaction
that
the
blog
Builder
must
either
include
or
show
that
we
couldn't
include
in
the
blog
that
we
made
and
the
only
way
that
we
can't
include
the
transaction
is
if
the
block
is
full.
So
if
you're
trying
to
keep
a
transaction
away
from
a
block
over,
let's
say
a
long
period
of
time,
it
becomes
increasingly
difficult
to
do
so
inexpensive.
A
The
reason
is
eip1559
in
ethereum
today,
if
a
block
is
full,
the
protocol
mandated
base
price
increasing
exponentially
over
time.
So
if
you
want
to
keep
censoring
something,
you
have
to
keep
making
full
blocks
and
it
becomes
just
impossibly
expensive
to
to
do
so,
and
so
that's
the
idea
behind
inclusion
lists.
Another
way
to
do
it
is
to
just
let
the
proposal
make
part
of
a
block.
So,
for
instance,
we
could
do
the
prefix
of
the
suffix
and
we
could
let
the
Builder
build.
The
rest
of
the
block
designs
exist
for
both
sides.
A
A
So
we
have
these
free
variants
and
we
are
not
incompatible
with
one
another.
It's
just
a
matter
of
deciding
you
know
the
trade-offs
and
and
what
fits
well
into
the
protocol
and
even
for
each
variant,
I
think,
there's
a
bit
more,
a
bit
more
margin
for
us
or
a
bit
more
parameters
that
we
can
tune.
So
if
we
do
a
partial
block
auction,
we
can
decide
which
path.
A
One
reason
why
we
might
not
want
to
is
because
we
could
still
strike
deals
of
chain
with
Builders
and
get
the
Builder
blocks
included,
even
though
they
receive
bids
on
some
kind
of
official
gossip
channel
for
the
beats
as
a
novel
proposal,
which
is
called
mev's
moving.
It's
a
mechanism
that
takes
the
block
value
and
Smooths
it
across
all
the
stickers
in
the
protocol,
rather
than
giving
it
only
to
the
current
block
producer.
That
would
make
it
binding
because
it
would
force
proposals
to
accept
the
higher
speed
received
on
this
official
B
Channel.
A
But
there's
more
questions
there
in
terms
of
incentive
compatibility
that
I
think
we
need
to
to
look
at
another
question
is:
would
relays
still
exist?
I've
been
talking
about
this
official
beat
Channel.
There's
questions
on
how
to
design
that,
but
it
could
still
be
the
case.
That
proposal
would
listen
to
out
of
protocol
bits
that
come
from
relays
that
we
prefer,
for
instance,
relays
might
be
very
good
at
getting
you
the
the
best
beat
very
fast
in
time,
or
they
might
be
constraining
the
Beats,
for
instance,
with
censorship.
A
So,
as
a
proposal,
if
there
are
transactions,
you
don't
want
to
include,
you
could
listen
to
to
some
relays
that
that
provide
you
beat
with
respect
to
that.
Some
Builders
may
even
prefer
to
use
math
boosts,
since
they
don't
need
to
put
The
Upfront
Capital.
Well,
it's
to
the
proposal's
risk
in
that
case,
pulling
a
little
bit
more.
What
does
the
protocol
see?
It's
a
question.
We
ask
ourselves
when
we
introduce
the
ap1559
and
the
answer
was
well:
it
prices
the
congestion
in
the
network.
A
It
prices
the
value
when
the
next
person
who
isn't
included
would
be
ready
to
pay
to
get
included
and,
as
we
add
more
of
these
economic
mechanism
in
the
protocol,
we
find
that
the
protocol
gets
more
introspection
about
what
happens
and
the
value
that
people
using
the
protocol
get
out
of
it.
And
so
one
reasonable
question
is:
what
does
the
PBS
bid
value
exactly
and
I
think?
Ideally,
that
bit
should
be
the
total
extractable
value
that
the
proposal's
position
confers
to
The
Proposal,
but
is
it
in
reality?
A
Does
the
PB
will
the
PBS
bid
really
represent
this
extractable
value?
Can
it
be
achieved
with
a
single
Builder?
Can
it
be
achieved
with
a
distributed
Builder,
there's
more
models,
I
think
that
we
can
work
out
on
this.
Another
way
to
think
about.
It
is
made
the
PBS
bit
be
the
spot
price
or
value
for
the
block,
for
instance,
if
there's
economic
value
from
selling
the
rights
way
in
advance
before
your
slot,
so
that
people
can
plan
for
it
and
possibly
make
promises
in
advance
with
the
PBS
bid.
A
Where
should
the
concern
stop
so
we
could
decide
that
you
know
if
proposal
don't
want
to
do
the
things
that
they
are
told
to
do
by
the
protocol
and
if
they
want
to
enter
into
this
third
party
relationships.
Well,
the
protocol
can't
prevent
them
from
doing
so,
but
doesn't
have
to
actively
help
them
either.
For
instance,
we
could
keep
in
including
more
things
into
the
Builder
API
at
the
client
level.
A
Just
so
that
the
communication
can
happen
between
the
proposals
and
these
third
parties,
but
call
it
today
and
let
the
out
of
protocol
markets
develop
there.
We
could
decide
to
draw
the
boundary
a
little
further.
So
this
is
the
distinction.
I
was
making
We
could
decide
to
say
well.
The
protocol
should
guarantee
some
kind
of
Market
structure
for
the
proposals,
because
that
makes
them
safe
and
it
backstops
certain
bad
cases,
for
instance,
relay
failure,
but
it
doesn't
have
to
determine
all
the
mechanisms.
A
So
my
Pepsi
proposal
is
in
that
direction
and
then
we
could
also
decide
that.
Well
all
the
markets
that
the
protocol
requires
for
these
third-party
relationships.
They
should
be
determined
at
protocol
level
and
we
should
be
able
to
find
the
best
way
for
these
markets
to
to
organize
I.
At
the
moment.
A
I'm
I
think
I'm
still
exploring
all
options
and
I
think
we
all
are,
but
as
a
protocol
oc5s,
it
might
be
more
and
more
difficult
to
say
for
sure,
but
we
got
it
right
the
first
time
around
and
that
it's
still
right,
50
years
later,
some
incomplete
ways
to
think
about
it.
I
think
these
are
really
the
criteria
that
help
us
decide
between
these
questions
and
the
first
is
what
is
the
risk
of
a
protocol.
A
So
if
there
is
a
very
systemic
dependency
on
this
third
party
relationship,
does
that
put
the
protocol
safety,
liveness
or
throughput
properties
in
Jeopardy?
When
we
do
things
at
protocol
level,
does
it
maximize
welfare,
for
instance,
increasing
capacity
serving
more
user
transaction?
That's
a
no-brainer
for
sure
this
gets
us
more
value
into
the
system
as
long
as,
of
course,
safety
and
liveness
are
preserved.
So
so
these
things
are
good.
This
is
maybe
a
hot
take,
but
I've
been
seeing
well
nav
boost.
You
are
selling
off
your
whole
rights.
A
Maybe
we
should
go
back
to
a
world
where
proposals
have
to
make
the
block
themselves
but
I'm
not
making
this
argument
entirely
either
I
think
sometimes
Outsourcing
things
to
third
parties.
It
might
be
good.
There
might
be
much
more
incentive
alignment
when
the
third
party
really
wants
something
to
go
into
the
into
the
protocol,
so
there's
also
that
to
weigh
in
the
scale.
The
final
thing
that
we
might
consider
is
the
risk
for
the
proposal
themselves.
A
In
asking
these
questions,
there's
going
to
be
much
more
talks
about
PBS
at
Defcon
and
I
definitely
encourage
you
to
to
check
some
of
these
out,
and
if
you
think
these
are
interesting,
questions
I
would
also
like
to
invite
you
to
apply
to
our
research
team,
as
we
are
currently
looking
for
someone
with
a
strong
research
background
who
knows,
mechanism
design
and
really
loves
it
and
wants
to
help
us
make
sense
of
all
of
it.
Thank
you
for
your
time.