►
From YouTube: Danksharding Workshop | Devcon Bogotá
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/danksharding-workshop/
Danksharding (full danksharding and EIP-4844) is the Ethereum layer 1 scaling protocol that Ethereum R&D teams are working on these days. This workshop is organized by the Ethereum Foundation Consensus R&D team. We will introduce to you the danksharding family solutions.
Speaker(s): Ansgar Dietrichs, Hsiao-Wei Wang, Dankrad Feist, George, protolambda, Francesco
Track: Layer 1 Protocol
Keywords: danksharding,das,scalability
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
Sharding
design
that
proposed
by
dankara
he's
here
today
in
2021
and
so
in
this
new
design
that
it
unlocked
so
many
scaling
I
mean
The
Challenge,
and
it's
not
that
now
the
charted
data
we
don't.
We
shot
it
at
the
data
blocks
rather
than
having
many
EVN
instructions,
but
the
dog
shotting
protocol
is.
There
are
still
some
technical
challenge
that
we
need
to
fix.
So
right
before
we
have
to
fall
down,
cutting
Proto
is
also
here
and
many
of
us.
A
They
call
elaborate
it
and
figure
out
that
we
can
have
a
more
feasible
Solutions
like
in
the
short
term,
to
address
this
cell
links
and
it
can
greatly
scale
the
ethereum
with
their
two
Roll-Ups
in
the
very
near
future.
So
that's
the
Proto
and
dankara,
and
this
is
the
Proto,
then
okay,
so
there
are
some
and
many
common
features
in
both
eip4
and
the
default.
Then
sharding.
So
today
we
will
break
down
these
topics
and
you
can
see
that
they
both
have
the
kcg
commitment.
A
So
Democrat
will
introduce
the
cryptography
part
first
and
they
also
have
the
blobs
transactions.
So
we
will
also
introduce
like
what
is
blob
today
and
fee.
Market
is
also
the
shared
common
features
here,
and
so
the
challenging
part
of
dunk
charting
is
the
PBS
and
the
DS.
So
we
will
also
talk
about
it
later.
A
A
B
Now,
I
will
be
going
through
the
technique
which
I
call
random
evaluation,
which
is
a
nice
trick
that
you
can
often
use
to
to
work
with
polynomials,
and
that
that
makes
a
lot
of
things
that
you
want
to
do
with
polynomials
a
lot
more
efficient
cool.
So
let's
talk
about
data
available,
assembling
and
eraser
coding,
so.
B
So
so
what
is
data
availability
sampling?
So
the
idea
is,
we
somehow
have
a
large
blob
of
data
and
and
what
we're
working
on
are
scalability,
so
scalability
means
that
somehow
we
have
to
make
it
so
that
a
node
has
to
to
do
less
work
to
achieve
the
same
thing
that
we
do
today
so
right
now,
every
node
ensures
that
all
ethereum
blocks
are
available
by
downloading
all
the
blocks.
B
That's
just
an
implicit
part
of
it
like
it
seems
obvious,
because
right
now
you
also
execute
the
full
blocks,
but
it's
one
of
the
things
that
don't
scale
in
the
current
ethereum
system.
So
we
need
a
way
to
to
reduce
this
this
workload,
but
we
want
to
do
it
in
such
a
way
that
we
don't
lose
any
of
the
security
that
this
provides
and
that
that's
what
makes
us
tricky
and
so
like
the
the
basic
idea,
is
okay.
B
B
So
if
we
do
this
naively,
if
we
just
take
the
data
as
it
is,
then
this
this
does
not.
This
does
not
really
work
because
even
even
missing
a
tiny
amount
of
data
is
catastrophic,
potentially
for
a
blockchain,
but
but
best
by
by
doing
random
sampling.
You
can
never
find
out
whether
a
tiny
bit
is
missing.
You
can
only
see
whether
major
parts
of
the
data
are
missing.
B
And
so
the
way
we
do
this
is
we
extend
the
data
using
a
so-called
resolomon
code
and
if
you
know
a
little
bit
about
polynomials
like
a
real
Solomon
code
is
nothing
else,
but
but
extending
the
data
using
polynomials.
So
what
you
do
is,
let's
say
like
in
the
simple
example:
we
have
four
blocks
of
original
data
and
what
we'll
do
is
we'll.
B
We
will
take
these
four
as
evaluation
as
of
a
polynomial.
There
will
always
be
a
polynomial
of
degree
three
that
goes
through
these
four
points,
and
then
we
can
evaluate
this
polynomial
for
more
points
and
what
this
means,
because
Four
Points
always
determine
a
polynomial
of
degree.
Three,
that
any
of
these
four
points
are
enough
to
reconstruct
exactly
the
same
polynomial.
B
It
does
not
matter
which
four
points
you
have,
and
so
this
this
is
like
this
is
the
basis
of
Erasure
coding
and
now
because
of
this,
the
data
will
be
sampling,
idea
that
we
had
here
and
actually
works,
because
now
I
don't
need
to
ensure
that
every
single
bit
of
the
data
is
available.
Now,
I
only
need
to
know
that
at
least
50
of
the
data
available
and
then
I
can
always
reconstruct
everything
yeah
sure.
B
Yes,
yeah.
We
have
double
the
data.
No,
so
that's
the
trick,
so
we
do
random
sampling.
So
as
an
example,
we
query
30
random
blocks.
So
if
the
data
is
not
available,
that
means
the
attacker
needs
to
have
withheld
50,
because
if
they
submitted
more
than
50
to
the
to
the
network,
it's
all
there.
Okay!
So
if
it's
not
available,
then
each
of
these
samples-
because
we
used
local
Randomness
to
query
them-
has
only
a
50
chance
of
succeeding.
B
So
that
means
in
aggregate
the
probability
that
all
of
them
succeed
is
now
2
to
the
minus
30,
which
is
one
in
a
billion.
So
this
is
why
it
scales,
you
don't
need
to
ensure
you
don't
need
to
query
50
of
the
data.
You
only
need
to
do
like
a
tiny
number
of
random
samples,
and
this
number
is
constant,
so
it
does
not
depend
on
the
amount
of
data
foreign
okay.
B
B
So
the
problem
with
this
is
that
mercury
Roots
do
not
tell
you
anything
about
the
content
of
the
data
so
like
it
could
be
anything.
So
in
this
case,
let's
say
an
attacker
wants
to
trick
our
data
availability
system.
They
could
just
not
use
this
polynomial
extension,
but
they
could
just
put
random
data.
So
basically,
in
coding
terms,
they
have
provided
an
invalid
code.
What
that
means
is
that
any?
B
So
the
interesting
question
is
what
if
we
could
find
some
kind
of
commitment
that
instead
always
commits
to
a
polynomial,
so
we
always
know
that
the
encoding
is
valid
cool
and
that
is
why
we
will
introduce
kcg
commitments
and
we
need
to
start
a
little
bit
earlier.
So
I
will
start
from
by
introducing
finite
Fields
a
little
bit
for
those
that
who
are
not
familiar
with
it.
Okay,
so
I
can
do
it
from
you,
okay,
so
what's
the
finite
field?
B
Okay,
so
to
understand
what
a
field
is,
it's
basically
think
about
rational,
real
or
complex
numbers,
which
you've
already
learned
about
and
just
remind
yourself
like
we
have
basic
operations
that
we
can
do
in
them.
We
can
add
subtract,
multiply
and
divide,
and
we
can
do
that.
Do
all
of
these
except
division
by
zero,
so
that
you're
always
you're
always
able
to
to
do
these
operations,
and
you
have
some.
B
You
have
some
laws
like
their
associative,
commutative
distributive
basic,
basically
just
think
of
like
I
mean
I
I
could
give
like
the
formal
laws
here,
but
I.
Don't
think
that
would
be
the
best
illustration,
because
you're
already
very
familiar
with
these
rules
when
you
work
with
rational
or
real
numbers,
and
the
big
difference
finite
feels
is
that,
unlike
unlike
these,
these
fields
that
we're
very
familiar
with
they,
which
all
have
an
infinite
number
of
elements?
B
They
have
a
finite
number
of
elements,
that's
quite
important,
because
otherwise
we
can't
encode
them
with
a
finite
number
of
bits,
which
is
yeah
kind
of
like
something
that
we
that
we
need
to
be
able
to
do
so
yeah.
So
that
means
that
each
element
can
be
represented
using
the
same
number
of
bits
and
as
an
example
on
of
showing
how
this
works.
Here's
he
has
a
very
small
finite
field.
This
is
F5
and
basically
the
way
it
works.
B
Is
you
you
take
the
five
numbers
zero
one,
two,
three
four
and
and
you
you
use
your
normal
integer
operations
to
compute
like
the
addition,
subtraction
and
multiplication,
but
whenever
you've
done
that,
you
take
the
result
and
do
module,
take
the
remainder
after
division
by
five.
So
you
take
it
modulo
five
and
then,
when
you
write
it
out,
basically
you'll
find
that
for
each
element,
so
we
haven't
yet
defined
like
how
do
we
do
division?
B
So
if
you
write
down
the
multiplication
table,
you'll
find
that
each
element
has
actually
an
inverse.
So
basically,
if
you
take,
for
example,
here
like
a
2,
then
you
can
see
that
2
times
3
is
6,
but
modulo
five,
that's
one.
So
it
has
an
inverse.
Okay,
that's
nice
and
like
then,
the
other
way
around
three
the
inverse
is
two
and
for
four.
B
B
So,
whenever
we
to
take
these
modular
operations,
modular
prime
number,
then
then
we'll
find
that
we
actually
have
a
finite
field
and
so
that
that's
our
final
Fields,
except
that
the
fields
we're
going
to
be
working
with
in
practice,
will
have
a
lot
more
elements.
So
the
prime
that
we're
going
to
be
using
will
have
255
bits.
B
So
it's
like
a
very,
very
big
number,
because
yeah
we
want
to
be
able
to
represent
a
lot
of
numbers
in
this
field:
cool,
okay,
let's
think
of
hashing
polynomials,
okay,
so
a
quick
reminder,
what's
a
polynomial,
so
a
polynomial
as
an
expression
of
this
form.
So
it's
like
a
sum
over
some
coefficients.
F,
I
and
and
and
terms
of
the
of
times
term,
of
the
form
x
to
the
power
five.
So
the
property
is
that
this
it
has
to
be
finite
sum.
B
So
it's
a
sum
from
zero
to
n,
and
we
is,
is
the
degree
of
the
polynomial
and
and
basically
the
other
important
thing
that
you
have
to
always
remind
yourself.
There
can
never
be
any
negative
terms,
so
you
cannot
have
x
to
the
minus
one.
It's
only
terms
of
the
form
x
to
the
power
of
0,
1,
2,
3
and
so
on,
yeah
and
and
each
polynomial
defines
a
polynomial
function.
So
it's
important
to
distinguish
between
the
two.
B
This
property,
you
don't
have
in
infinite
fields,
and
so
the
the
cool
property
that
polynomials
have
is
that
for
any
K
points
there
will
always
be
a
polynomial
of
degree,
K,
Min,
K,
minus
one
or
lower.
That
goes
to
all
of
these
points,
and
and
that's
polynomial
is
unique,
and
the
other
properties
property
is
that
a
polynomial
of
degree
n
that
is
not
constant,
has
at
most
n
zeros.
B
B
B
So
basically,
what
we
want
is
that
for
any
Z,
so
any
point
we
want,
we
can
evaluate
those
polynomials
comply,
compute
y
equals
F
of
that,
and
we
want
some
some
proof
that
this
is
correct,
so
that
that
that
would
be
an
interesting
hash
of
polynomials.
That
gives
us
something
new
and
and
this
this
hash
and
the
proof
should
be
small
in
some
sense.
B
So
here
here's
some
idea:
okay,
what
if
we
just
choose
a
random
number,
for
example?
Let's
say
we
choose
the
number
three:
if
we
want
to
Hash
a
polynomial,
we
just
evaluate
it
at
this
random
number.
Three,
so
we
said
we
put
x
equals
three
here's
a
couple
of
examples:
how
that
works.
If
we
stay
in
our
small
field
F5
for
between
that
five
and
before
with
just
those
five
numbers.
B
B
B
B
B
If,
if
you
use
this,
then,
if
someone
knows
this
random
number
right,
then
they
could
easily
create
a
collision
of
this
polynomial
function
because,
while
for
random
polynomials,
it's
very
unlikely
that
they
evaluate
to
the
same
point.
It
is
very
easy
to
create,
like
manually,
to
polynomials
that
evaluate
to
the
same
value
at
this
random
number,
so
it
doesn't
quite
work
as
a
hash
function
as
we
know
it,
but
what
it
would
be
different
if
somehow,
instead,
we
could
put
this
random
number
into
a
black
box.
B
They
cannot
craft
handcraft,
the
polynomials
that
so
that
they
evaluate
to
the
same
number.
At
that
point,
and
basically
the
cool
thing
is
that
elliptic
curves
actually
give
you
give
you
exactly
that
so
elliptic
curves
are
basically
you
you
can
think
of
them
as
a
way
of
creating
Black
Box
finite
field
elements
and
the
finite
field
that
you
have
to
use
is
the
curve
order
of
that
elliptic
curve.
B
If
you,
if
you
add
that
point
again
and
again
it
will
generate
your
whole
curve
and
the
the
order
of
the
curve
is
p.
So
that's
the
number
of
points
and
then
basically,
we
have
the
property
that
that
x
times,
G,
where
X
is
a
finite
field.
Element
x
times
G1,
it's
basically
this
black
box
and
the
reason
for
that
is
that
it
is
hard
to
compute
so-called
discrete
logarithms.
B
So
that's
that's
a
cryptographic
assumption,
and
so,
if
we
have
that,
then,
if
we
take
two,
if
we
took
two
elliptic
graph
elements,
G
and
H,
then
we
can
multiply
them
with
field
elements
like
we
can
compute
x
times.
G,
we
can
add,
add
the
two
G
plus
h
and
we
can
compute
linear
combinations
like
x
times,
G
Plus
y
times
H.
B
We
Define
that
at
x
times
G1,
and
so
basically
when
you,
when
you
see
these
square
brackets,
think
of
it
as
like.
This
is
a
prime
field
element
in
this
black
box
in
this
elliptic
curve,
black
box.
So
we
can
put
stuff
inside
and
there's
no
easy
way
to
take
them
back
out,
but
we
can
do
some
computations,
while
they're
in
there
cool
and
with
us.
We
are
ready
to
introduce
KCT
commitments.
C
B
So
it
looks
like
this:
it's
like
a
sum
of
coefficients
times,
powers
of
X
and
we
Define
the
kcg
commitments
as
as
this
sum
which
we
can
evaluate.
So
we
take
the
coefficients
and
we
replace
x
to
the
power
of
I
by
S
to
the
power
of
I
inside
this
black
box,
and
here
on
the
left
like.
So
this
is
something
we
can
obviously
compute.
B
B
It's
just
this
random
evaluation,
but
we've
managed
to
now
randomly
evaluate
this
polynomial
inside
a
black
box
at
the
secret
point
and
yes-
and
this
this,
we
call
the
kcg
commitment
to
the
function
f
and
now
in
order
to
to
do
interesting.
Things
with
this,
we'll
need
to
introduce
an
elliptic
curve
pairing.
A
B
B
And
so
what
we
couldn't
do
previously
between
elliptic
curve
points,
which
is
multiply,
multiply
two
elliptic
curve
points
is
that
we
can
do
in
a
way
between
pairing.
So
if
we
have
one
of
our
points
in
the
in
this
first
group
and
one
in
the
second
group,
then
due
to
this
bilinear
property,
we
can
it
actually
in
in
the
in
the
Target
group.
It
computes
something
like
x
times
y
right,
so
it
has
this
property.
B
We
Define,
we
Define
this
additional
notation
for
the
Target
group,
and
then
we
have
this
very
clean
and
nice
equation
that
the
pairing
of
X
as
a
black
box
element
y
as
a
black
box
element,
is
x
times
y.
So
this
is
very
important.
Basically
at
this
point,
when
we
have
the
pairings
and
that's
why
we
really
need
them,
we
can
do
one
multiplication
you
can.
B
That
we
have
two
polynomials
f
and
g
and
we
commit
to
those
polynomials,
but
we
come
commit
to
F
in
G1
and
G
in
in
G2
in
the
different
groups.
Then
then,
basically,
this
pairing
actually
lets
us
compute
this,
like
the
product
of
these
two
commitments
in
the
Target
group.
So
basically,
in
this
really
cool
polynomial
hash
that
we
have
defined,
we
can
now
if
we
commit
to
them
in
the
in
the
right
groups.
B
We
can
now
multiply
two
polynomials
that
are
committed
in
this
way,
so
we
can
multiply
the
the
commitments
without
even
knowing
the
polynomials
themselves,
okay,
cool
okay,
so
we
will
need
to
introduce
one
one
last
missing
piece
in
order
to
fully
come
to
how
how
kcg
commitments
work
and
how
we
can
construct
proofs,
and
that
is
quotient
of
polynomials.
Okay,
so
let's
say
we
have
foreign.
B
B
So
you
can
just
see
this
as
like
a
formal
expression,
but
sometimes
this
quotient
is
exact
so
sometimes
like
this
quotient
will
actually
result
in
another
polynomial
and
basically
there's
a
theorem.
That's
called
the
factor
theorem
It's,
relatively
elementary
math
you've-
probably
learned
that
in
school
at
some
point,
without
calling
it
that
basically
says
that
this
is
a
polynomial
disclosion,
exactly
if
F
of
Z
equals
y.
B
B
B
B
So
the
commitment
to
the
polynomial
polynomial
Q
and
in
order
to
verify
this,
what
the
verifier
will
do
is
they'll
take
this
quotient
and
they
will
multiply
it
by
the
commitment
to
S
minus
Z
and
check
that
this
is
the
same
as
original
polynomial.
The
commitment
to
that
minus
y
and
sorry.
This
is
unfortunate,
very
readable
on
this
background,
because
if
you
write
it
out
in
this
pairing
group,
then
you
get
on
the
right
hand,
side.
Q
of
s
times
s.
B
Minus
Z
in
the
Target
group
equals
F
of
s
minus
y,
and
this
is
the
same
as
the
second
equation.
So
the
cool
thing
is,
we
can
verify
this
equation,
because
we
are
able
to
multiply
two
polynomial
commitments
inside
using
the
pairing,
and
this
way
we
can
verify
that
the
portion
was
actually
computed
correctly.
B
Cool
yeah
and
that
that
is
basically
that
that
is
the
that
is
how
kcg
commitments
work
so
like
just
to
yeah
so
yeah.
So
so
the
idea
is
just
if
you
can
compute
this.
This
quotient
then
you'll
be
able
to
find
something
that
fulfills
this
equation
and
using
the
factor
ethereum
that
we
mentioned
previously.
B
If
F
of
Z
is
not
y,
then
you
cannot
compute
this.
It
doesn't
exist,
it's
not
a
polynomial
and
we
can
only
commit
to
polynomials
so
yeah.
This
is
the
recap
on
the
kcg
commitment.
We
can
commit
to
any
polynomial
using
a
single
element
in
G1
and
it
is-
and
this
is
just
the
version
valuation
of
the
polynomial
at
the
secret
Point
s
inside
the
black
box.
B
We
can
open
the
commitment
at
any
point,
so
we
can
compute
F
of
Z
and
by
Computing
the
quotient
Q
of
X.
We
can.
We
can
compute
this
proof
which
is
Q
of
s
in
the
black
box
and
in
order
to
verify
that
proof
we
use
this
pairing
equation
and
and
that
that
shows
a
verifier,
that
this
evaluation
is
correct.
B
B
Okay,
so
basically,
let's
recall
that
kcg
commitments
are
nothing
but
evaluating
a
polynomial
F
at
a
second
Point
s
inside
this
elliptic
curve,
Black
Box,
and
so
in
a
way.
This
is
already
like
a
random
evaluation
like,
but
basically
what
we've
done
is.
We've
we've
identified
this
polynomial
using
random
evaluation,
and
we
kind
of
we
somehow
found
that
this
is
good
enough
to
like
to
Hash
a
polynomial
in
a
way
that
it's
very
difficult
to
create.
B
Collision
and
more
generally,
this
random
evasion
trick
can
be
used
to
verify
polynomial
identities,
and
the
reason
for
that
is
the
amstrad's
typical
Lemma
and
I
will
just
formulate
as
a
more
General
one,
but
let's
say
what
it
says
in
one
dimension,
so,
let's
have
a
degree,
a
polynomial
of
degree,
less
than
n.
That
is
not
identical
to
zero.
So
there's
one
particular
polynomial
that
is
zero
everywhere,
that's
just
like
all
zeros
right,
that's
a
very
special
polynomial.
B
So,
for
example,
in
for
blast,
1231,
PES
255
bits
say
we
commit
to
a
polynomial
of
degree
2
to
the
12th,
then,
as
probability
is
something
like
2
to
the
minus
240
so
like
it's
a
very,
very
small
probability,
okay,
and
so
here
here's
the
first
way
in
which
in
which
we
can
use
this
so
like
we
have
this
transaction
blobs
that
we'll
Define
for
4844.
So
it's
like
they
are
commitments
to
polynomials
with
four
thousand
six.
B
Ninety
degree
4095,
so
a
total
for
1096
points
and
to
committing
such
Computing.
Such
a
commitment
is
not
very
expensive,
but
it
is
expensive.
It's
like
for
50
milliseconds
to
do
this,
but
verify
one
kcg
proof
is
quite
a
lot
cheaper.
It
only
costs
about
two
milliseconds,
so
we
can
use
this
to
our
advantage,
and
so
the
idea
is
this:
we
take
our
commitment
to
the
polynomial
see
and
we
take
the
polynomial
F
itself.
B
B
We
do
we
compute
a
random
point
and
one
way
to
get
a
random
point
is
actually
a
very
cool
technique.
It's
called
via
chamir
and
we
take
all
our
inputs.
So
we
compute
that
as
the
hash
of
the
commitment
and
the
polynomial.
Why
is
that
kind
of
random
because,
like
if
an
attacker
tries
to
craft
something
if
they
try
to
adversarially
compute,
either
C
or
F,
it
will
always
change
the
point
that
so
it's
very
hard
for
them
to
find
some
like
to
to
craft
them.
B
In
a
way
that
that
breaks
our
construction,
so
basically,
this
is
a
common
technique
in
and
cryptography
to
to
get
something
random,
that
the
attacker
cannot
control,
and
so
we
evaluate
this
polynomial.
Why,
at
at
this
random
point
that
we've
taken
and
then
we
compute
a
kcg
proof
that
F
of
Z
equals
y
and
basically
that
then
what
we'll
do
is
we
just
add
this
proof
to
our
transaction
blob
wrapper,
which
is
the
way
we're
sending
transactions
and
then
like
to
verify
this.
You
compute.
B
B
And
so
what
we
do
in
this
case
is
basically
you
have
to
you.
You
commit
to
the
data
in
a
different
ways,
so
we
have.
We
have
three
different
inputs,
so
we
have
our
blob
data,
which
is
this
function
f
itself
and,
and
we
have
two
different
type
of
commitments.
Now
we
have
C,
which
is
our
blob
commitment,
which
is
what
we'll
use
inside
ethereum
for
4844,
and
we
have
another
way
of
committing
to
this
data,
which
is
using
the
the
ZK
Roll-Ups
native
commitment.
B
So
they
will
in
some
way
it
will
also
have
some
way
of
committing
to
data
that
that
works.
Well.
For
the,
as
you
know,
it's
proof
scheme,
and
so
in
this
case,
what
we'll
do
is
we'll
take
Z
as
a
hash
of
C
and
R
like
these
two
different
commitments,
and
we
will
compute
y
again
as
F
of
Z
and
we'll
add
pi
as
a
proof
that
F
of
Z
equals
y
and
we'll
we'll
add
this
pre-compile.
That
allows
us
in
the
ethereum
virtual
machine
to
verify
that
the
the
kcg
proof
pi.
B
So
we
will
know
that
c
c
is
a
correct
commitment
to
f
and
what
we'll
need
to
add
is
to
add
the
proof
that
R
is
also
an
a
correct
commitment
and,
and
the
ZK
roll-up
can
do
that
inside
the
proof.
So
they
will
inside
the
proof
they
also
have
to
somehow
get
C
and
R
as
an
input
and
hash
them
and
compute
that
and
then
they
can
they
can
evaluate.
B
So
they
will
also
have
F,
because
the
rollup
wants
to
use
the
data,
so
f
is
completely
available
to
them
and
they
just
have
to
compute
y
equals
F
of
Z
and
use
some
technique
to
verify
that
the
f
is
the
same
as
they
are.
But
that's
there
are
ways
to
make
this
easy,
and
then
they
can
verify
that
they
have
the
same
data
as
was
committed
through
C,
so
that
will
make
it
much
easier
to
use
these
commitments
in
ZK,
rollups,
okay,
cool
and
yeah
I
collected
some
resources.
B
If
you
want
to
read
further
on
this,
so
vitalik
wrote
a
while
ago,
a
post
on
elliptical
pairings
I,
because
there
was
a
lot
of
interest
in
that
I
wrote
some
notes
on
how,
on
this
last
part,
how
to
use
kcg
commitments
in
ZK
roll-ups
for
those
who
are
like
kind
of
skeptical
and
they're
like
wondering.
Do
we
really
need
this
like
Advanced,
cryptography
and
trusted
setup,
and
so
on?
B
B
D
E
B
B
Yes,
but
so
we
are
setting
in
cryptography,
we
are
setting
our
security
parameter
already,
in
the
assumption
that
an
attacker
will
do
a
lot
of
computation
to
try
to
break
it
like
2
to
the
50
to
the
60
or
more
computation
power.
This
is
much
much
more
than,
however,
we
ever
use
it
in
in
the
actual
protocol
so
like
this
is
all
already
covered
by
the
by
the
cryptographic.
Construction.
B
I
mean
you
can
do
it,
but
the
random
probabilities,
like
the
probability
of
randomly
hitting
that
are
extremely
extremely
low,
like
if
you
like,
if
you
construct
it
so
that
the
probability
so
yeah
yeah
like
randomly,
they
are
less
than
two
to
the
minus
200,
or
something
like
that.
It's
like
so
low.
You
cannot
even
like
yeah,
think
about
it.
Yeah.
D
D
B
Yes,
yeah,
no,
you
can't,
but
that's
fine,
okay,
so
we
are
always
because
we're
limiting
the
degree
of
our
polynomials
right.
So
our
trusted
setup
will
only
go
to
a
certain
power,
for
example
to
the
power
of
12
and
inside
that
space.
There's
only
the
zero
polynomial,
yes
yeah
yeah
so
like.
If
you
have
no
limits
on
the
polynomial
decrease,
then
it
doesn't
work,
but
we
always
have
a
limit.
G
G
So
I'm
gonna
start
with
a
small
like
explanation
of
how
all
this
math
stuff
going
to
our
protocol
and
how,
like
you
know,
all
the
extra
bandwidth
of
4844,
travels
around
and
gets
verified,
then
Proto
is
gonna.
Take
it
and
tone
it
even
down
into
more
practical
stuff
like
how
the
l2s
are
gonna,
use
the
data
and
then
answer
card
is
going
to
turn
it
even
more
down
and
basically
explain
how
people
pay
for
this
data.
So
okay.
G
So
basically,
this
is
a
graph
that
shows
how
like
Optimum,
optimism
and
L2.
What
is
its
costs?
And
you
can
see
that,
like
this
blue
stuff,
is
the
data
fees
like
how
much
money
they
are
paying
for
the
like
data
they
put
on
chain
and
the
other
like
white
stuff
is
some
other
stuff?
But
you
can
see
that
the
blue,
the
data
is
dominating
all
the
costs.
So
basically,
what
4844
is
it's
like?
G
A
mechanism
that
drastically
increases
the
amount
of
data
people
can
post
on
chain-
and
this
is
all
it
is
right,
so,
okay,
so
basically
what
we
want
to
do
is
we
want
to
increase
the
amount
of
data.
So,
on
this
very
simple
picture,
on
the
left
side,
you
can
see
our
data,
which
we
call
blob,
because
it's
a
bunch
of
data
that
also
corresponds
to
polynomial
and,
on
the
right
hand,
side.
G
You
can
see
a
small
thing,
a
commitment
that
represents
that
data
commits
to
that
data,
and
the
like
graph
idea
is
that
you
know
commitment
goes
and
chain
forever,
whereas
The
Blob
is
kind
of
like
you
know
there
for
a
bit
and
then
disappears.
So
this
is
like
the
high
level
strategy
of
how
we
increase
bandwidth.
We
commit
to
data,
we
keep
the
commitment
forever,
but
the
data
is
ephemeral
in
a
way
okay.
So
let's
talk
a
bit
about
what
this
data
is,
what
these
blobs
are,
how
do
polynomials
enter
this
picture?
G
So,
okay,
this
is
a
polynomial
I
think
by
now
you're
very
familiar
with
it.
Based
on
the
last
talk,
the
question
is
like:
how
do
we
put
data
into
this
polynomial
and
like
the
basic
idea,
is
you
know
you
have
these
coefficients
the
A1
a2a
whatever
and
each?
If
you,
you
can
basically
put
data
into
this
coefficient.
So
you
know,
if
you
have
some
data
one
four
one
six,
you
can
put
it
in
the
coefficient,
so
you
make
this
little
polynomial
on.
H
G
G
So
in
our
case
the
numbers
are
going
to
be
finite
field,
so
they're
going
to
be
parts
of
a
finite
field
which
is
going
to
be
like
a
number
between
zero
and
this
insanely
huge
prime
number,
and
so
each
coefficient
is
going
to
be
a
number
between
these
two
things
and
that's
about
254
bits.
That's
about
31
bytes!
So
a
coefficient
with
a
polynomial
with
like
4096
coefficients,
can
store
about
128
kilobytes
by
putting
the
stuff
into
the
coefficients.
G
So
you
know
now
we
know
of
a
way
to
store
128
kilobytes
into
polynomial
and
that's
kind
of
interesting
because,
like
you
know,
right
now,
roll
ups-
they
don't
even
use
close
to
that
number
like
maybe
they
use
one
kilobyte,
so
we're
basically
giving
lots
and
lots
of
space,
maybe
even
uncomfortably
lots
of
space
to
roll
ups
to
put
their
stuff
in.
But
this
is
like
the
whole
idea
of
4844,
of
course.
G
G
So
you
end
up
with
a
situation
where
you
know
you
end
up
posting
on
chain
lots
of
data
and
then
a
small
commitment-
and
this
is
like
the
rough
idea
so
just
to
talk
a
bit
about
like
when
this
data
travels.
What
the
network
is
supposed
to
do.
You
know
like
when
you
see
a
commitment
that
corresponds
to
lots
of
data.
G
You
know,
fooling
us
and
giving
us
a
wrong
commitment
to
other
data
which
would
be
catastrophic
is
to
you
know
like
commit
to
P
of
X
use
this
black
box
again
commit
to
it
and
then
check
that
the
commitment
that
the
verifier
computed
matches
the
commitment
that
the
guy
gave
you
so
that
that's
basically
a
pretty
straightforward
way
to
to
verify
that
polynomial
matches
the
commitment.
But
you
know,
then
we
have
more
data
and
more
commitments.
G
You
know
in
a
transaction,
you
can
have
lots
of
those
in
a
blog,
you
can
have
block,
you
can
have
lots
of
those
and-
and
that
starts
being
quite
expensive.
So
what
we
end
up
doing,
because
you
know
like
it's
50
milliseconds,
to
do
each
of
the
commitments
so
and
it
scales
linearly.
So
that
ends
up
being
quite
expensive,
especially
you
know
for
mempool
and
this
kind
of
stuff.
G
G
I
You
foreign,
so
let's
talk
about
the
blob
usage
so
with
ep44
we're
introducing
a
transaction
type
to
make
to
confirm
these
blobs
in
the
evm10.
However,
something
to
note
is
that
it's
A
New
Concept
here
where
we
are
having
a
transaction
type
left
data
outside
of
the
transaction.
That's
now
responsibility
of
the
consensus
layer,
so
it's
like
a
regular
erpm159
transaction.
I
I
This
is
the
transaction
in
a
little
bit
more
detail.
Something
else
to
note
is
that
it's
not
ROP,
but
as
you
see
that
mercolizes
nicely
it's
better
for
layer
too,
and
then
note
here
that
we
have
these
data
hashes
committing
or
to
hashing
the
case
D
commitments,
which
then
commits
to
the
film
block
data.
I
These
data
hashes
are
available
in
the
evm
through
an
opcodes,
whereas
The
Blob
data
lives
outside
of
the
evm.
So
the
blob
content
is
unlike
call
data
not
available
in
evm.
Eventually,
we
can
prune
this
block
diagram.
It's
not
a
long-term
commitment
to
store
of
this
block
data,
but
rather
we
are
introducing
this
blob
data
and
just
for
the
availability
properties,
a
layer
2
needs
this
data
to
help
users.
Sync,
the
latest
states
permissionlessly,
without
communicating
directly
with
the
sequencer
or
whichever
operator,
exists
on
the
roll
up,
and
then
people
can
reconstruct
the
latest
stats.
I
I
This
is
task
for
develop
operator
and
then,
as
a
rollup
operator,
you
publish
your
bundle
to
layer,
one
with
this
new
transaction
type
and
then
in
the
transaction
pool.
We
have
both
the
transactional
paste
the
fee,
as
well
as
the
wrapper
data
with
the
actual
blob
content
and
then
the
layer
bomb
Beacon
proposer
creates
a
block
and
the
blobs
make
their
way
from
the
transaction
pool
in
the
execution
layer
to
the
consensus
layer
and
his
parents,
the
blobs
don't
get
into
the
exclusion
layer
back.
I
It's
just
the
responsibility
of
the
consensus
layer,
pairs
on
the
beacon
that
and
they
think
the
blobs
bundle
together
with
blobs
from
other
transactions
as
a
sidecar,
and
then
the
execution
payload
stays
on
layer
one,
whereas
the
blobs
stay
available
for
a
sufficient
amount
of
time
to
secure
there
too,
but
then
can
be
pruned
afterwards.
So
blob
data
is
bounded.
I
We
have
the
layer,
2
sequencer,
communicating
with
the
transaction
tool
the
execution
engine,
communicating
as
the
beacon
proposer,
then
Beacon
notes,
syncing
the
blobs
with
each
other
and
then
there's
the
splits
of
the
data
where
the
other
big
nodes
they
give
the
execution
payload
process
the
ECM
and
everything
fees
will
be
processed
by
everybody,
the
Deep
blobs.
They
are.
They
stay
in
the
contents
layer
into
a
layer.
Two
node
retrieve
stem
to
reconstruct
the
layer.
Two
stains.
I
Already
explained
the
proof
of
equivalence
trick
so
I'll
give
you
just
a
simplified
overview.
How
we
do
this
in
the
evm,
we
introduced
two
new
things
in
evm
and
opcodes,
and
a
pre-compile
the
up
codes
simply
retrieves
the
data
hash,
which
is
this.
This
hash,
that
is
part
of
the
transaction.
Just
like
the
hashes
in
the
access
list
from
the
Berlin
transaction
type.
I
It
can
be
retrieved
through
an
opcart
pushed
on
the
stack
and
address
this
pre-compile,
which
you
can
provide
with
a
proof
to
verify
that
a
certain
data
at
a
certain
position
matches
the
deep
Loop
contents
committed
to
by
the
data
hash
and
in
the
case
of
zika
rollup.
We
do
so.
We
use
this
pre-compile
to
do
a
randomly
Federation
and
prove
that
the
data
that
the
rollup
is
importing
is
equivalent
equal
to
the
data
that
develops
this
into
the
blob
is
introducing.
I
I
I
And
then
this
is
the
version
of
the
interactive,
optimistic,
roll-ups,
interactive,
optimistic
rollups
use.
This
concept
called
a
pre-image
Oracle,
where
we
do
not
access
all
the
data
at
the
same
time,
but
rather
we
loads
pre-images
one
at
a
time
and
by
bisecting
an
execution
Trace.
We
only
really
have
to
do
a
proof
for
a
single
step,
a
single
execution
of
a
single
like
VM
instruction,
and
this
might
be
loading
some
data.
So,
for
example,
the
start
with
a
layer,
1
block
header
hash.
Then
we
retrieve
the
fill
block
header
as
a
pre-image.
I
Then
we
retrieve
the
transactions
by
digging
into
the
Mercury
commitment
in
the
transactions
hash,
and
then
we
can
get
the
data
hashes
from
the
transaction
and
then
from
the
data
hash.
We
can
get
the
case
D
commitment
and
then
it's
not
a
regular
hash
commitment
anymore,
but
there's
a
different
type
of
commitment
with
the
same
Oracle,
where
we
loads
one
point
from
The
Blob
that
is
committed
to
by
the
plot
transaction.
J
I'm
going
to
talk
a
little
bit
about
now
that
we
hopefully
in
the
future,
will
have
this
functionality.
How
how
can
you
pay
for
it,
but
also
kind
of
conceptually
basically
I
mean
the
data.
Unboxing
is
already
you
know,
kind
of
pushing
into
limits
like
where's
the
extra
space
and
resource-wise
for
this?
Basically,
where?
Where
does
the
efficiency
gain
here
come
from
and
to
understand
that
first,
we
have
to
just
look
in
general
about
like
how
do
how
does
research
resource
pricing
on
ethereum
work
today?
J
J
Just
you
know,
keep
it
round
forever
for
history
purposes
and
similar
with
State
access
and
state
growth.
These
kind
of
things
now
specifically
for
4844
right.
What
we
are
introducing
is
this
new
type
of
data,
so
kind
of
the
the
resources
we're
talking
about
here
this
this
first
kind
of
row.
So
it's
it's
on
those
burst
limits,
it's
the
bandwidth!
How
how
big
can
box
get
and
then
on
the
sustained
limit?
J
It
does
mean
that
there
will
be
is
some
extra
requirement
for
node
operators,
but
it's
quite
bounded
Because
unless
normal
history
that
today
is
stored
forever,
but
even
after
this,
this
nice
erp444,
basically,
even
even
after
that,
it's
still
going
to
be
stored
for
a
year.
Blobs
are
only
stored
for
a
month.
So,
basically
in
terms
of
sustained
limits,
it's
it's
not!
Basically
it.
J
It
has
like
a
very
limited
impact,
but
the
more
interesting
and
also
more
tricky
side
of
this
picture
is
the
the
burst
limit,
so
so
bandwidth
and
to
kind
of
understand
like
what
what
the
situation
is
and
how
44
fits
in.
We
have
to
first
remember
that
today,
on
ethereum,
basically,
we
only
have
a
single
gas
price
right.
Whenever
you
send
a
transaction,
you
don't
actually
specify
how
much
bandwidth
am
I.
J
Basically,
but
the
way
it
works
is
basically
that
it
is
basically
that
those
two
resources
and
compete
for
for
for
for
for
usage
in
a
block
right.
So
you
could
imagine
if
you
use,
if
a
block
is
very
full
of
compute,
then
there's
very
little
room
for
to
to
put
any
data
in
it
or
the
other
way
around.
And
actually,
if
you,
if
you
want
to
like
open
ether,
scan,
for
example,
they
fight
for
every
block
for
the
detail
page.
J
They
actually
give
you
the
size
of
the
block
and
usually
it's
something
like
50
kilobytes,
100
kilobytes,
but
like
rarely
more
than
that.
But
if
you
look
at
what
would
a
block
look
like
if
it
was
was
like
just
full
of
call
data,
which
is
where
all
the
data
comes
from?
If
we
were
all
the
way
like
say
on
the
lower
part
of
the
diagram,
if
recess
B
was
was
Data,
it
could
actually
be
up
to
one
or
two
megabyte
like
well,
two
megabytes,
basically
of
of
size
right.
So
so
what
that
means?
J
Is
we
basically
determined
in
the
past
that
two
megabytes
per
block
are
kind
of
safe
and,
and
the
reasons
would
be
there
right,
it
basically
sitting
there,
but
an
average
block,
basically
almost
like
you
completely
underutilizes
data,
and
that
is
again
just
just
because
it
is
simpler
for
us
conceptually
to
price
these
things.
So,
most
of
the
time
we
are
like
very
far
up
up
the
slope
there
and
where
do
we
want
to
be
like
what
would
be
like
the
most
efficient
way
of
handling
resources?
J
Well,
that
would
basically
be
be
this
picture,
so
ideally,
you'd
want
to
basically
make
these
things
be
independently
used
consumable
where
you
can
basically
consume
the
most
amount
of
like
the
most
the
highest.
Save
amount
of
data
that
we
think
you
should
be
like
the
chain
can
manage,
but
then,
at
the
same
time
you
should
also
be
able
to
you
know:
do
we
still
do
state
access
to
the
biggest
the
highest
amount
possible
or
memory
or
whatever
right?
J
There
should
not
be
this,
this
kind
of
a
competitive
nature
to
it,
and
this
is
basically
where
four
eight
four
four
on
the
burst,
Limit
side
gets,
gets
it
in
efficiency
right
because
full
charting
full-time
charting,
we'll
hear
about
it
a
bit
more
after
this.
Actually,
that's
really
clever
things
where
people
only
sample
the
data,
so
bandwidth
constraints
goes
quite
down,
but
for
eight
for
four
there
is
no
fancy
trick
right.
J
Everyone
still
downloads
all
the
data,
so
it's
very
real
bandwidth
strain,
so
the
Innovation
and
the
burst
Limit
side
is
purely
trying
to
get
to
this
upper
right
point
trying
to
actually
basically
make
it
so
that
the
existing
resource
we
already
have
today
is
just
more
efficiently
utilized
and
the
way
we
do
this
is
by
going
from
as
we're
saying
like
right
now.
Today,
pricing
is
one
dimensional
and
so
what
we
introduced
with
point
for
voice.
Basically
we
go
to
D,
and
this
is
how
that
how
that
looks
like
so
this
is.
J
This
is
an
open,
PR
right
now,
it's
not
yet
quite
much,
but
you
can
have
a
look
so
like
small
details
might
still
change,
but
I
think
the
general
direction
is
is
pretty
sad
and
so
the
idea
is
we
introduce
what
we
call
data
gas
and,
as
you
can
kind
of
figure
from
the
name,
it's
not
blobcast
status.
The
aspiration
would
be
that,
like
maybe
in
the
future
we
can.
J
We
can
expand
this
to
cover
the
entire
data
Dimension,
but
for
now
it's
it's
only
used
for
blobs
and
we
we
set
it
in
a
way
where,
basically
like
one
byte
of
of
plop
will
cost
one
data
gas,
and
this
data
gets
importantly,
basically
is
completely
independently
priced
from
normal
gas.
So
it
has
its
own
5059
style
mechanism.
Where
and
that's
that's
where,
basically,
where
they
use
and
I
see.
J
Mario
is
not
very
happy
about
this
because
you
know
like
he
has
to
implement
it
and
get
it
in
of
the
day,
but
this
is
really
important
for
the
EAP,
because
other
than
that,
basically
you
wouldn't
be
able
to
get
to
this
more
efficient
bandwidth
usage.
So
what
does
it
look
like
and
how
does
how
can
you
think
about
it?
Well,
it's
just
you
know
similar
to
how
5059
already
looks
so.
The
way
to
the
this
is
the
courtesy
of
Proto
I
stole
the
site,
and
so
every
column
here
would
be
a
separate
slot.
J
So
the
first
slot-
and
in
this
case
basically
the
the
the
target
amount
of
blobs,
would
be
two
the
maximum
allow.
It
would
be
400
block.
So
the
first
block
first
block
comes
in.
It
has
exactly
two.
So
nothing
happens.
The
next
one
has
three
right:
the
red
one.
It's
basically
one
one,
two,
two
many
so
the
price
would
go
up
and
then
the
next
two
kind
of
like
are
stable
again
and
then
then
one
moves
as
a
blob,
so
the
price
goes
back
down.
J
So
it's
like
a
very
you
know
like
just
like
1559
like
you,
you,
you
know
and
love
it.
Basically,
it
is
a
bit
different
or
like.
Basically
it's
it's
under
the
hood.
It
works
a
bit
differently,
so
here's
kind
of
a
bit
more
more
look
at
the
details
here.
So,
first
of
all,
of
course,
just
we
have
the
max
data
gas
per
block
right,
just
similar
to
259
and
the
Target
that
that
is
half
of
that
transactions.
These
block
transactions.
J
They
specify
an
additional
Max
fee
per
gate
per
data
gas
field
so
like
how
much
are
they
willing
maximally
per
data
guess
and
to
to
to
have
their
transaction
included?
Importantly,
you
know
that
this
introduce
a
little
bit
extra
complexity
for
users,
but
users
in
this
case
are
not
actually
users.
Those
are
like
big
Roll-Ups
right,
so
basically
them
having
to
specify
one
more
value.
J
Basically,
if
the
demand
were
to
completely
crash
theoretically,
like
one
gas
could
could
be,
could
be
I
think
valued
as
little
as
seven
way,
which
is
just
the
minimum
after
which
basically
updates,
don't
don't
go
lower
anymore,
so
the
transactions
would
basically
be
free.
We
don't
quite
want
basically
to
make
the
the
lowest
demand
case
of
transactions
here
completely
free.
So
we
said
a
minimum
data
gas
price-
that's
a
that's
kind
of
at
least
somewhat
meaningful.
So
that's
like
10
to
the
minus
five
eighth
per
plop.
J
We
we
usually
check
the
base
fee
directly
and
then
we
update
it
every
every
block
and
actually
turned
out
after
we
introduced
it
like
looking
at
it,
it's
slightly
conceptually
ugly,
because
we
always
do
these
these
kind
of
so
basically
there's
some
some
properties
in
the
upgrade
updating.
We
don't
quite
love,
it's
it's
a
little
path
dependent
and
these
kind
of
things.
So
so
we
move
to
to
just
a
conceptually
simpler
way
of
tracking
for
this
Dimension,
where
we
track
the
excess
excess
data.
J
Guess
that
has
been
basically
been
used
over
the
existence
of
the
EIP
right.
So
basically
we
just
we
have
some
sort
of
Target
that
we
want
to
be
used
and
then
every
every
block,
if
it
basically
uses
more
than
that.
We
just
add
to
this
to
this
counter
and
then
every
block
wave
is
basically
use
less
than
that,
but
we're
still
above
zero.
In
this
counter,
we
just
reduce
the
counter
yeah
sure
if
you
wanna
foreign.
J
Just
like
the
base
fee,
yeah,
so
yeah
yeah.
So
this
is
one
additional
header
field
which
good
question
actually
also
I
you
can
you
can
see
that
because
I
just
wanted
to
give
you
like
an
impression
of
of
what
the
kind
of
calculating
the
the
the
the
the
cost
looks
like
with
this
header
field.
So
as
you
can
see,
basically
we
have
these
kind
of
functions.
J
If
you
want
to
to
get
the
the
feed
that
in
transaction
actually
has
to
pay.
It
depends
on
on
on
on
the
head
of
the
previous
box,
similar
to
1559,
and
so
you
first
get
the
total
data
guys
that
the
transaction
consumes,
which
is
just
you,
know,
data
gas
per
block
times
the
number
of
blobs,
and
then
you
calculate
the
basically
the
base
fee,
but
we
don't
call
it
basically
because
again,
there's
no
tip
so
it's
kind
of
unnecessary
to
have
the
base
fee
tip
distinction.
J
So
we
just
call
it
data
gas
price
and
so
how
you
basically
for
each
block
you
once
basically
calculated
its
state
I,
guess
price,
and
you
do
that
by
by
basically
taking
in
there's
this
excess
data
guys,
and
then
we
use
this
fake
exponential
function.
It's
a
little
nice
little
tidbit
I,
don't
know!
Maybe
it's
irrelevant,
but
it's
it's
something
time
to
talk
about
briefly
So
like
just
because
we
want
we
want
some,
so
maybe
I
can
already
go
to
the
next
step
to
explain
so.
J
Basically,
this
is
kind
of
how
the
pricing
develops.
It's
it's
like
1559
right.
So
basically,
if
you
were
to
continue
to
just
keep
keep
basically
using
up
all
the
data
space
in
a
block
not
just
the
target,
it
would
basically
be
on
an
exponential
curve
and
would
be
more
and
more
and
more
expensive,
and
you
can
see
basically
like
a
thousand
a
thousand
excess
plops
that
that's
roughly
I,
don't
know
something
like
10
minutes
or
so
so
within
10
minutes,
you'd
really
like
they
have
like
super
expensive
blobs.
J
So
this
the
nice
thing
about
this
is
that
it's
basically
a
pure
function
in
in
excess
data.
Guess
right!
So
it
doesn't
really
matter
if
it
was
simulated
at
the
beginning
or
at
the
end
there
will
probably
be
a
different
like
in
the
beginning.
It
will
probably
be
relatively
cheap
to
to
use
data
guess
because
robots
are
still
kind
of
adopted
in
the
process
of
adopting
it.
J
So
there's
not
that
much
that
much
demand
so
basically,
probably
for
the
first
first
month
or
so
we'd
be
like
in
the
very
zoomed
in
left
part
of
this
picture
and
then
later
on
once
once
it's
all
basically
fully
adopted
and
people
use.
It
we'll
be
like
a
bit
more
towards
the
right
in
this
picture,
but
it's
not
like
this
is
not
a
basically
because
it's
so
reactive,
it's
it's
similar
to
559,
so,
basically
every
block
in
it
most
they're
doing
12.5
update.
So
the
difference
here
like
basically
you
can
come.
J
You
can
go
from
one
of
these
paradigms
to
the
other
within
five
minutes
of
of
of
high
usage
or
low
usage
blocks.
So
it's
not
like
it's
not
basically
something
where
it
matters
immensely.
What
and
what
what
was
done
in
the
in
the
past?
Basically,
a
lot
High
consumption
in
the
past
only
means
that,
like
basically,
you
have
like
five
five
minutes
of
of
reduced
pop
usage
before
you're
back
to
your
normal
price
level.
So
it's
not
Yeah,
so,
basically,
there's
no
significant
kind
of
accumulation
effect
or
anything
right
right.
J
Sure
no,
no,
but
the
thing
is
because
so
so
the
way
to
think
about
it
is
like
because
the
the
the
price
is
a
pure
function
of
the
excess
data,
guys
so
at
any
excess
excess
data.
I
guess
I
mean,
of
course,
I
put
down
excess
plops
just
to
think
about
it
more
easily,
but
it's
tracked
in
excess
data.
I
guess,
but
once
you
reach
something
like
say:
I,
don't
know
a
thousand
excess
excess
blobs.
J
That
would
mean
that
sending
one
block
already
costs
30
each
and
that
doesn't
matter
whether
the
excess
blobs
were
accumulated
over
one
day
or
if
they
were
accumulated
over
a
year.
So,
basically,
once
they
access
the
data
gas
field
reaches
that
value.
It
would
cost
30
years
per
block
to
send
block.
So
we
would
expect,
of
course,
that,
if
robs
are
not
willing
to
pay
that
much
for
blobs
right.
J
So
if,
for
some
weird
reason
there
was
some
spike
in
demand
and
the
excess
would
shoot
up
to
that
level,
it
would
quickly
come
back
down
and
stay
at
some
some
kind
of
permanent
level.
So
the
excess
is
not
something
that
will
continue
to
grow
over
time,
it'll
just
similar
to
the
base
fee.
The
basically
doesn't
grow
over
time
it
just
Finds,
Its
equilibrium,
value
and,
of
course,
sometimes
goes
up
and
sometimes
goes
down
temporarily,
but
it
hovers
around.
J
Some
sort
of
you
know,
10
to
100
gray
level,
an
ish,
and
similarly
it
takes
us
blobs,
because
that
can
can
go
back
down
right
if
a
block
uses
less
than
a
Target.
The
number
goes
back
down,
so
it
will
just
find
some
sort
of
equilibrium,
value
that
corresponds
to
to
to
some
sort
of
equilibrium.
Price
and
it'll
just
have
around
that.
J
For
continued
questions
so
anyway,
so,
basically,
this
is
how
we,
how
we
make
flight
for
four
work:
history:
growth,
not
a
big
deal
bandwidth.
We
really
need
to
put
in
work
to
make
this
work,
and
this
is
kind
of
where
the
core
innovation
of
the
Erp
for
Now
lies
other
than
that
it's
forwards
compatible
for
full
length
sharding.
J
B
Okay,
I
want
to
introduce
now
to
the
two-dimensional
kcg
scheme
which
we
will
need
for
full
charting.
Sorry.
This
is
a
big
jump.
Okay,
so
when
we
do
foreshadowing,
why
do
we
not
take
all
the
data
that
we
want
to
encode
and
put
it
into
one
big
kcd
commitment,
and
the
reason
for
that
is
that
that
is
going
to
require
a
super
node
like
some
powerful
node,
that
you
probably
can't
easily
run
at
home
unless
you
like,
have
a
very
good
intent
connection
and
want
to
invest
some
money
into
it.
B
If
a
failure
leads
to
just
not
being
able
to
contact
blocks-
or
maybe
we
have
to
make
smaller
blocks,
so
we
have
to
make
blocks
without
chartered
data,
but
it
would
be
really
bad
if
the
absence
of
the
super
node
could
lead
to
the
to
a
network
split
where
some
people
think
data
is
available
and
some
people
think
it's
not
available.
This
is
what
we
want
to
avoid.
B
So
what
we
want
is
a
construction
where
yes
like
there
will
be
a
lot
of
data
in
the
network
and
maybe
like
someone
needs
to
be
there
specialized
into
Distributing
that
data,
but
once
they've
done
their
job.
The
very
decentralized
network
of
maybe
your
Raspberry
Pi
is
at
home
can
guarantee
that
it
will
always
converge.
It
will
always
be
safe
and
so
on.
B
B
B
So
if
we
do
this
naively,
we
just
take
many
commitments
and
we
sample
from
each
then
we'll
need
a
lot
of
samples,
because
we
before
I
had
this
number
of
samples,
for
example,
say
30
samples.
Now
we
need
30
samples
per
commitment-
okay,
that's.
That
would
be
a
lot
of
samples,
but
there's
another
much
cooler
way
of
doing
this,
where
we
use
read
Solomon
codes
again
and
we
ex
will
extend
M
commitments
for
like
M
actual
payload
blobs
and
extend
them
to
2m
commitments.
So
here's
how
this
is
going
to
work.
B
So
we
have
our
original
data
commitments
in
this
case
three
commitments
and
what
we'll
do
is
we'll
Define
another
four
commitments
that
are
an
extension
of
these
commitments,
so
they
will
be
completely
determined
by
the
actual
data
commitments
and
yeah.
So
here
here's
the
math
of
how
this
works.
So
what
we'll
do
is
we'll
Define,
a
two-dimensional
polynomial
for
the
data
and
it
works
the
same
way
as
before.
So
basically,
we
will
interpolate
this
polynomial.
B
We
will
Define
it
by
this
data
region,
the
original
data
that,
if
that
comes
from
many
different
transactions,
that
include
Charlotte
data
and
what
we'll
say
is
for
Simplicity
I'll
just
take
the
row.
K
will
just
be
the
evaluation
of
this
polynomial
where
we
set
y
equals
to
the
number
of
this
row
y
equals
k.
B
Okay,
so
we
have
FK
of
s
equals
to
this.
Now
we
replace
the
X
by
S
and
some
complicated
sum
in
there.
But
overall,
we'll
have
like
one
elliptic
curve
element
this
black
box
evaluation
and
we
call
this
C
of
K
okay.
Now
the
cool
thing
is:
if
you
look
at
this
expression
as
a
function
of
K,
then
this
is
also
polynomial
right.
It's
just
a
sum
of
terms
of
powers
of
K
okay,
so
this
is
very
cool
and
what
this
means
is
that
our
commitments
themselves
will
be
on
a
polynomial.
B
So
if
we
see
the
commitments
which
are
now
elliptic
curve
points
as
a
function
of
K,
they
are
on
a
polynomial.
So
what
we
have
is
before
we
started
with
having
each
row
being
a
polynomial
that
we
commit
to.
We
also
have
that
each
row
I
mean
this
is
a
property
of
just
a
two-dimensional
polynomial
each
column
will
be
a
polynomial,
but
also
the
commitments
themselves
are
a
polynomial
in
this
case
of
degree,
three
yeah,
because
they're
determined
by
these
four
commitments.
B
So
what
we
have
is
will
the
how
the
2D
commitment
scheme
will
work
as
we'll
have
two
2m
row
commitments,
and
we
can
actually
verify
that
this
is
the
cool
thing
like
a
any.
Anyone
who
validates
these
commitments
can
easily
verify
that
that
they
are
on
this
polynomial
using
a
random
evaluation
trigger
again,
which
I
introduced
earlier.
So
what
do
you?
B
What
we'll
do
is
we'll
take
the
first
M
commitments,
divide
them
at
a
random
point
and
we'll
do
the
same
for
the
second
M
commitments
and
if
these
two
result
in
the
same
Point.
Actually
the
point
will
be,
in
this
case
an
elliptic
curve
point.
Then
they
are
actually
on
a
polynomial
of
degree,
n
minus
one
for
those
who
are
interested
there's
a
way
to
do
something
very
similar
using
2D
commitment.
B
So
you
can
do
one
commitment
to
the
whole
thing,
but
I
won't
go
into
the
details
here,
but
there
are
basically
some
downsides,
but
which
is
why
we're
not
choosing
that
way
cool
and
so
what?
What's?
What?
Why
are
we
doing
this?
Okay?
So
we
have
properties
that
we
already
know.
We
can
verify
all
samples
directly
against
commitments.
B
There
are
no
fraud
proofs
acquired,
but
now
we
need
a
constant
number
of
samples
for
all
these
commitments
in
order
to
get
probabilistic
data
availability
and
basically
we
get
the
property
that
if
at
least
75
percent
of
those
samples
are
available,
then
all
the
data
is
available
and
it
can
be
reconstructed
and
that's
the
cool
thing
from
validators
or
other
and
also
only
observe
rows
and
columns.
So
there's
nobody.
B
So
what
you'll
notice
is
that
this
number
is
a
bit
higher
than
before
so
like.
If
we
only
have
one
commitment,
then
we
only
need
50
of
the
samples
to
be
available
for
the
square.
We
need
75,
so
the
number
of
samples
you
need
to
get
this
will
be
a
bit
higher
cool,
and
so
what
we
get
with
this
is
that
I
made
a
proposal.
I
mean
this
is
all
still
in
discussions,
but
like
one
of
the
ideas,
how
how
we
could
extend
this
to
a
full
trading
construction.
B
Is
that
basically,
the
way
validators
useless
construction
is
that
they
will
download
rows
and
columns.
They
will
each
choose
to
run
randomly
of
each
and
then
what
we
get
is
that
if
a
block
is
unavailable,
it
can't
get
more
than
1
16
of
it
attestations
so
automatically.
The
consensus
will
never
vote
to
unavailable
blocks
and
and
at
the
same
time,
they
can
use
these
full
rows
and
columns
that
they
don't
load
to
reconstruct
any
incomplete
rows
or
columns.
B
So
if
any
samples
are
missing,
they
can
reconstruct
this,
and
because
there
will
be
some
interactions
like
for
each
validator,
there
will
be
if
they
do
too
like
there
will
be
these
four
intersections
and
they
can
see
the
orthogonal
rows
and
columns
with
the
samples
that
may
be
missing
and
so
like.
As
an
example,
I
made
a
computation
that
basically
was
about
55
000
online
validators.
You
get
the
guaranteed
reconstruction,
where
basically
every
sample
will
always
be
reconstructed.
B
And
data
availability
sampling-
yes,
basically
just
checking
like
random
samples
on
a
square
and
what
we
want
is
again.
We
want
to
get
that.
The
probability
that
unavailable
block
passes
is
less
than
2
to
the
minus
30,
and
if
you
do
the
math,
you
find
that
you
need
about
75
random
samples
to
do
that,
and
so
the
bandwidth
to
do
that.
In
this
example,
if
we
do
is
512
byte
samples
would
be
2.5
kilobytes
per
second,
which
is
really
nice
low
number
cool,
okay,
handing
it
to
Denny.
K
Okay,
so
there's
a
lot
of
math
and
there's
an
elegant
construction,
assuming
that
we
can
do
a
constant
time
amount
of
work
if
we're
a
large
amount
of
data
to
kind
of
layer
it
into
it
as
similar
to
like
a
validity
condition
on
our
on
our
block
tree,
we
don't
consider
invalid
blocks
in
our
block
tree.
We
don't
consider
unavailable
blocks
in
our
block
tree,
and
so
the
math
and
the
construction
are
very
elegant.
K
But
when
the
rubbery
hits
the
road
datability
sampling
on
the
networking
layer
is
actually
non-trivial
problem,
that's
the
wrong
way.
Oh
the
arrow
that
goes
right
is
so
worn.
It
doesn't
look
like
an
arrow
anymore,
okay,
so
kind
of
stepping
back.
Why
is
this?
Why
are
we
making
this
problem
hard
for
ourselves?
K
Everyone's
seen
this
these
things
are
it's
not
fundamental
that
they
cannot
come
together,
scalability
security
and
decentralization
all
in
one
system,
but
it
is
hard
and
it's
hard
primarily
because
we
want
home
nodes
to
be
able
to
run.
We
want
standard
computers
to
be
able
to
validate
the
system,
to
kind
of
have
security
and
aggregate,
even
against
a
malicious
majority
of
our
consensus.
K
Participants
again
kind
of
in
that
validity,
condition
of
if
there's
an
invalid
block
and
all
the
validators
or
miners
are
saying,
that's
a
that's
that
what
is
that's
what
the
head
is,
you
say:
well,
that's
not
even
literally
real,
because
it
is
invalid
and
so
users
in
power
kind
of
Define
what
the
network
is.
Similarly,
we
want
to
do
that
with
our
bandwidth
consideration
with
respect
to
data
availability.
So
thus
we
need
to
focus
on
the
bandwidth
here.
K
A
lot
of
this
is
a
quick
recap.
We've
been
talking
about
this
all
day,
but
we
need
to
scale
execution.
We
need
to
scale
data
availability,
essentially,
Roll-Ups
give
us
some
sort
of
like
compression
algorithm
for
the
execution
of
transactions,
whether
it
be
from
fraud,
proofs
or
validity
proofs
data
availability.
We
use
DS,
datability
sampling
or
we
want
to
data
availability.
We've
been
talking
about
all
day
means
no
network
adjustment,
including
excluding
super
majority
of
full
nodes.
K
It
is
already
today,
as
we
noted,
you
have
to
download
full
blocks,
but
once
it's
a
lot
of
data
and
we
want
those
home
nodes,
it
becomes
very
hard
right.
So
again
we
want
the
amount
of
work
to
not
really
scale,
as
those
blocks
become
very
large
to
scale
the
network,
so
data
availability,
Insurance,
the
data
is
not
withheld.
Also
Assurance
of
data
was
published.
Real
quick,
shout
out
dockerd
made
most
these
slides
of
another
talk
and
I'm,
just
reusing
them.
Important.
To
note
it's,
not
data
storage,
it's
not
continued
availability.
K
K
You
know
it
kind
of
depends
on
the
use
case
and
and
it's
a
bit
of
a
more
of
a
ux
debate,
it's
kind
of
the
online
in
this
requirement
of
people
to
be
able
to
get
this
security
guarantee
without
trusting.
You
know
someone
else,
so
is
it
important
I?
Don't
think
we
need
to
get
into
this
too
much
optimistic,
Roll-Ups
and
ZK
Roll-Ups.
It's
critically
important,
and
you
know
who
knows
the
utility
of
solving
this
problem-
might
extend
beyond
these
two
types
of
systems.
K
So
networking
the
networking
is
hard
and
we
probably
are
making
it
even
harder
on
ourselves
by
some
of
our
assumptions
here.
So
we
could
say:
okay,
we
want.
We
certainly
want
to
make
sure
that
block
producer
and
consensus
nodes.
We
want
to
be
able
to
not
be
fooled
by
a
malicious
majority,
but
maybe
we
have
a
neutral
PDP
Network,
and
we
can
just
assume
that
the
P2P
network
is
like
healthy
and
gives
us
what
we
want.
This
is
certainly
attractive.
K
It
ensures
that
each
node
really
can
see
that
they
get
the
statistical
security,
but
if
we're
assuming
that
the
validators
can
be
malicious,
it's
very
high
amount
of
them.
At
least
you
know,
maybe
about
two-thirds.
Some
people
like
to
say
99
depends
on
probably
the
construction
on
what
the
real
one
is.
K
Then
the
Assumption,
then
that
the
network
network
is
neutral,
is
probably
not
a
realistic
assumption.
So
well
maybe
it's
realistic
in
most
scenarios,
but
if
we
want
to
really
be
able
to
harden
against
that
majority
adversary,
we
need
to
be
thinking
about
an
attacker,
controlled,
P2P
Network
by
some
threshold
defining
whatever.
That
is
again.
This
is
a
lot
of
kind
of
exposition
of
the
problem,
rather
than
total
Solutions
of
the
problem.
So
you
know
if
I'm
thinking
about
designing
data
availability,
sampling
I'm-
probably
it's
probably
interesting
to
think
about.
K
So
in
this
model,
certainly
some
nodes
can
be
fooled,
and
so
it
ends
up
being
a
collective
guarantee
again
depending
on
the
thresholds
and
how
the
system
is
tuned,
but
rather
than
no
node
can
be
fooled.
It's
probably
going
to
end
up
looking
like
no
above
certain
threshold
of
node
can
be
fooled,
maybe
for
a
certain
period
of
time,
maybe
until
the
network
kind
of
resolves
itself,
but
so
this
is
likely
correct
model,
but
it
does
make
that
problem
harder.
K
We
want
this
like
P2P,
distributed
data
structure
that
can
reliably
served
samples
so
that
people
can
do
their
job
of
getting
the
samples.
We
won
low
overhead
on
nodes
from
multiple
perspectives,
one
on
nodes
that
are
participating
in
pulling
down
samples,
but
also,
potentially,
we
want
to
leverage
nodes
that
are
not
just
validators,
not
just
builders
in
this
distributed
P2P
structure.
K
So
we
want
to
also
consider
the
the
overhead
of
these
nodes
that
are
participating
in
the
serving
of
the
samples
as
well
or
in
the
dissemination
of
the
samples
other
things
I
want
to
be
robust
against
attacks.
I.
Think
one
of
the
really
really
scary
things
here
is
liveness
attacks,
doses,
civil
attacks,
Etc
that
happen
on
the
network
layer,
because
if
a
majority
of
nodes
are
seeing
data
as
unavailable
either
temporarily
or
permanently,
then
they
cannot
follow
the
chain
at
all.
Again,
we
want
this
to
be
essentially
a
validity
condition.
K
You
know,
if
there's
an
invalid
transaction
in
this
Branch
I,
don't
follow
the
branch.
If
that
branch
is
unavailable,
I
don't
follow
the
branch,
so
that
is
a
very
important
critical
requirement,
but
a
very
terrifying
requirement,
meaning
that,
like
it,
is
very
important
that
this
these
PDP
structures
are
hardened
and
do
we
do
understand
kind
of
their
failure
modes.
K
We
understand
where
they
where
they
operate
and
if
you
don't
understand
how
they
resolve,
maybe
after
an
attack
and
low
latency
on
the
order
of
seconds
I,
have
a
page
of
some
deciderado
I'm
going
to
get
into
in
a
second
and
there's
some
distinct
challenges.
I
think,
when
you're
kind
of
thinking
about
this
problem
dissemination
into
the
P2P
structure,
we
have
a
lot
of
data.
How
do
you
efficiently
get
it
into
this
P2P
structure
without
causing
High
load
on
the
on
the
individual
nodes
of
the
P2P
structures?
K
Similarly,
we
want
to
support
queries
with
disseminated
data
sample
for
x
amount
of
time
which
I
can
get
into
this
centerata
again
and
validators,
certainly
with
their
row
and
column
kind
of
crypto.
Economic
Duty
can
identify
and
reconstruct
missing
data,
but
we
also
probably
want
to
consider
should
this
PDP
structure
be
able
to
identify
and
reconstruct
missing
data.
So
there's
two
kinds
of
potential
reconstruction
that
we
might
want.
So
validators
are
very
incentivized
out
the
gate.
K
You
know
if
things
are
missing
from
the
rows
and
columns
to
incentivize
to
to
repair
patch
and
make
make
things
whole.
But
if
say,
the
P2P
structure
is
supposed
to
serve
data
availability
sampling
for
one
week,
then
are
those
validators
the
same
people
that
will
then
identify
and
reconstruct
missing
data,
or
is
there
some
other
more
distributed
and
less
timely
required
method?
To
do
so?
K
These
are
you
know,
crypto
economically
incentivized
actors
that
we
can
try
to
leverage
in
this
construction.
They
do
have
the
rows
and
columns.
They
do
also
perform
data
availability
sampling
like
a
user
node,
and
then
we
have
users,
users
perform
data
availability
sampling;
hopefully
they
can
be
leveraged
in
serving
and
making
the
whole
P2P
also
more
resilient
itself.
Some
quick
deciderata
right
now.
K
You
know
if
I
were
thinking
about
building
datability
sampling
if
I'm,
researching
and
doing
stuff
I'm.
These
are
kind
of
some
Target
numbers,
but
I
would
also
be
sweeping
these
numbers
and
understanding
where
they,
where
they
work
and
where
they
don't
so
data
size,
32,
megabytes
per
block,
that's
per
12
seconds
or
if
the
slot
time
were
adjusted,
it
might
be
per
some
other
amount
of
seconds,
call
it
16
or
20.,
but
with
the
2D
Erasure
coding
that
ends
up
being
128,
megabytes
of
data
being
inseminated
into
the
network.
K
Chunks
I
think
we
there's
chunks
and
we
sample
the
chunks
or
their
samples
and
we
sample
the
samples,
but
on
the
order
of
250
000,
you
can
make
these
larger.
But
then
you
end
up
with
you
still
need
the
same
constant
number
of
samples.
So
you
end
up
with
more
overhead
samples.
He
said
75
something
on
that
order,
but
essentially
we
want
to
drive
that
probability
down
as
we're
doing
the
sampling.
K
Then,
on
the
order
of
four
seconds
we
have
a
problem
users.
You
could
have
a
potentially
lack
more
LAX
requirement
on
the
order
of
12
seconds
on
the
order
of
a
slot,
or
you
could
even
consider.
Maybe
they
needed
to
be
doing
it
on
the
order
of
epochs
and
optimistically
following
the
head
as
available
and
maybe
there's
some
play
in
in
the
constructions
there
validator
nodes
100K
is
pretty
optimistic,
but
we
probably
open
the
order
of
four
thousand
today.
K
You
know
100K
to
a
million
user
notes.
You
know.
So
it's
really:
if
the
user
nodes
cannot
participate
in
the
serving
of
samples,
then
the
load
on.
If
we
only
relied
on,
say
incentivize
actors
like
validators,
then
the
load
would
actually
scale
as
the
the
to
serve
as
the
user
nodes
serves.
So
it's
probably
very
important
to
tie
them
into
the
data
structure
itself.
Bandwidth
assumption,
I,
don't
know.
It's
probably
worth
discussing.
K
The
eth.org
website
suggests
a
minimum
of
10
megabytes
per
second
to
run
a
full
node,
but
but
for
good,
whatever
25
megabytes
per
second
I,
don't
know
who
came
with
that
number?
Maybe
it's
a
good
place
to
start
the
conversation
and
then
persistence.
Obviously,
like
I
said:
datability
sampling
is
not
for
persistence.
K
It's
to
ensure
that
data
was
made
available
where
how,
but
you
know,
data
if
data
was
made
available
for
half
a
second
like
No
One's
Gonna
necessarily
be
able
to
prove
that
to
themselves
that
it
was
made
available
or
a
very
small
subset.
So
is
it
two
epochs?
Is
it
two
weeks
there's
much
debate
here,
onsgar
I
think
what
was
your
recent
number?
Is
he
still
here.
K
My
intuition
here
is
that
the
online
in
this
requirement
for
users
that
want
to
get
their
you
know
State
transition
changes
from
ZK,
Roll-Ups
or
policemen
users
that
want
to
submit
fraud
proofs
for
ZK
for
optimistic
Roll-Ups.
You
know
this
dictates
their
online
in
this
requirement
and
so
I'm
I
feel
like
10
min.
Oh
man,
I
gotta,
get
out
of
here,
Okay
cool,
so
debate
an
hour
seems
short
P2P
designs.
K
K
This
is,
is
nice.
You
know.
If
you
connect
to
one
on
a
supernode,
then
you
get
what
you
need,
but
this
doesn't
really
fit
well
into
the
node
model,
especially
if
validators
you
know
a
node,
that's
running
on
the
order.
One
two,
maybe
three
validators,
should
be
able
to
run
on
the
order
of
you
know
home
resources,
which
is
definitely
not
the
case.
Foreign.
K
Nice
way
to
distribute
data
and
attribute
to
data
structure
across
the
network,
it's
a
nice
way
to
find
data
and
seems
intuitively
like
a
very
good
direction,
a
very
good
start.
It
fits
really
well
in
because
each
of
these
nodes
can
have
very
small
amount
of
data
and
really
nice
scalability.
As
you
add
more
nodes
to
network
you
can,
depending
on
your
redundancy
Factor,
you
can
have
you
know
similar
or
less
data
per
node
prone
to
lightness
attacks.
K
Dhgs
docker's
been
digging
to
escadimlia
and
I
believe
there
may
be
some
others
in
this
room
that
have
looked
at
some
other
papers
about
hardened
dhcs
and
we
do
have
you
know
we
as
long
as
you
have
a
simple
resistance
set,
then
you
all
of
a
sudden
can
have
certain
guarantees
in
these
constructions.
So
you
can
Leverage
The
validator
set
or
maybe
other
types
of
crypto
economic
sets
to
have
hardened
dhts.
K
So
you
could
use
standard,
open,
DHD
for
average
case
performance
and
maybe
a
secondary
or
fallback
DHT
leveraging
the
validator
set
for
in
case
of
attack.
You
could
also
yeah
there's
some
weirdness
because
then
all
of
a
sudden
you're,
assuming
that
you
have
a
certain
amount
of
honest
validators
for
this,
so
does
that
sufficient.
Suffice
under
the
malicious
majority
construction
sure
you
can
probably
tune
the
numbers,
but
you
could
also
potentially
layer
other
types
of
crypto
economic
sets.
K
You
know
proof
of
humanity,
Spruce
ID,
whatever
the
hell
all
sorts
of
stuff
and
could
have
layered
dhts,
where
they're,
ultimately
just
kind
of
fallbacks
in
the
event
that
the
the
big
main
DHT
starts,
failing
validator
privacy
and
optionality
and
how
they
construct
their
node
setups
is
probably
very
important.
I'm.
Definitely
over
time.
Okay,
cool,
great.
L
L
Introduction
like
it's
not
going
to
be
yeah,
it's
not
going
to
be
too
advanced,
it's
going
to
be
just
for
you
to
get
a
picture
of.
How
does
it
fit
with
dunk
sharding
and
what
does
it
have
to
do
with
it
in
general
and
also
like
kind
of
how
does
the
road
map
of
that
fitting
in
the
protocol?
Look
like
yeah.
So,
first
of
all
what
is
PBS?
L
So
this
is
the
normally
today
we
only
think
about
the
creating
part
like
only
basically
putting
together
a
new
execution
payload,
but
the
distribution
part
will
also
become
critical,
especially
in
the
well
in
the
context
of
dunk,
charting
and
yeah,
and
also
this
distribute.
So
the
distribution
will
involve
the
data
that
is
committed
to
which
is
going
to
be
eventually
very
large.
So
that's
why
it's
it's
kind
of
an
important
task
eventually,
and
so
for
these
reasons
and
well
later,
it
will
get
a
bit
more
into
them.
L
L
Proposing
includes
both
things,
both
this
kind
of
consensus,
part
of
making
a
beacon
block
and
including
all
the
consensus
messages
in
it
attestations
and
other
things
like
slashing
messages
or
anything,
that's
kind
of
critical
to
the
good
function
of
the
beacon
chain,
but
then
also
the
put
in
an
execution
payload
in
it.
So
today
it's
still
possible
for
anyone
to
do
this
by
themselves
and
kind
of
have
both
the
roles
together.
L
But
if
we
kind
of
ignore
this
execution
payload
part,
this
is
really
not
a
particularly
specialized
role
and
we
think
that
it's
always
going
to
be
possible
to,
or
we
really
want
this
to
always
be
possible
with
low
requirements.
Basically,
what
we
expect
today
validator
to
have
and
yeah
the
separation
is
just
that
these
two
things
are
split
up
like
we
don't
the
default.
L
It
would
not
be
any
more
that
a
validator
does
both
things
or
the
proposer,
which
is
a
validator,
does
both
things,
but
that
the
proposer
does
the
beacon
block
relevant
part.
The
consensus
messages,
part
and
some
other
kind
of
specialized
actor
comes
in
with
the
execution,
payload
and
the
distribution
of
the
data
eventually
and
yeah.
So
why
do
you
want
to
do
this?
I've
kind
of
already
well
hinted
at
it,
but
yeah
it's
it's
simply
that
if
we
Outsource
the
specialized
stuff,
we
can
keep
the
simple
stuff,
basically
decentralized.
L
We
can
keep
the
really
consensus
critical
things
essentially
done
by
a
very
decentralized
validator
set,
which
is
a
really
important
goal
in
ethereum
in
general.
So
and
I
mean
practically
why
you
know
what
are
these
things
that
we
want
to
Outsource
so
that
we've
for
all
the
whole
day,
we've
been
talking
about
dunk
sharding,
and
it's
not
there's
nothing,
really,
I,
guess
fundamental
about
starting
that
requires
this
Outsourcing.
You
could
imagine
other
models,
I
mean
the
I
guess
original
starting
model
before
the
Dank
part
didn't
require
this
Outsourcing.
L
We
don't
want
to
require
this.
It's
like
or
there's
a
magnitude
more
than
what
someone
would
need
today,
because
basically,
the
most
you
might
need
to
distribute
is
128
gigabytes
per
block
and
yeah.
But
again
this
is
not
a
kind
of
fundamental
reason.
If
there
was
no
other
reason
that
we
needed
the
separation,
for,
we
might
be
a
bit
more
skeptical
about
dunkshardi,
we
might
think.
Well,
you
know
we
don't
need
these
other
actors.
Why
are
we
introducing
the
system
just
to
get
the
simplification?
L
That's
not
kind
of
the
ethos
of
ethereum
like
we
really
want
everything
to
be
as
decentralized
as
possible
as
like
resilient
as
possible.
These
actors,
probably
you
know,
do
introduce
some
complexities
in
this
Vision,
but
the
issue
is
down
charting,
isn't
the
reason
why
we
these
actors?
The
reason
is
med,
and
this
is
kind
of
fundamental
reason.
L
There's
I,
don't
think
anyone
that
has
looked
into
me
enough
thinks
that
there
there's
any
other
way
essentially
to
go
and
the
issues
simply
that,
as
I
said,
these
execution
payloads
are
really
valuable
and
extracting
value
from
them
is
a
really
sophisticated
activity.
From
many
points
of
view,
algorithmic
infrastructure,
like
requires
potentially
very
good
Hardware.
A
very
a
very
good
connection
like
latency,
is
really
important.
So
there's
like
all
kinds
of
reasons,
oh
and
also
like
access
toward
their
flow.
L
L
So
there's
like
all
kinds
of
reasons,
why
it's
just
not
realistic
to
think
that
validators
will
be
able
to
profitably,
make
their
own
blocks,
and
so
there's
this
really
like
strong
centralization
pressures.
If
we
essentially
don't
provide
them
a
way
to
do
it,
you
just
go,
and
you
know,
have
someone
else
to
do
it
well,
which
is
the
whole
point
of
Separation,
but
there's
different
ways
in
which
it
could
happen.
L
L
We
already
have
a
PBS
today,
like
we
usually
say
PBS,
and
we
mean
basically
empirical
PPS
so
where
the
protocol
kind
of
knows
about
the
separation,
like
has
a
concept
of
a
builder
and
in
some
sense
like
negotiates
this
Outsourcing,
but
today
we
basically
have
PBS
is
just
not
in
protocol.
It's
called
a
map
boost,
maybe
probably
a
lot
of
you
know
it
and
essentially
what
it
does
is.
It
introduces
a
trusted
third
party
in
between
a
builder
and
proposer,
which
are
these
three
layers.
L
I,
don't
think
I
have
time
to
like
go
into
the
details
of
it,
but
essentially
you
know
we
don't.
We
want
Builders
to
not
trust
proposers.
We
want
proposers
to
not
trust
Builders,
there's
reasons
for
that
and
yeah.
We
just
basically
put
like
a
trust
to
the
third
party
in
the
middle,
which
kind
of
negotiates
the
The
Exchange.
So
you
know
the
proposal
wants
something
they're
built
from
the
Builder.
The
Builder
wants
to
get
something
to
the
proposer.
The
third
party
makes
sure
that
the
exchange
happens.
L
You
know
we
where
none
of
the
two
parties
can
cheat
each
other
essentially,
and
so
this
already
exists
today.
A
lot
of
ethereum
blocks
are
built
in
this
way.
So
it's
it's
the
reality
that
and
it's
not
something
that
you
know
the
ethereum
community
kind
of
made.
Well,
it
is
something
that
deterior
Community
made
happen,
but
it's
in
some
sense
inevitable,
like
anyone
could
always
build
some
infrastructure
of
this
kind,
and
people
could
use
it
if
it's
more
profitable
for
them,
so
yeah.
So
you
know
we
already
have
this.
L
Why
do
we
care
about
potentially
putting
this
separation
protocol
so,
as
I
said
relays
that
trusted
third
parties?
We
don't
usually
like
to
have
these
sort
of
entities
in
the
protocol.
They're,
not
critical
in
some
sense.
Well,
if
things
are
set
up
properly,
which
I
mean
I,
think
there's
a
lot
of
improvements
to
be
done
on
the
infrastructure
that
exists
today.
L
It's
very
you
know
young
infrastructure,
but
either
way,
there's
always
going
to
be
some
kind
of
failure
modes
that
we
don't
really
like
or
some
some
requirements
that
we
don't
really
like
from
having
these
these
parties.
So
one
is
that
you
have
to
basically
white
list
them
because
they're
trusted,
so
everyone
has
to
kind
of
go
and
configure
some
list
of
these
entities
that
they
they're
fine
with.
Essentially
the
trust-
and
we
don't
care
if
Builders
do
that,
but
we
don't
really
like
validators
to
do
that
or
well
I.
L
Don't
know,
that's
debatable,
but
anyway,
there's
I
think
there's
a
future
for
relays
to
still
exist
and
just
have
a
full
fallback
in
protocol.
That
is
not
the
default,
but
that's
a
conversation
from
our
time
but
yeah.
Another
thing
is
that
today
we
don't
really
have
a
kind
of
live
monitoring
for
relays
like
locally
people,
don't
have
a
chance
to
observe
interactions
that
really
have
had
with
other
proposers
and
then
disconnect
from
them.
L
If
these
interactions
look
suspicious,
essentially
so
that's
something
that
we
can
include,
we
can
basically
really
improve
the
you
know
the
the
resilience
of
this
whole
system,
because
we
can
make
it
so
that
people
don't
need
to.
You
know,
go
on
Twitter
and
find
out.
Oh,
this
relay
is
malicious
and
I'm
going
to
disconnect
from
them,
but
just
maybe
this
can
happen
locally.
L
Essentially,
so
there's
a
lot
of
improvement
there,
but
still
there's
some
kind
of
I
guess
really
fundamental,
catastrophic
scenario
that
seems
unavoidable
to
me
if
we
keep
having-
or
rather
if
we
only
rely
on
these
entities
for
this
Outsourcing,
if
we
have
kind
of
no
fallback
so
especially
we're
done
charting
so
today
you
can
always
have
a
fallback.
Actually,
it's
not
so
fundamental
to
this
this
state
of
things
today,
you
could
always
have
this
fallback,
which
is
essentially.
L
The
characteristic
scenario
is
like
all
relays
that
most
people
are
connected
to
fail
for
some,
whatever
reason:
they're,
malicious
or
they're
attacked,
Anything,
Could
Happen
they
fail
and
now
all
of
a
sudden.
Today,
it's
fine,
you
could
you
know
once
you
manage
to
disconnect,
because
you
realize
okay,
these
people
haven't
given
me
blocks.
For
you
know,
however
many
times
I've
tried
or
if
you
have
this
monitoring
system,
that's
fine!
L
You
just
fall
back
to
you,
you
building
your
own,
you
know,
gather
or
whatever,
like
other
execution,
clients
you're
running
building
your
own
blogs.
So
now
we're
likeness
is
not
really
threatened.
Maybe
it's
like
a
temporary
thing,
but
with
dunk,
sharding
and
also
statelessness
in
some
sense,
if
you
know,
let's
say
all
the
validators
are
still
list,
they
cannot
build
their
own
blocks
or
within
charting
like
they
cannot
distribute
data.
L
Then
this
becomes
like
a
threat
to
know
our
liveness.
We
dangsha
did
not
exactly
it's
like
you
could
make
blocks.
You
just
cannot
put
a
lot
of
data
into
them,
but
you
could
argue
well.
Is
that
really
liveness
like
if
all
the
roll
ups
can
stop,
because
they
don't
have
access
to
data
anymore?
That
is
not
really
what
we
want
yeah.
So
this
is
maybe
what
it
would
well.
L
This
is
like
the
one
of
the
current
ideas
of
what
it
could
look
like
to
put
it
in
protocol
I,
think
well,
yeah
I
think
it
probably
can't
really
go
into
it.
I,
don't
think
we
have
time
to
go
into
it
in
much
detail,
but
basically
it
looks
like
you
know,
as
I
said
before,
what
are
the
relays
they're
just
these
kind
of
actors
that
negotiate
the
The
Exchange,
you
know
what
do
we
do?
L
We
want
to
remove
these
actors,
we
basically
have
the
protocol
negotiate
exchange
and
the
protocol
in
this
case
is
basically
other
validators.
So
there's
a
proposer
there's
a
builder
and
we
have
the
whole
rest
of
the
validator
set,
or
some
committee
more
well
likely
that
basically
kind
of
makes
sure
with
their
well.
They
observe
the
exchange
and
with
their
attestations,
they
sort
of
make
sure
that
if
the
proposal
tries
to
shoot
the
Builder,
they
they
fail
and
vice
versa.
L
Essentially,
so
it
essentially
gives
us
the
property,
for
example,
that
if
the
proposer
accepts
some
block
and
or
some
some
like
a
bid,
you
could
say
from
from
a
builder-
and
we
have
good
latency
like
things
are
fine
from
a
fortress
perspective
from
a
network
perspective,
then
the
proposal
will
get
paid.
It
doesn't
matter
what
the
Builder
does
if
they
reveal
their
block.
A
good
kind
of
this
is
a
good
case
if
they
don't
reveal
their
block
they're
really
late.
L
You
know
tough
luck
for
them,
they're,
going
to
repeat
the
validator
and
not
even
get
their
building
opportunity,
and
so
this
is
one
design.
There's
this
other
design,
which
is
kind
of
interesting.
Oh
yeah,
also
thanks
to
vitalik
for
all
of
the
things
that
just
took
him
from
many
of
his
research
posts,
but
yeah
like
so.
This
is
basically,
you
could
say
empirical
map
boost,
because
it's
really
like
designed
to
look
like
map
boost
again.
L
We
have
basically
this
like
party
in
the
middle
this
time
more
clearly
than
before,
which
is
in
this
case
a
committee.
It
also
was
before,
but
anyway,
and
in
this
kind
of
party
again
negotiates
negotiates
The
Exchange.
We
could
think
of
the
party
as
basically
an
availability
Oracle.
So
it's
basically
its
job
is
to
ensure
it's
to
give
guarantees
to
the
proposer
that
what
the
Builder
sent
is
available.
So
the
proposal
will
accept
a
header
like
a
basically
offer
of
you
know.
L
I
want
to
give
you
this
blog
pay
you
this
much
and
the
Builder
will
essentially
erase
your
code.
So
you
know,
hopefully,
if
you
follow
the
discussion,
you
know
whether
it
is
recruiting
is
by
now
the
essentially
the
execution
payload
to
the
committee,
like
essentially
encrypt
well
Azure
code,
then
encrypt
and
then
basically
split
the
parts
to
the
committee,
so
that
if
some
threshold
of
the
committee
is
honest
and
online,
they
will
be
able
to
decrypt.
L
Even
if
not
all
of
the
committee
is,
and
basically
the
committee
signs
you
know.
Essentially,
the
individual
members
of
the
committee
will
attest
to
the
fact
that
they
have
their
part
so
that,
if
you
see
enough
attestations
and
the
committee
is
officially
honest,
then
you
know
that
as
a
proposer
that
this
thing
will
be
able
to
be
decrypted,
and
you
know
the
data
will
be
there
essentially,
so
it
actually
yeah
this
kind
of
fits
in
quite
nicely
with
these
data
availability.
L
Discussions
like
that
is
really
the
problem
here,
that
the
purpose
is
accepting
a
bit,
but
the
Builder
doesn't
want
to
say
what
the
bid
is,
because
that's
the
are
kind
of
private
like
secret
information,
and
we
want
basically
some
guarantee
that,
even
if
you
don't
know
what
it
is,
it
is
going
to
be
there
once
the
time
comes
essentially
like
once,
you've
accepted
the
bid
and
it's
ready
to
go
in
the
chain.
So
that's
yeah,
that's
what
it
looks
like
looks
like
and
just
last
quickly.
I
want
to
comment
on.
L
Basically
well,
so
there's
like
sensory
resistance
questions
about
PBS
and
I.
Think
they're,
not
you
know,
they're
like
fairly
well
understood.
There's
a
there's
clearly
like
a
way
that
PBS
in
or
out
of
protocol
says
it
doesn't
really
depend.
This
is
like
you
know
our
questions
also.
Today
it
does
the
great
censorship
resistance,
but
that
we
already
know
kind
of
how
to
deal
with
that.
There's.
L
That's
it
there's
no
way
well,
I
mean
there's
ways
like
soft
working
or
you
know
other
reasons
other
ways,
but
there's
no
kind
of
automatic
way
to
to
do
that,
whereas
with
a
decentralized
by
leadership,
we
can
always
do
that
and
yeah.
So
inclusion
lists
are
quite
simple
in
some
sense
and
there's
like
disagreements
about
how
exactly
they
should
work,
but
they're
super
simple
today.
L
So
if
we
have
like
the
property
that
it
is
easy
for
a
validator
to
say
this
transaction
is
available
and
this
transaction
is
valid,
so
the
validity
part
becomes
a
bit
harder
with
account
abstraction.
So
there's
some
questions
there,
but
won't
go
into
that.
That's
not
really
relevant
here.
The
availability
part
that
becomes
a
bit
harder
with
down
charting
because
now,
all
of
a
sudden,
you
know
there's
all
this,
like
all
these
blobs
floating
around
the
network.
L
There's
all
this
data
that
you're
not
supposed
to
no
you're
not
supposed
to
essentially
download
all
of
you're
only
supposed
to
sample
what
actually
ends
up.
Okay,
yeah
well,
I've,
just
finished
this
phrase
and
then
I
guess
that's
it,
but
yeah,
basically
with
yeah,
so
we're
done
charting
the
terminal
availability
becomes
a
bit
harder.
So
we
would
like
to
have
some
kind
of
Chardon
mempool
construction,
so
that
you
can
even
for
things
that
have
not
been
included
in
a
block.
A
M
F
F
Well,
oh
I
see
it
well
so
like
if
you're
in
the
middle
of
an
inactivity,
League
that
probably
makes
sense
I
mean
I
think
like
I
personally
favor
blobs
being
around
for
long
enough,
like
you
know
among
like
at
least
a
month
or
so
so
that
you
know
any
like
it's
longer
than
any
realistic
inactivity
leak.
That
would
happen,
but
there's
different
approaches.
F
So
the
problem,
the
reason
why
we
need
like
data
availability,
sampling
in
consensus
and
why
it's
like
so
different
from
you,
know,
ipfs
and
everything
out.
There
is
because
we
want
to
have
like
actually
have
consensus
on
the
fact
that
the
data
is
available.
Right,
like
the
yeah
like
ipfs,
does
not
provide
that
right
and
there's
ways
to
like
upload
files
so
that
some
people
think
it's
available
and
other
people
think
it's
not
available
and
for
like
regular
file.
Publishing.
F
That's
fine,
because
if
it's,
if
a
file
is
half
available,
you
just
publish
it
again.
But
for
Roll-Ups
like
it,
you
need
like
exact,
like
Global
agreements
on
which
data
was
published
on
time,
in
which
data
was
not
published
on
time,
because
the
roll-ups
like,
in
order
to
figure
out
the
current
state
of
our
rollup,
you
need
to
figure
out
like
which
data
blobs
to
include
and
which
ones
to
skip
over.
F
I
mean
there
have
been
proof
of
class
study
designs
that
we've
worked
on
over
the
years.
I
think
it's
kind
of
it's
on
the
sort
of
rhetorical
back
burner,
because
we
just
like
know
that
these
techniques
exist
and,
like
we
know
that
when
the
time
comes,
you
know
we
can
probably
just
stick
them
in
to
get
extra
security.
P
Yeah
so
I
wanted
to
ask
about
the
multi-dimensional
fee
Market
quickly.
We
talked
about
this
excess
data.
Gas
field.
I
was
just
wondering
if
the
same
would
like
in
an
Ideal
World.
If
we
hadn't
already
done
eip1559
with
the
same
construction,
be
wanted
for
the
like
original
kind
of
gas,
yes
yeah,
and
but
this
can
happen
simply
just
could.
J
Cool
so
I
think
they
even
already
thoughts
in
their
directions,
I
think
over
long
over
the
medium
term.
We
would
want
to,
and
one
of
the
nice
side
benefits
it
would
give
us
that
it
also
makes
other
improvements
to
to
5059,
like
mechanism
easier,
like,
for
example,
like
a
Time
based
instead
of
a
block-based
kind
of
throughput
targeting
so
yeah.
We
would
probably
want
to
homogenize
this
over
time.
Q
Yep,
so
I
could
be
wrong
in
one
of
these
assumptions,
but
my
understanding
is
that
proposer.
Builder
separation
was
motivated
largely
by
the
centralizing
effects
of
Mev
and
US,
wanting
to
keep
the
proposer
set
decentralized
but
then
kind
of
later.
With
these
designs
like
full
sharding,
we
realized
that
we
could
utilize
the
builders
as
kind
of
with
extra
Hardware
requirements,
because
they'd
be
incentivized
with
the
Mev
that
they're
extracting
to
have
these
nodes,
but
then
there's
also
Research
into
completely
mitigating
Mev.
Okay,
so
maybe
that's
the
wrong.
F
Example:
okay,
there's
multiple
strands
of
research
and
some
of
them
are
definitely
sort
of
covering
for
each
other
in
case
the
other
fails,
but-
and
some
of
them
are
complementary
right,
so
there's
a
PBS
which
allows
proposers
and
validators
to
be
more
decentralized,
but
at
the
cost
of
kind
of
Shifting
that
centralization
to
builders.
There's
a
separate
strand
of
research
on
the
topic
of
trying
to
make
build
like
Builders
themselves,
a
decentralized
internally
so
like
a
some
kind
of
protocol,
would
plug
into
the
market
and
make
bids
instead
of
being
a
single
actor.
F
P
L
Like
I
think
anyone
that's
thought
about,
maybe
for
some
time
will
come
to
the
conclusion
that
it's
just
not
possible
to
assume
that
there's
not
going
to
be
an
incentive
to
be
a
specialized
actor
like
there's,
even
if
all
transactions
are
encrypted.
There's
always
going
to
be
some
reason
to
be
the
first
to
to
touch
this
state,
like
you
know
so,.
L
J
And
just
to
mention
it's
not
just
tank
sharding,
where
basically
a
PBS
like
architecture
would
help.
So
once
we
move
with
worker
trees
to
some
through
a
world
where
it's
easier
to
run
stateless
nodes
and
then
also
with
what
PBS
would
get
us
would
be
that,
like
that,
normal
validators
would
basically
all
of
a
sudden
have
like
way
way
and
lower
a
storage
requirements,
and
we
only
we
don't
don't
get
that
if
they
still
have
to
create
blocks,
because
then
they
need
the
state.
B
I
mean
I
think
that's
definitely
a
possible
construction.
You
could
like
see
a
way
like
where
you
oops
a
specialized
sample
provider,
and
you
pay
them
I.
Think
like
the
downside,
is
that
it
makes
it
much
harder
to
run
a
note,
because
now
you
need
to
somehow
set
up
this
payment
infrastructure.
So
I
think
it's
not
ideal,
but
it's
possible.
B
B
F
S
H
H
F
Mean
I
think
yeah
from
from
the
kind
of
network
perspective
of
how
the
thing
should
be
yeah
implemented
like
this
thing,
has
much
higher
requirements
in
terms
of
Byzantine
and
fault
tolerance
and
in
terms
of
real-time
access
and,
like
real-time,
real-time
being
able
to
change
what
you're
accessing
yeah.
Those
are
probably
the
biggest
differences
in
requirements.
Okay,
great.
E
Thank
you
something
I
was
thinking
about
is
that
if
so
we
we
assume
that
nav
exists
and
that
people
want
to
you
know,
sandwich
other
people's
transactions
and
stuff
like
this.
So
we
we
have
this
proposed
to
build
a
separation
which
makes
a
lot
of
sense,
and
then
we
once
we
have
this,
we
kind
of
start
to
utilize
it
to
do
heavier
work
like
thanks,
sharding
and
things
like
this.
E
F
Yeah
I
know
well,
no.
This
is
actually
one
of
those
things
that
I
yeah
I,
think
I
wrote
a
new
research
post
about
last
week,
right,
like
basically
yeah
like.
Can
we
push
the
autonomy
in
choosing
a
block
contents
back
to
the
proposer
and
like
that's
a
spectrum
that
potentially
could
go
all
the
way
up
to
the
purpose
of
having
an
option
to
make
everything?
F
And
then
one
of
the
conclusions
there
was
that
if
we
want
to
have
that
kind
of
proposal,
autonomy,
property,
but
also
have
the
the
property
of
like
potential
low
proposal
requirements,
we
might
need
to
have
a
third
category
of
actor.
That
does
are
kind
of
not
and
not
MVP
extraction
that
in
basically
the
entire
bundle
of
computationally,
expensive
stuff.
So
like
witness,
Edition,
State,
Route
calculation
in
the
future,
ZK
snarking
and
minimum,
like
figuring
out
polynomial
commitments
and
proofs
and
broadcasting
and
so
forth,.
B
I
mean
I
I
just
want
to
comment.
I
think,
like
people
need
to
stop
thinking
of
Mev
only
as
a
bad
thing,
because
you
think
of
sandwiching
and
even
without
any
front
running
any
sandwiching.
We
still
have
lots
of
Mev
and
it's
actually
a
necessary
part
of
the
system.
Like
someone
needs
to
do
the
Arbitrage
on
the
exchanges,
someone
needs
to
do
the
degradation
someone
need
to
submit
the
fraud
proofs.
All
of
these
are
Maybe.
B
T
F
Yeah,
so
there
are
slashing
mechanisms
different,
slashing
mechanisms
that
play
right
so,
like
there's
a
swatching
mechanism
that
slashes
the
proposer,
if
they
make
two
conflicting
blocks
in
some
of
these
partial
block
auction
protocols
and
we
use
eigen
layer
and
that's
like
basically
exposes
the
proposal
to
kind
of
extra
swatching
if
they
yeah.
So
if
they
violate
the
rules
of
the
partial
block
auction
protocol,
Builders
can
get
slashed
in
some
like
some
contacts
and
forget
exactly
yeah,
which
ones
but
there's
a
definitely
a
few
cases.