►
From YouTube: Peep an EIP #1: Writing an EIP with Matt Garnett
Description
Slides: https://docs.google.com/presentation/d/1SqXJIJg-C2QiTh89l5asQ_ZKnx5dfawZLpmUd8IQMBc/edit
Follow Matt Garnett at Github (@lightclient) & Twitter (@lightclients)
If you're new to the Ethereum community, we highly recommend watching Core Developer Learning Ecosystem Call #1 to have an introduction to EIP: https://www.youtube.com/watch?v=_6BRMN3oUrg&t=504s.
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
Just
to
give
you
a
little
background
based
on
my
engagement
with
the
network
upgrade
and
protocol
improvement
process.
Since
joining
the
category
group,
I
sensed
a
gap
of
education
required
to
understand
and
accept
the
ethereum
improvement
protocols.
This
was
the
motivation
behind
my
proposal
of
a
video
series
dedicated
to
discussing
ethereum
protocols.
A
A
A
A
B
Thanks
a
lot
puja,
you
know.
I
think
this
series
is
a
awesome
thing
that
you
guys
are
doing
for
with
the
cat
herders.
I
definitely
empathize
with
the
need
to
bring
this
process
to
more
people
in
the
community.
I
think
it's
a
really
important
process,
and
so
I'm
pretty
humbled
to
talk
about
it
with
everybody
today.
B
So
what
I'm
going
to
cover
is
everything
that
includes
the
definition
of
eip
timeline
for
eeps
and
people
are
participating
in
the
structure,
we'll
go
through
some
examples
of
good
ideas,
reefs
and
things
that
may
not
be
as
good
ideas
and
then
some
common
mistakes
that
people
make
that
I've
seen
that
people
make
when
they
write
an
eip
and
we'll
wrap
it
up
with
some
q.
A
of
this
and
other
things
that
are
on
the
e
process,
so
with
that
said,
let's
define
an
eep,
I
think
of
it
as
a
concise
and
thorough
document.
B
The
most
popular
category
of
eep
is
the
erc
type
of
standards
track.
Even
this
usually
defines
interfaces
for
smart
contracts
on
the
ethereum
network,
and
this
helps
to
find
standards
that
let
people
interoperate
with
smart
contracts
and
the
erc20
token,
is
a
great
example
of
this
type
of
eep.
It
defines
an
interfa,
a
token
interface
that
different
types
of
smart
contracts
can
utilize
and
so
things
that
kind
of
live
within
that
live
within
this
erc
category.
B
The
interface
and
networking
types
of
eeps
are
important
for
the
client,
but
they
aren't
necessarily
things
that
necessitate
network
upgrades.
It's
really
the
consensus
related
changes
in
the
core
category
that
needs
to
be
included
in
some
sort
of
network
upgrade
the
other
two
less
popular
types
of
eeps
are
the
the
meta
eve
and
the
informational
eep,
and
I
think
the
informational
eats
are
criminally
underutilized
in
the
process.
B
And
this
is
a
stage.
That's
often
overlooked,
I
think
it's
really
important
because
it
can
save
you
and
people
in
this
process
time,
if
you
just
you
know,
talk
to
some
people
about
your
idea
and
try
and
understand
if
it's
been
proposed
before
and
if
something
related
to
it
has
been
proposed
before
what
the
feedback
on
that
wasn't
trying
to
use
that
to
to
vet
your
idea
some
more
and
decide
if
you
want
to
move
to
the
next
stages.
B
If
you
do
that
and
you're
happy
with
your
idea,
and
you
think
that
there's
a
need
and
the
desire
opportunity
to
have
this
idea,
then
you
can
move
on
and
actually
write
a
specification
and
in
this
draft
format
it
doesn't
need
to
be
perfect,
but
it
needs
to
embody
the
idea
enough
of
a
way
that
it's
a
good
reference
point
for
people
to
get
feedback
on,
and
that's
going
to.
Let
you
move
like
this
next
stage
of
iteration.
B
Once
you
have
your
draft
in
that
format,
then
you
would
want
to
submit
a
pull
request
to
the
eavs
repository
and
the
editors
will
take
a
look
at
it
and
make
sure
that
it
meets
the
criteria
for
being
a
draft
deep
and
the
criteria
is,
is
all
listed
in
the
e1,
but
it's
generally
like
does
it?
Is
it
syntactically,
correct
or
is
the
information
that
needs
to
be
there
included
in
the
eep
and
these
sorts
of
things
they
might
give
some
some
technical
technical
feedback
on
it?
B
Then
you
can
motion
for
it
to
be
final,
and
it's
important
to
note
that
this
final
state
is
really
just
a
statement
of
the
eep
itself.
It's
not
a
statement
of
will
it
be
included
in
an
upcoming
network
upgrade
or
anything.
It's
really
just
saying
that
this
eve
has
been
looked
at
by
people
from
the
community.
B
B
Then
we
have
the
editors
who
you
know
are
probably
the
most
formally
defined
role
in
the
process.
The
editors
are
listed
in
each
one
and
their
role
is
generally
to
facilitate
the
the
process
and
to
make
sure
that
the
eaves
that
are
going
are
properly
following
the
process
and
that
they're
syntactically
correct.
They
are
filling
up
the
correct
structure
of
the
eaps,
and
sometimes
they
give
technical
advice
to
eep.
B
So
they
try
to
help
people
determine
if
their
eep
is
like
is
really
actually
a
good
idea
to
be
a
neighborhood
doesn't
necessarily
need
to
be
one.
I
think
that
a
lot
of
people
put
too
much
pressure
on
editors
to
give
technical
feedback,
and
I
think
that
it's
not
necessarily
the
editor's
job.
I
think
it's
the
community's
job
as
a
whole
to
really
help
provide
technical
feedback.
So
it's
not
it's
not
reasonable.
B
These
are
the
people
who
are
maintaining
clients
and
have
a
really
good
understanding
of
what's
feasible
and
what's
not
feasible
with
the
core
protocol,
and
so,
although
their
time
is
incredibly
limited,
if
you
can
get
them
involved
and
even
get
some
feedback
from
them
early
on,
they
can
help
save
a
lot
of
time.
And
you
can
understand
you
know
from
their
experience.
What
may
or
may
not
be
possible.
B
B
So
now
I
just
want
to
go
through
just
a
few
examples
of
things
that
might
make
a
good
ethan
or
some
things
that
may
not
be
as
eapable,
and
the
first
example
is
an
eep
that
could
introduce
an
op
code
which
returns
the
sender's
nonce.
This
is
definitely
a
standards
track
core
e,
because
it's
modifying
the
evm.
This
is
something
that
you
would
want
to
do
a
network
upgrade
to
achieve
it.
You
know
it's
up
for
debate.
B
B
Another
example
is
something
that
would
reduce
gas
costs
of
call
data.
This
is
this
is
something
that's
been
done
in
the
past
and
is
obviously
a
good
example
of
you
know
when
you
want
to
do
an
eve,
if
you
think
that
something
is
overpriced
in
the
ethereum
gas
schedule,
and
you
can
explain
and
get
some
rash
now
why
you
think
it
is
then.
B
You
know
it
obviously
has
an
interface
that
your
dap
is
using,
but
unless
a
lot
of
other
contracts
on
the
network
need
to
interoperate
with
your
gaming
contractor,
more
of
your
gaming
contracts
will
be
deployed
with
the
same
interface.
It's
really
unlikely
that
you
need
to
standardize
this.
This
is
something
that
you
would
want
to
standardize
for
your
own
purposes,
but
it
doesn't
provide
utility
to
the
community
as
a
whole.
B
As
an
informational
eep,
I
think
that
explaining
some
of
the
gotchas
about
client
development
will
be
really
valuable
and
I
think
the
go
ethereum
team
does
a
great
job
on
their
pull
requests
and
they've
recently
written
a
blog
post
about
this
exact
topic
about
how
to
officially
represent
the
state
database
on
disk,
and
I
think
that
this
were
these
sorts
of
things
would
be
very
valuable
to
write
in
in
format
and
save
for
posterity
for
the
future
and
for
future
client
developers
to
understand
and
see.
So.
B
I
think
this
is
a
really
good
example
of
an
informational
type
of
because
it
provides
utility
to
to
the
community
the
protocol
as
a
whole
a
lot.
The
last
example
I
have
that
I
don't
think
is
a
good
example
of
an
epis.
If
you
have,
if
you've
released
some
sort
of
dow-
and
you
want
to
give
an
update
to
the
community
on
the
status
of
your
dow,
I
don't
think
that's
a
a
good
example.
Even
if
your
dao
is
completely
decentralized
and
open
to
anyone.
B
It's
unlikely
that
the
community
as
a
whole
is
interested
in
your
specific
now,
and
so
you
wouldn't
it's
not
providing
utility
to
the
community
as
a
whole
to
provide
information
about
the
specific
dialogue
update.
You
would
want
to
do
that
through
whatever
channels
you've
built
with
your
community,
whether
that's
like
twitter
or
a
blog
or
something
the
ips
repository,
is
not
a
great
place
for
that
to
occur.
B
B
It
defines
how
to
write
trees
like
what
should
be
in
each
section
what
the
process,
what
the
stages
are-
and
you
know,
a
lot
of
the
stuff
that
I've
pretty
much
everything
that
I've
talked
about
in
this
presentation
is
written
explicitly
in
e1,
and
so
it's
important
that,
if
you're
going
to
write
me
to
go
through
this,
you
can
read
it
several
times
and
understand
what
what
what
needs
to
be
done
to
get
it
to
a
certain
state.
That's
going
to
alleviate
a
lot
of
a
lot
of
back
and
forth.
B
That's
going
to
need
to
happen
between
you
and
editors
who
are
required
to
make
sure
that
you
conform
to
that
that
standard.
That's
specified
I'll,
see
a
lot
of
spelling
and
grammatical
errors,
and
we
have
tools
in
the
repository
to
help
alleviate
this
sorts
of
stuff.
But
I
think
that
this,
these
errors
just
come
from.
B
And
people
take
the
time
to
actually
go
through
it
and
double
check
their
work
before
submitting
it.
I
also
see
people
avoiding
community
feedback.
This
is
something
that's
that's
critical
to
have
from
the
idea
stage.
All
the
way
to
the
last
call,
you
can't
write
an
eep
at
a
fan
in
your
own
box.
You
need
to
receive
feedback
and
iterate
on
it.
So
it's
really
unlikely
that
you're
going
to
know
everything
that
needs
to
be
done.
It's
unlikely
that
you,
your
point
of
view,
is
the
point
of
view
held
by
everyone
in
the
community.
B
Both
sections
are
really
important
in
the
motivation.
Section
is
extremely
important
to
to
show
why
it
should
exist,
but
there's
a
specific
section
for
it.
I
don't
think
that
the
abstract
is
necessarily
where
a
lot
of
that
should
live
like
the
gaming
contract.
I
see
a
lot
of
eaps
that
are
focused
on
these
single
use
cases.
I
don't
know
if
it's
people
who
just
want
to
write
an
ease
to
write
an
eep
or
they
want
some
sort
of
prestige
associated
with
a
heaps
number.
But
writing
you
prefer
a
single
use
case.
B
That's
not
going
to
provide
utility
and
interoperability
for
the
community
is,
is
not
useful
and
the
last
common
mistake
that
I
see
a
lot
is
people
who
just
abandoned
work.
I
think
there's
been
some
pretty
high
profile
leaps
where
the
author
has
written
some
sort
of
sensational
leap,
they've
drafted
it
and
they've
never
kind
of
come
back
to
actually
merge
it
in
and
and
take
the
feedback
of
the
editors
have
given
them
and
and
integrate
that
into
their
work.
B
B
So
if
you
want
to
get
involved
the
place
where
privilege
often
egg
is
on
github
at
the
eaps
repo
under
the
ethereum
organization.
This
is
where
you
can
see
the
raw
version
of
all
the
eeps
in
their
markdown
format,
and
you
can
split
your
pull
request
to
include
your
own
eaps
there's,
also
a
discussion
forum
eastmagician.org.
B
So
if
you're
interested
in
following
the
discussions
around
eve,
so
this
is
generally
where
those
take
place.
If
you're
interested
in
following
a
discussion
for
a
specific
heap,
I
would
recommend
taking
a
look
at
that
eve
and
then
seeing
where
it's
discussion
two
is
pointed
to
most
the
time
it's
an
ethereum
magician's
thread,
but
sometimes
it
could
be
a
github
issue
or
something
else.
B
That's
all
I
had
for
the
presentation.
I'm
really
excited
to
see
more
people
get
involved
with
the
e-process.
I
think
it's
an
incredibly
important
process
in
the
ethereum
community
and
so
the
more
people
that
we
have
involved
and
I
think
the
higher
the
quality
the
eaps
will
be.
Therefore,
the
higher
the
quality
our
protocol
is
going
to
be.
C
D
D
D
A
C
A
Right
so
when
we
submit
a
pull
request
in
the
eip
github
repo,
sometimes
we
see
a
green
check.
Sometimes
it
is
a
red
mark
that
that
is
easily
visible.
So
my
understanding
is
that's
because
of
validated
bot,
so
I
would
love
to
hear
more
about
how
people
can
get
past
they
bought.
I
remember
encountering
such
issue
myself
for
an
example
like
when
we
submit
a
pull
request.
The
ap
one
suggests
that
we
should
not
be
entering
the
eip
number.
A
D
A
All
right,
thank
you.
Another
question
is
related
to
these
kind
of
stuff.
Only
when
we
talk
about
informational
and
meta
e,
as
explained
in
one
of
the
earlier
slides
about
the
you
know,
parameters
that
we
should
consider,
I
think
security
concentration
and
test
cases
may
not
be
valid
for
those
kind
of
needs.
So
when
we,
you
know
create
informational
or
meta.
If
we,
if
we
remove
these
sections,
do
you
think
it
is
the
right
one
or
do
we
have
different
template
for
different
eve.
D
Oh,
I
think
once
you
get
out
out
of
the
technical
leaps
into
those
all
bets
are
off
and
even
in
the
more
technical
ones
you
you
can
violate
the
structure.
If
there's
a
reason
to,
and
then
the
editors
will
argue
about
it
a
little
bit
and
from
my
point
of
view,
if
the
thing
makes
sense
and
you
can
implement
it,
I'm
not
too
worried
that
if
it's
just
information
presented
this,
as
is
appropriate
for
the
information.
C
Matt,
maybe
if
I
could
comment
on
a
little
bit
of
the
presentation
you
mentioned
problems
with
spelling
and
grammar,
occasionally
I've.
No,
I
definitely
am
no
expert
on
the
ip
repository
itself,
but
I'm
wondering
is
some
of
that,
possibly
just
a
language
barrier,
and
I
mean
to
make
that
a
more
practical
question.
Someone
who
does
not
speak
english
is
the
first
language
may
have
limited
faculty
in
english.
B
Yeah,
I
mean
that's
a
good
point
and
I
definitely
think
that
part
of
it
is
that
the
you
know
the
each
repository
is
mainly
an
english
repository,
I
think,
all
in
english
repository
and
so
people
who
don't
speak
english
as
their
first
language,
it's
hard
for
them
to
construct
really
good
grammatically,
correct
eeps.
I
don't
know
if
I
have
a
good
solution
for
you
know
this
sorts
of
things.
I
would
be
curious
to
know
how
other
standards
organizations
work.
B
B
I
think
that
this
is
a
role
that
editors
can
help
in
or
that
champions
can
help
in
and
find
people
who
you
know
do
speak
the
language
of
the
eeps
repository.
Currently,
if
it's
in
I
you
know
my
my
point
of
view
is
that
if
it's
an
important
eep,
even
if
you
don't
speak
english,
we
can
find
people
who
care
about
this
heap
and
can
champion
it,
and
you
know
get
it
to
a
place
where
it
is
grammatically.
Correct
and
it's
you
know
very
readable
for
for
people
who
are
implementing
it.
C
I
hear
that
it
made
me
think
also
that
it
would
seem
to
me
that
there's
really
an
importance
in
trying
to
build
up
a
bit
of
a
community
around
an
heap,
which
is
something
that
I
think
we've
been
seeing
a
bit
more
of
I
mean
it
would
prevent
author
champion
burn
out
to
a
certain
degree.
It
would
probably
also
ensure
a
certain
amount
of
resource
into
making
sure
the
iep
can
actually
clear
the
various
hurdles
that
it
needs
to
clear.
Do
you
have
any
particular
thoughts
about
community
building
around
eips.
B
Yeah,
I
have
been
thinking
about
this
a
lot
because
you
know
a
lot
of
my
frustrations.
The
things
that
I
see
that
are,
you
know
not
going
as
well
for
the
youth
repositories.
I
think
they
could
be
is
exactly
what
you
said.
It's
to
me
due
to
a
lack
of
community
and
I
feel
like
there's,
you
know
a
lack
of
a
lack
of
ownership
and
a
lack
of
accountability
that
exists
there
and
one
potential
solution
that
I've
been
thinking
about.
B
And
so
I
think
that
if
we
have
some
working
groups
who
kind
of
own
the
concept
of
the
evm
or
working
groups
who
own
the
you
know,
interface
layer
of
ethereum
they're,
going
to
be
able
to
help
inbound
eeps
and
give
feedback
to
them
and
they're
going
to
be
able
to
set
goals
for
their
group
and
to
set,
like
you
know,
have
general
ideas
of
eeps
that
they
want
to
author
or
they
want
to
help
find
people
or
you
know,
navigate
incoming
resources
to
to
work
on.
So
to
me.
B
B
B
A
Another
question
I
may
have
for
you
matt
related
to
the
good
example
and
bad
example
of
heaps
that
was
shown
in
one
of
these
slides
today.
So
when
we
say
that
if
an
eep
is
only
specific
to
a
single
use
case,
just
for
example,
the
game
use
case
that
you
have
mentioned.
So
those
are
not
a
good
example
of
eeps.
So
when
we
say
that
what
does
that
mean
those
eats
are
rejected
and
if
they
are
like,
how
do
we
do
that?
A
B
I
think
eep
one
will
pretty
clearly
lay
out
the
things
that
might
be
eatable
and
if
there's
some
gray
area,
I
think
generally,
you
know
when
there's
gray
area
people
and
editors
and
greg
can
jump
in
and
you
know
share
his
opinion,
but
I
think
there's
some
gray
area
that
people
are
pretty
willing
to
hear
why
you
might
think
it's
beepable
and
you
know
if
it's
pretty
cut
and
dry,
it's
a
very
specific
use
case.
It's
not
adding
utility.
D
Editors
vary
and
we'll
talk
some,
but
generally
we
we
actually
don't
want
to
question
the
content.
All
that
much.
We
don't
we've
gotten
in
some
bad
political
situations
before
and
so
we're
more
inclined
to
just
merge
it
if
it
meets
the
formal
requirements
and
leave
it
to
the
rest
of
the
process.
It'll
most
of
those
will
die
on
the
vine.