►
From YouTube: Post-Merge MEV Breakout Room meeting #16
Description
Agenda: https://github.com/ethereum/pm/issues/423
Document being presented: https://hackmd.io/70AnBNnKTbGe3D5kT8x9ZA?view
Discord: Eth R&D - Execution R&D #block-construction
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethcatherders
Website: https://www.ethereumcatherders.com/
A
Okay,
we
are
recording
welcome
to
the
post,
merge,
mev,
breakout,
room,
stefan's
gonna,
walk
us
through
the
proposal,
architecture,
some
demos,
and
then
we
have
plenty
of
time
also
for
questions
comments,
conversations
from
the
different
client
teams,
yeah
again
this
being
recorded.
If
you're
not
interested
in
that,
please
jump
off
now.
We'll
have
full
notes
and
record
it
available
for
people
who
want
to
watch
later
yeah
over
to
use
the
phone.
B
Then
probably
do
a
quick
demo
of
what
we
have
with
merge
mock
running
right
now,
jason,
if,
if
he
sure,
would
be
the
right
person
to
jump
on
and
buy
that
demo
and
then
yeah,
we
can
go
into
discussion
and
I've
listed
in
here
sort
of
the
the
open
remaining
questions
to
to.
They
need
to
be
figured
out
over
the
next
couple
months:
okay,
without
further
ado,
let's
jump
into
it
so
I'll
just
assume
a
good
amount
of
background
knowledge
on
of
geth.
B
If
you
don't
quite
understand
how
the
system
works,
definitely
go
check
out,
docs.flashbots.net,
it
has
sort
of
a
good
description
and
highlight
of
how
it
works,
but
basically
right
it's
a
block
space
auction.
It
allows
for
outsourcing
parts
of
the
job
of
block
construction
to
basically,
anyone
in
in
the
network
and
and
the
way
that
it
works
today
is
with
sort
of
this
intermediary.
B
You
know
it's
working
right:
it
achieves
sort
of
the
goals
that
us
set
out
to
achieve,
which
is
providing
a
block
space
auction
mechanism,
but
it's
by
no
way
perfect.
So
I've
just
listed
here
some
of
the
properties
that
that
we're
looking
to
improve
upon
for
with
my
boost
and
with
with
pbs,
so
the
first
one
is
full
block
bids.
B
So
right
now
right
it
only
accepts
bundles,
but
that
doesn't
allow
for
expressing
sort
of
the
full
range
of
of
types
of
med
that
can
be
extracted
or
really
preferences.
On
the
the
order
of
transactions
and
so
switching
over
to
a
system
that
is
able
to
send
full
payloads
right
in
the
in
the
proof
of
stake,
context,
sort
of
addresses
this
this
issue.
B
Another
component
is
solo,
sticker
participation,
so
right
now
the
way
that
medgath
works,
we're
sending
all
the
transactions
over
to
the
miner
in
cleartext.
So
the
miner
has
a
view
of
all
the
transactions
that
are
coming
in
and
really
we're
relying
on
a
trusted
relationship
between
the
relay
operators
and
the
miners
to
prevent
the
miners
from
sort
of
stealing
those
transactions
or
you
know,
dropping
censoring
those
transactions
inserting
their
own
et
cetera.
B
And
the
goal
is
to
move
away
from
from
this
because
it
restricts
the
ability
of
solo
miners
to
participate
in
this.
So
I've
got
today
right,
there's
really
only
mining
pools
that
are
participating
and
and
only
mining
pools
with
a
with
a
significant
history
of
participation
in
the
network.
But
we
want
to
move
towards
a
model
where
anyone
can
sort
of
just
connect
their
their
proof-of-stake
validator
node.
As
long
as
they
have
you
know,
the
32-each
stake
they're
able
to
connect
to
the
system
and
start
receiving
payloads.
B
So
to
do
that,
we
want
to
withhold
sort
of
the
content
of
the
transactions
not
reveal
them
and
instead
only
forward
over
to
the
validator,
the
header.
So
we
have
it
sort
of
noted
here
as
the
validator
gets
the
payload
header
from
the
relay,
and
then
it's
able
to
return
this.
This
signed
header
so
yeah.
This
allows
for
the
soil
sticker
participation,
but
it
also
sort
of
adds
an
additional
sort
of
trust,
assumption
on
on
the
way
that
the
relay
operates.
B
So
this
diagram
sort
of
shows
right
the
components
that
we're
already
familiar
with
the
boundary
client,
the
beacon
node
and
the
execution.
Client
meth
boosts
sort
of
slots
itself
in
between
here,
as
as
a
middleware
and
interfaces
with
both
the
execution,
clients
and
and
the
relays
for
performing
block
construction
duties
and
then
yeah.
We
can
talk
a
bit
about
the
the
trade-offs
are
involved
in
here,
so
complete
privacy
and
trustlessness.
B
Here,
there's
sort
of
a
an
asterix,
because
it
does
improve
the
condition
over
the
way
that
mev
guest
works
because
the
validators
don't
see
the
content
of
the
transactions.
But
it
still
relies
on
relays
as
sort
of
being
actors
that
that
aren't,
as
you
know,
profiting
from
the
from
the
content
of
the
transactions
that
it
receives.
B
So
that's
a
property
that
only
really
gets
removed
in
the
full
pbs
at
the
protocol
level,
where
we're
able
to
remove
the
the
relay
component
completely
and
the
builder
can
communicate
a
payload
without
revealing
its
content
to
to
any
third
parties
and
then
yeah
trustlessness
sort
of
works
in
the
same
way.
But
this
is
really
from
the
validators
perspective,
which
is
under
the
boost
formulation
of
of
the
separation.
B
B
B
Okay,
cool
yeah,
maybe
I'll,
try
to
keep
an
eye
on
the
chat
as
well.
If,
if
anyone
wants
to
just
drop
questions
there,
while
I'm
going
through
I'll,
just
try
to
answer
them
so
this,
I
just
want
to
talk
a
bit
about
how
I
see
network
topology.
So
I
think
one
of
the
scary
things
about
looking
at
this
is
like
wow,
okay,
so
there's
one
builder
one
relay
and
then
you
know
they're
sending
payloads
over
to
the
validator.
That's
not
really
the
goal.
B
B
You
know
this
is
just
network
redundancies
to
make
sure
that
the
system
continues
to
operating
as
normal,
but
in
any
case,
the
validator
sort
of
locally
has
still
the
ability
to
fall
back
to
a
local
execution
client.
If
all
this
fails
and
all
this
becomes
invalid,
so
yeah
we've
done
a
few
rounds
of
iteration
on
how
the
system
works.
So
this
is
kind
of
like
the
latest
sequence
diagram
of
how
the
messages
are
being
passed.
I'm
just
going
to
go
over
it
quickly.
B
B
It
starts
by
the
engine
fork,
choice,
updated
call
which
gets
proxy
to
the
relay,
or
I
should
say
to
my
boost
that
also
sends
that
to
execution,
clients
and
and
the
relays.
So
right
now,
this
fork
choice.
Updated
is
used
for
both
like
notifying
what's
the
latest
head
of
the
chain,
but
also
for
communicating
the
the
fee
recipient
address,
that's
going
to
be
used
by
by
the
by
the
slot
tenant
on
their
block
proposal
once
it's
time
to
actually
produce
the
block
here.
B
B
Great
the
consensus
client
receives
this
payload.
It
puts
it
into
a
beacon
block,
it
signs.
The
block
we've
introduced.
This
new
call,
which
is
proposed
blinded
block,
so
this
is
blinded
block,
is
basically
what
we
call
a
a
beacon
block
which
does
not
contain
the
transaction
list
of
the
payload
and
said
that
is
just
null
and
then,
but
you
know,
the
the
signature
and
the
header
of
the
block
and
the
header
of
the
payload
are
all
still
valid.
B
At
the
same
time,
the
relay
is
going
to
propose
that
that
full
beacon
block
to
to
the
network,
and
you
you
move
into
the
next
step
of
the
block
proposal
with
the
attestation
and
everything
else
so
yeah.
I
guess
there's
quite
a
bit
of
cover
here,
but
the
highlight
is
these:
two
new
modified
calls
right,
get
payload
header
and
proposed
blinded
block,
which,
which
are
sort
of
inserted,
as
complements
to
the
the
current
engine
api.
B
So
great,
where
do
we
go
from
here?
We've
been
working
on
this
on
the
implementation
of
medboost
here
under
flashbot,
slash
navboost,
and
we
sort
of
detail
what
are
the
different
implementation
milestones
and
and
what's
involved
with
them,
we
split
up
the
development
into
into
four
milestones
right
now.
B
The
first
one
is
really
just
about
the
basic
logic:
that's
required
for
met,
boost
to
be
able
to
communicate
with
various
relays
and
be
able
to
propose
payloads
to
to
the
consensus
clients,
and
it
also
involves
sort
of
the
support
by
consensus
client
for
for
these
blinded
blocks.
So
I
highlight
sort
of
the
the
behavior
and
the
client
modifications
here,
but
yeah
the
the
consensus
client.
Basically,
the
only
change
that's
required
to
be
compliant
with
this.
B
B
The
other
thing
that
we
have
ready
is
a
merge
mock
implementation
that
supports
this
milestone,
one.
So
that's
the
demo
that
we'll
jump
into
just
just
in
a
few
minutes.
So
great
we
have
the
basic
logic,
but
by
no
means
are
all
the
questions
I
answered
yet.
So
the
milestone
two
that
we've
laid
out
here
is
meant
to
implement
all
the
remaining
critical
components
of
of
the
system
and
those
involve
security.
B
B
So
the
goal
for
these
is
to
have
them
expect
over
the
course
of
the
next
month
and
implement
it
by
the
end
of
january,
so
that
we
can
do
further
testing
with
those
now
there's
another
two
milestones
here
that
are
worth
discussing.
I
think
we
can
probably
skip
over
milestone,
four,
which
is
just
about
about
configurations,
optional
configurations
and
optimization
that
various
validators
might
want
to
run
if
they
have
different
preferences
on,
for
example,
privacy
or
or
or
you
know
where
they
want
to
optimize
for
latency,
etc.
B
B
There
is
a
design
of
the
system
that
that
avoids
revealing
the
mp
addresses
of
the
validators
to
the
relays,
but
it
requires
a
lot
of
work
with
implementing
custom
channels
or
topics,
I'm
not
sure
what
they're
called
with
with
lib
pdp
and
just
from
initial
feedback
from
both
validators
and
client
implementation
teams.
It
seems
it's
not
really
such
a
concern
for
them,
so
this
is.
B
This
is
marked
as
as
optional,
and
I
think
we'll
be
pending
more
discussion
with
with
the
client
teams
and
the
ef
to
see
if
it's
worthwhile
to
to
put
in
the
the
engineering
cycles
to
implement
this
or
not.
So
with
that
said,
I
think
it's
worthwhile
to
jump
into
a
a
quick
demo
of
of
merge
mock
connecting
to
met
boost,
and
then
I
could
start
highlighting
some
of
the
other
open
questions
that
we
have
here
and
and
move
into
more
discussion.
C
All
good
awesome
all
right,
so
this
is
the
med
boost
repository.
I'm
just
gonna
start
up
my
boost
real
fast.
It's
written
in,
go
it's
very
straightforward.
It's
relatively
simple!
As
far
as
implementation
goes,
let's,
let's
move
over,
so
I'm
gonna
run
in
three
separate
terminals.
So
in
the
first
term
I'm
gonna
run
my
boost
second
term,
I'm
gonna
run
merge
mock
the
execution
engine
for
those
unfamiliar
with
merge
mock,
it's
just
a
very
simple
stripped-down
client
for
both
engine
and
consensus.
C
It's
meant
for
doing
mock,
testing
mock
integration
testing,
so
I'm
gonna
start
that
up
and
I'm
gonna
start
the
consensus
client
as
well
thing
worth
noting
here
is
I'm
doing
one
extra
flag
here,
which
is
I'm
pointing
the
engine
at
port
1850,
one,
eight,
five,
five:
zero!
That's
where
med
boost
is
running
so
instead
of
how
this
normally
runs.
Is
this
communicates
directly
with
the
merge
mock
execution,
client
or
with
you
know,
a
geth?
Or
what
have
you
whatever
execute
clients
in
our
case
we're
instead
communicating
with
my
boost
directly.
C
Let's
go
back
to
my
boost
logs
and
we
can
see
it's
successfully
getting
the
payload
header
and
it's
revealing
the
payload
in
the
proposed
blinded
block
call.
So
if
you
refer
back
to
the
charts
or
the
the
documentation
that
stavan
showed
earlier,
we're
no
longer
calling
git
payload
we're
calling
get
payload
header
and
then
in
a
second
step.
The
consensus
client
will
fetch
well
we'll
send
a
blinded
block
and
then
fetch
a
full
payload
back
from
web
boost.
C
There's
some
areas
here,
you're
seeing
it's
it's
not
actually
communicating
with
the
relay
at
all.
This
is
only
communicating
with
the
execution
clients
so
for
the
purpose
of
testing
mergemon.
This
is
great
right.
It's
it's!
We
can
see
it
working.
We
see
it
working
exactly
as
it
used
to
with
the
merge
box
execution,
client,
and
I
think
we
have
plans
to
provide
more
extensive
testing
on
the
relay
side
as
well.
We'll
provi
probably
provide
a
mock
relay
to
run
locally
as
well,
but
for
this
for
consensus,
client
implementation
purposes.
C
C
B
B
Yeah
we
can
either
talk
about
some
of
the
remaining
design
decisions
for
this
this
milestone
and
have
a
discussion
about
that
or
yeah.
Maybe
let's,
let's
do
that
I'll!
Just
list
these
I'll
list,
these
open
questions-
and
these
are
all
things
that
we
are
looking
for-
additional
feedback
from
feedback
on.
They
are
currently
sort
of
underspecified
right,
they're,
mostly
ideas
but
and
proposals,
but
hopefully
they'll
they'll
move
to
being
much
more
concrete
over
the
course
of
the
next
few
weeks,
so
yeah,
the
first
one.
B
B
B
B
B
D
B
Maybe
the
problem
is,
I
would
require
that
withdrawal
address
to
collect
all
the
fees
for
like
transactions
and
and
mev
and
like
even
the
block
rewards,
I
guess
not
in
e3
and
in
proof
of
stake.
There's
no
there's
no,
no
such
thing,
but
certainly
the
the
transaction
fees
and
the
mev.
That's
would
be
where,
like
all
the
fees
would
go.
So
perhaps,
if
they're
comfortable
with
that,
then
yes,
I
think
right
now,
the
fee
recipient
isn't
like
limited
to
being
to
being
the
withdrawal
key.
D
B
It
is
true
that
I
think,
even
if
the
view
recipient
is
a
withdrawal
key,
you
can
then
like
you're,
not
limited
to
to
withdrawing
and
so
withdraw
that
value
before
stake
withdrawals
are
implemented
because
correct
yeah,
I
guess
yeah
this.
The
idea
here
is
that
it
would
be
possible,
but
not
like
required
right
for
for
the
withdrawal
key
to
be
the
few
recipients,
so
the
valder
can
pick
whatever
address
they
want.
B
So
the
fee
recipient
is
what
goes
into
the
coinbase
lab
code,
but
actually
this
is
a
really
good
question.
So
the
builders
so
because
the
the
the
coinbase
opcode
is
a
part
of
the
header
and
can
be
accessed
through
edm
execution.
It
also
creates,
like
you,
can
have
a
code
path
that
switches
based
on
the
coinbase
address
right.
So
when
the
builder
or
the
relay
are
processing
their
blocks.
In
order
for
that
block
execution
to
be
deterministic,
they
need
to
know
ahead
of
time.
What
is
the
the
address?
B
That's
going
to
be
used
in
in
in
the
coinbase,
so
there's
two
ways
to
go
about
that.
One
of
them
is
like
the
validators
communicates
the
the
fee
recipient,
and
then
the
builder
like
includes
that
as
the
coinbase
address
of
that
block
and
then
like
submits
that
through
or
the
alternative
is
for
the
builder
to
set
their
own
address
as
a
coinbase
address
and
then
at
the
end
of
the
block
that
they
produce.
B
B
So
this
step
here
right
this
this
logic,
where
my
boost
compares
the
payloads
it
receives
and
selects
the
most
valuable.
One
really
requires
some
indication
of
the
value
of
the
payloads,
so
the
get
payload
header
call
and
the
like
get
payload
call
need
to
be
able
to
return
an
extra
field
that
says
this
block
contains
like
x,
eth
of
delta
in
value
for
the
fee
recipient.
B
That
is
that
is
defined
so
sort
of
talk
about
it
here,
but
that
message
needs
to
be
returned
in
a
way
that
that
boost
is
able
to
compare
these
different
payloads,
just
like
the
most
valuable
one
and
submit
it
and
like
a
further
enhancement,
would
be
for
this
call
to
include
some
some
kind
of
miracle
proof
on
the
on
the
balance,
change,
which
would
which
would
provide
potentially
further
guarantees.
The
tricky
thing
here
is
obviously
it
requires
some
changes
to
the
engine.
B
That's
okay!
From
like
the
network
perspective,
because
once
the
full
block
is
revealed,
it's
still
up
to
the
attestation
committee
to
actually
validate
if
the
block
is
valid,
and
so
the
network
will
never
finalize
an
invalid
block,
but
it
does
cause
the
validator
to
to
lose
the
value
that
it
could
have
received
from
both
the
mev
and
the
reward
for
the
for
the
block
proposal,
and
it
basically
just
got
a
miss
slot
in
in
the
chain.
So
you
want
to
have
a
system
where
other
validators
can
can
notice.
B
So
let's
say
you
know,
this
is
the
path.
That's
taken.
You
get
a
bunch
of
transactions,
all
the
relays
propose
a
block
to
the
validator
here,
and
this
is
the
boundary
of
slot
one.
This
is
the
value
of
slot
two,
the
value
of
slot
three
slot.
Four.
You
know
if
the
validator
receives
an
invalid
payload
from
the
relay
and
submits
it
to
to
the
network.
B
You
want
the
validator
number
two
to
be
able
to
notice.
Oh
wow,
like
this
really
proposed
invalid
payload,
even
if
he
sends
me
a
payload
for
my
slot,
I'm
going
to
ignore
them
and
just
switch
to
using
the
the
other
relays
and
the
way
to
do
this
is
using
sort
of
this
fraud.
Proof
message
so
because
all
of
the
relays
and
all
the
validators
are
listening
to
leia's
state
of
the
beacon
chain.
What
you
need
is
the
validators
to
be
able
to
communicate
back
to
all
the
relays.
B
Hey
here
is
the
payload
that
I
received
from
relay
one.
This
is
the
one
I
decided
to
include
in
my
block.
I
can
prove
it
because
they
signed
it
and
then
all
the
other
relies
are
like.
Okay.
Now
we
can
validate
to
see
if
this
payload
was
correct
or
not.
If
it's
incorrect,
what
they
want
to
do
is
send
this
fraud.
Proof
message
to
validator
number:
two
that
says:
hey.
Look.
We
really
number
one
proposed
this
payload
for
this
block
height.
B
Okay,
if
you're
still
there,
if
you're
still
bearing
with
me
the
final
one,
is
splitting
away
the
execution
payload
call.
So
one
of
the
components
I
mentioned
in
milestone
two
here
is
a
security.
So,
under
this
description
right,
the
beacon
client
is
only
communicating
with
the
local
execution
client
through
meb
boost,
but
really
what
you
want
is
a
situation
where,
if
md
boost
goes
offline,
for
whatever
reason
has
some
software
fault,
the
beacon
client
is
still
able
to
operate
all
those
duties
by
falling
back
to
communicating
directly
with
with
the
execution
clients.
B
B
F
F
We
kind
of
become
at
risk
of
centralizing
upon
this
thing,
not
from
not
necessarily
from
like
a
I
don't
like
a
governance
perspective,
but
more
from
like
a
piece
of
software
that
can
fail
and
take
everything
down
sort
of
perspective.
So
the
designs
reflect
that
now.
Something
I've
been
trying
to
make
sure
is
that
we
have
the
ability
to
fall
back
to
the
local
execution.
Node,
like
you,
know,
nevermind
geth,
whatever.
F
So
try
to
make
it
so
that
it's
easy
to
implement
to
consensus
clients
and
make
it
so
that
there's
a
clear
path
to
doing
that,
so
that
it
means
that
we
can
get
all
of
the
consensus
clients
that
are
interested
in
implementing
it.
I
can
get
them
on
board
with
a
pretty
low
barrier
to
entry,
so
that
we
don't
end
up
with
a
scenario
where
you
know.
F
If
you
want
to
run
any
of
the
boost,
you
need
to
run
some
client
and
therefore
we'll
skew
the
network
so
yeah,
it's
been
great
working
with
the
flashbots
team,
looking
forward
to
being
involved.
More
yeah
and
if
anyone
especially
from
the
client
teams,
have
any
questions
or
want
to
talk
about
it,
I'm
my
door's
always
open
thanks.
B
G
I
I
have
a
question
so
as
muv
boost
is
kind
of
this
middle
layer
that
between
something
that
produces
a
block
like
an
execution
engine,
but
we
still
have
a
execution
angle
to
fall
back
to
right.
Would
it
make
sense
to
like
bundle
it
with
an
execution
engine
process
like,
for
example,
never
mind?
Has
this
plug-in
ability?
G
B
Yeah,
I
I
think
this
is
kind
of
like
an
open
question
of
like
how
deeply
can
mav
boost
be
integrated
with
both
the
beacon
nodes
and
the
execution
clients.
We've
tried
really
hard
to
comply
as
closely
as
possible,
with
the
way
that
the
engine
apis
work
today,
so
that
it's
like
cross-client
compatible
by
default.
B
That
being
said,
I
do
expect
that
there's
some
advantages
to
having
deeper
integrations.
I
we
haven't
spent
that
much
time
looking
into
it.
To
be
honest,
we've
just
been
focused
on
how
to
make
this
thing
as
as
stable
as
possible
and
and
like
broadly
compatible
as
possible,
but
yeah.
I
do
expect
there.
There
could
be
some
some
advantages
to
to
integrate
further.
G
B
Right,
like
you,
could
definitely,
I
think,
implement
all
of
them
met
boost
logic
as
part
like
as
a
module
on
nethermind
right,
probably,
and
then
you
wouldn't
have
this
like
other
piece
of
software.
That's
running
in
between
you
would
just
have
the
execution
client,
that's
also
talking
to
our
relay
and
it's
it
ends
up
looking
much
closer
to
the
way
that
mavgeth
is
sort
of
architected
right,
but
you
do
like
remove
the
need
to
have
this
this
other
piece
of
software.
I
I
think
if
you
like,
if
you
run
a
successful
relay
or
like,
if
there's
a
cost
for
validators
to
to
to
like
be
at
multiple
relays
in
terms
of
whatever
setting
it
up
bandwidth
whatever,
then
they
would
probably
only
go
to
a
couple
and
like
how
can
we
make
sure
that
those
relays
are
not?
I
don't
know
getting
getting
bribed
out
of
banned
by
the
builders.
B
That's
propping
up
around
various
different
actors,
running
different
segments
of
the
system
right,
like
even
solo
stakers,
who
are
running
about
a
client
and
beacon
client,
are
still
outsourcing
their
execution,
clients
and
fira
right.
So
each
component
is
sort
of
set
up
to
be
bundled
together
with
each
other
in
a
way
that
provides
a
service
that
might
be
interesting
to
some
to
some
users.
B
Oh
yeah,
we
don't
want
to
trust
a
a
third-party
relay,
who
you
know
will
see
the
content
of
the
blocks
that
we
produce
and
so
we'd
rather
be
able
to
just
communicate
directly
with
validators,
and
so
they
they
will
try
to
run
their
own
relay
as
well
and
and
get
as
much
as
many
validators
as
possible
to
to
sign
up
for
for
their
relay.
Similarly,
I
do
expect
that
some
of
the
large
validators
will
say.
B
You
know
in
the
proof
of
workland,
both
the
relay
and
and
their
miners,
so
the
I
expect
they'll
probably
continue
to
do
this,
but
there
will
also
be
these
sort
of
individual
entities
that
are
incentivized
to
to
run
relays
so
within
the
flashbacks
working
group
right
now,
there's
three
entities
that
I've
indicated
so
I'm
interested
at
doing
this,
so
so
one
of
them
is
blocks
routes
who
they
are
currently
running.
A
relay
for
the
proof-of-work
version.
They'll
continue
to
do
this
here,
there's
a
consensus.
B
That's
indicated
they
perhaps
want
to
see
if
this
is
a
product
that
would
make
sense
within
pure
and
then
alchemy
as
well
have
have
indicated
some
interest
in
exploring
this.
So
I
do
think
there
are
some
entities
like
those
whose
you
know
business
model
is
very
much
so
on
being
an
infrastructure
provider
whose
role
is
quite
fitting
to
run
this
really
infrastructure.
I
I
B
On
that
right,
yes,
that's
right,
actually
I'll
shift
over
to
here
I
mean
I
have
one
line
on
here
that
describes
it,
but
it's
something
that's
worth
talking
about.
There's
a
slide
on
on
milestone.
Four
that
says,
consider
adding
merkle
proof
of
payment.
You
know
to
shift
verification
requirements
to
the
relay.
So
basically,
what
this
means
is,
instead
of
leaving
the
option
for
the
builders
to
set
their
own
coinbase
address,
or
you
know,
use
the
fee
recipient
of
the
coinbase
address.
B
It
would
say:
okay,
no
builders
always
set
their
own
coinbase
address
and
they
include
a
transaction
at
the
end
of
the
payload
that
pays
the
fee
recipient
and
then
what
they
can
also
do.
Then
the
relay
can
produce
this
proof
that
that
transaction
was
included
and
has
you
know
the
the
right
precondition
on
the
balance
of
the
builder
to
be
able
to
to
complete
the
payment
to
the
to
the
fee
recipient?
I
Yeah,
but
it
adds
like
some
complexity
to
to
block
building
and
two
like
two.
It
also
adds
complexity
to
people
that
are
not
using,
maybe
maybe
boost
right,
because
they
have
to
to
to
opt
into
this
to
the
same
api
like
I
would.
I
would
be
okay
with
having
this
as
an
optional
field
in
the
in
the
payload
in
the
in
the
get
payload
object,
but
not
having
this
required
yeah.
I
think
that's.
J
B
Correct
yeah,
so
in
this
initial
post
right
that
describe
this
architecture,
we
list
three
ways
that,
like
a
relay,
can
misbehave
first
one
is
just
producing
a
valid
payload.
Second,
one
is
misrepresenting
the
value
that
the
payload
has
and
then
the
third
one
is
missing
data,
so
just
never
revealing
the
transaction
list,
so
there
isn't
really
a
good
way
to
do
like
a
frog
proof
for
that
right,
because
it's
just
based
on
timing.
B
You
know
I
really
can
claim
that
the
message
came,
but
just
too
late
and
I
can
just
stall
it
out
or
or
whatever.
So
I
think
this
can
be
much
more
subjective.
Maybe
it
has
to
be
like
a
statistical
approach
where
you
know
if
a
relay
misses
more
than
x
number
of
slots
within
you
know
y
amount
of
block
proposals,
then
it
becomes
like
disabled.
J
Yeah,
thank
you,
yeah.
I
think
it's
going
to
be
solvable
without
like
like
completely
of
chain,
maybe
like
some
complicated
mechanics,
but
it's
it
would
complicate
things
but
yeah.
It's
like
still
like
a
possibility
of
of
attack,
this
kind
of
not
revealing
the
payload
in
the
end
of
all
interactions
but
yeah.
I
think
that
good
relies.
It's
not
interesting
in
twinsies.
K
B
B
They
allow
for
like
any
third
parties,
to
submit
a
list
and
like
maintain
their
list
of
tokens,
it
could
be
a
similar
system
here,
where
the
validators
can
delegate
to
a
third
party
list.
That's
curated
by
you
know
some
some
entity
that
carries
some
reputation
and
who
focuses
on
exclusively
verifying
the
the
activity
of
of
of
the
relays,
but
really
the
goal.
The
goal
is
for
always
maintaining
the
ability
for
the
validator
to
to
define
which
release
they
trust.
K
B
Yeah
it's
it
relies
on
this
reputation
right.
So
if
the
relay
does
something
malicious,
super
malicious
and
then
they
go
offline
and
like
spring
back
up
with
a
different
identity,
it's
it's
kind
of
up
to
all
the
users
in
the
network
to
try
to
identify
that
if,
if
the
user,
using
like
a
third
party
to
do
this
like
reputation,
check,
then
you'd
hope
that
that
third
party
would
be
able
to
identify
that
too.
So
it's
certainly
it's
certainly
a
risk
like.
K
B
B
Yeah,
so
you
could
have
like
an
extended
period
like
let's
say
all
the
relays
at
the
same
time
start
producing
bad
blocks.
Then
you
would
have
like
a
cycle
where
validators
like
one
by
one
disable
the
relays
right
and
so
maybe
like
just
thinking
about
it.
The
longest
amount
of
time
that
the
chain
would
go
is
like
the
number
of
like
relays
are
enabled
by
all
the
validators.
B
B
K
K
So
like,
obviously,
they
can
either
like
not
respond
with
a
block
which
is
the
same
thing
as
responding
with
an
invalid
block.
But
is
there
a
possibility
that
they
basically
respond
with
a
block?
That's
like
not
been
built
by
a
builder
and
they
just
come
up
with
their
own
thing,
and
it's
like
a
bad
block
in
some
way.
B
Yeah,
so
I
can
dig
into
like
the
three
ways
that
I
really
can
sort
of
do
something
bad,
so
the
first
one
is
just
like
it
tries
to
like
send
whatever
a
transaction
from
somewhere
that
doesn't
make
sense
or
like
just
contains
some.
You
know
some
logic
that
that
doesn't
work
like
the
the
header
is
formatted,
or
something
like
that
right,
so
the
payload
can
just
be
invalid.
B
Another
one
is
like
inaccurate
value,
so
something
that
a
really
could
do
is
you
know
the
block
that
it's
actually
producing
has
one
each
worth
of
value,
that's
being
paid
to
the
validator,
but
they
claim
that
there's
10
eth
worth
of
value,
and
so
you
know
they
can
basically
guarantee
that
they
win
the
profit
switching
here,
even
though
the
block
that
they
produce
wasn't
that
valuable.
So
I
say,
that's
probably
like
a
clearly
malicious
thing
that,
like
wouldn't
happen
by
accident,
is
over
reporting
the
the
value
of
a
block.
D
H
L
B
So
it's
not
defined
within
the
system,
you
know.
Actually
neither
is
the
builder
compensation
right.
I
sort
of
propose
like
the
way
that
I
think
builders
will
likely
want
to
monetize,
which
is
they
set
their
own
coinbase
address,
and
then
they
like
have
some
payment
and
they
can
keep
some
delta
between
the
two
and
still
their
incentive
is
to
pay
the
most
that
they
can
because
they're
competing
against
all
the
other
builders
and
producing
this
I
expect
relay's
business
model
to
be
more
fees
oriented.
B
So
if
we
just
think
about
how
like
block
blocks
route
operates
today
right,
they,
they
have
like
a
fee
per
number
of
messages
that
that
it
inputs-
and
you
know
obviously
infuria
and
alchemy-
have
a
similar
system
where
they
just
charge
by
like
api
calls.
So
I
expect
those
to
be
the
like
likeliest
monetization
routes
for
the
relay.
B
Maybe,
though,
I
don't
see
that
being
super
stable,
like
basically,
would
require
adding
additional
transactions
somewhere,
where
they
really
would
say.
You
know,
we
only
accept
blocks
from
builders
who
like
pay
us
within
the
block
that
they
produce,
and
then
they
would
like,
then,
for
the
payment
on
by
adding
their
own
transaction
at
the
end
of
the
block
to
the
to
the
validate
year.
So
it
could
be
doable.
It
could
be
doable
feels
somewhat
less
likely
to
me,
but
it's
a
possibility.
M
B
Yeah
good
question,
so
we
had
a
a
discussion
last
friday
where,
where
vitalik
presented
pbs
and
like
the
properties
that
that
it
has
so
it's
called
mev
roast,
maybe
there's
a
way
to
surface
a
link
to
that,
but
I
definitely
recommend
checking
out
that
talk.
Basically,
what
you
need
to
remove
the
relay
completely
from
the
system
is
the
ability
for
the
value
to
accept
messages
from
any
builder,
and
to
do
that,
you
need
to
have
unconditional
payments
attached
to
to
a
payload,
so
right
now
right.
B
The
way
that
it
works
is
the
builder
creates
a
payload
and
submits
it
through.
But
if
the
payload
is
invalid
right,
if
the
payload
reverts,
for
whatever
reason
the
validator
doesn't
get
paid
but
under
to
have
all
the
properties
that
you
want
to
be
able
to
remove
the
relay
you
need
to
have
this
be
completely
independent,
where
even
if
the
block
that
the
builder
proposed
is
is
completely
invalid
and
reverts
or
like
just
never
gets
accepted.
B
The
payment
from
the
builder
to
the
validator
still
still
settles
and
that
creates
sort
of
the
counter
incentive
for
builders
to
produce
valid
blocks.
It
like
prevents
the
dos
and
spam
issues
and
then
you
can
handle
basically
making
sure
that
you
continue
mining
on
the
ballot
chain
by
updating
the
fork
choice,
rule
of
of
the
chain.
So
that's
that's
how
pbs
sort
of
handles
this
issue.
A
Okay,
well
yeah.
If
there
are
other
questions
comments
as
people
look
into
it,
like
we
mentioned
earlier,
the
blog
construction
channel
is
the
right
place
to
discuss
this
thanks
a
ton
to
the
flash
boss
folks
for
coming
on
presenting
this
yeah
agreed
with
the
comments.
This
was
really
helpful
and
yeah.
Thanks
to
everybody
else
who
attended,
ask
questions
and
yeah,
I
guess
we
can
wrap
it
up.
We'll
have
a
recording
for
this
and
I'll
share
it
on
the
discord
as
soon
as
it's
ready.