►
Description
Topics covered:
0.44 - Introduction
EVM
2:25 - EVM shortcomings
3:20 - Broad overview - the structure of the EVM
5:05 - Metrics to measure EVM
5:45 - EVM critics - What problems do we have if EVM reads only 256-byte words? Is there a way to do anything about that?
9:05 - Is there a way on working around the intermediate languages?
10:10 - Complaints about EVM jump - What the static analysis is? How is the EVM jumps make that hard?
14:10 - In other VMs in general, how do they get around to?
15:08 - Does the resulting inefficiency translates itself in some form of the Gas cot?
17:10 - What the Merkle-Patricia trie is? Is the trie storage an inefficiency?
21:54 - EVM makes some interesting choices, what's goes on the stack, what's in memory. Could you talk about it?
27:05 - How does stack allow us to be more versatile?
31:05- What is the biggest thing holding back the growth, scalability of Ethereum? Where do you see a solution?
32:58 - Would you say the current wat at the EVM is comparable to a single-threaded process, then the sharding would be multi-threaded?
33:46 - Why would people want to be on the most used shard?
34:50 - Asynchronous communication process - Would you say, a fantastic solution would be a framework where the asynchronous process will be the basis of the functionality? The benefit of being synchronous on the same shard would be outweighed by the benefit of the multiple shards?
36:04 - Opinion on the way EVM compiles the bytecode?
38:00 - Is that an inherent weakness in the way the logs are set up?
EIP Process
42:03 - History of the EIP process. How do you see the current EIP process wrt earlier EIP process?
45:35 - Thoughts on Informational EIPs?
48:22 - Thoughts on ERCs in EIP repo?
49:47 - How can you do a hard thing to separate specification from politics, any thoughts on this?
Follow at Twitter:
Nick Johnson @nicksdjohnson | Pooja Ranjan @poojaranjan19 | William Schwab @William94029369 | Brent Allsop @Brent_Allsop | 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
A
Today's
topic
is
potential
direction
for
new
eips
and
our
guest
is
a
long
time
eip
editor,
who
has
authored
some
very
useful
eips
and
is
also
the
founder
of
ens
no
prices
for
guessing
here.
Please
welcome
nick
johnson
welcome
to
the
show
nick
excited
to
have
you
and
curious
to
know
about
your
journey,
so
please
take.
B
B
C
Cool,
so
I
I
definitely
want
to
give
a
little
bit
of
a
preface
here
that
I
am
not
a
core
developer
myself.
I
have,
I
would
say,
casual
knowledge
of
a
bunch
of
things
about
the
vm.
I'm
definitely
interested
in
diving
a
bit
deeper,
but
I
guess
to
a
large
degree.
I
just
want
to
give
the
caveat
that
I'm
attempting
to
sound
knowledgeable
here,
and
I
can
only
hope
that
I
do
a
good
job.
C
C
B
I
I
guess
a
sort
of
a
broad
overview
of
the
structure
of
the
evm
is
probably
warranted
briefly
and
great
idea.
Yeah,
the
evm
is,
is
more
or
less
what
you
get
if
you
gave
a
third
year
comp
size
student,
the
assignment
to
design
an
ev,
a
virtual
machine
that
was
as
straightforward
and
easy
to
implement
as
possible.
B
B
Okay,
less
attention
to
the
the
implementation.
Details,
then,
is
perhaps
warranted,
and
the
result
is
that
efficiency
is
a
serious
issue
with
ethereum
and
that
also
the
design
also
impacts
things
such
as
the
ability
to
static
analyze,
aesthetically
analyzed
contracts,
things
such
as
that,
so
there's
definitely
a
lot
of
room
for
improvement,
some
of
it
we're
stuck
with
because
it
would
break
backwards.
Compatibility
too
badly.
C
Cool,
so
if
I
could
maybe
take
something
that
you
said
there,
I
think
that
you
mentioned
two
different
metrics
that
we
could
sort
of
measure.
The
evm
by
one
is
the
conceptual
simplicity
which
you
said
is
really
maximized
in
a
lot
of
ways.
Another
is
the
efficiency
another
one
that
I
see
brought
up
every
now
and
then
is
the
not
composability
the
the
ease
of
understanding
like
sort
of
I
I
don't.
C
C
B
It's
the
reason
it
was
picked
basically,
is
because
some
operations
in
the
evm
need
to
be
done
on
256
bit
operands,
so
public
keys
addresses
and
so
forth,
although
you
know
addresses
of
160
bits,
but
you
know
close
enough.
Hashes,
of
course,
are
another
a
very
common
example,
and
so
the
reasoning
and
the
sort
of
thing
that
you'd
see
in
a
model
vm
is
well
some
of
our
operands
need
to
be
this
long.
If
we
make
all
of
our
operands
this
long,
then
we
minimize
the
size
of
the
instruction
set.
B
B
And
the
result
is
that
even
very
ordinary
operations,
like
you
know,
addition
and
multiplication
of
small
numbers
like
indexing
arrays,
require
require
words
that
are
four
times
the
size
of
what
a
common
machine
actually
implements,
and
so,
in
order
to
add
one
plus
one.
Your
machine
in
a
naive
implementation
under
the
hood
is,
is
adding
up
four
separate
numbers
and
and
incurring
many
times
the
overhead
that's
necessary.
B
So
I
think
that's
a
perfect
example.
It's
slightly
more
difficult
to
fix,
because,
although
you
could
implement
diverse
word
sizes
and
so
on,
you
would
have
to
significantly
expand
the
instruction
set.
You'd
need
to
change
a
lot
of
things
around
and
it's
unclear
to
me
whether
that
would
be
the
best
way
to
do
it.
But
I
think
it
also
points
at
the
the
general
sort
of
architecture
of
the
evm.
In
that
it
was
chosen
that
all
items
on
the
stack
would
have
just
a
single
type.
B
They
would
all
be
256-bit
words,
which
is
both
simple
and
mirrors,
how
you
implement
something
in
hardware.
But
if
you
look
at
other
intermediate
language
vms
such
as
the
clr,
the
common
language,
runtime
for
net
or
the
jvm,
they
have
stacks
that
take
objects
basically
and
they.
So
they
can
take
multiple
different
operand
types
and
it
would
be
less
of
a
block
of
instruction
set
and
complexity
to
say
you
can
push
a
32-bit
word
or
you
can
push
a
256-bit
hash
in
here.
The
operands
to
write
defined
on
that.
C
B
Not
really
I
mean
they,
so
they
can
and
do
define
smaller
operands
which
make
their
reasoning
easier
and
allow
them
to
do
things
like
you
know,
overflow
checking
on
smaller
types
on
things
like
potentially
packing
things
together
into
struts
for
storage,
but
none
of
that
information
makes
it
through
to
the
vm.
So
it
doesn't
benefit
the
vm
implementers.
B
So
it
is
possible
to
write
a
vm
that
optimizes
things
and
avoids
like
operating
on
256-bit
words
when
you
know
both
the
operands
and
the
product
will
fit
in
a
smaller
space,
but
you
have
to
do
it
at
runtime
and
in
fact
your
ability
to
do
it
at
runtime
is
also
hampered
by
the
fact
that
the
evm
is
very
difficult
to
statically
analyze,
because
all
jumps
are
dynamic,
and
so,
as
a
result,
you
can't
go
ahead
and
do
all
these
optimizations
ahead
of
time.
You
have
to
do
them
on
the
fly.
C
I
I
did,
I
definitely
did
want
to
get
into
the
jumps
later
debating.
If
I
should
stick
you
into
jumps
now
or
keep
on
the
words
for
a
second,
I
think
I
think
I
am
going
to
stay
on
the
wow,
I'm
like
not
with
it.
I'm
like
losing
my
train
of
thought,
left
right
and
center.
I
am
going
to
jump
onto
the
jumps.
I
think
there
we
go
an
evm
style
jump.
A
lot
of.
C
I
see
a
lot
of
complaints
about
the
way
that
the
evm
jumps
around
you've
mentioned
a
couple
of
times
that
it
makes
the
evm
difficult
to
statically
analyze.
Could
you
explain
a
little
bit
about
that
about?
I
guess
maybe
taking
a
step
back
to
explain
what
static
analysis
is
and
then
how
the
evms
implementation
of
jumps
make
that
hard
sure.
B
Know
whether
this
is
any
better,
so
so
the
one
of
the
goals
of
a
vm
or
at
least
potential
goals,
is
making
it
easy
to
statically
analyze
a
program
and
what
that
means
is
take
the
program
and
do
some
sort
of
analysis
on
it.
That
tells
you
something
about
it.
So,
for
instance,
a
really
useful
analysis
might
be
if
you
could
determine
statically
that
this
particular
operation
will
never
overflow
a
64-bit
word,
for
instance,
and
you
could
tell
that
by
saying
you
by
establishing
bounds
on
the
inputs,
you
could
say.
B
Well,
I
know
that
this
input
comes
from
here
and
it's
limited
to
the
size,
and
I
know
that
this
input
is
this
constant
six,
and
I
know
that
six
times
this
can
never
be
more
than
a
64-bit
word
or
something
like
that,
and
then
in
many
cases
the
static
analysis
is
it
gives
you
three
answers.
Yes,
no
or
maybe
because
of
turing
completeness,
you
can't
always
get
a
complete
answer,
but
even
just
being
able
to
analyze
the
cases
where
the
answer
is.
B
Yes
allows
you
to
implement
optimizations
and
so
forth,
and
so
that
also
allows
you
to
do
things
such
as
determining
whether
certain
code
is
reachable
or
under
which
circumstances
it's
reachable,
it's
useful,
not
just
for
runtime
optimization,
but
also
for
analyzing
programs
for
correctness
and
so
forth.
If
you
can
statically
analyze
a
program,
then
you
can
more
easily
determine
properties
like
whether
a
particular
invariant
holds
whether,
for
instance,
a
token
will
always
preserve
the
sum
of
its
balances
and
things
like
that.
B
So
if
you
try
and
statically
analyze
the
vm,
your
circumstances
in
which
you
can
do
this
are
much
more
limited
because
you
have
to
be
able
to
determine
what
this
jump
location
is
statically
and
actually
doing
that
in
the
first
place
is
extremely
difficult.
So
typical
basic
control
flow
analysis
in
a
vm
where
the
jump
locations
are
determined.
B
You
know
directly
from
the
code
is
a
reasonably
straightforward
process,
but
doing
it
in
the
in
the
evm
basically
involves
sort
of
pseudo
executing
all
the
code
to
try
and
figure
out
where
your
operands
are
coming
from
and
because
of
the
stack
based
nature
of
it.
The
the
op
code,
for
where
to
jump,
could
well
have
been
inserted
in
the
stack
a
long
way
back
because
they
had
to
do
a
bunch
of
other
intermediate
things
first
and
calculate
results
and
so
forth.
B
So
it's
it's
very
difficult
and
there
are
efforts
to
to
remedy
this
in
a
mostly
backwards
compatible
way.
Greg
colvin
has
submitted
some
proposals
for
new
jump
up
codes,
and
the
idea
would
be
that
old
programs
would
remain
difficult
to
analyze,
but
new
programs
could
use
these
jump
codes
and
therefore
be
easier
to
analyze
going
forward.
C
B
C
B
This
is
another
example
of
the
the
conceptual
simplicity
of
the
the
evm
there's,
a
total
of
one
class
of
opcode
that
accept
that
has
arguments
and
that's
the
push-up
codes.
So
you
have
push
one
which
takes
the
next
one
byte
and
push
two
which
takes
the
next
two
bytes
and
so
on,
and
they
grab
the
next
n
bytes
from
the
bytecode
and
shove
them
on
the
stack.
The
jump
up
code,
like
every
other
type
of
op
code,
doesn't
take
anything
from
the
bytecode
directly.
It
only
takes
it
from
the
stack.
B
So
if
you
want
to
jump,
you
do
say,
push
one
and
then
the
one
byte
offset
and
then
jump
what
other
vms
do
is
the
jump
pop
code
itself
takes
the
argument
directly
from
the
bytecode,
and
that
means
it
can't
change,
and
that
means
when
you're
going
through
analyzing
it.
You
know
exactly
where
that
can
possibly
jump
to.
C
B
Not
as
an
extra
gas
cost,
but
rather
well,
so
that's
not
quite
true.
Yes,
some
operations
cost
more
gas
than
they
would
if
they
were
more
efficient.
Simply
because
you
know
the
gas
costs
reflect
the
actual
cost
of
execution,
but
also
the
general
inefficiency,
particularly
when
it
comes
to
global
things
like
operating
on
256-bit
words,
effectively
just
inflates
the
cost
of
gas
globally
and
decreases
the
maximum
gas
limit
that
ethereum
could
afford.
B
So
if
the
uvm
had
been
implemented
with
64-bit
words,
we
could
potentially
fit
say
as
much
as
twice
as
much
twice
as
many
units
of
gas
in
a
block
at
a
random
guess.
It
may
well
be
more
than
that,
just
because
of
the
share
over
here
of
having
to
evaluate
all
these
large
operands,
every
single
computation
step.
C
Yeah,
I
think
that
actually
ends
up
being
partially
a
computer
science
question
and
partially
an
economics
question,
because
if
we
had
more
efficiencies
so
then
it
doesn't
necessarily
like
it
could
be
that
the
gas
price
for
a
smaller
operation
that
can
now
be
performed
might
very
well
be
smaller.
But,
like
you're
saying,
the
resulting
effect
is
just
that
more
gets
packed
in
yes,.
C
C
Do
you
see
that,
as
also
like
a
inefficiency?
Also,
I
mean
I
see
that
james
is
here.
It
could
be.
You
could
comment
if
stateless
is
worried.
I
believe
stateless
is
working
on
another
tri
structure,
so
it
could
be.
This
is
something
that's
actually
already
under
development,
but
I
was
wondering
if
you
could
talk
to
that
a
bit.
C
D
C
B
So
if
you're,
if
you're
wanting
to
send
a
proof
over
the
wire
like
with
stateless
ethereum,
ideally
you
want
a
binary
tree,
because
that
way
you
only
have
to
provide
the
hash
of
one
other
internal
node
with
every
level
of
your
merkle
proof.
This
is
assuming
they're
using
vocal
proofs,
and
so,
if
they're,
with
ethereum's
current
merkel
patricia
try,
you
have
up
to
15
other
internal
node
hashes
with
every
level
of
the
try.
So
the
try
is
a
lot
shallower,
but
you
end
up
having
to
spend
a
lot
of
effort
encoding.
B
B
Though,
there's
the
idea
of
the
delay
bandwidth
product,
which
is
effectively
the
number
of
milliseconds,
it
takes
you
to
do
a
disk
query
times
the
theoretical
throughput
of
your
disk
and
if
you're,
making
very
small
reads,
then
you're
spending
most
of
your
time
waiting
for
the
data
to
sorry
waiting
for
the
query
to
happen
and
the
response
to
come
back
and
your
bandwidth
is
sitting
idle.
And
if
your
blocks
are
really
big,
then
you're
reading
a
whole
lot
of
data
that
you
don't
need.
B
In
contrast,
a
merkle
patricia
tri
node
is
on
the
region
of
like
128
to
256
bytes.
So
what
we
should
be
doing
is
if
we
wanted
efficient
disk
storage,
and
that
would
reduce
the
number
of
reads.
You
have
to
do
to
read
a
single
value
off
disk
which
would
correspondingly
decrease
the
cost
of
any
sload
or
any
store.
B
You
would
want
a
tree
that
was
much
much
bushier
and
if
you
want
efficient
proofs,
you
want
a
tree,
that's
much
much
narrower
and
there
is
a
sort
of
a
solution
here,
which
is
that
you
store
on
disk
the
aggregation
of
several
levels
of
trinode
together
as
a
single
unit.
But
then,
when
you
transmit
them,
you
see
them
as
individual
nodes,
just
parts
of
the
block.
So
you
read
out
an
entire,
very
large,
very
bushy,
sort
of
sub
tree
as
a
single
read
operation
and
then
pick
out
the
bits
you
need.
B
They
a
warp
sync
node,
was
actually
unable
to
serve
up
some
of
the
internal
nodes
of
the
try
and
that
didn't
become
a
big
problem,
because
parity
was
only
ever
a
minority
part
of
the
network.
The
sort
of
geth
picked
up
the
slack,
but
it's
an
ongoing
problem
with
any
trying
to
do
that
sort
of
optimization.
C
B
Yeah-
and
it
was
sort
of-
I
have
a
short
little
list
of
of
things
that
could
do
with
future
improvement
and
are
actually
practical,
and
this
was
near
the
top
of
it
it's
so.
The
evm
has
the
execution
stack,
because
it's
a
stack
based
virtual
machine
and
all
of
the
op
codes
take
arguments
from
the
stack
and
it
has
some
stack
manipulation,
op
codes
which
allow
you
to
swap
elements
around
or
duplicate
elements
from
the
stack.
B
But
the
intention
of
the
evm
designers
clearly
was
that
this
is
a
stack-based
machine
and
this
is
for
evaluation
and
that,
if
you're
building
a
higher
level
language
typically,
you
would
store
the
actual
variables
in
memory
and
then
you
would
load
them
from
memory
and
save
them
to
memory
as
needed.
And
if
you
have
an
optimizing
compiler,
then
it
can
identify.
Oh
some
of
the
time
we
don't
really
install
this
in
memory.
It
can
fit
on
the
stack,
but
that's
an
optimization.
B
B
Is
they
stick
them
at
opposite
ends
of
the
memory
address
space
and
they
grow
towards
each
other
as
they
they
fill
up
and
that's
a
very
easy
way
to
build
it,
because
you
generally
don't
have
to
worry
about
the
two
running
into
each
other
until
you've
literally
run
out
of
memory
and
in
the
case
of
the
evm.
If
it
supported
this,
you
wouldn't
because
you've
got
a
256
bit
address
space,
but
because
the
evm
charge
is
based
on
the
the
total
length
of
memory
consumed.
B
This
compiler
structure
is
impractical,
and
so,
when
solidity
was
written,
for
instance,
they
decided
to
put
all
of
the
variables
all
the
local
variables
on
the
evaluation
stack
rather
than
putting
them
in
memory.
Because
that
way,
you
don't
have
this
whole
issue
of
them
sort
of
being
interleaved
with
stuff.
That's
been
dynamically
allocated
and
so
forth.
The
flip
side
is
that,
then
you
have
the
whole
stack
too
deep.
B
Please
try
removing
some
local
variables
error
in
solidity,
which
is
a
bit
of
a
nightmare,
so
the
here's
somewhere,
where,
where
someone
who
was
determined,
could
actually
make
a
difference.
I
think,
and
I'm
not
aware
of
any
big
barriers
to
this.
It
would
be
quite
practical
to
write
an
ape
that
changes,
the
gas
accounting
for
memory
to
use
a
page
table
structure.
B
B
You
know
address
2
to
the
255,
minus
1
and
each
time
you
just
get
charged
for
one
page
and
that
would
allow
writing
compilers
that
take
this
more
typical
architecture
and
structure
heap
and
stack
at
opposite
ends,
and
that
would
make
it
possible
to
write
sort
of
better
and
more
versatile
compilers.
And
the
best
thing
is
for
programs
that
were
written
before
this.
They
would
simply
be
charged
what
they
are
now
or
less,
because
they
would
be
charged
based
on
just
using
the
first
pages
of
memory.
C
That
is
super
interesting,
so,
basically,
what
an
eip
like
that
would
do
is
instead
of
using
the
current
gas
structure,
but
the
current
structure
for
charging
gas
on
for
putting
things
on
this
stack,
which
doesn't
look
at
how
much
you're
putting
on
it
looks
at
the
location
of
the
information
that's
put
and
charges
for
for
the
for
the
entirety
of
the
stack
up
to
that
location.
This
would
be
looking
at
the
actual
information.
Push
to
stack
is
that
roughly.
B
Correct
so
it's
we're
talking
about
charging
for
memory
rather
than
the
the
evaluation
stack.
The
the
evaluation
stack
is
limited
to
1024
slots,
but
it's
not
directly
charged
for,
but
at
the
moment
memory
is
charged
based
on
the
the
length
you
use
from
zero
up
to
the
last
byte,
that's
non-zero,
and
with
this
instead,
it
would
be
charged
in
pages.
C
B
In
a
typical
programming,
just
to
disambiguate
we're
talking
here
about
a
variable
stack,
so
a
stack
of
local
variables.
So
if
you
look
at
it
say
how
c
implements
it,
for
instance,
when
you
have
a
local
variable,
the
compiler
says:
okay,
the
next
byte
after
the
beginning
of
this
function's
frame,
which
is
where
the
sort
of
a
bit
of
memory
that
belongs
to
this
function
starts,
is
going
to
be
this
first
variable
and
then
the
next
variable
and
so
on.
And
then,
when
you
call
a
when
that
function,
calls
another
function.
It
goes.
B
Okay,
we'll
move
the
frame
up
here
and
now.
We'll
start
writing
new
variables
up
here
and
so
on
and
when
it
returns,
it
goes.
Okay,
we'll
move
it
down
here
and
all
this
memory
is
now
free
for
the
next
function
call
and
at
the
same
time,
at
the
opposite
end
of
memory
you
have
the
heap
and
the
heap
stores
things
that
were
dynamically
allocated
using
functions
like
new
and
malloc,
because
they
can
outlast
the
function,
call
that
they
were
called
in.
B
You
can
call
a
function
which
allocates
something
and
passes
it
back
to
you,
which
means
it
can't
be
hit
on
the
stack,
because
if
it
was,
it
would
go
away
as
soon
as
the
function
returned.
So
that's
kind
of
like
a
semi-unstructured
area
up
at
the
top
of
memory
that
has
all
of
these
blobs
that
you
know
can
be
held
more
or
less
indefinitely
and
their
lifetime
is,
you
know
different
for
each
one.
B
What
the
what
compilers
like
solidity
have
done
is
they've
they've,
said:
okay,
we're
just
not
going
to
store
we're
just
not
going
to
have
a
local
variable
stack
at
all
in
memory,
we're
just
going
to
store
everything
in
the
evms
evaluation
stack
and
and
accept
the
limitations
that
come
from
that.
I.
F
E
B
C
Interesting
so,
and
in
short,
then,
basically,
what
we'd
be
able
to
do
is
we'd
be
able
to
differentiate
more
easily
between
more
ephemeral
data
and
data
that
needs
to
stick
around
for
longer
without
running
into
these
nightmares.
So
just
knowing
where
the
like,
what's
still
being
used,
what's
not
being
used
fitting
fitting
new
information
around
it.
C
G
B
B
G
Yeah
I
hadn't
heard
of
the
rule
so
for
the
sharding.
I
remember
you
mentioned
something
about
like
it's
almost
like
an
asynchronous
process.
Would
you
say
that
the
current
way
that
the
evm
is
built
is
like
comparable
to
say
like
a
single
threaded
process
and
then
the
sharding
would
be
multi-threaded.
B
I
think
sharding
is
more
like
multiple
processes
than
multiple
threads,
because
they
can't
directly
communicate
with
each
other,
except
by
passing
messages
and
in
the
case
of
any
practical,
either
sharding
or
roll-up
system.
Those
messages
have
to
be
asynchronous
and
that
your
your
calling
process
can't
hang
around
and
wait
for
the
result
to
come
back,
and
why
would.
B
So,
in
the
case,
I
think
where
you
had
where
you
have
multiple
identical
shards
the
the
attraction
is
that,
if
you're
on
the
same
shot
as
say
uniswap,
then
you
can
make
synchronous,
calls
to
uniswap
and
get
the
result
back
and
that's
simpler
and
more
efficient
and
also
faster
in
the
sense
that
you
can
respond
to
the
data
it
returns
in
the
very
same
block.
But
if
you're
on
another
block-
oh
sorry,
another
shard,
then
you
have
to
send
a
message
and
then
wait.
B
Potentially
several
blocks
for
the
response,
which
is
both
more
complicated
to
program
with
and
if
you're
trying
to
do
something
like
arbitrage
is
just
doesn't
work.
So
you
have
this
perverse
incentive
to
all
group
together
on
the
same
place
and
potentially
you
end
up
with
a
few
sort
of
hot
shards
and
a
whole
bunch
of
ghost
shards
that
are
a
little
used,
and
so
your
your
actual
scalability
is
much
worse
than
your
theoretical
scalability.
G
Would
you
say
that
a
major
like
one
say
like
fanatical
or
fantastical
solution
would
be
a
framework
where
the
it's
like
asynchronous
processes
are
handled
like
are
kind
of
the
basis
of
the
functionality,
so
the
benefit
of
being
synchronous
on
the
same
chart,
for
example,
would
be
outweighed
by
the
benefit
of
multiple
shards.
I
I.
B
Asynchronous
communicating
processes
is
a
really
interesting
model
and
it
would
have
been
a
really
good
candidate
for
ethereum
from
day
one.
I
I
think
it
would
be
really
neat,
I'm
unsure
how
practical
it
would
be
to
retrofit
in
the
sense
that
I
mean
yes,
we
we
can
afford
to
break
some
backwards,
compatibility
moving
to
f
2.0.
C
B
Yeah,
I
stack
based
machines.
I
think
generally
tend
to
be
reasonably
concise,
except
insofar
as
sometimes
they
require
the
whole
push
something
and
then
do
something
with
the
thing
you've
pushed,
which
can
can
give
a
slight
expansion
of
of
size.
I
think
in
general
they
tend
to
be
reasonably
concise.
B
You
know,
at
least
by
my
standards.
There
definitely
can
be
less
readable
because
you've
got
a
lot
less
locality
in
terms
of
where
your
references
are
coming
from.
You
know,
you
see
this
add
up
code,
and
you
know
it
takes
the
top
two
arguments
from
the
stack
but
tracing
back
where
those
two
arguments
came
from
is
a
whole
hassle
all
on
its
own,
complicated
by
how
difficult
the
evm
is
to
statically
analyze.
B
So
other
vm
models
like
register
based
vms
are
definitely
more
human
readable
if
you're
looking
at
the
text
form
of
the
the
vm
byte
code.
But
if
the
evm
was
more
statically
analyzable,
we
could
write
tools
that
make
them
just
about
equally
easy
to
read.
You
know
you
could
annotate
your
ad
up
code
in
the
decl
and
the
disassembly
with
you
know,
arrows
or
indicators
or
variable
names
pointing
to
where
those
arguments
come
from,
which
would
make
it
much
easier
to
follow.
B
C
C
C
B
So
so
I
might
be
disappointing
here
and
that
I
actually
think
that
the
event
logging
system
is
one
of
the
best
design
bits
of
the
evm,
the
the
the
original
vision
and
and
which
a
lot
of
contracts
actually
implement
is
that
when
something
changes
in
your
internal
state
that
is
relevant,
you
log
that
event
in
such
a
way
that
an
external
process-
that's
replaying.
All
of
those
events
can
reconstruct
your
internal
state,
or
at
least
the
bits
that
are
relevant
to
external
observers.
B
B
But
it's
also
a
fundamentally
difficult
issue
is
how
do
you
index
data
when
you
don't
know
what
the
query
pattern
is
going
to
be?
You
know
we
have
indexed
fields,
but
that's
about
the
most
flexibility
we
have
and
yet
nodes
have
to
somehow
store
all
of
this
data
in
a
way
that's
efficiently
retrievable
when
they
don't
know
their
applications
and
they
don't
know
what
their
users
are
going
to
want
and
they're
also
constrained
in
terms
of
the
processing
resources
they
can
devote
to
it
without
opening
themselves
up
to
dos
attacks.
B
They're
going
to
be,
you
know,
give
me
the
balance
of
the
top
10
accounts
or
something
which
would
always
fundamentally
require
replaying
and
summing
up
every
single
event,
which
is
just
not
practical.
So
you
have
to
maintain
these
application.
Specific
databases
that
index
stuff
that's
relevant
to
that
particular
application,
which
nobody
can
know
on
a
sort
of
a
a
node
designer,
certainly
can't
know
what
that's
going
to
look
like.
C
A
Thank
you,
william,
so
yeah
moving
on
to
the
next
section
to
like
the
eip
process
section,
but
before
that
I
would
like
to
thank
william
to
bring
nick
on
the
show.
I
mean
it's
re.
I
have
heard
that
it's
really
hard
to
get
to
you.
I
mean
I
would
like
to
give
some
credit
to
twitter
as
well
that
helps
you
give
break
time
to
time
whenever
you
need.
A
B
Bips
originated
from
pips
python
improvement
proposals
and
python
doesn't
have
that
issue
like
every
python
improvement
proposal
is
a
change,
a
proposal
for
a
change
to
the
spec
of
python,
and
if
you
accept
it,
if
it's
accepted,
then
it's
implemented
as
a
change
to
the
spec.
You
don't
have
this
whole
thing
of
this
is
defining
a
standard
by
which
you
know
you.
Should
we
just
advise
you
do
a
thing.
E
B
The
rc20-
or
this
is
defining
like
a
fundamental
change
to
the
system,
so
in
a
way
we
were
on
our
own
with
you
know
neither
neither
precedent
being
very
useful
in
terms
of
figuring
out
how
to
separate
out
these
things
or
separate
the
concerns.
I
guess,
and
initially
I
think
the
the
eip
process
was
quite
messy
as
a
result,
because
nobody
really
anticipated
this.
You
know
becoming
a
thing
and
as
a
result,
there
was
a
lot
of
politicizing
around.
B
You
know
how
eips
should
be
approved
and
and
so
forth
and
and
effectively
people
saw
them
as
a
governance
mechanism
for
what
goes
on
the
chain.
So
my
motivation,
when
I
was
acting
as
an
editor,
was
really
to
try
and
separate
that
out
to
say
look.
This
is
a
technical
standardization
process.
This
is
how
you
standardize.
B
You
know
this
is
how
you
standardize
the
specification
of
a
thing
in
a
way
that
everybody
can
read
and
agree
that
it
says
the
same
thing
and
then,
if
you
want
to
take
that
standard
and
say
we
should
implement
this
on
the
ethereum
main
net,
then
that's
something
you
should
pretty
much
do
outside
the
eip
process.
What
we've
done
is
we've,
provided
you
with
a
clear
spec
that
everybody
can
agree
will
implement
the
same
on
on
every
node.
A
No,
that
is
really
good
to
know
like
we
also
have
joined
by
james,
so
james
is
presently
leading
the
the
second
half
that
you
said
that
contains
more
controversy,
which
should
go
in
and
out
by
taking
a
lead
on
like
a
network
upgrade
process.
So
I
believe
that
this
process
would
is
going
to
be
very
helpful
for
you
as
well.
A
So
talking
about
the
categories
and,
like
you
know,
the
eip
categories.
Initially,
we
had
like
three
different
categories
started
informational.
I
feel
that
standard
track
is
the
only
category
that
is
making
good
number
of
improvement.
Proposals
like
other
two
categories
met
and
information
are
underutilized,
so
in
some
cases
like
we
have
recently
observed
that
many
people
are
just
creating
upper
requests
with
individual
dap
specific
use
cases
and
making
that
as
an
informational
aip.
A
B
Minimum
bar
probably
needs
to
be
that
it
is
sufficiently
of
interest
to
a
sufficiently
broad
spectrum.
So
if,
if
you're,
what
you're
standardizing
is
just
one
particular
depth
nomenclature
or
notation
or
or
numbers
registry,
or
something
like
that,
you
probably
don't
need
neep
for
this.
You
can
you
can
document
it
anywhere
you
want
that
is
reasonably
stable.
B
I
I
think,
though,
that
in
terms
of
information
leaps
specifically,
we
don't
necessarily
need
parity
between
that.
You
know
the
numbers
of
information
leaps
and
the
numbers
of
standards.
Trackies,
there's
always
going
to
be
some
types
that
are,
that
are
a
lot
more
specific.
You
know
a
lot
more
less
of
interest
to
the
general
technical
developing
population,
so
I
guess
my
general
push
would
be
for
a
lot
of
stuff
that
people
want
to
write
up
as
an
informational
leap.
B
Consider
whether
you
need
me
at
all
in
the
first
place,
all
right.
One
tangential
thing
is,
I
wonder
if
at
some
point
it
would
be
useful
for
the
eeps
process
to
have
the
equivalent
of
the
ietf's
registries,
because
currently
we
have
a
number
of
standards
that
require
defining
a
registry
of
some
kind
of
mapping
between
numbers
and
allocated
identifiers,
and
the
canonical
example
in
the
wider
ecosystem
is
slip
44
with
the
coin.
Ids,
that's
not
really
a
standard.
B
You
can
define
a
standard
which
is
how
to
use
those
and
encode
those
and
so
on,
but
the
list
itself
in
the
case
of
the
ietf
they've
quite
sensibly
separated
that
out
and
they've
said
this
is
a
registry
and
a
registry
has
rules
for
amending
it,
and
that
gets
around
the
issue
that
you
want
your
standard
to
be
stable
and
and
eventually
fixed.
But
you
need
your
registry
to
be
a
thing
that
grows
over
time.
A
Interesting,
so
I
have
one
last
question
on
this
like
please
excuse
me,
quoting
you
here,
one
of
your
quotes.
I
found
that
I
I
don't
cheerleader
and
I'm
happy
to
talk
about
ethereum,
shortcoming
and
trade-off.
So
my
question
is
the
here
that
may
lead
to
controversy.
I
do
not
want
to,
but
I
just
want
to
get
your
opinion
here.
A
few
minutes
ago
we
saw
some
discussion
on
the
like
what
should
be
there
in
the
eip
repo
should
we
have
ercs
as
a
separate,
I
mean
separated
from
the
present
eip
repo.
B
E
Yeah
just
a
quick
question:
you
mentioned
a
bunch
of
a
lot
of
the
core
developers,
talk
about
separating
out
the
politics
from
the
the
specification,
but
that
always
seems
problematic
to
me
and
and
if
you
have
a
hierarchical
organization,
it's
not
problematic
because
the
guy
at
the
top
and
says
thou
shalt
do
this
and
everyone
does
it.
But
if
it's
leaderless
like
ether,
is
you
risk,
forks
and
all
those
kind
of
problems,
but
I'm
interested
in
solving
that
problem?
E
How
can
you
do
hard
things
like
you
mentioned,
an
asynchronous
switching
to
an
asynchronous
programming
paradigm
or
any
or
recovering
a
million
dollars
worth
of
ether,
that's
locked
up
in
a
contract
or
any
that
you
know
everyone
wants
to
make
that
change,
but
it's
too
controversial,
but
I'm
interested
in.
Can
we
solve
that
problem
and
we're
working
on
a
tool
to
that?
I
I
think,
could
make
that
more
possible.
But
anyway,
do
you
have
any
ideas?
B
B
I
think
the
the
biggest
things
that
I
think
are
impractical
are
mostly
because
of
their
wide
ranging
technical
implications
rather
than
because
of
controversy,
or
rather
they
would
be
controversial,
because
the
argument
would
be
whether
or
not
this
is
worth
the
the
difficulty
of
implementing
it.
So,
for
instance,
greg
colvin's,
you
know
better
jump
off.
Codes
are
a
definite
step
forward
in
terms
of
static
analysis,
but
nothing
it's
it's
still
a
partial
measure,
because
you
know
the
real
measure
would
be
like
evm
v2
everything.
B
B
We've
looked
at
the
evm
in
detail,
here's
a
v2
that
satisfies
all
these
requirements-
and
you
know
maybe
we'd
just
do
one
thing:
we'd
make
it
more
statically
analyzable,
rather
than
also
trying
to
fix,
word
size-
and
you
know
you
want
it
to
still
resemble
the
evm
and
we'd
go.
You
know
now
we're
going
to
propose
a
hard
fork
to
include
support
for
this,
this
v2
evm
and
then
later
maybe
we're
going
to
prohibit
deployment
of
new
v1
evms.
B
If
you
want
to
get
really
controversial,
but
then
that
leads
to
all
sorts
of
problems,
because
it's
effectively
impossible
to
completely
prohibit
deploying
old.
You
know
evm
v1
code
for
various
reasons,
but
I
think
the
again
the
main
controversy
around
that
would
be
that
introduces
a
lot
of
work
for
node
developers.
It
introduces
a
lot
of
technical
risk
around
new,
bugs
and
so
forth.
B
E
Okay,
cool
so
probably
for
what
I'm
looking
for,
probably
just
finding
a
100
million
dollars
worth
of
ether,
that's
locked
up
and
just
seeing
if
we
can
find
up
a
mechanism
that
we
can
get
everyone
and
prove
that
everyone's
on
board,
with
with
a
process
to
recover
100
million
dollars
worth
of
ethernet.
I
can't.
B
H
B
E
B
H
E
A
Thank
you.
Thank
you
brent.
We
probably
went
a
little
over
time,
but
I
think
it
was
totally
worth
it.
I
wanted
to
touch
a
little
bit
on
enos
as
well,
but
maybe
we'll
save
it
for
some
other
time.
Also,
I
see
some
proposals
are
there,
which
I
think
would
be
worth
discussing
it's
in
some
point
of
time.
Maybe
we
we
should
arrange
another
meeting
with
you,
nick
sometimes
in
february
march,
if
you
are
available
and
we'll
try
to
arrange
that.
A
We
discussed
some
potential
direction
for
new
eips
core
eips,
specifically
so
viewers.
If
you
have
a
got
a
proposal
and
you
are
planning
to
document
it.
Please
follow
the
suggestions
that
we
discussed
today
and
we
also
have
an
episode
with
matt
garnett
on
writing
the
eip.
So
if
you
haven't
watched
that-
and
you
are
planning
to
write
it-
that
right
and
a
proposal,
it's
highly
recommended
to
watch
and
it
will
provide
you
a
feel
of
what
are
do's
and
don'ts
for
a
very
good
proposal.
A
We
started
this
peep
and
eat
series
in
late
august
this
year
with
hopes
that
it
will
help
explain
core
proposals
under
discussion,
create
awareness
about
the
eips
and
ercs
and,
above
all,
contribute
to
the
process
improvement.
I'm
very
excited
to
share
that.
It
has
created
a
distinct
place
in
the
eip
resources
and
is
very
helpful
for
a
proposal
overview.
A
This
is
the
last
episode
for
2020,
but
we
have
got
quite
a
few
interesting
proposals
lined
up
for
2021,
so
stay
tuned
with
us.
If
you
have
questions
comments
and
concerns
about
this
episode
or
any
other
eip,
and
I
have
suggestions
that
which
proposal
can
be
included
in
our
show.
Next,
please
leave
a
comment
if
you
liked
this
episode,
don't
forget
to
hit
like
and
share
button.
A
Do
subscribe,
ethereum
categories
youtube
channel,
you
may
find
twitter
handle
for
today's
guest
and
rest
of
the
participants
of
this
meeting
in
the
description
section
below
we'll
be
back
in
january
2021
with
another
new
proposal
till
then
keep
sharing
your
love
with
cat
hairdressers.
This
is
your
host
position,
signing
off
happy
holidays
and
a
very
happy
new
years
cheers.