►
From YouTube: Peep an EIP #18: EIP-3102: Binary trie structure & EIP-2584: Trie format transition with Guillaume B
Description
Topics covered:
1:19 - Introduction
EIP-3102
2:26 - Hexary trees
4:09 - Key points
4:42 - Binary trees
6:00 - Why no RLP
8:33 - Why BLAKE2
9:26 - Merge account & storage tree
13:09 - Why key at the leaf level
17:39 - EIP-2584
18:29 - Conversion process
21:32 - Phase 0
22:26 - Phase 1
23:26 - Phase 2
23:28 - What's the difference between the overlay tree and the base tree in phase 1?
24:24 - Why the two phases are necessary? Why phase 1 is not writing the final binary tree?
26:28 - Is it really worth it?
29:50 - Where would tree fit in the Ethereum stack of development?
31:22 - Is the primary point of having a binary tree is to make the information less computationally expensive?
32:04 - Does the binary tree make searching fast in general?
32:52 - Is it a more efficient state management system for Ethereum?
33:25 - What's the primary motivation for the binary tree?
33:48 - How does one compute the state proof & how does the binary tree make a difference?
38:08 - Why does witness size matter?
39:22 - Hash function - have you considered SHA 256?
40:10 - Are these proposals ready to be moved into "Review" status?
43:21 - Thoughts on moving the 'discussion to' to Fellowship of Ethereum Magicians?
EIP-2584: https://eips.ethereum.org/EIPS/eip-2584
Eth research paper - https://ethresear.ch/t/overlay-method-for-hex-bin-tree-conversion/7104
EIP-3102: https://eips.ethereum.org/EIPS/eip-3102
Eth research paper - https://ethresear.ch/t/binary-trie-format/7621
Follow at Twitter:
Guillaume Ballet @gballet | Pooja Ranjan @poojaranjan19 | William Schwab @William94029369 | James Hancock @JHancock | Alita Moore @AlitaMoore85
Check out other exciting EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Contact Ethereum Cat Herders
Discord: https://discord.gg/sgdnxZe
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Hello
and
welcome
to
the
one
and
only
erp
dedicated
series
evening
where
we
discuss
an
ethereum
improvement
proposal,
understand
its
importance
and
talk
about
how
it
is
going
to
make
ethereum
even
better.
I'm
your
host
pooja
ranjan
and
we
are
joined
by
william
shaw,
alita
more
from
ethereum
cat,
herders,
rathan
drive
from
consensus
and
our
hardware
coordinator
dreams
in
2021.
A
Both
eips
are
standard,
track
core
proposals
and
are
in
draft
status.
How
close
these
proposals
are
and
how
they
are
going
to
help
ethereum
chain?
Let's
hear
out
from
the
author
itself,
so
without
further
ado.
Let's
welcome
you,
please
let
our
audiences
know
a
little
bit
about
yourself
and
then
we'll
dive
into
the
proposal.
B
And
yeah,
so
I'm
going
to
to
present
two
eips,
I
mean
mostly
one.
The
other
one
is
a
bit
more,
a
back
burner
for
for
reasons
that
will
that
will
appear
evident
well,
hopefully,
and
so
the
first
one
is
about
switching
from
hexary
tri
to
to
a
binary
tri.
Actually
both
of
them
are,
but
this
one
defines
the
the
structure
of
the
binary
tri.
So
just
for
those
for
whoever
might
watch
this
this
video
later
and
doesn't
know
what
the
heck's
a
tree
is.
B
B
B
It's
it's
saving
for
four
times
roughly
between
three
and
four
times
the
space,
at
least
theoretically.
So
that's
the
that's.
The
role
of
this
of
this
eip
do
to
propose
what
will
be
the
structure?
How
do
you
organize
the
whole
the
whole
tree
to
to
keep
all
the
the
benefits
and
to
to
reap
the
benefits
of
the
binary,
the
binary
trees
to
to
to
build
more
efficient
proofs?
B
So
the
key
points
of
this
eip.
Well,
obviously,
it's
about
using
binary
trees,
it's
about
changing
the
the
hashing
algorithm
from
ketchup
256
to
blake
2.,
it's
about
getting
rid
of
rlp,
which
was
something
everybody
yeah,
but
by
popular
demand.
We
we
got
rid
of
rlp
and
there
are
two
more
two
more
things
like
we
put
the
key
at
the
leaf
level,
but
I
will
I
will
explain
that
a
bit
more
in
details
at
the
end
of
the
presentation,
so
yeah
the
binary,
the
binary
tree.
B
B
B
So
we
just
get
rid
of
it
and
the
reason
for
that.
The
reason
why
it
was
chosen
in
the
first
place
is
because,
if
you
have
16
siblings
and
let's
say
most
of
them
are
empty.
If
you
take
a
fixed
structure
with
16,
16
entries
or
or
17,
if
you
have
a
value,
you
find
yourself
yeah
having
a
lot
of
space
taken
and
most
of
which
is,
is
empty.
B
Empty
u256,
like
32,
bytes,
sequences
of
32
bytes
and,
as
a
result,
there's
a
bit
of
compression.
So
rlp
was
actually
used
in
this
case
for
compressing
compressing
nodes,
but
in
the
case
of
binaries,
when
you
only
have
binary
trees,
when
you
only
have
two
nodes:
two
children,
you
don't
really
need
this
compression,
because
each
branch
in
the
tree
will
always
and
systematically
have
two
children,
so
the
compression
really
does
not
exist.
B
So
the
proposed
structure
is
to
just
a
pair
of
two
32-byte,
integers
or
or
u2
u256
and
depending
on
the
type
of
node
yeah.
Those
two
values
contain
something
else,
and
the
this
fixed
structure
is
also
nice,
because
it's
got
some
apparently
it's
easier
to
build
the
to
to
make
zk's
like
zero
knowledge
constructions
out
of
out
of
this.
So
this
is
also
something
that
was
that
was
requested.
So
in
the
case
of
a
branch
of
a
branch
in
a
tree.
Well,
it's
simple
the
first.
B
B
I
was
also
talking
about
blake
too,
so
why
did
we
pick
a
black
two?
We
we
made
some
measurements,
so
you
have
four
four
plots
with
different
size.
Three
sizes,
and
every
time
you
can
see
that
the
the
the
use
of
black
two
as
a
hashing
algorithm
is
actually
four
times
faster.
I
mean
roughly
four
times
faster
as
the
ketchup
one
which,
which
is
nice,
because
it
compensates
exactly
the
the
length
of
a
path
from
from
the
leaf
from
the
root
to
to
a
leaf.
B
So
yeah,
that's
something
else,
and
the
reason
why
you
have
something
so
small
on
the
on
the
left
side
and
something
so
high
on
the
on
the
right
side
is
because
one
method
was
using
extension
nodes
and
the
other
one
was
not
so.
There's
there's
been
a
big
debate,
but
I'm
not
going
to
to
delve
into
this
for
the
presentation
right.
So
I
was
talking
about
merging
the
accounts
and
the
storage
trees.
So
in
ethereum
you
have
a
lot
of
trees
that
are
more
or
less
independent.
B
I'm
actually
not
sure
why
they
were
separated
initially,
but
it
makes
it
makes
sense
to
to
merge
them
simply
because
if,
in
order
to
access
slot
storage
this
the
slots,
the
slot
of
an
account,
you
prefix
it
with
the
address
or
the
hash
of
the
address
of
that
account.
So
if
it's
all
stored
in
a
subtree,
when
you
store
everything
in
a
database,
everything
is
contiguous.
So
you
can,
you
can
like
load
the
account
and
part
of
its
storage
directly
from
disk
in
one
go.
B
You
don't
have
to
do
a
lot
of
db
searches
in
the
db,
so
it's
it's
a
bit
faster.
It
reduces
io
and
io
is
the
is
the
killer
when
it
comes
to
performance
and
also
there's
another
eip.
I
forgot
to
check
the
number.
It's
29,
something
it's
about
code
localization,
so
one
of
the
ideas
is
instead
of
passing,
all
the
the
code
to
a
live
client.
B
You
only
pass
the
bits
that
are
really
needed
for
the
the
execution,
and
this
is
another
tree,
so
it
starts
looking
like
you
have
too
many
independent
trees
so
might
as
well
gather
or
bring
them
all
under
one
one
tree
right.
So
this
picture
is
a
bit
cut
off.
Let
me
see,
I
don't
know
if
you
can
see
yeah,
it
looks
like
you
can
see
it
properly
now.
B
So
the
question
is:
how
do
you
access
all
those
those
info
because,
like
I
said,
there's
a
very
fixed
structure
of
two
to
32,
byte
integers
and
the
problem
with
this
is
that
you
cannot
no
longer
have
val
values
inside
the
the
inner
node
of
of
a
tree.
So
what
we
propose
is
to
actually
put
all
those
values
in
separate
locations
in
three
separate
leaves.
B
B
So
we
we
save
this,
this
hashing
part
for
that
specific
property,
but
we
keep
the
we
we
clear
the
two,
the
last
two
bits
of
of
this
first
32
byte
address
to
select
as
some
kind
of
selector
to
to
get
the
the
item
in
an
account.
So
the
balance
is
zero.
The
the
nonce
is
one
and
well.
The
code
right
now
is
a
is
a
big
blob
of
data.
B
Sorry,
yes,
64
bytes
addresses
so
500
512
bits,
and
you
also
do
the
hashing,
because
you
have
this
two
two
level
hashing
which
was
already
present
in
the
hexary
tree
and
and
is
necessary
for
for
keeping
the
tree
balanced
and
the
last,
and
actually
is
it
the
last
yes,
the
last
optimization
or
the
last
point
I
wanted
to
talk
about
for
this
eip
is.
Why
did
we
decide
to
put
the
the
key
at
the
leaf
level?
B
And
it's
simply
because
well,
the
key
is
already
when
you
search
inside
the
tree,
the
you
already
have
the
key
handy
and
doing
all
this
putting
it
like
in
the
hexary
tree.
So
in
the
hexory3
you
have
chunks
of
keys
all
over
the
all
over
the
internal
nodes,
so
the
keys
is
split
and
it's
actually
split
into
nibbles.
B
So
four
four
bits
yeah
packs
of
four
bits,
and
you
find
yourself
having
to
shuffle
data
around
like
because
if
it's
on
an
uneven
nibble,
you
have
to
to
shift
everything
by
four
bits.
So
there's
a
lot
of
data
data
manipulations,
which
also
end
up
being
yeah,
very
complex
error
prone
consuming,
and
we
didn't
want
to
time
consuming
and
we
didn't
want
to
go
into
this.
B
This
trouble
again
with
bits,
because
now,
instead
of
having
one
in
two
chances
of
having
to
shuffle
the
data,
you
find
yourself
having
a
one
in
eight
chances
of
of
having
to
to
shuffle
the
data
lots
of
complexity,
there's
a
whole
article.
I
wrote
about
this
so
yeah.
We
didn't
want
to
go
into
this
and,
like
I
said
before,
I
was
talking
about
the
flat
database,
or
at
least
I
was
hinting
at
the
flat
database.
B
B
B
You
have
a
first
fork,
so
you
choose
the
right
one.
So
that's
one
bit
right
over
or
left,
then
you
have
a
prefix
of
four
bits.
So
that's
where
that's
what's
stored
here
and
then
you
have
another
fork
in
the
yeah
another
branch.
So
it's
either
it's
one
bit
for
either
right
or
left
and
then
to
complete
the
eight,
the
full
by
the
four
eight
bits.
B
B
So
you
really
don't
need
to
change
that
that
node,
so
that
was
the
that
was
the
an
optimization
I
wanted
to
to
make
clear,
because
I
really
think
it's
it's
a
nice
one
right,
so
that
was
it
for
the
for
the
structure
of
the
binary
tree
and
now
I
just
want
to
quickly
go
over
20
25
84,
which
is
this,
which
just
describes
the
the
method
for
converting
from
a
hexary
to
a
binary
tree.
So
this
is
actually
the
one
that
started
everything.
B
B
B
So
the
idea
which
is
actually
taken-
I
don't
know
if
people
have
been
using
or
have
been
looking
at
the
way
docker
works,
for
example,
it's
layers,
so
you
have
a
read-only
layers
and
you
have
the
top
layer
right.
So
it's
the
the
way
file
systems
work
in
docker.
You
have
layers
representing
files,
several
layers
and
the
file
system
at
the
top
is
writable.
So
if
you
write
to
the
to
the
file
system,
it
will
end
up
in
the
overlay
layer
the
the
layer
at
the
top.
B
So
we
do
the
same
thing.
We
have
the
x
the
hexary
tree
and
we
have
the
the
binary
tree
and
there's
something.
I
should
have
explained
sorry
about
that.
The
problem:
why
don't
we
just
convert
everything
in
one?
Go
and
and
be
done
with
it?
It's
because
doing
the
conversion
on
my
benchmarks
takes
roughly
a
day
to
to
convert
from
from
hexary
to
binary.
B
So
this
is
why
it's
extremely
slow,
but
because
of
this,
because
this
is
the
current
reality-
you
have
the
problem
that,
as
you
start,
covering
all
the
keys
and
building
the
new
tree,
someone
like
blog
still
needs
still
need
to
execute
and
because
they
still
need
to
execute,
they
might
update
values
in
the
part
that
has
already
been
converted
and
there's
there's
a
bit
of
a
locking
issue.
It's
not
it's
not
really
nice
and
as
soon
as
you
get
locking
consensus
issues
are
not
far,
so
we
wanted
to
avoid
that.
C
B
Right
so
because
you
can't
fit
a
whole
day
in
14
seconds.
Indeed
you
you
need
some
kind
of
alternative
method,
and
so
the
idea
is
indeed
to
all
to
have
all
the
rights
go
into
a
binary
tree
that
is
laid
over
the
the
hexagon
tree.
So
every
time
you
you
write,
it
ends
up
in
that
tree.
Every
time
you
read,
it
will
first
search
in
the
binary
tree.
If
it
can't
find
the
value
it
will
search
in
the
hexagon.
That
can
be
done
in
parallel,
of
course,
but
this
is.
B
You
need,
because
you
have
two
trees,
you
have
a
base
tree
and
and
then
overlay
tree.
You
need
to
have
two
values
in
in
the
block
two
like
two
state
routes
in
the
block.
So
yeah,
that's
that's
a
bit
of
the
of
the
question
at
least
the
the
the
the
thing.
The
sorry
I'm
looking
for
for
the
word,
the
criticism
that
has
been
raised
during
during
the
review
so
like
yeah
like
easter.
B
The
process
has
three
phases
and
the
first.
The
first
phase
is
the
one
where
all
the
rights
end
up
in
in
the
binary
overlay
and
meanwhile,
in
the
background,
all
those
all
the
base,
three
which
is
read
only
so
no
longer
changes,
is
being
translated.
N
blocks,
so
n
items
per
block
from
so
they're.
Basically
read
from
the
hexary
tree,
like
you
read
endless
on
the
the
hexary
tree
and
you
insert
it
into
a
binary
tree.
B
So
that's
basically
n
times
the
number
of
the
number
of
leaves
or
the
sorry
n
n
times
the
number
of
blocks.
When,
when
that
value
gets
over
the
size
of
the
of
the
hexary
tree,
you
switch
to
phase
one,
and
in
that
case
you
just
replace
the
so
the
base
three
the
hexary
tree
is
deleted
and
it's
replaced
by
its
binary
equivalent
and
then
every
block.
B
So
the
overlay
tree
is
presumably
much
smaller
because
it's
only
maybe
a
day
worth
of
of
rights,
whereas
it's,
whereas
the
base
tree
is,
is
like
five
years
worth
of
write,
and
so
you
just
it's
basically
the
same
process,
but
it's
the
the
layer
that
is
read
only
at
the
layer
that
is
written
to
are
inverted
yeah.
You
were
very
faint,
so
I
don't
know
if
you,
if
you're
still
talking.
D
B
Right,
so
that's
because
it's
for
parallelism,
because
you
don't
want,
if
you
do
this,
if
you
write
both
together,
you
still
have
the
problem
that
you
need
to
write
back
like
if,
if
a
value
gets
written
into
into
the
tree,
you
need
to
yeah
like
the
conversion
happens,
and
you
you
still
have
the
problem
that
you
might
write
like
you
might
have
to
recalculate
recalculate
things.
So
it's
really
just
because
it's
too
simplified
to
simplify
the
the
merge.
B
Basically
it's
yeah,
so
that
you
can
do
both
in
parallel.
They
don't
you
don't
need
to
lock
all
right
because,
okay,
let
me
let
me
re-explain
that
in
a
more
in
a
simpler
way,
if
you-
and
if
you
want
to
do
them
in
parallel,
they
have
to
be
separate
if
they
are,
if
they
are
not,
if
they
are
written
in
the
same
tree,
you
need
to
make
sure
that
either
like
basically,
they
need
to
be
sequential
either.
B
B
D
B
Right
it
could
be
done
yeah,
it's
just
it's
an
optimization
that
maybe
has
no
has
no
reason
to
exist.
But
yes,
that's
that's
the
reason,
yeah
and
so
phase.
Two,
it's
simply
yeah.
You
just
drop
the
extra
header
you
because
the
that
it
starts
when
the
overlay
tree
is
empty.
So
when
the
overlay
tree
is
empty,
you
just
you
just
drop
that
extra
header
and
and
you're
done
so
the
question
is:
is
it
really
worth
it?
So,
at
the
time
I
created
the
this
dip?
B
So
I
would
say:
I'm
yeah,
I'm
less
enthusiastic
about
the
about
the
cip
at
the
moment,
but
the
real
question,
like
the
real
decision,
whether
it's
abandoned
or
not,
will
be,
will
be
clear
when
when
eip
3102
is,
is
complete,
so
yeah.
That
was
that
was
it
and
yeah.
That's
pretty
all
much
all
for
the
presentation,
so
yeah.
If
you
want
to
join
the
discussion.
There's
this
thing:
oh
yeah,
on
medium,
I
I
tend
to
to
write
some
some
articles
about
this.
B
That
tried
to
be
a
bit
more
accessible,
so
there's
two
two
of
them
in
the
pipe
right
now,
so
hopefully
they'll
come
soon
and
there's
a
pr
that
I
wanted
to
show.
So
currently
the
33102
has
been
implemented,
there's
still
a
huge
to-do
list,
but
the
the
basic
logic
is
here.
So
that's
the
one
if,
if
people
want
to
implement
their
their
like
try,
try
it
in
their
own
clients.
This
is
the
one
to
look
at
and
to
criticize
it's
by
no
means
perfect.
B
In
fact,
it's
not
even
passing
lint,
but
but
overall,
like
the
the
general
logic
is
here
and
yes,
if
I
also,
I
wrote
an
article
about
explaining
in
detail,
why
why
we,
we
are
dropping
rlp,
so
that
could
be
interesting
as
well
and
with
that,
oh
yes,
there
was
another
question
that
was.
I
was
supposed
to
answer
it's.
When
do
we
move
to
the
next?
When
do
we
move
to
the
next
step
of
the
aip?
B
Well,
basically,
when
this
pr
is
done-
and
we
also
need
the
other
clients
to
to
try
this
eip
and
give
us
feedback
because
we
don't
want
to
be-
I
mean
I
don't
want
to
be
making
the
the
decisions
for
every
single
client
out
there.
So
there
should
be
some
some
implementation
based
feedback
and
when
we
get
that,
I
think
we're
ready
to
to
move
to
the
next
stage
and
yeah
this
time.
I'm.
C
B
E
B
So
if
you
want
to
be
able
to
use
ethereum
in
on
mobile
or
in
in
a
lighter
clients-
or
you
just
simply
don't
want
to
go
through-
oh,
like
hosting
all
of
the
internet's
data
and
you're
just
interested
in
your
own
data.
So
there's
there's
a
lot
of
usability
tweaks
associated
to
this.
So
it's
very,
I
agree.
It's
very,
very
core,
very
boring
details
for
most
people,
but
but
it
will
have
an
impact
on
usability.
E
So
the
way
that
I
know
the
way
that
I
would
normally
like
consider
a
binary
tree
would
be
like
just
simply
for
sorting
right-
and
just
I
guess
to
clarify
is
the
primary
point
of
this
binary
tree
to
make
finding
information
like
a
lot
less
computationally
expensive,
because
I
remember
you
mentioning
that
for
turbo
get
the
primary
performance
hold
back.
Was
the
memory
access.
B
B
No,
they
don't,
but
because
of
that
flat
database
that
we're
model
that
we're
switching
to
it's
not
going
to
have
an
impact
like
basically
the
switch
to
the
the
new
database
model
is
the
one
that
is
going
to
to
provide
the
the
performance
and
therefore
the
binary
tree
performance
is,
is
fairly
irrelevant
and
therefore
we
can
we
can
adopt
a
simpler
structure.
So
it's
it's
basically
more
of
a
maintenance
code,
maintenance
issue.
B
Not
exactly,
let's
yeah
like
it's
really
just
that
it's
the
choice
of
the
data,
the
new
database
format
that
lets
us
pick
whatever
tree
format
we
want
and
we're
just
gonna
pick
the
format
that
is
available
in
every
textbook.
Every
that
is
well
understood.
That
is
like
there's
a
million
implementation,
a
very
good
implementation,
so
yeah,
it's
just
simpler
to
conceptualize.
D
B
D
B
B
E
E
Please
sure
so.
Dunkrod
just
mentioned
that
that,
like
the
primary
motivation,
is
to
reduce
the
amount
of
like
processing
requirements
to
to
provide
a
proof
that
a
certain
transaction
or
feature
exists
within
the
entire
tree
within
the
entire
ethereum,
like
history
and
state.
And
so
my
question
is
like
how
does
one
normally
compute
that
proof
and
how
does
the
binary
tree
like
make
that
different.
B
This
is
how
you
compute
the
proof,
so
you
can
see
there's
a
lot
of
siblings,
there's
15
per
level,
and
if
you
use
a
binary
tree,
you
have
only
one
sibling
per
level,
so
the
depth
of
your
tree
is
four
times
as
yeah.
The
the
tree
is
four
times
as
deep,
but
the
the
number
of
sibling
is
two,
so
you
you
only
have
instead
of
having
15
15
times
two
you
have
you
have
there,
it
must
be
yeah
eight,
eight
times
eight
times,
two.
D
D
B
C
I
might
I
might
be
able
to
try
so
in
and
correct
me
if
I'm
off
on
this
stuff
guys,
but
everything
that's
ever
happened
in
ethereum,
whether
it's
your
account
how
much
ether
you
have
how
many
erc20s
like
where
you
are
somehow
fits
in
these
in
this
tree
and
each
block
something
happens
like
if
I
make
a
transaction
something
happens
to
those
tree.
Usually
there
is
some
access,
that's
having
been
changing
to
the
storage,
but
there
is
the
state
of
ethereum
is
huge.
Every
block,
not
everything's,
always
going
to
be
touched.
C
So
if
you
can
only
pick
the
parts
that
are
being
changed
and
then
have
that
be
be
part
of
what's
being
stored
or
proved,
then
you
can
have
a
lot
smaller
thing
than
trying
to
save
the
entire
tree,
the
entire
time
every
time
or
share
the
entire
tree
every
time.
So,
if
you're
trying
to
find
something
in
a
binary
tree
and
define
where
it
is,
it's
a
lot
become
more
compact
to
be
able
to
do
that
with
the
binary.
C
E
That
makes
sense
so
then,
what
you're
saying
is
like,
instead
of
having
to
prove
the
in
the
entire
every
in
like
every.
I
guess
what
I'm
trying
to
say
every
piece
of
information
on
the
tree
to
prove
that
one
occurred.
You
just
have
to
prove
that
the
single
I
guess
branch
of
the
tree
exists
and
that's
like
the
major
difference.
C
D
E
D
Yeah-
and
I
mean
the
answer
for
that-
can
be
different.
Things
like
one
is,
for
example,
you
want
to
know
how
much
ether
do
you
have
in
your
account
right,
and
you
can
just
ask
a
note
and
they
give
you
an
answer
and
you
can
trust
them,
but
with
this
structure
you
can
actually
get
something
better.
You
can
ask
the
note-
and
the
note
can
say
like
well
from
the
current
root
hash
of
ethereum.
I
can
prove
it
to
you.
I
can
show
you
that
this
is
correct.
D
This
is
the
witness
and
that
that
that's
becoming
smaller
and
this
matters
even
more
because
in
the
future
we
might
want
to
go
to
a
world
where
every
block
actually
includes
complete
proofs
that
the
changes
that
were
made
to
the
state
are
were
done
correctly,
and
these
would
become
a
lot
smaller
in
this
in
this
structure,
and
that
means
you
can
validate
a
block
without
even
knowing
what
this
huge
like
many
gigabytes
of
states.
Are.
You
can
just
look
at
this
block
few
megabytes
and
see
how
it's
corrected.
This
is
the
correct,
ecm
block.
D
D
B
B
A
A
Okay,
so
moving
on
to
the
next
section
that
is
related
to
the
eip
processes,
the
cat
leaders
are
also
involved
in
the
process.
Improvement
of
eips
and
network
upgrade.
So
with
this
series,
we
are
trying
to
share
information
about
the
latest
processes
that
are
being
followed,
and
we
have
recently
published
a
couple
of
blogs
on
each
medium,
explaining
the
aib
standardization
process
and
the
network
upgrade
process.
A
Talking
about
the
statuses
for
these
two
eips
according
to
the
eap,
it
is
in
draft
status.
Recently,
a
status
review
has
been
introduced
that
is
in
between
draft
to
the
last
call
right
so
as
as
per
one
eight
one.
The
review
is
like
when,
whenever
an
eip
author
marks
an
eip
to
be
ready
to
be
reviewed
by,
you
know
peer
review,
we
can
move
it
to
that
state.
B
A
This
is
just
for
the
information
of
all
other
authors
out
there,
who's
the
erp's
need
to
status
change.
If
you
need
help,
please
reach
out
to
eip
ethereum
cathedrals.
We
we
just
want
to.
We
just
want
to
make
sure
that
whenever
community
is
reaching
to
eips.ethereum.org,
they
should
get
all
the
correct
information
there.
A
So
the
next
question
I
have
is
related
to
a
discussion
to
link,
as
per
the
current
eip,
both
the
eips
points
towards
eth
research,
which
is
really
good
place
for
technical
discussion.
But
because
these
eips
are
standard
track
code
proposals,
we
hope
to
see
them
in
one
of
the
future
upgrades.
Obviously
after
berlin-
I
don't
know
when,
but
yes,
so
this
will
invite
more
community
participation,
consensus
and
visibility
like
more
than
the
present
technical
set
of
people.
So
we
generally
recommend
to
point
eips
discussion
to
to
the
fellowship
of
ethereum
magician.
B
Yeah,
no,
I
mean
the
there's
no
problem
in
in
doing
this.
Moving
the
I
mean
especially
getting
community
feedback
is
always
interesting.
I
I
still
think
each
research
is
the
place
for
for
technical
technical
feedback,
although
yeah,
if
you're
a
magician,
is
not
a
bad
place
either.
No
okay,
I
I
can.
I
can
do
that.
A
There
is
another
episode
we
recorded
in
december
with
nick
johnson.
That
would
be
having
some
useful
information.
If
you
haven't
watched
it
already,
you
can
watch
it
on
ethereum
categories:
youtube
for
community
watching
to
learn
proposal.
Do
let
us
know
if
your
comments,
if
you
have
any
questions
that
could
not
be
answered
in
this
episode,
you
can
ask
the
author
directly
his
twitter
handle
and
links
for
discussion,
as
well
as
the
presentation
that
was
shared
today,
would
be
provided
in
the
description
section.
A
So
we
started
this
peep
and
eat
series
late
in
2020
and
we
received
pretty
good
responses
from
community
for
2021.
We
have
got
quite
a
few
interesting
proposals
lined
up
next
week.
We
will
be
joined
by
alberto
canada
to
talk
about
an
interesting
erc
that
is
eip
3156
flash
loans,
so
stay
tuned.
Keep
sharing
your
love
with
ethereum
cathedrals.