►
From YouTube: PEEPanEIP #28: EIP-1474: Remote procedure call specification with Erik Marks & Marius VanDerWijden
Description
Resources:
- EIP: https://eips.ethereum.org/EIPS/eip-1474
- Discussion to: https://ethereum-magicians.org/t/eip-remote-procedure-call-specification/1537
- Presentation: https://docs.google.com/presentation/d/1HuzXqr-a9w4gQSz_BtXhM1T2rOszZnMXhmg90vZydz0/edit?usp=sharing
Topics:
2:10 - Introduction
3:30 - EIP-1474: Overview by Eric
4:20 - RPC demo with Metamask test dApp
10:30 - JSON RPC standards by Marius
10:52 - JSON RPC History
13:10 - Why JSON RPC?
14:47 - JSON RPC in Geth
15:45 - Geth's requirement
20:10 - Adding a new method (demo)
23:40 - EIP-1474 feedback by Tomasz (Nethermind)
27:40 - Thoughts on RPC standards standardization process. Should it be standardized with the EIP process or should we have a different process in place?
35:50 - What could be the biggest challenge in terms of implementation in different clients?
38:05 - Thoughts on standardizing JSON RPC API as a living EIP?
39:49 - From the API provider's point of view, any specific advantage that you'd like to mention and anything that you'd like to see it getting done before the JSON RPC goes into the next level of standardization?
45:50 - Funding the authors for creating a standard
47:33 - Roadblocks on doing an EIP
49:26 - A peep on PR-3410 wrt EIP-1474
53:15 - What are the historic ways of implementing an interface proposal in Geth? Is EIP-1474 already implemented?
55:33 - Moving to "Review" status
58:04 - Removal of outdated texts before creating the pull request.
Follow at Twitter:
Erik Marks @rekmarks | Marius Van Der Wijden @vdWijden | James Hancock @JHancock | William Schwab @William94029369 | Alita Moore @AlitaMoore85 | Brent Allsop @Brent_Allsop | Pooja Ranjan @poojaranjan19
Related EIPs on RPC:
EIP-3085: Wallet Add Ethereum Chain RPC Method with Erik Marks - https://youtu.be/nOIl2w33sGU
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow PEEPanEIP earlier episodes at https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.gg/tzYmDmF
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
Ethereum
is
the
biggest
blockchain
with
several
nodes
running
on
different
clients,
but
there
is
no
formal
ethereum
rpc
specification,
at
least
not
in
the
full
state.
Yet
this
proposal
aims
to
standardize
the
specification
to
provide
developers
with
a
predictable
ethereum
rpc
interface,
regardless
of
underlying
node
implementation.
A
Eip1474
is
a
standard
track
interface
proposal
proposed
in
october,
2018
and
currently
in
draft
status.
This
is
an
active
discussion
and
the
ethereum
oss
team
started
to
push
the
standardization
with
monthly
meeting
since
january
2021..
There
is
also
a
discussion
channel
on
eat
rnd
discord
for
people
interested.
They
can
share
their
thoughts
there
to
talk
about
the
proposal.
A
A
For
those
who
aren't
aware,
eric
has
also
co-authored
eip3085
wallet,
rdt
chain,
rpc
method
and
was
on
our
show
two
weeks
ago.
So,
if
you
have
missed
watching
the
talk,
you
may
follow
the
recording
available
on
penny
playlist
at
ethereum
cathedrals.
So
without
further
ado,
let's
welcome
our
guest
thanks
for
joining
eric
and
maurice
may.
We
have
a
quick
intro
and
then
we
will
proceed
with
the
presentation
and
the
discussion.
B
C
B
I'm
I'm
going
to
introduce
the
eip
and
talk
a
little
bit
about
the
json
rpc
api,
like
what
it
is
and
so
forth,
and
then
I'll.
Let
mars
talk
about
it
from
his
perspective
and
then
we
have
a
lot
of
people
with
a
vested
interest
in
moving
this
proposal
forward,
and
you
know
interesting
perspectives
on
it
as
well.
So
hopefully
proceeding
to
interesting
discussion
from
there,
but
I'll
begin
by
just
sharing
my
screen
so
yeah.
B
B
It
was
originally
written
by
paul
beauchamp,
who
was
a
part
of
metamask
but
as
far
as
I
know,
is
no
longer
working
in
ethereum
or
cryptocurrencies.
Generally,
we
at
metamask
we
decided
to
that.
We
wanted
to
create
the
cip
because
there
existed
no
standard
or
or
even
the
ip
attempting
to
standardize
the
ethereum
json
rpc
api.
B
B
B
B
B
None
of
the
client
teams
became
involved
in
trying
to
drive
the
standard
forward
and
those
are
sort
of
the
probably
the
most
important
people
to
to
get
on
board
in
order
to
actually
standardize
at
the
api
that
ultimately
they
implement.
I
mentioned
that
from
metamask
perspective.
There
are
some
rpc
methods
that
are
implemented
directly
in
metamask
and
some
that
are
implemented
by
the
ethereum
clients
and
for
the
ones
that
are
implemented
by
the
clients
we
just
route.
B
B
C
C
C
They've
been
continuously
updated
whenever,
like
a
new
erp
eip
introduces
some
new
functionality
or
something,
and
we
need
a
rpc
method
for
that,
then
it
was
implemented
and
yeah
there's
no,
no
formal
standardization
process
until
like
two
years
ago,
and
what's
really
interesting,
we
have
like
ten
different
modules,
so
we
have
different
modules
in
in
go
ethereum
for
different
functionality.
We
have,
for
example,
the
miner
module
which
provides
access
to.
C
C
Because
some
of
these
apis,
you
don't
really
want
to
want
to
like
open
them
up
for
for
everyone
to
consume.
So,
for
example,
if
you,
if
your
note
is,
is
online-
and
you
want
to
let
other
people
query
your
note
for
for
current
tx
pool,
for
example,
or
something,
then
you
don't
really
want
to
also
let
them
send
transactions
or
sign
transactions
over
your
node.
C
So
we
have
different
name
spaces
and
just
as
an
example,
there
are
like
110
methods
only
in
the
eighth
and
the
debug
name
space,
and
we
also
have
some
problems
with
overlapping
methods.
For
example,
we
have
sign
personal
sign
and
then
sign
transactions
once
in
eth
in
the
east
module
ones
in
the
personal
module,
and
they
are
a
bit
different,
but
yeah.
There
are
several
instances
of
that.
C
Why
did
we
choose
json
rpc?
In
the
first
place?
I
think
it's
really
important
for
for
ethereum
nodes
to
have
a
human,
readable
format
makes
it
easier
for
for
people
to
write,
call,
requests
and
and
send
like
easy
requests
to
the
handwritten
requests
to
the
note,
which
is
nice
and
also
it
makes
debugging
a
lot
easier.
C
C
There's
a
discussion
to
be
had
about
changes
in
the
dialogue
protocol,
so
there
are
queries
that
are
pretty
heavy.
For
example,
if
I
ask
you
give
me
the
state
at
block
x
or
give
or
trace
me
this
transaction
so
execute
the
transaction
and
show
me
every
every
state
that
this
transaction
executed
or
every
every
opcode
every
every
function
that
it
called
these
queries
can
be
quite
heavy.
C
However,
they
are
not
really
encoding
heavy,
so
the
heaviness
is
basically
on
the
node
and
there
there
is
some
some
discussion
to
be
had
about
the
dialogue
protocol,
for
example,
for
caching,
for
caching
certain
queries
or
something,
but
I
think
in
general
we
all
agree
that
json
rpc
is
the
the
best
format
for
for
ethereum
right
now,
jsonrpc
and
geth.
You
can
you
have
two
ways
to
consume
it,
either
via
http,
websocket
or
ipc.
C
C
What's
what's
really
lacking
in
the
current
standard,
is
error
handling,
so
this
is.
This
is
a
personal
issue
of
mine
that
currently
there's
not
really
a
way
for,
and
I
think
rick
from
ethers
will
agree,
there's
currently
not
really
a
way
to
check
which
error
occurred.
Other
than
then
like.
Comparing
for
the
error
message,
which
in
turns
mean
in
turn,
means
if
we,
if
we're
updating
our
error,
messages,
we're
going
to
break
stuff
out
there,
and
this
is
really
bad
because
it
yeah
it.
C
C
For
example,
we
have
debug
dot,
start
cpu
profile,
which
in
start
and
stop
cpu
profile,
which
starts
cpu
profiling,
our
node,
I
think.
In
the
end,
it
would
be
okay
if
we
have
a
gas
dot.
Starch
cpu
profile
instead
of
debug
dot,
stop
cpu
profile,
but
I
think
it
is
important
also
for
like
retaining
client
diversity
that
we
have
client,
specific
methods
which
would
also
enable
us
to
quickly
extend
our
own
implementation.
C
So
in
the
future,
I
think
we
are
already.
We
already
talked
about
that
in
the
in
the
json
in
in
the
json
standardization
calls
that
we
want
to
have
a
common
test
harness
now.
I
wanted
to
show
you
a
bit
how
the
workflow
works.
If
you
want
to
implement
a
new
method
for
that,
I
have
it
here
on
the
slides,
but
I
think
I
have
enough
time
to
also
show
it
to
you
live.
C
So
if
you
have
a
new
method
here,
you
can,
for
example,
I
I
want
to
create
an
access
list.
You
go,
you
implement
the
access
list
in
some
file
somewhere
and
now
you
have
to
you,
have
to
go
to
eth
api.go
and
basically
you
have
these
public
debug
api
objects
or
private
debug
api
objects,
and
you
can
create
a
new
method
there.
That,
for
example,
creates
the
access
list,
so
you
can
create
the
access
list.
C
If
I
now
start
a
geth
note,
I
can
use
our
new
api
newly
created,
debug
dot,
access
list,
dot,
create
sorry
debug.create
access
list
and
it
will
create
you
an
access
list.
Unfortunately,
because
you
you
don't
like,
there's
a
there's,
an
issue
with
the
creation
right
now,
but
it
will
give
you
out
the
access
list
so
yeah.
So
if
you
ever
want
to
implement
a
rpc
method
in
one
of
the
clients
or
in
gath,
I
just
showed
you
how
to
do
that.
A
D
I
think
actually,
if
I
could
even
maybe
try
and
direct
hamas
as
a
lead
director
of
a
client,
I'm
interested
just
to
hear
what
your
feedback
is
about.
The
eip
in
general,
maybe
about
another
minds,
implementation
of
the
rpcs
of
the
the
the
eip
and
and
what
your
thoughts
are
in
general.
Maybe
you
could
kick
that
off.
D
F
E
Yeah,
I
think
I
think
that
when
looking
at
the
gap,
implementation
there's
lots
of
lots
of
similarities,
of
how
we
see
about
like
what
kind
of
complexities
adding
new
json
rpc
methods
can
cause
and
there's
not
that
many
I
mean
like
it
seems
to
be
generally
by
most
of
the
clients
supported
as
either
plugins
or
simple
code.
Modifications.
We've
all
built.
Some
kind
of
modules
features
here,
so
json
rpc
is
definitely
friendly
for
for
users
and
we've
seen
many
discussions
around.
E
Oh
when
you,
when
you
have
json
or
pc,
should
you
replace
it
with
something
more
performant
like
protobufs
or
grpc?
Or
should
you
replace
it
with
some
different
format
or
whatever?
And
it
comes
back
over
and
over
again
because
of
ethereum
2
choosing
different
formats
because
of
trying
to
standardize
and
asking
people
before
standardizing
whether
they
would
like
to
go
to
other
format.
E
But
we
see
that
quite
a
lot
of
people
say
that
it's
actually,
they
like
it
as
human
readable
that
they
like
it
as
reasonably
simple,
even
if
it's
not
most
efficient,
because
this
is
created
for
integrations
for
quick,
dynamic
integrations
and
it's
also
very
consistent
with
the
approach
from
from
crypto
community.
Like
I
never
used
it
myself,
but
I've
heard
bitcoin
use
a
json
rpc
as
well
for
for
most
of
this
integration,
so
it
seems
very
natural
choice.
Sorry,
if
I
say
too
much
here,
but
also
come
from
different
angles.
E
So
we
work
on
this
standardization
effort
by
by
ethereum
oasis
on
this
rpc
and
being
fully
aware
of
eip1474.
Was
there
and
thinking
of
how
not
to
repeat
that
effort
and
how
to
just
improve
it.
We
treat
eep
1474
as
the
basis
for
everything
that
we
do
so.
First
of
all,
it
introduces
the
agreement
on
the
all
the
basics.
So
like
what
quantities?
E
What's
the?
How
is
hash
represented?
How
are
the
numbers
represented?
How
are
the
error
codes
returned
and
so
on?
And
then
it
goes
to
by
presenting
various
methods.
I
think
the
ethereum
oasis
discussion
with
multiple
teams
ends
up
with
the
approach
when
1474
is
this
meta
iap
that
describes
all
the
things
that
are
reusable
by
all
the
different
modules
and
methods.
E
But
what
we
also
want
to
deliver
is
every
single
method
to
have
its
own
specification,
because
we've
seen
that
trying
to
trying
to
describe
this
in
our
pc
as
a
whole
or
as
a
module
by
module
ends
up
having
those
differences
between
clients
standing
in
the
way
of
just
achieving
something,
simple
and
just
clear
and
something
that
everyone
agrees
on
so
yeah.
Sorry,
I
listened
to
this
one.
I'm
really
interested-
and
I
think
it's
amazingly
well
written
eip,
but
also
tackling
the
complexity
of
having
to
to
describe
everything
with
all
those
clients,
differences.
C
Yeah
I
I
agree.
I
agree
with
that
that
the
current
eip
tries
to
yeah.
It
tries
to
do
everything
and
it's
hard
for
everyone
to
agree
on
on
everything.
That's
why
I
that's
why
I
said
that
maybe
the
eap
process
yeah.
Of
course
we
can.
We
can
create
a
single
eap
for
for,
like
every
every
every
rpc
call,
but
that
will
quickly
get
out
of
hand.
I
think
so
if
we
like
standardize
like
100
200
rpc
calls.
C
B
I
think
that
that
is
to
me
a
very
interesting
question
and,
and
speaking
from
like
the
perspective
of
metamask,
we've
ended
up
in
situations
where
we've
wanted
to
add
a
new
feature.
Like
most
recently,
we
have
the
ability
for
adapts
to
suggest
evm
chains
to
add
to
the
user's
wallet
and-
and
that's
the
after
mentioned
eip
3085,
and
we
chose
to
implement
that
as
a
we
chose
to
create
a
json
rpc
method
in
the
wallet
underscore
namespace.
B
So
I
think
in
my
mind,
the
like
the
status
of
living
like
living
eips
is
a
bit
of
an
underexplored
space.
So
I'm
wondering
if
because
in
my
mind
the
biggest
thing
for
eip
for
an
eip
standardizing
the
json
rpc
api,
the
biggest
problem
for
it
to
solve
is
like
how
do
we
change
it?
How
do
we
add
new
things
to
it?
B
A
I
quickly
want
to
like
address
this
one
thing
like
the
issues
with
the
process
that
that
has
surfaced
here.
Yeah
I
mean
we
are
trying
to
improve
the
eip
process
and
there
is
a
group
specifically
eipip
group.
We
are
actually
considering
collecting
all
the
grievances
and
issues
that
has
been
faced
by
either
the
author
or
decline
team,
get
it
fixed
and
improve
the
new
process,
but
for
now
I
can
just
for
this
specific,
the
cib.
D
D
So,
on
the
one
hand,
we've
got
the
core
evm
eips,
where
any
evm
when
will
have
a
specific
amount
of
opcodes,
no
client
can
implement
additional
opcodes
and
they
all
must
have
all
of
the
op
codes
that
are
present,
but
when
you
take
a
look
at
something
like
the
erc
track
or
the
standards,
so
if
somebody
has
an
extension
that
they
want
to
put
on
your
rc20,
they
don't
need
to
make
a
new
eip.
For
that
you
know
they
don't
need
anybody's
permission.
D
D
Eips
that
represent
any
client
will
have
these
rpc
calls
and
we'll
make
these
calls
these
ways,
but
that,
in
a
way
that
doesn't
mean
that
this,
these
are
the
only
json
rpc
calls
that
a
client
that
a
client
could
have
that
way.
You
give
the
clients
their
flexibility
they
can
put
in
their
independent,
their
independent
calls.
They
have
their
independent
ways
of
doing
things,
but
there's
also
kind
of
just
the
foundation
of
the
basics
there
for
anybody
else,
who's
implementing
a
new
client
or
who
wants
to
know
how
to
make
certain
calls.
F
I
I
just
wanted
to
agree
with
the
that
the
eip
process
is
really
cumbersome
for
stuff
like
this
and
like
historically,
everything
was
done
through
the
eip
process
and
then
recently
we
realized
that
the
hard-fought
coordination
stuff
that
goes
decisions
onto
mainnet
doesn't
really
fit
in
the
eip
process,
and
so
what
we
haven't
done
yet
is
figure
out
kind
of
what's
in
between
and
what
fits
where.
And
at
least
for
me
like
it
sounds
like
jason,
rpc
or
networking.
F
Stuff
is
very
mainnet,
specific,
not
really
general
standard,
specific
and
so
some
other
place
and
other
way
to
do.
It
entirely
would
be
totally
appropriate.
And
I
and
I'd
like
to
hear
kind
of
more
ideas
on
what
that
could
be
or
where
that
could
live.
Just
like
completely
free
up
the
process
entirely.
E
I
think
this
so
far,
this
agreement
in
middle
ground
looks
like
not.
A
single
client
thinks
that
it
should
be
a
set
in
stone
set
of
the
methods
we
want
to
have
that
flexibility,
and
I
think
there
every
single
client
has
some
methods
that
will
never
be
re-implemented
anywhere
else,
because
they're
specific
for
the
client
and
they're,
not
necessarily
in
the
client
name
modules
like
gaff
underscore,
and
then
they
might
underscore
they
might
be
interweaved
with
other
things.
E
What
we
found
important
was
to
provide
standardization
for
those
calls
that
have
been
in
use
for
four
years
in
major
integrations,
but
still
cause
trouble
to
the
integrators,
because
there
are
some
minor
edge
case
differences
between
various
clients.
I
think
this
great
examples
are
if
you're
sending
eth
estimate
gas
without
the
from
field
or
the
gas
price
field
specified
or
the
gas
limit
specified
what
the
estimate
is
assigned
to
the
transaction,
what
timeouts
will
happen?
E
You
only
discover
when,
when
users
start
to
report
that
to
you
and
then
when
they
report
it
to
you,
your
first
impression
is
that
you
actually
does
seem
to
be
behaving
okay,
very
intuitive
from
your
perspective,
but
you
just
see
that
it
doesn't
behave
exactly
the
same
as
other
clients
and
it
causes
a
massive
trouble
to
users.
So
that's
the
that's
the
direction
for
this
pair
methods,
eip
specification,
where
you
know
that
the
effort
required
for
eip
process
is
worth
it's
worth
it.
E
G
E
I
think
more,
the
discovery
of
all
of
these
things
and
just
describing
them
later
and
making
sure
that,
as
you
said
like
that,
it
may
get
out
of
control,
that's
what
maria
said
is.
If
we
end
up
with
ataps
for
80
different
methods,
it
may
be
a
bit
too
much,
so
maybe
we'll
stop
after
10
or
20
and
we'll
say
this
were
so
important.
Actually
that's
what
everyone
wanted
when
they
were
saying,
json
or
pc
standard,
because
we
keep
saying
json
rpc
standard
we
need,
but
maybe
we
simply
need
to
stand.
E
20
30,
most
basic
methods
and
everything
else
can
have
this
minus
minor
differences,
so
challenging
is
the
discovery
of
all
the
differences,
making
sure
that
you're
not
missing
it
and
and
showing
everyone
how
this
process
looks
and
just
delivering
it
implementation
wise.
Rarely.
This
causes
a
lot
of
trouble.
I
think,
unless
these
are
some
very
complex
methods
like
debug
tracing
but
yeah,.
B
You
know,
I
agree
with
the
points
raised
by
maurice
and
tomas
here
that,
basically,
the
ultimately,
the
implication,
implementations
by
the
client
teams
will
end
up
driving
the
standard
forward
for
like
new
editions
and
future
changes.
I
think
that's
basically
unavoidable,
regardless
of
how
we
would
like
a
standardization
process
to
work.
I
also
want
to
emphasize
that
I
don't.
B
B
No
there's
no
process
we
can
create
that
is
going
to
solve
the
problem
of
coordinating
between
all
of
these
different
stakeholders
in
these
in
this
api,
and
I
and
I
do
like
the
idea
of
basically,
you
know
identifying
the
things
that
we
absolutely
need
to
standardize
and
and
standardizing
those.
I
think
one
thing
that
I'd
be
interested
in
exploring
is
you
know
what,
if
we
created
a,
I
don't
know:
if
does
the
eap
process
specify
how
a
living
standard
is
updated?.
B
F
B
Right
so
this
I
mean
maybe
one
thing
for
the
you
know
this.
This
effort
led
primarily
by
tomas
to
standardize
the
json
rpc
api.
You
know
one
if
there
is
a
standard
like
the
thing
to
figure
out
is
like
how
do
we
update
that
standard,
and
when
do
we
update
that
standard
and
who
gets
to
choose
how
the
standard
is
updated?.
A
Obviously,
this
eip
1474
reaching
final
status
will
be
helpful
for
all
developers,
epm
developers
working
on
any
of
the
ethereum
clients,
but
because
it
is
an
interface
proposal
and
you're
from
the
ethos.js
from
that
is
an
apa
provider.
What
advantage
do
you
see
from
eip1474?
Getting
into
the
final
I
mean?
Is
there
any
specific
that
you
would
like
to
talk
about?
That's
number
one
and
number.
Two
is
like
anything
else
that
you
would
like
to
see
before
it
can
go
ahead
with
the
next
status
of
the
eip
standardization.
H
Hi
I'm
looking
forward
to
it
it's.
It
would
be
great
if
there
was
some
way
to
pull
these.
These,
I'm
not
sure
if
we
were
discussing
about
the
open,
json
rpc,
there's
some
sort
of
description
of
the
description
for
how
these
json
rpc
methods
work,
and
it
would
make
things
much
easier
to
pull
those
in
and
just
be
off
to.
The
races,
for
example,
ethers
in
a
lot
of
places
will
convert
chain
id
into
a
number
and
it
will
convert
gas
limit
into
a
big
number.
H
So
I
think,
by
having
this
sort
of
description,
it
might
be
easier
to
programmatically
make
those
type
of
bindings
where
it
produces.
What
makes
sense
so
for
the
things
that
are
common
like
get
transaction
by
hash,
get
block.
I
have
my
own
hard-coded.
Do
this,
do
that,
and
do
this
other
thing,
but
when
new
things
come
on
get
proof.
H
This
is
something
that
would
have
to
be
added
manually
by
me
if
it
was
to
be
supported
across
the
board,
with
something
like
this
it'd
be
great
because
I
could,
theoretically
just
kind
of
so
if
I'm
using
a
proxy,
I'm
not
sure
how
technical
javascripty
people
are
here,
but
you
can
imagine
calling
a
brand
new
method
on
an
ethers
provider
object
that
simply.
I
was
unaware
of,
because
everything
returns,
a
promise.
Everything
is
deferred
and
asynchronous
anyways.
H
H
I
don't
know
if
savings
right
word,
I
feel
like
it
would
mean
I
could
interoperate
with
things
that
I
didn't
even
know
existed
in
a
meaningful
sense,
at
least
until
people
complained
saying.
Oh,
this
is
a
little
bit,
not
what
I
expected.
Can
you
make
it
do
this,
then
I
can
go
through
and
add
the
special
custom
thing
that
makes
the
world
happy
yeah.
So
I
mean
I'm
a
big
proponent
of
of
these
type
of
standards
in
general.
H
The
other
really
big
area,
I'm
looking
forward
to
is
having
standardized
errors
right
now,
when
I
get
an
error
in
ethers,
I
do
a
ton
of
string
replacements,
a
bunch
of
like
regexes
on
it,
because
parity
versus
ether
scan
versus
whatever
version
of
parity
or
ether,
scan
or
sort
of
parity
or
geth
alchemy
is
running.
The
strings
are
slightly
different
and
ether
scan
has
their
own
special
apis.
So
I
have
this
list
of
like
20
strings.
I'm
searching
through
does
the
word
insufficient
balance
occur
is
the?
H
Is
there
too
little
balance
for
this
operation
to
occur
like
I
have
to
find
all
these
different
things
so
that
I
can
feed
back
to
the
user
consistent
error,
because
at
the
end
of
the
day,
people
using
ethers
don't
want
to
have
to
replicate
these
20
strings?
That
might
happen
because
they
used
inferior
today
in
alchemy
tomorrow.
H
C
But
of
course
they
they
are
like
handwritten
and
only
written
by
us.
You
know
in
in
basically
our
free
time.
So
I
think
if
we
have
these
these
standards,
it
would
be
really
easy
for
for
anyone
and
for
for
all
the
teams
to
to
write
tests
that
can
be
used
by
everyone
else.
So
I
think
that's
what
I'm
that's,
what
I'm
really
looking
forward
next
to
to
the
to
the
errors.
A
Sounds
good,
but
if
I
understand
correct
like
at
at
this
stage
this
eip1474,
it
is
all
good
to
go
in
the
next
stages
status
of
the
eip
standardization.
It's
just
that
we
are
looking
for
some
more
improvements
which
may
be.
We
can
bring
it
with
the
help
of
some
other
proposal
or
the
improvements
later
on.
If
that
makes
sense,.
B
It's
like
a
full-time
job
to
drive
any
complicated,
ethereum
standard
through
to
the
end
like
when
we
were
standardizing
the
ethereum
provider
api,
which
is
an
effort
that,
on
this
call,
rickman
particular
was
it
was
involved
with
I
spent
I
had
to
spend
a
ton
of
my
time.
You
know,
while
I
would
have
you
know,
maybe
like
to
be
like
writing
code
for
metamask
working
on
the
standards
process
and
like
ultimately
like
I
enjoyed
it,
and
the
work
was
useful,
but
it
does
take
effort.
H
On
that
note,
actually
one,
so
I
feel
like
that's
the
thing
basically
doing
an
eip
is
a
tremendous
amount
of
effort,
and
I
do
find
that
there's
often
a
lot
of
weird
roadblocks
and
people
saying
things
and
and
pushing
back
on
things
that
maybe
basically
we
want
to
make
it
easier
and
more
friendly
for
the
eip
process
to
move
forward.
But
one
thing
especially
for
1193.
H
We
almost
need,
like
some
sort
of
person,
who's
hired
just
as
morale
booster,
because
no
matter
what
you
say,
you're
gonna
have
people
are
either
really
happy
about
it
or
really
really
angry
that
you're
not
doing
x,
y
or
zed,
and
you
almost
need
someone
like
pat
you
on
the
back
saying
like
it's:
okay,
it's
okay,
it's
just
one
person
there
or
four
people.
You
know
they're
they're
hating
on
it,
for
whatever
reason
or
whatever
we
just.
H
H
A
Okay,
I'm
definitely
gonna
like
raise
this
point
like
maybe
we
could
have
a
call
some
kind
of
community
call
to
discuss
and
collect
or
more
feedback
on
that,
but
for
now
let's
get
back
to
the
esp147
so
like.
I
would
like
to
give
a
special
mention
of
you
know
the
etienne
oss
team.
Thank
you
to
mass
for
organizing
eat
one
dot
x,
json
rpc
api
standard
meetings.
A
A
E
Yeah,
so
this
is
about
the
first
guideline
and
the
example
of
the
method
specific
eip.
So
instead
of
approaching
json
rpc
as
a
whole
and
started
standardizing
it,
we
create
a
single
template
showing
how
to
standardize
properly
with
all
the
details,
a
single
method-
and
we
pick
very
simple
one,
which
is,
if
block
number,
and
we
show
why.
We
think
that,
even
on
a
single
level,
a
single
method
level,
it
can
be
quite
complex
and
demanding.
E
E
So
we
we
ask
a
question:
what
does
it
mean?
The
latest
block
number
from
the
perspective
of
different
clients,
and
we
already
had
all
those
questions
about
what
does
it
mean
during
the
fast
sync?
What
does
it
mean
in
the
archives
thing?
Is
the
latest
block
the
one
that
we
fully
process,
the
one
that
we
know
about,
and
we
think
is
the
best
block
on
the
network?
E
A
A
I
know
this
is
not
a
core
proposal,
so
it
will
not
go
on
undergo
the
upgrade
the
hard
fork.
So
I'm
just
curious
like
how
historically
have
been
get
the
including
any
proposal
for
their
client
like
the
current
version
of
client.
Does
it
include
this
or,
if
not,
then
what
is
the
plan
of
including
it
in
client
specification.
C
C
A
Okay,
that
sounds
fair.
I
know
we
are
almost
at
time,
but
I
have
just
a
couple
of
questions
for
the
ap
author
that
is
related
to
eip
status.
The
number
one
is
like
moving
to
review
status.
I
think,
would
be
the
ideal
thing
to
do
at
this
point
of
time
if
we
want
to
move
it
along
the
eip
standardization
process,
so
that
it
can
gain
momentum
and
it
can
be
pushed
forward
as
we
know
that
eap
1474
is
also
required
by
a
handful
of
new
proposals.
A
That
also
requires
so
no
need
to
mention
that
creating
pr
sooner
rather
than
later,
will
be
helpful.
As
I
understand
the
priority
of
creating
pr
may
not
be
something
that
is
for
developers
so
as
always
I'll
be
happy
to
engage
cat
editors
if
needed.
But
if
you
can
go
ahead
and
create
the
pull
request,
that
would
be
helpful.
B
I
mean,
I
think
that
makes
sense,
because
because
the
point
is
like
we
don't
want
to
go
ahead,
take
1474
as
it
is
finalize
it
and
be
like
that's
the
json
rpc
api,
because
we
know
that
there
are
differences
between
the
client
implementations
and
if
we
just
finalize
something
that
doesn't
have
any
basis
in
reality,
the
client
teams
are
just
gonna,
ignore
it,
and
so,
but
I
think
like
keeping
it
as
a
living
standard,
and
you
know
basically
trying
to
make
it
match
reality.
After
the
fact
I
mean.
B
If
we're
you
know,
obviously
that's
not
how
maybe
in
an
ideal
world
how
we
do
how
we
would
want
to
do
standards,
but
in
a
realistically
that's
pretty
much
what
we're
gonna
end
up
doing
anyway,
and
obviously
you
know
nobody
has
based.
No,
you
know
ethereum
hasn't
been
stopped
from
progressing
because
1474
hasn't
been
standardized
up
to
this
point
right,
so
I
think
you
know
getting
it
into
a
living
status
sooner.
B
A
Sounds
good.
There
is
one
last
thing
that
I
want
to
bring
it
here.
It's
not
like
a
question,
it's
just
something
that
I
saw
in
the
proposal,
not
sure
if
it
relates
to
the
present
scenario,
the
mention
of
parity-
and
I
don't
know
if
they
are
still
supporting
ethereum
1.0
chain.
It's
particularly
in
the
implementation
section
of
the
proposal,
so
we
might
want
to
look
into
that
and,
if
appropriate,
might
replace
it
with
the
current
client
like
nether,
mind
b.
So
we
can
go
ahead
and
add
that
too.
B
A
This
was
really
great
thanks
for
suggesting
to
organize
it
in
a
different
way.
Eric
I'm
glad
we
were
able
to
bring
most
of
the
concerned
participants
on
one
call,
and
we
discussed
that
this
conversation
was
really
wonderful
and
we
came
up
with
different
suggestions
and
maybe
end
up
having
another
living
erb,
I'm
not
sure
of
that.
A
I
wish
to
see
this
proposal
going
on
a
fast
track
for
standardization,
although
I
don't
know
myself
like
what
fast
track
means
here,
but
by
understanding
it
sooner
it
will
reach
to
an
appropriate
status
will
be
helpful
for
both
the
ethereum
client
developers
and
the
dav
developers
for
having
a
formal,
ethereum
rpc
specification
which,
if
needed,
can
be
modified
through
the
process.
I
think
this
release
of
this
episode
may
have
cleared
many
doubts
and
answered
many
questions
on
this
note
for
all
our
youtube
viewers.