►
From YouTube: Peep an EIP #11: EIP-2718 with Micah Zoltu
Description
EIP: https://eips.ethereum.org/EIPS/eip-2718
Discussion: https://ethereum-magicians.org/t/eip-2718-typed-transaction-envelope/4355
Follow at Twitter:
James Hancock @JHancock | Lightclient @lightclients | Pooja Ranjan @poojaranjan19 | William Schwab @William94029369
Check out other exciting EIPs in Peep an EIP: 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
Today
we
are
going
to
learn
about
eib
2718
type
transaction
envelope
and
our
guest
is
michael
jordan,
who
is
also
the
author
of
this
proposal
and
one
of
the
eip
editors
of
eip
repository.
We
are
also
joined
by
james.
The
hardware
coordinator,
like
client,
and
our
cad
headers
member,
jim,
brent
and
william
eap2718
is
standard
track
core
eip
that
was
proposed
in
june
this
year
and
according
to
summary,
provided
in
the
proposal,
it
is
defined
as
a
new
transaction
type
that
is
an
envelope
for
future
transaction
types
to
be
more
specific
for
eip1559
transaction
type.
A
So
this
proposal
is
added
in
the
list
for
yellow
v3,
which
is
at
the
moment,
is
eips
considered
for
berlin
without
further
a
delay.
Let
me
welcome
micah
micah.
Thank
you
for
joining
us
today.
Please.
Let
us
know
something
about
you,
your
engagement
with
the
game
community,
and
then
we
will
get
into
the
proposal.
B
B
B
B
The
reason
for
that
is,
I
want
to
make
ethereum
better,
because
I'm
a
firm
believer
in
the
project
and
as
a
whole,
and
so
I
of
course
have
opinions
on
everything.
My
background
is
in
software
engineering.
I've
been
doing
software,
for
I
don't
know
almost
20
years
now,
maybe
god
that
makes
me
sound,
so
old,
so
yeah.
B
The
data
field
was
kind
of
overloaded
to
be
used
for
contracts,
and
so
when
you
wanted
to
call
a
contract,
you'd
put
send
some
data
along
with
it,
and
the
contract
would
interpret
what
that
data
means
over
time.
Eventually,
solidity
gained
prominence,
and
now,
basically
everything
in
ethereum
interprets
the
the
data
field.
The
the
way
solidity
interprets
it,
because
everything
is
all
just
about
everything
is
a
silly
contract.
B
The
other
thing
that
data
field
is
used
for
is
for
deploying
transactions,
and
so
when
you
send
a
transaction
and
you
want
to
deploy
a
new
sorry,
we're
deploying
contracts.
So
when
you
want
to
deploy
a
new
contract,
you
would
fill
the
data
field
with
some
code
that
you
want
to
be
executed
on
chain
and
then
at
the
end
of
that
that
will
return
the
contract
that
you
want
to
want
to
deploy.
B
And
then,
when
you
do,
that,
you'd
send
it
to
the
address
the
address,
zero
and
that's
your
destination,
because
there's
no
recipient
you're,
not
sending
it
to
anything,
and
so
it
kind
of
special
cases
that
and
so
even
from
the
beginning,
as
you
can
see,
there,
we've
kind
of
had
two
transactions
they're,
just
both
overloaded,
the
same
set
of
fields.
So
we
had
the
two
field
and
if
the
two
field
was
zero,
then
it
means
that
this
is
a
contract
deploy
and
we
should
interpret
the
data
field
a
certain
way.
B
And
if
the
two
field
was
not
zero,
then
the
data
field
should
be
interpreted
interpreted
differently,
but
because
both
of
these
used
the
same
kind
of
size
and
order
of
fields,
we
were
able
to
kind
of
smash
them
together
and
just
have
one
transaction
type
and
one
signature
type.
So
when
you
sign
a
transaction,
you
sign
it
in
this
particular
way
and
everybody
signs
the
transaction
the
same
way
and
gas
is
paid
the
same
way
for
all
of
them,
and
so
it
generally
has
worked
overtime.
B
However,
we
have
found
more
and
more
needs
here
and
there
for
wanting
other
things
in
a
transaction.
We
first
saw
this
in
eip-155,
remember
quickly,
which
was
the
I
actually
can
show
you
here
so
eip155,
which
was
simple
replay,
attack
protection
and
for
those
of
you
that
have
looked
at
this,
it's
this
kind
of
complicated
bit
munching
thing
we
do
where
we
make
it
so
a
transaction
that
is
destined
for
ethereum
mainnet
will
not
work
on
ethereum,
classic
or
ethereum
test
nets
like
roxton
or
kovin,
or
vice
versa.
B
If
it's
a
number
that's
27
or
28,
then
you
interpret
a
different
way,
and
so
this
is
unfortunate
because
for
developers
who
are
trying
to
integrate
with
ethereum,
you
now
need
to
have
this
weird
logic
where
you
have
to
look
at
the
transaction
and
look
at
the
different
fields
and
say:
okay,
if
the
two
field
is
zero,
then
we
interpret
it
this
way.
If
the
two
field
is
not
zero
interpret
this
other
way.
B
C
A
B
So
it's
yeah,
so
that's
a
it's!
It
is
software
enforce.
So
this
is
this
all
is
consensus,
and
so,
if
the
two
field
is
zero,
then
all
the
different
clients
do
need
to
interpret
the
data
field
as
a
contract
deployment,
and
they
need
to
execute
it
in
a
certain
way,
because
every
every
client
in
ethereum
acts
in
lockstep
with
each
other,
which
means
that
they
all
need
to
make
sure
they
make
the
exact
same
changes
at
the
exact
same
time.
B
At
the
time
it
was
just
the
easiest
thing
for
humans
to
do
so,
rather
than
trying
to
introduce
a
new
transaction
type
back
when
eip155
was
around,
it
was
decided
that
you
know
that
that
sounds
complicated.
Let's
just
agree:
let's
just
all
agree:
all
the
clients
will
all
agree
to
interpret
the
v
field
differently
from
here
on
out,
and
so
that
was
the
hard
fork
the
155
was
included
in
was
a
consensus
change
hard
fork
because
all
the
clients
needed
to
agree.
Okay.
B
C
B
Even
if
we
introduced
two
seven
one,
eight
one,
five
five,
the
code
for
155
will
still
live
on,
and
every
single
new
client
will
need
to
understand
it,
and
most
likely
most
apps
will
also
need
to
understand
it,
and
most
tools
will
need
to
understand
it.
So
introducing
2718,
which
we'll
get
into
in
a
minute,
doesn't
actually
resolve
that
problem
of
all
these
people
now
needing
to
understand
all
those
idiosyncrasies,
it's
more
about
preventing
new
idiosyncrasies
from
being
introduced.
That
add
even
more
complexity,
so
we
want
it.
B
B
All
of
these
will
introduce
new
transaction
types
and
when
they
do
we
don't
we
want
to
minimize
the
the
long-term
damage
they
do
in
terms
of
the
complexity
for
new
developers
entering
the
ecosystem.
So
when
someone
shows
up
in
five
or
ten
years
and
they
want
to
develop
for
ethereum,
we
don't
want
them
to
have
to
deal
with.
You
know:
okay,
here's,
the
4
000
different
little
things
we
tacked
on
to
a
transaction
and
the
772
different
ways
that
you
need
to
interpret
these
different
fields
depending
on
what
this
number
is.
B
Okay,
so,
if
so
transaction,
if
the
two
field
is
this,
that
means
this
and
then
oh
we've
run
out
of
places.
We
can
jam
stuff
in
there.
So
now
we're
gonna
start
saying:
if
the
gas
is
zero,
then
that
means
these
other
fields
mean
these
other
things.
We
want
to
avoid
that.
We
can't
undo
the
past
in
ethereum,
unfortunately,
but.
E
B
Yes,
that
is
correct
so
that
that
choice
in
155,
which
I
I
I
will
not
say
that
the
choice
was
wrong
at
the
time
it
made
sense
at
the
time
and
right,
but
to
a
certain
extent,
yeah
exactly
it
will
live
with
us
forever.
There
are
some
again
as
a
slight
tangent.
There
are
some
proposals
of
mechanisms
for
kind
of
getting
rid
of
old
ethereum
choices.
Those
ones
are
kind
of
very
future.
Looking,
though,
don't
expect
them
anytime
soon,
things
like
regenesis
or
minting
a
new
genesis
block
in
general
would
maybe.
B
The
idea
here
is
to
create
a
new,
a
mechanism
whereby
we
can
introduce
new
transaction
types
in
the
future
without
having
to
try
to
jam
them
all
together,
yet
having
a
consistent
mechanism
of
identifying
what
those
different
transaction
types
are.
And
so,
as
I
mentioned
a
moment
ago,
we
have
one
five,
five,
nine.
We
have
two
seven
one
one.
We
have
29
30
and
several
others
that
all
kind
of
propose
to
introduce
new
transaction
types,
and
so
we
would
rather
have
a
consistent
story
for
all
of
them
and
be
able
to
say
okay.
B
This
is
how
you
identify
what
type
of
transaction.
It
is
so
that
you
know
how
to
interpret
the
data,
because
over
the
wire,
when
clients
are
communicating
with
each
other
over
a
gossip
network,
they're
just
sending
bytes
to
each
other,
and
so
they
need
to
agree
in
advance
what
how
those
bytes
are
structured
and
what
they
mean.
And
so,
when
someone
receives
a
list
of
transactions,
they
need
to
know
how
to
interpret
that
list,
and
so
the
idea
with
2718
is
to
give
a
consistent
way
to
interpret
that
and
now.
B
Finally,
here
the
the
way
to
do
that
is
the
very
first
byte
of
a
transaction
will
represent
the
transaction
type,
which
means
we
have
not
quite
255
we'll
get
into
why
not
down
below,
but
you
can
for
now.
We
can
just
say
we
have,
let's
say
over
128
transaction
types,
which,
given
the
rate
at
which
we
introduced
new
transactions.
B
All
the
clients
still
need
to
agree
on
it,
but
now
we'll
at
least
have
a
consistent
way
of
of
interpreting
it
and
presenting
that
when
they're
gossiping,
so
when
you're
gasping
with
each
other-
and
you
send
a
big
bucket
of
bytes-
and
you
say:
hey
here's
a
list
of
transactions-
someone
can
knows
how
to
iterate
through
those
those
those
bytes
and
say.
Okay,
this
first
byte
says
it's
type
zero,
and
so
that
means
I
interpret
the
next
n
bytes
in
this
particular
way.
Or
it
says,
oh
this
next,
this
this
byte
first
byte
is
seven.
B
B
It's
it's
hard
to
explain
where
this
complexity
comes
from.
Just
just
know
that
the
if
it's
harder
to
explain
in
human
words,
it's
probably
hard
to
explain
to
a
computer
as
well,
and
so,
if
it's
easy
for
me
to
say
oh
if
that
first
byte
is
five,
then
this
is
how
you
interpret
it.
It's
harder
for
me
to
say
if
the
first
byte
is
five
and
the
second
byte
is
seven
and
this
the
third
byte
is
divided
by
divisible
by
three,
then
do
that.
B
So
the
that's
pretty
much
all
27
18
is
really
it's
just
a
mechanism
for
describing
how
transactions,
how
you
identify
the
mechanism
to
interpret
the
bytes
of
a
transaction
as
part
of
that,
we
also
need
to
deal
with
receipts.
So
for
those
of
you
that
aren't
deep
in
ethereum
a
transaction
receipt
is
a
piece
of
data
that
all
the
clients
agree
on.
So
it's
part
of
consensus
and
they
they
all
agree
that
this
is
a
high
level
overview
of
what
happened
in
a
transaction.
B
And
so
when
a
transaction
happens,
a
receipt
is
generated.
All
the
clients
generate
a
receipt
and
that
receipt
is
they
all
generate
separately
because
they're
acting
in
lock
steps
they'll
do
the
same
thing
at
the
same
time
and
then,
when
the
block
is
passed
around,
they
all
look
at
that
and
they
say:
oh
yep,
I
got
that
same
number,
oh
yep.
I
got
that
same
number,
oh
yeah.
I
got
that
same
number
and
so
that's
the
receipt,
and
so
we
need
to
make
sure
that
they
all
generate
their
seats.
B
The
same
and
so,
and
we
want
to
change
the
receipt,
because
future
transactions
may
also
have
a
new
receipt
type
so
currently
for
transactions.
The
receipt
contains
a
status
and
a
cumulative
gas
used,
bloom
logs
boom
and
a
logs
array.
I
believe
I'll
check
that,
but
I'm
pretty
sure
this
is
just
an
array
of
logs
in
the
future.
We
might
have
a
transaction
type
that
will
never
generate
logs,
and
so
we
don't
necessarily
need
this.
The
logs
bloom
or
the
logs.
B
We
can
just
save
some
bytes
by
not
including
them
or
maybe
in
the
future.
We'll
have
a
transaction
type
that
does
batch
transactions,
which
case
the
receipt
may
become
more
complex
because
there's
multiple
transactions
that
all
need
receipts,
since
you
need
like
an
array
of
receipts,
and
so
because
of
that
we
want
to
make
it
so
the
receipt
can
iterate
along
with
the
transaction
and
it
works
basically
the
same
way.
The
the
transaction
type
is
the
first
byte,
and
that
tells
you
how
to
interpret
the
rest
of
the
receipt.
B
Along
yeah,
it's
great
excellent,
so
getting
into
the
rationale
section
so
for
those
of
you
that
aren't
deep
into
eip,
editing
eips
contains
several
sections:
we've
got
the
abstract
the
simple
summary
which
are
kind
of
self-explanatory.
We
won't
go
into
them
today.
Motivation
talks
about
why
we
want
to
do
this
specification
talks
about
the
very
technical
details
of
this
is
what
this
specification
does.
The
rationale
section
is
used
for
describing
why
certain
choices
were
made
within
a
transaction.
B
If
you
don't
do
a
must,
then
you
will
be
kicked
out
like
you
would
not
none
of
the
other
clients
will
talk
to
you,
they'll
all,
stop
talking
to
you
because
you're
doing
it
wrong.
If
something
is
a
should,
though,
it's
saying
really
the
authors
of
this
eip
really
think
you
should
do
this
thing.
It's
a
good
idea,
but
if
you
don't
do
it
you're
not
technically
wrong
like
it's
it's.
B
We
really
think
this
is
a
good
idea,
but
maybe
it's
okay,
if
you're,
if
you
don't
and
usually
it's
used,
if
there's
certain
situations
that
we
know
exist
that
are
like
well,
we
know
there
will
be
a
time
when
this
is
not
true
and
we
want
to
make
it.
So
that's,
okay,
but
we
really
still
would
rather
people
not
do
them.
B
So
this
is
one
one
example
of
that,
and
so
the
we
recommend,
using
the
should
wording
that
future
transaction
types
should
include
the
first
byte
in
the
data
that
they
sign,
so
so
when
they
sign
something
this
transaction
type.
So
let's
say
I
go
saying
this
is
just
a
single
byte,
it's
a
number.
If
we've
got,
I
create
a
new
ip
eip
and
I
introduced
new
transaction
type
and
it's
type
seven.
B
B
This
introduces
a
whole
new
attack,
surface
area
and
in
fact
this
is
part
of
the
reason
that
some
of
the
the
complexity
is
introduced
when
we
have
the
new
transaction
types
because
we
don't
want
to
make
it
so
if
you
send
a
transaction,
it
could
be
interpreted
as
one
of
two
different
things,
specifically
the
stuff
that's
signed.
So
if
you
say
imagine
if
you
signed
a
piece
of
paper
and
there
was
a
little
spot
on
it,
that
was
left
blank
and
someone
could
fill
it
in
with
one
of
two
words
and
your
signature
is
valid.
B
The
thing
you
signed
is
the
thing
that
someone
interpreted
as,
and
so
we
want
to
be
careful
of
that,
and
so
if
we
have
two
transactions
that
are
pretty
close
to
each
other
again
remember
just
just
bytes
and
a
wire.
We
want
to
make
sure
that
if
someone
signs
a
set
of
bytes
that
someone
else
can't
submit
that
bytes
to
the
network
and
have
them
interpret
it
a
different
way,
and
so
by
signing
that
transaction
type
byte
as
the
first
byte,
we
give
pretty
strong
guarantees.
In
fact,
I
believe,
hard
guarantees.
B
Yeah,
that's
pretty
that
this
trans.
This
transaction
cannot
be
interpreted
in
two
different
ways
like
that.
If
you
have
a
signature
of
this,
you
can't
interpret
it
some
other
way,
because
each
transaction
type
is
interpreted
one
very
specific
way,
and
each
transaction
type
has
its
own
number
transaction
type
number
and
so
they're
guaranteed
to
be
different.
B
This
sounds
like
something
that
should
be
a
must
like
we
should.
We
should
have
hard
guarantees
that
we
must
do
this
thing,
but
we
don't.
The
reason
for
that
is
is
because
we're
not
starting
from
zero
we're,
not
starting
from
a
clean
slate,
where
we
can
say
that
all
transactions
ever
will
follow
this
rule,
because
we've
been
going
for
four
or
six
or
however
many
years.
B
It's
been
now
with
transactions
that
do
not
follow
these
new
rules
and
we
want
to
make
sure
those
transactions
are
still
valid,
because
we
have
existing
tools
that
are
out
there.
We
have
hardware
wallets,
we
have
offline,
wallets
people
who
have
wallets.
You
know
that
are
on
computers
that
have
never
connected
the
internet
and
they
don't
want
to
ever
connect
to
the
internet.
We
have
hardware
wallets
like
ledger
or
the
trezor,
and
they
have
signing
built
into
them.
B
B
We
could
say:
okay
well,
if
you're
a
legacy
transaction
which
doesn't
actually
use
a
transaction
type
at
all,
then
you're,
okay
to
sign
a
different
way,
but
what
we
want
is
we
want
to
eventually
make
it
so
legacy
transactions
are
now
also
type
transactions,
and
so
they
follow
the
same
typing
system
to
try
to
get
rid
of
a
little
bit
of
that
kind
of
legacy.
Code.
B
Like
I
said
before,
we
can't
delete
any
code,
but
we
can
at
least
make
it
so
new
tools
who
are
only
working
with
new
transactions,
particularly
like
application
developers
or
javascript
library
developers.
We
can
try
to
make
it
so,
at
least
they
don't
have
to
deal
with
the
old
stuff.
So
ethereum
clients
always
have
deal
field
stuff,
but
some
of
the
other
things
on
the
edges
might
we
might
be
able
to
get
to
a
place
where
they
don't
have
to
deal
the
old
stuff,
and
so
we
want
to
turn
the
old
transaction
types.
B
The
stuff
that
we've
been
signing
for
years
want
to
make.
So
you
can
still
sign
them
using
the
same
tools
like
hardware
wallets,
offline,
wallets
stuff
like
that
or
and
also
you
know,
have
signatures
that.
Maybe
you
generated
a
signature
four
years
ago
and
you
wrote
the
signature
down
and
put
it
laminated.
B
It
buried
it
under
your
house,
and
you
know
in
30
years
you
plan
on
demolishing
your
house
and
digging
it
up,
and
so
you
want
to
make
sure
that
transaction
signature
is
still
valid
for
those
people,
but
we
want
to
make
it
so
when
we're
communicating
about
that
transaction
over
the
gossip
network-
and
you
know
just
in
general-
the
tools
are
dealing
with
it.
They
don't
have
to
deal
with
the
that
old
kind
of
old
code
so
because
we
want
to
make
those
signatures
still
valid
and
we
want
to
have
them
have
a
transaction
type.
B
Let's
see,
we've
got
so
this
one
actually
came
out
very
recently,
so
I'll
be
quick
on
this
one,
because
it's
pretty
technical-
and
I
don't
know
okay,
so
I'll-
be
semi-quick
on
this
one.
So,
historically,
all
transactions
have
been
encoded
with
rlp,
which
is
a
particular
encoding
scheme
for
encoding
bytes
when
you're
ready,
transfer
transport
them
over
the
wire.
There's
lots
of
different
encoding
schemes
on
the
internet
for
encoding
data.
Rlp
is
one
of
them
that
ethereum
uses.
B
So
originally
we
actually
said
that
the
transaction
type
instead
of
concatenating
the
transaction,
the
transaction
bytes.
I'm
sorry
up
here
on
the
end
of
the
transaction
type,
so
you'd
have
the
first
byte
is
the
transaction
type
and
then
you'd
have
just
all
the
other
bytes
after
that
are
the
transaction
itself.
B
However,
we
want
in
the
future
part
part
of
this
is
we
want
to.
We
want
this
eip
to
make
it
possible
to
introduce
new
transaction
types
that
may
be
formatted
differently
and
that
formatting
could
include
different
encodings
eth2,
for
example,
is
likely
to
use
ssz
encoding
instead
of
rlp
for
a
lot
of
its
stuff,
and
so
there
might
be
a
situation
in
the
future
where
we
need
a
transaction
type
and
ethereum.
B
That
would
really
make
a
lot
more
sense
if
it
was
ssc
encoded
or
maybe
we
get
benefits
for
ssd
encoding.
I
think
there's
some
merklization
benefits
that
I'm
not
super
familiar
with
with
ssd
encoding
that
we
may
be
able
to
benefit
from
in
the
future,
and
so
rather
than
we
still.
We
still
could
do
that.
We
could
still
have
the
an
rlp
wrapper
and
then
ssz
inside
of
that,
but
we
want
to
make
it
so.
B
B
Sorry
got
distracted
now
we
want
to
make
it
so
that
if,
in
the
future
we
switch
to
ssd
for
a
bunch
of
stuff
we're
not
stuck
forever
with
rlp
now
you
could
just
say.
Well
I
mean
you
have
to
choose
between
rlp
or
truncation,
which
truncates
what
we're
doing
either
way
you're
encoding
something
the
advantage
of
truncation
is
truncation
is
really
really
easy.
You
don't
even
need
a
library
to
decode
it.
B
So
when
you're
decoding,
when
you're
decoding
a
thing
like
an
array
of
bytes,
it's
very
easy
in
every
language
that
I
know
of
to
just
strip
off
the
first
byte,
read
it
and
then
read
the
rest
of
the
bytes
separately
like
that
is
a
simple
thing
to
do.
You
don't
need
any
special
decoder.
You
don't
need
any
special
software.
You
can
do
it
with
a
human
can
do
with
their
eyeballs
like
this.
B
Is
so
trivially
easy
to
do
everywhere
that
you
it
you
don't
need
to
really
think
about
it
like
it
doesn't
take
even
a
second
thought
to
figure
out
how
to
do
it.
Like
everybody
who
has
been
software
engineering
for
a
while
knows
how
to
do
this.
Naturally,
like
it's,
it's
a
very
simple
thing:
rlp,
on
the
other
hand,
well
it's
a
fairly
simple
encoder
encoding
mechanism.
B
You
do
need
a
library
to
decode
stuff
like
it's
complicated
enough
and
it's
it's
variable
length
which
means
like
okay,
so
you
read
the
first
byte
and
if
the
first
byte
is
in
this
range
of
numbers,
then
you
need
to
read
the
next
n
bytes
in
a
specific
way.
Whereas
if
it's
in
this
other
range
numbers,
then
the
next
n
bytes
means
something
different,
and
so
it
becomes
complicated
to
read
rlp
complicated
enough
that
you
almost
always
are
going
to
want
to
use
a
library
for
it.
B
If,
in
the
future,
we
move
to
sse
in
a
lot
of
places,
we,
it
might
be
that
some
places
don't
actually
need
to
understand
our
rlp
at
all
like
right.
Now
there
are
application
developers
out
there
who
are
developing
for
ethereum,
who
don't
know
rlp.
There
are
also
application
developers
who
know
rllp
only
because
they
need
to
know
it,
so
they
can
encode
a
transaction
like
that's
the
only
reason
they
need
to
know
it.
B
B
If
ssz
is
the
encoding
internally,
we
don't
want
to
have
to
have
every
li
every
author
either
learn
how
to
do
rlp
stuff
or
find
the
library
for
rlp
just
so
they
can
decode.
You
know
those
two
items
like
we
want
to
avoid
that,
and
so
that's
why
we're
going
with
a
not
using
rlp
and
instead
using
concatenation,
and
actually
I
just
realized.
I
answer
that
question.
That
is
not
what
this
question
is.
I
need
to
add
this
to
the
rationale
as
I
went
over
this
again
today
with
somebody.
C
B
Yeah
this
is
we
we've
talked
about
this
several
times,
and
many
of
these
have
come
up
multiple
times.
That's
usually
how
things
end
up
in
the
rationale,
at
least
for
my
process
is
I
write
the
ip
and
the
rationale
is
mostly
blank,
and
then
someone
will
ask
me
a
question,
and
this
one
asks
me
the
same
question,
and
so
that
point
say:
okay.
B
So
we
see
here
they
have
the
transaction
type,
which
is
a
byte
and
then
just
bytes,
like
transaction
payload,
is
just
a
byte
array.
This
is
not
anything
specific.
This
is
so
we
can
use
ssd,
internally
or
rlp
internally
or
leb128
internally
or
fixed
width
format
internally,
whatever
we
want
can
be
used
in
future
transactions,
and
that
leads
into
that
other
answer
I
just
gave
where
I
mean
well,
then
why
are
we?
B
B
Most
of
the
questions
I
get
are
things
that
are
in
the
rationale.
I
don't
blame
people
for
not
reading
it,
I'm
going
to
hold
it
against
them
against
them,
because
I
know
that
by
the
time
you
get
through
the
specification,
your
head
hurts
and
you're
tired,
and
you
don't
really
want
to
read
more,
but
there's
a
good
chance.
Your
your
question
is
answered
in
the
rationale,
so
I
do
encourage
people
to
read
the
rationale.
B
E
B
Okay,
so
127
128,
129
somewhere
in
there
specifics
don't
matter
here.
What
matters
is
that
it's
it's
about
half
of
the
available
numbers,
and
so
you
might
think
well.
Why
are
we
limiting
ourselves
with
only
half
the
numbers?
That
seems
like
a
waste
a
again,
we
don't
think
we're
gonna
need
that
many
like
in
the
last
four
or
six
years
or,
however
long
ethereum's
been
around.
We
have
only
used,
arguably
four
like
if
we
had
this
at
the
start.
B
All
legacy
transactions
will
start
with
a
number
that
is
greater
than
c0
and
in
hex,
and
so
we
want
to
make
sure
that
those
don't
overlap
with
some
future
number.
We
don't
want
someone
to
come
along
and
say:
oh,
my
new
transaction
type
is
c1
and
then
have
that
be
malleable
with
a
legacy
transaction,
meaning
a
single
signature
could
apply
to
both.
B
B
So
if
we
do
run
out
of
transaction
type
numbers,
so
we've
used
up
0
through
128
or
whatever
it
is,
and
then
we've
said:
okay
well,
anything
greater
than
c0
is
invalid.
We
are
still
left
with
ff,
which
we
can
use
as
an
extension
extension
indicator.
So
if
we
could
say
in
a
future
eip,
for
example,
you
say:
okay,
if
that
first
byte
is
ff,
then
it
means
the
next
byte
is
really
where
you
look
to
see
the
transaction
type
and
we
can
kind
of
extend
that
way.
B
As
I
mentioned
earlier
in
this
discussion,
I
really
one
of
the
things
we're
trying
to
do
here
is
make
it
so
the
complexity
goes
down,
introducing
ff
as
an
extension.
Byte
would
increase
complexity
fairly
noticeably,
and
so
I'm
really
hoping
we
don't
get
there,
but
I'm
pretty
confident
we
won't,
and
so
I
I
I'm
pretty
confident
7f
is
going
to
be
enough
just
again,
just
because
eips,
don't
ethereum
doesn't
move
that
fast.
B
B
Yeah
exactly
that's
someone
else's
problem
at
that
point.
Hopefully
we
have
ai's
writing
code
for
us
at
that
point,
and
so
it's
their
problem
now,
not
even
human
problem,
which
would
be
nice,
so
origin
versus
color.
So
in
ethereum
in
the
evm
there's
op
codes,
which
you
can
call
one
of
those,
is
the
origin
op
code,
the
other
one
is
the
color
op
code
and
what
the
origin
does
it
tells
you
who
it's
kind
of
vague
right
now
it
basically
tells
you
who
signed
the
transaction.
B
So
this
is
the
address
of
the
person
who
signed
the
transaction.
The
caller
op
code
is
the
one
that
says:
who
is
the
person
that
called
this
specific
call
frame
when
your
new
transaction
types,
the
caller
and
the
origin,
the
caller
for
the
first
frame
and
the
origin
may
not
mean
the
same
thing
anymore,
because
what
it
means
to
sign
a
transaction
may
change.
B
For
example,
let's
say
we
introduced
a
new
multi-sig
transaction
type,
where
a
single
transaction
includes
two
signatures
well
now,
so
we
can't
just
look
at
the
signature
alone
and
determine
what
the
address
is.
So
maybe
we
have
some
new
mechanism
for
determining
address,
or
maybe
the
like,
like
what
caller
means
or
what
origin
means
isn't
super
well
defined
anymore,
like
because
we
have
these
new
types
transactions
that
may
introduce
new
signing
mechanisms
mechanisms.
B
So
we
have
to
deal
with
that
and
the
way
we
deal
with
that
in
the
cip
is
by
saying
we're
not
going
to
deal
with
it.
So
basically,
we
say
eip2718
does
not
specify
what
origin
and
color
means
it
is
up
to
individual
new
transaction
types
to
specify
that,
but
we
recommend
that
you,
you
try
to
treat
them
as
basically
the
same
thing
as
they
mean
today.
B
Maybe
there
will
be
some
where
they
just
origin
makes
no
sense
at
all
and
we'll
have
to
deal
with
that
when
the
time
comes,
but
basically
you
say
that's
up
to
each
new
transaction
types
needs
to
define
what
these
mean
and
it's
pretty
simple.
In
most
cases,
we
can
see
for
the
possible
future
they're,
just
it
might
not
be
in
the
future.
Whatever
that
went
over
that.
B
If,
if
we
were
expecting
this
new
transaction
types
to
come
about
every
month
or
so
or
faster,
then
yeah
we'd
probably
want
some
list
somewhere
that
maybe
lives
in
the
ip
repository
or
somewhere
else.
That
keeps
track
of
these,
but
for
now
at
least
we're
saying
we
don't
think
that's
necessary
that
subject's
change.
Of
course,
if
it
turns
out
that
this
is
a
big
problem,
then
maybe
we'll
keep
a
list
somewhere.
B
B
If
the
length
of
the
transaction
is
what
255
bytes
long
meaning
the
the
number
that
defines
the
length
is,
is
a
full
256
bit
number
and
it
needs
all
the
bytes
so
you're
looking
at
you
know
it
means
your
transaction
is
bigger
than
the
memory
of
all
computers
on
the
planet
kind
of
thing,
maybe
even
all
the
stars
in
the
galaxy-
I
don't
remember
so
ff
will
never
be
used.
That's
why
we
set
that
aside.
C
B
Realistic,
that's
everything
in
this
eip
we've
at
least
covered
all
of
it
at
a
high
level.
Again,
if
you're
implementing
this,
I
do
not
recommend
you
use
this
video
alone
for
your
implementation.
I
recommend
you
actually
yeah.
I
recommend
you,
you
read
the
eip.
If
you're
going
to
implement
this,
especially
the
specification
section,
you
can
kind
of
ignore
the
rationale
section
unless
you
want
to
know
the
why,
but
hopefully
that
gives
a
high
enough
level
overview.
B
It
goes
all
the
way
down.
Vip's
all
the
way
down,
vip's
all
the
way
down
until
it's
elephants
or
turtles,
so
27-11
was
introducing
a
new
trend,
several
new
transaction
types
or
sort
of
one
new
transaction
type.
You
could
argue,
but
that
had
subtypes
and
originally
I
actually
folded
in
this
change.
This
is
this
new
transaction
type
concept
into
27-11
or
27-18
pretty
quickly.
However,
I
realized
that
that
was
not
doesn't
scale
very
well,
because
you
know
it
was
all
my
problem
for
27.11,
but
it
won't
solve
one
five,
five,
nine.
B
It
won't
solve
for
twenty
nine.
Thirty,
almost
all
for
anything
else.
It
was
just
me
solving
my
own
problem,
and
so
what
I
did
at
that
point
is,
I
basically
extracted
out
just
the
the
little
bit
about
how
do
we
do
type
transactions
into
its
own
eip
and
then
wrote
that
this
this
one
in
particular,
just
as
a
very
brief
overview,
it
didn't
was
going
to
introduce
transaction
batches,
so
you
could
send
multiple
transactions
in
one
transaction
so
like
they
could
do
multiple
things
in
a
row.
B
It
was
also
going
to
introduce
a
sponsorship,
meaning
someone
else
could
pay
for
your
gas
instead
of
you
and
it
was
going
to
introduce
expirations
where
a
transaction
is
valid
until
some
time
stamp
is
reached
at
which
point
becomes
invalid
and
not
all
those
may
make
it
to
the
end.
The
cfp
may
not
make
it
all
the
way,
so
we
won't
go
over
that
now,
but
that
was
the
genesis
that
was
where
this
came
from.
C
Oh
the
internet,
this
is
he's
typing,
I'm
like
he's
lagging
he's.
Gonna
reconnect
in
the
text
chat
just
for
context
of
yours,
so
I
guess
we
roll
commercials
here
yeah.
Well,
I
can
give
some
context
of
of.
I
was
working
on
1559
and
then
I
saw
this
eip
show
up
and
I
was
and
I
and
it
was
like.
Yes
thank
you.
D
Yeah,
it's
actually
funny,
because
I
I
don't
think
that
we've
had
so
many
different
transaction
ideas
until
just
the
summer
and
while
it
came
out
and
a
lot
of
people
were
working
on
1559
like
yourself,
we
were
working
on
account,
abstraction
and
the
way
we
were
originally
planning
to
do
account.
Abstraction
was
just
saying:
oh,
the
signature
will
just
be
all
zeroes.
D
The
two
address
will
be
some.
You
know
random
some
specific
pre-compile
and
and
that's
how
we're
going
to
kind
of
hack
transaction
in
and
in
june,
whenever
micah
hits
it
was
talking
about
2718.
We
realized
that
this
was
going
to
be
the
perfect
fit
for
us.
So
it's
funny
how
it
kind
of
came
at
the
time
that
it
was
needed
for
a
lot
of
people.
C
B
D
Have
a
question
for
you
micah,
so
you've
proposed
this.
You
know
early
in
june
and
you've
authored
quite
a
few
eeps
in
the
last
few
years.
I
think
I
just
looked
it
up.
You
have
13
eavs
to
your
name
so
far,
but
I
wonder
if
you
could
just
talk
about
what
the
process
has
been
like
since
june.
To
get
this
e
pretty
much
on
the
docket
for
berlin.
It
seems
like
a
very
strong
contender
for
berlin
and
maybe
how
other
eeps
fall
short
and
end
up
never
progressing
to
a
hardboard.
B
Sure
I
can,
I
can
try.
So
my
number
one
recommendation
for
eip
authors
is
keep
your
eip
as
simple
as
possible.
The
one
thing
I've
noticed
is
that
client
developers
who
are
the
ones
who
are
deciding
what
goes
into
the
hard
forks
largely
are
very
busy
people.
They
do
not
have
a
lot
of
time
to
read
a
very
long-winded
ip.
B
If
your
eip
is
very,
very
wordy
and
long-winded,
the
there's
a
good
chance
that
it
will
get
pushed
back,
not
because
it's
a
bad
eip,
but
just
because
the
core
developers
are
very
busy
and
they
don't
have
time
to
really
dig
into
it
deeply,
and
so,
if
you're
writing
eip
and
you
you
want
to
go
through,
simply
keep
it
short,
keep
it
simple.
Keep
things
very
focused
very
on
point,
and
this
isn't
just
for
this
api.
B
I've
noticed
this
for,
for
all
the
ips,
the
the
smaller
the
eip
is,
the
more
likely
it
is
to
go
through,
and
you
actually
see
this
in
a
lot
of
the
older
eips.
Many
of
the
ones
that
have
made
it
in
are
all
very
short.
They're,
like
you
know,
three
sentences,
they
change.
One
thing
they
do
something
very
small,
it's
much
easier
to
get
a
small
change
through
than
a
big
change.
B
But
that
was
a
problem,
and
so
I
I
had
drafted
this
eip
and
this
erp
is
still
pretty
short
compared
to
some
ips,
but
it
kind
of
puts
a
bunch
of
things
together
and
that
has
caused
it
to
slow
down,
and
it's
part
of
why
I
attracted
27.18
out
as
well
is
because
it
could
be
extracted.
So
if
you
have
an
eip
and
you
can
split
it
up
into
multiple,
smaller
erps,
I
strongly
recommend
you
do
that
that
will
really
increase
your
chances
and
again
for
2718.
B
The
actual
specification
is
very
small,
like
you
can
fit
it
all
on
one
page
here,
it's
you
know
basically
two
paragraphs
that
cover
all
of
it
and
it's
really
simple:
you
can
keep
in
your
head.
Someone
can
scan
it
in
the
middle
of
a
meeting
and
get
the
gist
of
what
it
does
the
abstract
also
it's
again,
because
people
are
often
in
a
hurry
having
an
abstract.
That
gives
a
very,
very
quick
overview
to
someone
who
wants
to
implement
this,
so
you
can
get
the
idea
rapidly.
B
A
B
You
need
to
engage
people
rapidly,
get
them
to
decide
whether
they
like
this
idea
or
not
fast,
and
then
once
they
do
decide,
they
like
the
idea,
make
it
easy
for
them
to
identify
like
read
the
spec
to
see.
Okay
is
there
anything
in
here
that
stands
out
to
me
is
going
to
be
a
problem
and
and
again
make
sure
it's
separated
out
as
much
as
you
can,
because
you
want
to
make
it.
So
you
don't
want
one
piece
of
your
your
change
to
block
the
rest
of
your
change.
B
B
As
for
this
particular
one,
I
think
the
reason
it
went
through
is,
like
you
were
saying
just
a
moment
ago.
There's
a
bunch
of
stuff
that
kind
of
wants
this
all.
At
the
same
time,
you've
got
account
abstraction
you've
got
one
five:
five
nine
you've
got
27
11.,
there's
actually
several
other
proposals
that
are
contending
with
27-11
that
do
some
similar
things
and
they
all
and
29
30,
which
is
also
going
in
2930.
B
B
So
by
splitting
that
up
into
multiple
smaller
eips,
it
turns
out
that
I
got
someone
else
to
sort
of
lobby
for
my
eip
for
me,
because
it
was
a
small
little
piece
and
other
people
could
use
that
building
block,
and
so
now
I
gained
the
advantage
of
having
other
people
saying
oh
yeah.
We
should
do
that
instead
of
just
me
trying
to
lobby
for
it
for
myself.
So
in
another
reason,
two
small
emps
they
can
be
building
blocks
and
other
people
can
build
other
aps
off
of
them,
which
is
valuable.
B
Yes,
very
true
and
that
actually
there's
a
good
chance,
2718
wasn't
going
to
make
it
to
berlin
because
even
though
everybody
agreed
yeah
that's
a
good
idea,
but
until
2930
came
along,
there
was
nothing
to
do
with
it,
and
so
it's
like
well
we're
all
going
to
engineer
this
building
block
that
we're
not
going
to
use
that
seems
silly
and
so
2930
was
the
first
thing.
That's
going
to
use
that
building
block.
D
D
This
made
me
think
of
another
question,
but
as
an
eip
editor
and
as
an
author
of
many
eaves,
what
is
your
feeling
of
the
permissionless
of
the
upgrade
process,
and
this
is
also
kind
of
a
question
for
james?
That's
a
hardcore
coordinator.
But
what
are
your
guys's
feeling
in
terms
of?
Are
there
gatekeepers
of
these
this
process?
Is
it
very
difficult
for
someone
who
is
not
a
part
of
the
community
who
has
a
good
idea
to
make
a
change
to
ethereum,
or
do
you
think
that
there
is
too
much
gatekeeping
or
bureaucracy
in
that
process?.
C
C
D
No,
I
think
it
didn't
know
catch
up.
I
think
it's
more
just
talking
about.
There
are
critics
of
the
process.
Obviously
it's
a
very
difficult
process
to
get
the
right.
Balance
of
you
know
pushing
upgrades
to
ethereum,
not
letting
the
protocol
stagnate,
but
also
balancing
with
security
concerns
and
ensuring
that
we
are
building
a
protocol.
That's
going
to
last
10
20
30
100
years.
B
Non-Technically
speaking,
one
might
look
at
this
yeah
one
might
look
at
this
and
say:
oh
my
god,
that's
just
all
bureaucracy,
but
technically
it's
not
there's
not
because
you
can
only
have
bureaucracy
if
you
have
an
official
process.
But
yes,
there
are
lots
of
barriers
like
there's
lots
of
foreign
knowledge.
One
needs
in
order
to
get
an
eip
through
and
there's.
B
Unfortunately,
this
foreknowledge
is
not
like
things
that
are
easy
to
write
down
and
I
think
cat
herders
are
trying
to
do
this
they're
trying
to
document
that
not
process
not
so
we
can
make
an
official
process
because
that
would
mean
we'd
have
bureaucracy.
We
don't
want
bureaucracy,
but
just
so
people
who
are
coming
along
can
hopefully
have
a
little
easier
time
like
they
can.
They
can
go
reference
the
material
and
get
these
little
nuggets
like.
Oh,
if
you're
gonna
introduce
a
eip
like
2718,
make
sure
to
also
have
something
to
go
along
with
it.
B
That
uses
it
like
that.
That's
a
little
nugget
of
wisdom
that
someone
who's
been
in
this
process
might
know,
but
someone
who's
not
wouldn't
it's
not
an
official
bureaucratic
step,
but
it's
a
you
know.
Good
idea,
we
recommend
this
we've
seen
this
pattern
in
the
past.
Of
these
things
got
through
these
other
things
did
not
get
through
the
I'm,
not
a
cord
developer,
and
so,
even
though
I
go
to
core
developer
calls
sometimes-
and
I
you
know,
do
eip
stuff
now
I
don't
come
from
a
background
deep
in
the
guts
of
ethereum.
B
I
come
from
a
background
of
writing
applications
for
ethereum,
so
an
ad
app
developer
as
it
were,
and
so
it
is
possible
to
approach
this
process
as
a
non-core
developer,
but
it
is,
it
is
also
hard
like
I
I
had
to
learn
the
hard
way
you
know
how
what
the
process
or
not
process
was.
I
had
to
show
up
to
court
of
calls
listening
on
them.
Try
to
understand
why
things
were
the
way
they
they
are
and
and
contrary
to
popular
belief.
B
They
are
the
way
they
are
because
they
are
the
way
they
are
because
there's
a
bunch
of
different
things,
contending
this
isn't
the
right
discussion
forum
for
it,
but
there's
lots
of
different
things
that
people
want
from
ethereum
and
one
of
those
things
is
censorship,
resistance
and
permissionless,
and
those
often
contend
with
what
one
would
see
as
an
efficient
process.
Most
efficient
processes
have
a
like
someone
at
the
top
who's
making
decisions
and
that's
kind
of
against
the
ethos
of
ethereum.
B
Where
we
don't
want
someone
at
the
top
who's
making
decisions,
we
don't
want
a
shot
caller.
We
don't
want
someone
who's
saying
this
goes
in
because
I
say
so,
and
so
because
of
that
we
we
don't
have
that
efficiency,
that
you'd
get
from
like
a
traditional
company,
but
it
also
means
that
we
don't
end
up
with
a
centralization
problem
that
a
lot
of
the
people
in
this
ecosystem
are
trying
to
get
away
from
like
we're
trying
to
get
away
from.
B
You
know
one
person
calling
the
shots
or
one
person
having
the
ability
to
censor
someone
else,
and
so
this
this
can
kind
of
creates
a
tension
between
efficiency.
Where
you
want
to
get
things
done
and
at
the
same
time
you
don't
want
someone
in
power
like
we
don't
want
to
create
that
power
that
someone
could
then
seize
later
like.
B
So
maybe
we
all
trust
like
vitalik
today,
but
you
know,
he's
not
gonna
be
around
forever
and
when
he's
not
someone
else
is
gonna
take
his
place
and
when
that
person
comes
around
they
may
not
be
as
benevolent
as
he
was,
and
so
by
creating
that
that
power
structure
we're
creating
an
opportunity
for
someone
to
take
over
later,
and
we
don't
want
that.
And
so
it's
not
just
because
we
hate
efficiency.
I
know
it
seems
like
that.
Sometimes.
A
C
C
We're
trying
to
make
it
so
we
you
don't
have
to
rely
on
us,
but
I
just
I
had
this
thought
of
like
an
analogy
of
why
part
of
this
is
kind
of
opaque,
because
anyone
really
can
jump
in
it's
like
we
have
a
giant.
It's
like
ethereum
is
like
a
giant
mansion
and
there's
like
water,
slides
and
a
pool
and
a
theater
room,
and
then
in
the
in
the
basement.
C
So
that's
where
I
go
to
hang
out
right
right
right,
so
you
and
I
and
a
couple
other
people
there
just
isn't
a
lot
of
people
that
sit
in
there
long
enough
to
see
it
through.
What
what
I
see
is
a
lot
of
eip
authors
come
in,
they
figure
out
what
they
need
to
do.
They
do
an
eip
and
then
they're
out
doing
all
the
other
stuff.
A
Well,
thank
you
so
much.
This
is
all
interesting
conversation
about
not
only
about
the
proposal,
but
also
about
the
process
that
I
have
been
meaning
to
have
this
on
on
the
peep
and
eve
show,
because
this
is
all
about
proposals
and
process
improvement
coming
back
to
eap
2718.
This
is
one
of
the
building
block
for
changes
that
are
being
proposed
in
the
future
upgrades
and
it's
currently
in
the
list
of
bucket
lists
of
yellow
v3.
A
A
If
you
like
this
episode,
please
share
it
with
the
other
community
members
and
let
them
know
about
people
see
you
all
with
sam
wilson
and
anne
scott
dietrich
to
discuss
about
eip
2938
account
abstraction
till
then
keep
sharing
your
love
with
us.
This
is
your
host
bucharen
signing
off.
Thank
you.
Everyone
for
joining
today.