►
Description
Agenda: https://github.com/ethereum/pm/issues/454
Resources:
EIP-4444 breakout room meeting (1) - https://youtu.be/lkKXlVlFvZQ
EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
Discussion to: https://ethereum-magicians.org/t/eip-4444-bound-historical-data-in-execution-clients/7450
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethcatherders
Website: https://www.ethereumcatherders.com/
A
A
A
B
A
A
Hello
alex
I
just.
I
was
just
saying
that
I
posted
this
agenda.
I
basically
have
this
road
map,
which
we've
kind
of
like
roughly
talked
about
in
the
past,
and
some
questions
I
don't
know
if
there
are
other
specific
things
that
people
haven't
added,
that
they
want
to
talk
about.
But
if
not,
we
can
just
talk
about
this
road
map
and
then
answer
those
questions
where.
F
C
A
E
A
A
A
We
need
to
then
implement
some
sort
of
mechanism
in
the
execution,
clients
to
verify
those
sse
objects
and
also
create
them
and
then
actually
import
and
execute
them
so
that
you
can
get
to
the
the
latest
state
with
those
the
historical
data
and
then
like
farther
along
is
we
need
to
talk
about
how
we're
going
to
distribute
the
data
over
bittorrent
like?
Are
we
going
to
have?
A
And
then
the
final
thing
is
like
to
actually
implement
four
fours,
which
I
think
we're
you
know
pretty
far
away
from
doing
right
now,
since
it's
not
something
that
I
think
is
going
to
be
accepted
into
a
client
for
at
least
six
months.
So
if
we
do
implement
it
now,
we'll
just
have
to
keep
rebasing
against
changes
for
clients
just
so
that's
kind
of
roughly.
What
I
see
is
like
a
road
map.
I
don't
know
thoughts
on
that.
E
E
B
E
A
A
B
I
think
the
more
I
I
think
I
mean
that's
mario's
position,
but
I
think
we
can
argue
him
out
of
that
if
he
can
just
sit
down
with
me
for
an
hour,
I
think
the
bigger
pushback
from
the
guest
theme,
I'm
confident
I
think
the
bigger
pushback
from
the
guest
team
is
that
they
don't
want
the
impression
I
got.
Is
they
don't
want
it
to
be
something
that
is
not
in
the
clients
like
they
want
the
guest
client?
If
I
understand
correctly,
someone
else
may
really
crack
them
here.
B
B
D
A
I
think
you've
looked
into
ssd
a
little
bit
and
I
I
think
I
understand
was
at
some
point
you
would
come
up
with
say
this
is
what
I
think
the
actual
definition
of
the
ssd
object
should
be,
and
we
can
talk
about
and
make
sure
that
that's
like
what
we
all
are
sort
of
assuming
like.
I
think
we
all
sort
of
think
that
this
is
going
to
be
some
sort
of
ssd
list.
C
Yeah
that
that's
kind
of
my
idea
and
by
the
way
for
those
I
know
I've
met
some
of
you
on
a
recent
call,
but
for
those
I
haven't
I'm
kind
of
new
to
this
whole
thing,
I'm
relatively
recent
convert
and
working.
You
know
looking
to
get
into
working
on
ethereum
I've
done
a
bunch
of
database
stuff
previous
to
that,
and
so
having
worked
with
tim,
he
suggested
I
could
help
out
on
implementing.
C
C
It
sounds
like
unless
there's
some
I
mean
it
sounds
like
we
can
get
going
with
those
two
without
having
to
settle
the
broader
question
of
will
this
of
the
bittorrent
and
of
the
distribution
mechanism
and
whether
or
not
that's
integrated
into
clients
and
and
all
of
that
for
sure,
that's
something
that
we
should
do
in
parallel,
yeah
and
yeah.
I.
C
C
Yeah,
so
well
you
just
the
the
outline
that
you
had
is
is
more
or
less
what
I
was
thinking
and
I
think
what
we
discussed
last
time.
I
guess
well
one
of
the
questions
I
had
so.
I
started
looking
at
this
more
seriously
last
week
and
this
week
a
little
bit
getting
into
ssc
and
one
question
which
is
which
I
need
to
figure
out
pretty
soon.
C
That's
kind
of
related
to
number
two
is
which
execution
client
would
be
the
best
candidate
for
this
and
and
the
reason
I'm
interested
in
that
is,
there's
a
bunch
of
ssc
implementations
in
in
different
languages
and
I'm
kind
of
looked
a
little
bit
at
the
fast
ssc
and
go,
and
I
know,
there's
a
python
one.
I
don't
know
if
there's
a
kind
of
natural,
obvious
good
candidate
for
the
execution
client
to
use
the
proof
of
concept
or
not,
but
that
would
that
would
be
helpful.
Yeah,
usually
guess
is
the
preferred
one.
Okay,.
B
C
B
Death
is
the
preferred
one
I
would
say
because
it
is
dominant,
but
we're
really
trying
to
make
it
not
the
dominant
client
like
the
way
ethereum
works.
We
don't
want
a
dominant
client.
We
specifically
want
people
to
use
other
things,
and
so
people
use
guest
because
guess
is
what
they
know,
and
so,
if
you
know
nothing,
I
would
weakly
encourage
doing
something
else,
like
any
other
client,
just
to
kind
of
just
incentivize,
more
growth
out
into
other
places.
B
C
A
C
G
G
A
Yeah,
this
is
one
of
the
main
questions
that
I
had
and
I
think
the
strongest
you
know
proponent
for
sse
was
actually
piper
when
we
originally
spoke
and
it
you
know
I
think
like
for
me,
the
the
two
main
reasons
to
go
with
ssd
is
number
one.
Ssd
is
sort
of
the
next
generation
serialization
format,
and
I
think
that
the
more
new
things
that
we
do
in
ssd
the
easier
it
will
be
to
transition
over
time
everything
to
ssd,
even
if
that
takes
a
long
time.
A
So
I
think
that
is
in
itself
a
pretty
strong
reason
to
go
that
direction,
and
the
other
reason
is
is
that
if
we
are
going
to
basically
be
creating
these
checkpoints
that
are
creating,
you
know
large
segments
of
blocks
that
we're
committing
to.
Then
we
can
now
prove
something
about
a
historical
block
and
we
don't
really
have
that
functionality
in
ethereum
right
now.
A
This
is
like
something
that
will
be
out
of
the
protocol,
but
we
will
have
a
way
where
similar
to
having
like
a
weak
subjectivity
checkpoint,
where
we
say
this
is
something
I
trust
I
can
now
say.
I
trust
this
route,
and
now
I
can
prove
something
about
a
historical
block,
so
that
kind
of
gives
us
more
functionality.
The
thing
is:
is
that
we're
not
there's
not
a
lot
of
people
who
are
requesting
that
functionality?
A
There
are
people
who
want
to
have
it
in
the
protocol
in
a
smart
contract
context,
but
I
don't
think
that
this
will
be
like
easily
like.
Maybe
we
can
have
a
smart
contract
where
we
post
these
routes
to
like
they
are,
you
know,
checkpoints
and
you
can
like
sort
of
prove
them,
but
they're,
not
something
that
you're.
You
know
ascertaining
from
the
protocol
itself,
so
there's
like
a
weaker
a
weaker
guarantee
there.
So
to
me
those
are
the
two
reasons
to
go
with
ssc.
B
I
think
the
reason
you
gave
are
the
exact
reasons
I
was
going
to
give
just
to
play.
Devil's
advocate
a
little
bit
reason
for
going
with.
Rlp
is
just
because
that's
what
everything
today
uses
and
so
integration,
it's
going
to
be
a
little
faster
and
easier
like.
If
you
don't,
you
know,
convert
the
blocks
all
to
sse.
You
just
have
an
rlp.
We
already
have
them
all
in
rlp.
B
A
C
A
You
know
the
manipulation
of
the
sse
object
into
the
rlp
object,
whereas
if
we
just
commit
to
the
ro
to
the
ssc
list,
we
do
get
a
lot
of
the
functionality
of
being
able
to
prove
things
about
historical
blocks.
We
don't
have
the
granularity
of
being
able
to
prove
a
specific
thing
in
a
block.
We
have
to
prove
the
whole
block,
but
we.
A
A
B
I
think
perhaps
the
reason
I
don't
see
the
future
is.
I
have
always
imagined
this
to
be
something
that
sits
external
to
the
clients,
and
so
you
would
have
some
little
thin
thing.
That
knows
how
to
download
a
torrent
and
knows
how
to
do
some
data
manipulation,
and
you
would
use
that
to
do
the
bulk
file
download
and
then
you
would
just
have
a
button
in
there.
B
That
says,
export
to
another
mind
or
export
to
guess
or
export
to
whatever
and
so
and
the
reason
for
that
is
because,
specifically
so
we
can
avoid
having
to
convince
clients
to
let
us
integrate
into
them.
We
can
just
build
this
entirely
isolated
from
the
clients
and
just
say:
hey,
you
know
we're
done.
You
know
you
can
now
sync
guess
by
running
this
little
script
or
whatever
this
little
tool
hit
a
button,
and
now
your
your
brand
new
guest
client
is
synced
up
to
january,
first
2021
or
2022,
or
whatever.
C
A
A
We
can
already
probably
do
it
like
micah
is
saying
you
know
this.
I
guess
another
question
like
exactly:
how
is
this
integration
going
to
go?
I
would
say
one
client
does
have
to
have
four
force
integrated,
because
we
want
to
be
able
to
export
the
historical
data
into
these
structures
and
we
want
to
be
able
to
verify.
I
think
verification
is
important
because
whenever
you
know
some
entity
says
this
is
the
you
know.
B
A
B
A
I'm
just
imagining
that
you
know
we
create
this
new
checkpoint.
This
period
like
we
haven't,
expired
these
blocks
yet,
and
so
we
still
have
them
locally,
and
this
is
the
proposed
checkpoint
of
the
those
historical
blocks.
So
I
should
be
able
to
download
that
and
then
compare
them
to
what
I
have
locally
and
so
yes,
you
could
execute
them
and
make
sure
that
you're
at
the
you
know
the
canonical
head
of
the
chain,
but
that's
a
lot
more
time
consuming
than
just
verifying
that
you
are
aware
of
those
blocks.
A
Yeah
henry,
I
guess,
like
you,
are
the
you're,
the
person
who's
really
going
to
be
driving
a
lot
of
this
initial
implementation.
So
are
there
things
that
we
can
do
or
questions
that
you
need
answered
so
that
you
can
move
forward
like
on
our
front?
We'll
continue
we'll
talk
with
the
guest
teams,
where
we'll
continue
like
working
on
some
of
the
more
like
philosophical
questions
about.
You
know
what
is
okay
to
distribute,
how
to
distribute
data,
but
I
want
to
make
sure
that
you're
unblocked
to
move
forward
yeah.
C
Thanks,
I
I
think
I
am
that
this
has
been
helpful
and-
and
I
think
I
mean
given
that
the
immediate
first
step
is
the
is
writing
out
or
coming
up
with
the
first
roman
layout.
I
I
can
get
started
on
that
right
away
and
then
I
guess,
as
it
I'll
update
as
it
gets
as
it
moves
forward
and
and
there's
something
to
get
feedback
on.
A
E
E
I
was
just
gonna
say
like
in
parallel
with
implementation
work.
We
can,
like
you
know,
start
drafting
some
kind
of
vip-ish
thing
because,
like
the
more
concretely,
we
can
write
down
what
we're
trying
to
do.
The
more
we
can
say:
hey
get
team,
hey
piper,
like
you
know,
how
does
this
sound
and
the
more
specific
you
know
the
more
productive
we
can
narrow
down
to
a
specific
design?
So
so
that's.
A
D
G
A
Cool,
so
I
would
say
you
know
how,
whatever
format
you
want
to
write
this
up
in
henry
as
you
like
work
through
this,
then
we
can
like
work
together
and
put
that
into
something.
That's
like
an
eip,
so
that'll
be
the
first
step
for
the
actual
data
format
and
then
we'll
you
know.
The
distribution
format
is
something
we'll
continue
working
on
discussing.
E
Like
probably
a
great
way
to
start
like,
maybe
we
like
get
six
months
down
the
road
and
various
is
like.
We
can
never
do
torrents,
and
then
you
know
we
have
to
tweak
it.
But
if
we
start
now
thinking
it
thinking
of
it
as
this
like
modular
bit
right
to
this
design,
then
we'll
swap
it
out
when
we
need
to.
A
That's
you
know.
I
think
this
is
something
that's
you
know
at
least
18
months
24
months
away,
because
I
don't
think
that
geth
is
looking
to
remove
any
any
consensus
code.
You
know
in
the
near
future,
but
it
is
something
in
the
law,
the
medium
to
longer
term
that
they
will
want
to
do.
I
do
think
that
it's
pretty
important
that
we
like
maintain
the
ability
to
generate
all
historical
artifacts.
A
So
that's
something
to
keep
considering,
I
think,
like
you
know,
it's
not
really
a
theoretical
problem
that
needs
a
solution
like
it
seems
relatively
clear,
like
we
just
run
certain
client
versions
and
have
some
sort
of
you
know,
multiplexer
that
is
able
to
route
request
to
the
version
of
the
client
that
understands
the
information.
It's
just
going
to
be
an
engineering
challenge.
B
A
B
To
go
down
the
rabbit
hole
of
ssc
all
the
way
down
like
I,
I
feel
pretty
strongly.
That
would
be
a
big
boon
long
term.
You
think
that
we
should
ssc
the
actual
block
without
the
value
blocks,
transactions
uncles.
Everything
like
the
we
just
get
so
much
power
from
being
able
to
prove
everything
arbitrarily.
B
F
G
B
A
A
B
B
F
Right
right,
like
I
think,
with
the
merge,
what
happens
is
that
the
transaction,
this
the
list
of
transactions
becomes
ssd,
but
each
transaction
is
still
opaque
and
then
the
receipts
are
still
okay
and
then
obviously
the
state
is
still
opaque
and
I
guess
we
wants
to
eventually
moving
the
receipts
over.
That's
disease
should
not
be
super
hard
and
then
eventually,
the
one
move
transaction
internal
structure
over.
G
F
Protocols,
yes,
I
was
actually
having
some
discussions
about
crossway
or
two
bridging
and
one
of
the
big
hurdles
that
actually
came
up
was
basically
the
fact
that
that,
if
he
wants
to
prove
something
in
what
one
way
or
two
to
another
way
or
two
then
like
first
of
all,
there's
stuff
that
the
layer
two
is
haven't
done,
that
they
really
should
do
like
make
the
api
l1
block
cache
accessible.
That's
an
op
code,
but
even
going
beyond
that,
like
it
requires
these
proofs
going
into
a
receipt
that
contains
the
l2
state
route.
F
And
then
you
have
to
do
the
same
thing
inside
of
the
l2,
and
the
thing
with
roll-ups
in
particular,
is
that
with
roll-ups
execution
becomes
much
cheaper,
but
data
does
not
become
cheaper
at
all,
and
so
merkel.
Proofs
could
easily
become
like
the
biggest
cost
factor
of
cross
if
a
secure
crossroad
stuff
becomes
the
norm
and
so
like.
Might
it
even
make
sense
to
skip
ssd
and
go
directly
into
putting
receipts
into
like
either
a
verbal
tree
or
a
ksig
commitment?
I
don't
know.
F
G
B
Yes,
so
I
think
I
I
I
I
really
like
the
idea
of
using
this
opportunity.
This
is
an
opportunity
to
get
data
structures
into
a
for
like
a
better
word,
more
modern
place
so,
like
we've
got
vertical
trees
instead
of
merkel,
trees,
we've
got
ssc
instead
of
rlp.
There's
lots
of
things
that
if
we
were
to
start
over
with
ethereum
today,
we
probably
would
not
do
the
way
they
are,
and
so
this
this
is
a
kind
of
an
interesting
opportunity
to
take
on
that
and
say,
you
know
hey.
B
This
is
the
new
standard
way
we
do
blocks
in
ethereum.
We
still
have
the
legacy
way
that
all
the
clients
use,
but
you
know
going
forward
if
you're
building
something
new
use,
this
new
new
data
format,
of
course,
as
I
was
arguing
earlier,
that's
you
know
the
more.
We
do
write
the
more
engineering
we
have
to
do
to
get
it
right,
like
it's
much
easier
just
to
do
the
status
quo
than
it
is
to
do
something
new.
So
I'm
conflicted
on
that.
G
G
On
this
all
right
so
above
those
receipts,
the
this
is
like
the
information
about
the
execution
output
of
the
layer
one.
This
is
really
different
from
all
the
input
information
in
that
we
rely
solely
on
the
receipt
root
of
the
layer,
one
to
interpret
the
execution
as
a
layer
two.
So
this
really
distinction.
It's
not
just
about
data
commitments,
but
about
knowing
about
execution,
and
the
problem
here
is
the
receipts
can
be
huge.
G
They
can
be
larger
than
you
can
load
into
the
evm,
making
optimistic
roll-ups,
for
example,
really
difficult,
and
they
are
mercurized
in
a
way.
That's
also
quite
ugly,
with
the
mercury
doing
index.
Data
like
this
is
the
type
of
tree
where
we
have
consecutive
in
the
protective
leaves
where
we
can
just
simplify
the
dimmer
construction.
B
So
understand
correctly,
the
idea
here
is
that
if
we
could
easily
prove
receipts
something
like
a
zk
roll
up
where
some
some
roll
up
somewhere,
optimistic
or
ck
might
see
a
transaction
that
updates
a
state
route,
but
it
doesn't
have
a
way
to
verify
that
the
evm
actually
did
successfully
update
that
state
route.
It
wasn't
just
one
line
right,
like
you,
can
send
a
transaction
with
the
state
route
update,
it
doesn't
mean
it
was
accepted,
whereas
the
receipt
actually
says.
B
G
G
B
Potentially
I
mean
if
you
really
want
to
go
all
the
way,
a
single
data
point
from
a
single
log
and
just
say:
hey,
I'm
going
to
prove
to
you
that
this
log
occurred
with
this
as
parameter
3
or
whatever,
and
you
can
be
confident
in
that.
Just
with
the
witness
and
a
single
like
block
cache
set,
for
example,.
G
This
is
one
example
where
look
information
in
a
different
shape
or
different
commitment
type
is
really
useful.
I'm
sure
there
are
others,
and
if
you
know
of
any
any
of
these,
you
should
aggregate
those,
and
maybe
you
can
include
the
same
eip
or
at
least
add
this-
to
the
eip
discussion
about
the
format
for
the
historical
blocks.
B
I
mean
there's,
I'm
guessing.
Someone
could
make
basically
more
or
less
the
same
argument
broadly
for
vertical
of
verticalification
of
the
state.
Right
like
you
want
to
prove
some
piece
of
state
and
you
just
have
a
block
cash.
I
mean
I
I've
written
contracts
that
do
this
and
it's
hell,
you're
paying
600
000
gas
just
for
the
proof,
like
alone,
not
even
invalid,
just
getting
the
proof
on
chain
is
half
a
million
gas.
F
But
the
thing
with
verbal
trees
is
like.
Basically,
it
would
be.
It
would
be
nice
if
possible,
like
if
we
start
moving
moving
things
over
to
verbal
trees
like
if
we
want
to
just
standardize
and
say
virgo
trees
are
where
everything
is
going
and
then
there's
obviously
a
lot
of
a
lot
of
benefits
that
come
with
that.
F
But
then
there's
the
question
of
like
we
want
to
make
sure
that
we
get
standardized
on
like
the
same
sort
of
structure
as
we're
fine
at
as
we're
introducing
in
other
places
like
in
the
state.
Just
to
make
sure
we
don't
accidentally
like
create
two
slightly
different
implementations
and
like
blow
up
to
like
four
different
kinds
of
structures.
Instead
of
three.
G
F
I
guess
I'm
just
thinking
like
like
well
what
would
need
to
be
standardized
with
vocal
trees?
Probably
the
main
thing
is
that
in
a
virgo
stage,
tree
like
we
have
this
thing
where
the
keys
get
assigned
randomly,
but
in
one
of
these
virgo
trees
it
would
be
like
the
keys
would
be
assigned
sequentially.
F
G
F
B
C
G
There
are
two
problems
I
currently
deal
with.
They
would
already
be
solved
with
sse
here
in
the
best
of
your
scenes,
but
I,
like
future
compatibility
as
well,
so
I
mean
if
there
was
a
way
to
verify
these
circle
commitments
or
these
kind
of
factor
commitments
whatever
trees
are
built.
On
top
of
at
this
moment,
if
we
had
that
in
the
evm
or
as
like
ready
libraries
for
outside
evm
as
well,
then
I
think
we're
good
to
go
and
just
directly
skip
their
maybe
skip.
As
you
see.
G
Yes,
I
mean
the
layer:
two
will
eventually
have
to
verify
it
in
the
evm
or
outside
of
the
evm
and
in
either
of
those
places.
We
have
good
tooling
for
freckle
trees
right
now
and
for
the
case
of
sse,
it's
just
a
matter
of
using
the
most
popular
hash
function,
with
concatenation
of
32,
bytes
and
32
binds
and
that's
it.
The
mercury
station
is
really
really
simple.
B
G
F
F
B
G
I
mean
the
current
design
is
crazy,
expensive
anyways
because
of
the
rlp
overheads,
all
the
logic
gates
around
encoding,
the
rlp
before
mercalizing
at
each
step.
Ssz
is
simple
but
still
expensive
because
of
the
ash
function
and
then
vertical
trees
or
any
kind
of
factor.
Commitment
in
that
area
of
research
would
be
an
improvement
for
ck
layer,
2
usage.
B
F
B
F
F
B
G
G
Yeah,
so,
okay,
we
have
these
three
iaps
for
for
us,
one
for
format,
one
for
the
import
export
functionality,
one
for
the
distribution
at
the
very
first.
We
have
this
description.
That's
right!
The
funds
there.
We
should
try
and
see
how
ssc
exclusion
payloads
work
if
it's
worth
trying
just
improves
the
improved
situation
of
our
historical
block
data
which
could
help
projects
stack
that
from
piper
and
then
we
can
have
that
or
not
anyways.
We
have
the
virtualization
of
sse
on
top
and
we
could
look
at
faculty
fertilization
here,
but
I
think
for
fur.