►
Description
Topics covered
-----------------------------
2:03 - Andrei’s introduction
2:35 - Presentation
2:38 - Different EOF EIPs available
3:42 - Relationship of EIP-3540 & EIP-3670
4:35 - Motivation
10:54 - EIP-3540 Specification
13:04 - EIP-3540 Validation rules
13:20 - EIP-3540 EOF version 1
14:11 - EIP-3540 Example bytecode
15:50 - EIP-3670 Code validation
19:02 - EIP-3670 Deprecate SELFDESTRUCT, CALLCODE
19:47 - EIP-3670 Security consideration - Gas change for code validation
21:50 - EIP-3540/3670: Creation rules
25:03 - EIP-3540: Execution rules
26:13 - Future of EOF proposals
28:39 - Learn more
29:05 - Questions
29:50 - What advantages do you see of deploying EIP-3541 with the London upgrade?
32:04 - These byte codes added because of 3541, was it anyway affecting the present EVM working?
33:50 - Why SELFDESTRUCT was introduced and why is the team in favor of deprecating it?
40:05 - How is the team doing with testing EOF proposals?
41:35 - Where to follow proposals and how to participate?
Resources:
-----------------
Everything about the EVM Object Format (EOF) - https://notes.ethereum.org/@ipsilon/evm-object-format-overview#Everything-about-the-EVM-Object-Format-EOF
Slides - https://notes.ethereum.org/@ipsilon/peepaneip-eof1
EIP - https://eips.ethereum.org/EIPS/eip-3670
Discussion to - https://ethereum-magicians.org/t/eip-3670-eof-code-validation/6693
EIP - https://eips.ethereum.org/EIPS/eip-3540
Discussion to - https://ethereum-magicians.org/t/evm-object-format-eof/5727
Follow at Twitter
-----------------------------------------------
Andrei Maiboroda @gumb00 | Alex Beregszaszi @alexberegszaszi | Paweł Bylica @chfast | Pooja Ranjan @poojaranjan19
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Shanghai playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxpok0smGmq-dFGVHQzW84a2
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/
A
Evm
or
ethereum
virtual
machine-
if
you
have
heard
this
term
before
you-
are
probably
a
blockchain
developer
or
have
been
in
the
space
for
a
while,
you
and
I
understand
evm
improvement
is
important
to
improve
the
portability
of
software
as
well
as
to
make
sure
applications
are
separated
from
each
other
and
also
from
their
host.
Today
we
are
going
to
talk
about
upcoming
evm
changes
with
team
epsilon.
A
Team
epsilon,
formerly
known
as
team
evosum,
are
long-time
contributors
to
evm
upgrades.
They
have
been
on
our
show,
multiple
time
to
discuss
different
proposals,
eap
3541,
which
was
deployed
with
the
london
upgrade
eip
3855
and
eap,
3860,
which
are
expected
to
be
going
live
with
the
shanghai
upgrade.
So
if
you
missed
watching
the
recording
for
any
of
these
check
out,
our
playlist
for
respective
upgrade
welcome
again
team
super
excited
to
have
you
here
to
learn
about
upcoming
changes.
B
Okay,
I
will
be
doing
a
presentation,
maybe
a
couple
of
words
of
introduction.
My
name
is
andre
and
I
work
with
epsilon
team,
I'm
working
in
general
on
ethereum
since
late
2016.,
I
was
maintaining
c
plus
plus
a
client
of
ethereum,
originally
and
after
that
transition
to
working
with
ewasm
team,
which
is
currently
known
as
epsilon,
and
we
are
focusing
on
evm
related
research
and
development
since
then
and
yeah.
Let
me
share
my
screen
now
all
right.
I
would
like
to
start
first
with
explaining.
B
B
It
is
currently
already
deployed
in
the
london
upgrade
and
it
was
kind
of
a
preparatory
eap
that
made
it
possible
to
make
a
full
proposal
for
entire
eva
motion
format.
Spec
and
now
we
have
these
erp-3540
and
3670,
which
are
considered
for
inclusion
for
shanghai,
and
we
will
be
focusing
on
them
in
these
slides
and
but
we
also
have
a
couple
of
proposals
that
build
on
top
of
this
base,
which
is
defined
in
these
two
eips.
B
So
maybe
a
bit
more
I'll
mention
them
in
the
end,
but
these
are
like
new
features
that
can
be
built
on
top
of
evm
object,
format
and
yeah,
but
these
two
eaps
that
we
have
accepted
for
shanghai.
I
should
also
clarify
the
relation
between
them,
so
3670
technically
requires
35.40.
It
does
not
it's
not
possible
to
deploy
it
without
it,
but
in
fact
we
see
these
two
as
kind
of
a
single
eof
proposal,
so
we
are
strongly
in
favor
of
activating
them
together
in
one
upgrade
in
shanghai
and
yeah.
B
That's
why
we
are
presenting
them
together
and
they
should
be
thought
of
as
one
single
proposal.
I
think
so.
First,
let's
touch
on
the
motivation
for
both
of
these
aps
and
for
uf
in
general.
So
one
way
to
look
at
it
is
to
think
that
there
is
a
multitude
of
various
issues
you
could
say
with
evm
design
or
some
weird
edge
cases
in
design
decisions
made
that
are
hard
to
change
with
the
live
network.
B
The
way
we
introduce
new
instructions
in
the
evm
is
it
involves
some
kind
of
a
risk
every
time,
because
if
any
of
the
old
already
deployed
contracts
on
chain
has
the
value
of
the
new
opcode
and
it
relies
on
the
fact
that
this
op
code
is
undefined
and,
and
that
is
it
will
abort
execution
in
case
execution
reaches
this
byte
and
we
in
case
we
want
to
define
this
as
a
new
opcode.
It
means
that
some
old
contracts
might
change
their
behavior
and
then
might
they
might
break.
B
So
this
is
highly
undesirable
and
this
risk
is
always
around
it's
not
a
huge
risk.
We
don't
think
this
ever
happened,
but
it's
not
an
ideal
design
and
we
would
like
to
improve
this
situation
and
another
more
important
and
more.
A
bigger
problem
is
is
similar,
but
it's
about
deprecating,
some
of
the
instructions
that
existing
right
now
in
evm
and
due
to
deprecation
for
various
reasons-
and
this
is
also
not
an
easy
task,
because
the
problem
is
similar.
Some
currently
existing
contracts
do
use
these
op
codes.
B
B
Another
kind
of
a
problem
with
evm
is
the
way
that
how
jump
instructions
work
currently
so
jump
and
jump.
I
instructions
require
that
target
to
be
a
special
special
byte
value,
which
is
called
jump
desktop
code,
and
this
rule
seems
simple,
but
there
is
a
weird
edge
case
to
that.
In
case
this
jump
does
byte
is
inside
push
data.
There
is
bytes
immediately
following
one
of
the
push
instructions.
B
Those
are
bytes
that
will
push
instructions
and
pushes
on
stack
in
case
jump
dust
is
inside
this
data.
It
is
not
a
valid
jump
destination
and
a
attempt
to
jump
there
must
fail,
and
this
leads
to
a
complication,
because
to
make
this
possible
client
implementations
need
to
do
some
kind
of
analysis
before
every
execution.
It's
called
jump
dust
analysis
and
yeah.
B
It
is
just
data
and
it
is
fine
for
edm
interpreter
itself,
but
for
various
tooling
or
layer,
2
solutions,
it's
difficult
or
can
be
infeasible
to
find
these
data
sections,
and
it
might
be
important
for
them
because
they
might
want
to
do
some
analysis.
Some
static
analysis
on
the
code
part
only,
and
so
this
is
complicated.
Currently,
this
is
one
of
the
well-known
problems
with
evm.
There
were
some
proposals
trying
to
address
these,
introducing
some
way
to
mark
this
data
section
and
yeah.
You
have
also
is
trying
to
address
it
in
some
way.
B
Also,
it
provides
a
way
to
do
exactly
exactly
that
or
another
way
to
look
at
motivation
is
to
think
that
versioning
mechanism
is
something
that
is
highly
desired
in
evm,
because
it
would
actually
solve
these
problems
that
I
just
mentioned.
It
would
be
easier
to
introduce
new
features
like
new
op
codes
or
deprecate
some
some
currently
existing
op
codes
without
disruption
to
already
deployed
contracts,
or
it
would
provide
extensibility,
in
other
words
and
yeah.
This
is
also
was
approached
several
times
by
several
proposals.
B
It
would
require
the
change
to
the
structure
of
the
entire
state
tree,
and
this
would
probably
need
some
migration
procedure,
so
uf
tries
to
approach
it
in
a
different
way
by
putting
the
version
inside
the
bytecode
and
yeah
I'll
show
this
in
more
details
a
bit
later
and
another
important
part
of
the
motivation
is.
We
would
like
to
introduce
this
validation
at
deploy
time,
meaning
that
any
contract,
when
it
is
being
deployed,
will
first
go
through
this
validation
procedure.
B
Yeah.
This
is
one
important
part
of
motivation
behind
uf
and
I'll
get
now
into
the
specification
as
outlined
in
eap
3540.
I
would
say
the
specification
consists
of
several
distant
parts
there.
The
first
one
is
just
general
container
specification
container
is
a
term
introduced
in
the
eip
to
disambiguate
from
the
older
term
code,
meaning
that
account
will
be
associated
with
the
entire
container
and
code
can
be
only
a
part
of
this.
That's
why
a
new
term
like
this
was
needed
and
yeah.
B
This
is
a
general
general
description
of
the
binary
format.
For
for
the
container,
it
is
general
in
the
sense
that
it
should
apply
to
any
uf
version
currently
proposed
or
any
future
version
yeah,
and
it
like,
looks
like
this
here
on
the
picture.
More
specifically,
it
starts
with
magic
sequence.
These
are
two
bytes
ef00,
and
these
are
yeah.
This
is
a
special
combination
that
was
chosen
specific
in
such
a
way
to
guarantee
that
no
other
contracts
with
this
prefix
already
exist
on
chain.
B
As
of
now,
and
thanks
also
to
this
already
mentioned
eip-35,
it
is
forbidden
to
deploy
other
contracts
since
london.
So
this
allows
us
to
make
sure
that
only
valid
contracts
will
end
up
deployed
on
chain
and
yeah
following
it.
There
is
one
byte
for
a
version.
We
define
version
numbers
starting
from
one
to
ff.
We
leave
zero
value
just
in
case
some
tools
would
like
to
use
zero
to
mean
legacy
code
and,
following
that
container
basically
may
consist
of
arbitrary
number
of
sections.
B
There
is
a
description
of
each
section,
first,
showing
its
kind
as
a
one,
byte
value
and
its
size
as
two
byte
value,
and
then,
following
that
there
are
contents
of
all
the
sections,
and
next
to
that,
the
spec
defines
a
number
of
rules
to
validate
this
binary
format.
These
are
kind
of
common
sense
rules.
I
will
not
read
them
out,
like
things
like
sections
should
not
be
empty,
must
not
be
empty
and
the
next
part
of
the
spec
it
defines
the
the
first
version
for
eof.
B
So
this
is
this
further
restricts
this
validation
on
top
of
container
being
well
formed.
There
is
this
specific
thing
that
we
call
the
first
version
of
uf,
and
specifically
it
means
eos
version.
One
has
one
obligatory
code
section
and
one
optional
data
section,
in
other
words,
any
eof
version.
One
valid
contract
will
have
either
one
code
section
and
one
consecution
only
or
a
code
section,
plus
a
data
section,
and
the
implication
here
to
note
is
that
data
only
contracts
will
not
be
allowed
in
case
you
would
want
to
deploy
only
data.
B
You
would
still
need
to
have
at
least
one
byte
long
code,
section,
yeah
and
here
I'll
illustrate
these
all
these
rules
in
a
simple
example
of
how
uf
code
could
look
like
so
about
uc
legacy
code
as
it
exists.
Now
this
is
just
a
sequence
of
opcodes
without
having
any
particular
structure
and
uf
code
can
be
seen
as
having
these
three
parts.
First
part
is
a
header
defined
in
all
sections,
then
the
code
section
follows
follows
it
and
finally,
there
is
a
data
section
and
some
more
details
like
yeah.
It
starts
with
this
magic
sequence.
B
B
Then
the
code
section
is
contains
just
a
regular
sequence
of
opcodes,
as
the
bytecode
legacy
bytecode
does
now.
This
is
nothing
special
here
and
finally,
we
have
a
data
section
in
this
particular
case.
It
is
also
a
sequence
of
opcodes,
because
this
entire
container
is
an
init
code
in
this
case,
and
it
returns
this
data
in
the
end,
and
this
data
will
be
deployed
on
chain
as
a
code
of
new
contract.
So
in
other
words,
these
are
also
sequence
of
opcodes,
but
they
are
treated
just
as
data.
B
As
of
now
yeah,
any
attempt
to
deploy
an
undefined
opcode
would
result
in
a
failure
and
motivation
for
this
is
this
makes
implementation
a
bit
simpler
in
the
part
where
to
determine
whether
a
specific
byte
value
is
defined,
op
code
or
not,
you
would
need
with
this
rule
in
place.
You
would
need
on
the
eof
version,
and
otherwise
you
would
also
need
a
network
upgrade
version,
probably
fork
version
or
something
and
yeah.
B
Another
motivation
is
this:
with
this
rule
in
place,
it
becomes
easier
to
introduce
new
op
codes
in
the
future
without
bumping
uf
version.
We
see
this
as
a
useful
property
and
a
second
rule
of
validation
check
is.
We
require
the
code
section
to
end
with
one
of
the
instructions.
Terminating
execution
like
stop,
return
revert
self-destruct
to,
and
invalid
opcode
and
yeah.
This
provides
a
number
of
benefits.
B
B
One
thing
to
note:
is
it's
possible
to
deprecate
some
of
the
op
codes
that
we
think
are
due
for
deprecation,
at
least
for
the
future
uf
contracts?
It's
like
as
easy
as
in
excluding
them
from
the
list
of
the
defined
ones
and
according
to
the
validation
procedure
of
ap
3670,
any
contract
with
these
op
codes
will
be
rejected
and
yeah.
We
generally
think
it's
a
good
idea,
we're
in
favor
of
doing
it.
B
It's
not
currently
part
of
the
eap,
but
I
think
we
want
some
more
feedback
regarding
whether
it
should
be
the
same
ep
3670
or
we
should
make
another
one
for
this
and
yeah,
but
in
general,
we're
in
favor
and
yeah.
Another
important
thing
about
ep3670
is
related
to
security
considerations,
so
this
new
validation
procedure
for
code
section.
It
introduces
some
overhead
because
to
perform
these
checks,
you
need
to
do
one
pass
over
the
code
section
and
yeah
and
it
it
must
be
accounted
for
in
the
guess.
B
Charges
for
creation
of
the
new
contracts-
and
also
the
thing
to
note
here
is
that
this
happens
in
two
stages.
You
could
say:
first,
the
init
code
is
before
being
executed,
is
being
validated
with
all
the
rules
for
uf
and
when
unit
code
finishes
execution
and
returns
the
code
to
be
deployed.
That
code
must
also
be
validated
and
it
must
be
valid,
otherwise
it
is
not
allowed
to
be
deployed.
B
So
there
are
two
stages
to
this
overhead:
two
parts
of
it
and
for
the
deployed
code
we
already
paid
200
gas
per
each
deployed
byte,
and
that
is
quite
high
price.
It
accounts
for
the
storage
for
the
new
contract
and
we
think
that
it's
not
reasonable
to
increase
it
like
just
a
bit
for
one
guess
or
something.
We
think
it
covers
enough
to
cover
the
validation
of
the
deployed
code
as
well,
but
for
unit
code.
B
There
is
no
such
charge
currently,
and
but
this
eap
3860
is
related
to
this,
and
one
of
the
motivations
for
that
eap
is
also
to
cover
this
case
related
to
uf.
It
has
other
benefits
too,
and
it's
it's
useful
by
itself,
but
we
also
in
favor
very
much
of
activating
it
together
with
eof
proposals,
because
it
will
make
it
more
secure
to
to
have
this
validation
in
place
and
getting
back
to
the
specification
of
both
both
aps.
So
one
important
part
is
the
changes
to
the
rules
of
how
contract
is
created
yeah.
B
This
is
the
same
thing
that,
as
I
just
mentioned,
the
validation
is
added
to
to
validate
both
init
code
and
and
deployed
code,
but
also
we
do
not
disallow
in
these
eips
deploying
the
legacy
code.
Yet
we
think
it's
still
useful
to
have
some
transition
period
when
it's
allowed
to
use
legacy
code
and
deploy
legacy
code
still.
So
this
means
that
init
code
can
be
either
eof
or
legacy
code,
and
the
implementations
should
check
it
by
the
prefix
in
case
the
unit
code
or
code
has
uf
prefix.
B
It
means
that
the
code
declares
itself
as
being
eof
and
then
it
must
go
through
validation
procedure
in
case
it
is
ends
up
invalid.
Then
entire.
The
entire
creation
fails
for
creation
transaction.
It
means
just
aborting
the
creation
and
importing
entire
transaction
transaction
fails
in
this
case
and
for
create
and
creating
two
instructions.
That
means
execution
of
them
ends
with
the
zero
result
on
stack.
This
is
similar
to
other
creation
errors
for
these
opcodes.
B
B
Should
read
that
for
sure-
and
another
thing
to
note
is
that
so
unit
code
and
deployed
code
are
independent
in
a
way
that
both
of
them
can
be
either
uf
or
legacy
code.
So
there
are
these
four
combinations
possible
and
you
have
init
code
deploying
uf
code.
We
see
this
as
kind
of
an
ideal
situation,
ideal
future
for
evm,
when
everything
will
be
eof
code
and
yeah.
We
do
not
disallow,
as
I
said,
deploying
in
legacy
code
from
legacy
unit
code.
This
is
just
the
usual
normal
legacy
situation.
B
Legacy
init,
deploying
uf
code
is
also
can
be
useful.
We
think
for
this
transition
period,
but
this
striked
out
option.
You
have
init
code
deploying
legacy
code.
We
don't
really
see
much
sense
in
allowing
this.
So
this
is
not
part
of
the
spec
currently,
but
we
are
planning
to
add
this
change.
We
we
we
are
planning
to
forbid
this.
This
is
not.
It
should
not
be
a
load.
We
think
so
there
are
these
three
combinations
left
really
and
finally,
the
spec.
B
B
B
Pc
instruction
returns
an
offset
relative
to
code,
section
start;
in
other
words,
it
starts
with
zero
and
grows
from
there
and
quote
copy
and
x
code
copy
of
codes,
on
the
other
hand,
use
absolute
offsets
in
the
absolute
offsets
in
the
entire
container,
and
that
is
useful
to
make
it
possible
to
copy
from
the
data
section
if
needed,
yeah.
So
that's
that's
all
I
wanted
to
tell
about
these
two
eips.
B
As
I
mentioned,
we
have
these
other
proposals
which
are
using
and
3670
as
a
base
and
built
on
top
of
it.
One
of
them
is
4200
static,
relative
jumps.
These
are
new
instructions
to
for
for
jumps.
Basically
that
have
their
destination.
Statically
known,
they
are
taking
it
from
immediate
argument
in
the
bytecode,
as
opposed
to
taking
it
from
stack,
as
current
jumps
do,
and
this
is
beneficial
for
a
number
of
reasons.
B
This
is,
can
be
seen
as
a
step
towards
getting
rid
of
dynamic
jumps
completely,
which
is
desirable
for
some
reasons
and
yeah.
Another
step
is
this
second
eap
4750,
which
proposes
a
new
subroutine
mechanism
where
we
define
multiple
code
sections
possible
in
the
eof
and
each
code
section
represents
the
code
for.
B
3779,
is
the
work
of
greg
kolvin,
and
we
think
this
is
also
very
interesting
direction
to
explore
and
it
proposes
some
advanced
procedure
to
to
validate
the
code
section,
which
would
provide
much
stronger
guarantees
like,
for
example,
it
can
prove
that
code
during
execution
cannot
underflow
stack,
for
example,
and
that
it
is
very
beneficial
to
know
that,
because
then
we
can
not
do
these
checks
during
run
time
running
of
the
contract,
and
this
would
make
it
would
make
the
implementation
of
uvm
simpler
and
more
efficient
yeah.
There
are
other
ideas
to
also.
B
Based
on
uf
proposals,
but
these
are
yeah.
We
find
these
important
and
interesting
and
yeah.
That's
all
I
wanted
actually
to
present.
We
have
this
meta,
spec
kind
of
a
document.
It
has
all
the
links
about
to
all
the
write-ups
about
ef.
So,
if
you
are,
you
want
to
learn
more
so
check
this
link
out
yeah.
That's
all
I
had
thank
you.
A
A
A
A
B
B
So
it
would
be
very
easy
to
break
this
invariant
and
and
yeah.
Then
we
don't
get
this,
and
this
is
something
very
different
from
what
we
want
to
achieve
and
by
deploying
this
in
this
two
upgrade
mechanism,
we
first
forbid
to
deploy
contracts,
starting
with
ef
byte,
and
then
at
this
moment
some
people
can
still
deploy
some
contracts
like
this
and
there
there
were
actually
three
of
them.
B
I
think
deployed
on
the
main
net
since,
since
between
we
announced
this
eap
and
between
london
upgrade,
but
when
it
was
forbidden
and
after
that
after
london
upgrade,
we
analyzed
this
entire
chain
and
found
these
three
contracts
and
two
chosen
have
chosen
these
prefix.
That
still
allows
us
to
say
that
all
future
uf
contracts
will
be
only
those
that
will
be
deployed
after
shanghai.
A
B
So
I
I
don't
think
it
affected
evm
in
any
practically
important
way.
So
it's
strictly
speaking,
it
does
affect
the
consensus
rules.
Some
of
the
things
that
could
be
deployed
before
were
not
possible
to
deploy
after
london,
and
that
is
not
possible
now,
so
some
rules
did
change,
but
I
don't
think
this
affected
anyone.
We
like
haven't
heard
of
anyone
complaining
about
this.
This
is
just
there.
There
should
be
no
reason
to
be
affected
by
this.
Really
it's
a
minor
kind
of
a
change,
but
with
important
implications.
C
Yeah,
if
I
can
add
to
that,
I
mean
the
like-
we
pick
ef
byte
as
a
kind
of
first
first
one
of
the
magic
sequence,
and
we
knew
that
nobody
actually
deployed
contracts
for
the
whole
history
of
ethereum,
with
starting
with
this
byte
and
the
only
three
examples
that
happened
would
actually
related
to
the
cip.
We
we
we
proposed
and-
and
that
was
the
the
main
indicator,
but
like
formally
yeah-
that's
that's
that
can
be.
A
A
C
So
maybe
it's
good
to
start
with
this
new
new
evm,
let's
say
version
that
actually
doesn't
have
it
included.
So
it's
continue.
It
will
continue
for
the
old,
like
contract
subsystems.
It
will
continue
to
work
as
well
or
it'll
be
modified.
It
depends,
but
at
this
here
we
can
start
without
it,
and
one
more
nice
thing
about
eof.
Is
that,
because
of
this
forward
compatibility
properties,
we
can
always
add
it
back
if
that's
needed
or
like
add
modified
version,
but
it's
it's
rather
better
to
start
without
it.
A
Well,
thank
you
for
explaining
that
I
know
this
was
not
directly
related
to
the
proposal,
but
because
this
is
also
a
very
important
topic
and
it's
always
good
to
have
as
much
as
information
available
on
this
topic
and
now
that
it
is
being
proposed
that
should
not
approve
that
contract
for
self-destruct.
So
it's
good
to
know,
maybe
like
one.
A
A
B
B
We
use
by
the
way
our
implementation
in
go
ethereum
to
generate
the
tests,
and
we
also
are
aware
of
one
anoth,
another
team,
theorem
js
team,
that
already
implemented.
You
have
proposals
and
used
these
tests
successfully
and
yeah
and
other
clients
are
welcome
to
do
the
same
and
for
36.70
we,
I
would
also
say
it's
quite
far:
we
have
a
set
of
tests,
I
think
they
are
quite
complete
and
we
will
open
apr
on
test
triple
soon
as
well.
Yes,.
A
B
B
A
A
A
On
this
note,
thanks
to
all
our
youtube
viewers
for
watching,
if
you
have
any
question,
comment,
concern
join
the
discussion
on
the
discussion
to
link
provided
in
the
description.
If
you
have
a
suggestion
on
which
eip
would
you
like
to
learn
more
about?
Let
us
know
in
the
comment
or
share
on
the
echo
this
discord
subscribe
to
ech
youtube
channel.
If
you
haven't
done
it
already
see
you
next
time
with
another
interesting
proposal
till
then
keep
watching
keep
sharing
your
love
with
ethereum
cat
harness.