►
From YouTube: Ethereum Core Devs Meeting #115 [2021-06-11]
Description
A
A
A
A
A
A
We
can
maybe
skip
that
one
and
see
if
martin
comes
in
the
second
one
was
probably
the
simplest.
So
basically
the
idea
of
adding
the
effective
gas
price
to
eat
get
transaction
receipt
light
client.
You
had
a
pr
open
for
that
already.
It
seemed
like
everyone
was
roughly
in
favor
of
it,
but
we
did
just
wanted
to
check
here
to
see
yeah
if
there
was
any
objections
or
if
people
all
thought.
This
was
a
good
idea
and
let
me
post
kind
of
the
pr
here
but
yeah.
A
D
So
I
think
there
was
a
discussion
a
while
ago,
either
on
discord
or
maybe
in
some
other
channel
where
people
were
saying
hey.
Maybe
we
just
have
tx.gas
price
be
set
to
the
effective
gas
price,
and
so
when
you
do
eat
get
transaction,
it
would
return
the
effective
gas
price
for
for
all
transactions,
because
the
gas,
the
gas
price,
is
the
effect
of
grass
price
today
and
then
for
1559
transactions.
That
would
be
overloaded
to
be
the
effective
gas
price.
So
I
don't
know.
D
I
know
some
of
the
people
in
this
pr
specifically
want
to
do
the
latter,
where
the
gas
price
is
not
in
the
transaction
object,
and
it's
only
in
the
receipt
and
their
arguments
are
that
the
effective
gas
price
is
this
computed
property,
and
so
it
doesn't,
it
generally
computed
properties
generally
shouldn't
live
in
the
transaction
return
value.
They
should
be
things
that
are
sent
by
the
receipt
rpc,
but
that's
just
their
argument.
B
A
B
A
D
E
A
A
Yeah,
I
seems
like
the
one
kind
of
has
a
strong
opinion
on
it.
Yeah
like
client,
since
you
opened
it,
do
you
have
a
preference
for,
and
you
did
a
lot
of
the
work
on
the
fpr
as
well.
Do
you
have
a
preference
for
moving
it
like?
I
guess,
would
you
be
if
we,
if
we
just
like
merging
your
pr,
are
you
okay
doing
the
change
in
geth?
If,
if,
if
it
needs
to
happen,
so
that's
it
sure,
okay,.
A
D
A
A
F
Yeah
so
background
about
it
is
that
for
equal,
yes
and
parity
back
and
they
used
to
handle
things
differently,
guess
would
use
whatever
the
account
of
the
node
that
you
made.
The
column
would
use
that
as
the
like
the
caller,
if,
unless
otherwise
specified-
and
that
was
a
pretty
yeah.
Arbitrary
choice
apparently
used
the
zero
address.
As
the
sender.
F
And
gets
switched
over
to
that
as
well,
and
the
problem
is
that
the
xero
address
didn't
always
have
funds
and
as
a
solution
for
that,
we
use
the
zero
gas
price.
So
we
can
do
the
eighth
call,
you
can
see
what
happens
and
it
works
you.
We
can
specify
any
gas
limit.
You
want,
because
gas
doesn't
cost
anything,
and
the
problem
with
when
we
do
is
call
on
1559
is
that
it
has
to
cost
something
because
there's
a
base
fee
and
if
we
use
the
base
3,
we
have
to
charge
whatever
it
basically
is.
F
A
A
I
I
So
if
I
understand
correctly,
the
the
discussion
on
the
discord
we
want
to
for
this
function
h
call
to
work
in
two
modes.
One
mode
is
to
mimic
the
the
what
happens
in
reality
when
you
apply
some
transaction
on
a
specific
block
and
the
second
mode
is
to
just
analyze
the
control
code.
I
guess,
while
assuming
that
the
base
fee
is
zero
and
the
gas
price
is
zero,
so
just
to
omit
some
of
the
of
the
data
that
is
not
needed
for
that
for
that
mode.
I
So
I
think
the
right
way
to
discuss
about
it
is
to
first
decide,
what's
the
actual
meaning
and
the
usage
of
this
function,
should
we
just
assume
that
this
function
is
used
by
default
that
is
used
to
to
analyze?
What's
happened?
What
have
what
happens
in
reality
and
then,
if
we
want
to
use
it
in
some
other
specific
way,
then
we
need
to
provide
additional
additional
conditions
through
the
parameter
list.
A
A
Cool
and
the
last
json
rpc
thing
was:
what
was
it
sorry
lost
in
the
tabs?
You
guess
price
or
free
history,
yes,
okay,
yeah
best
one
for
us.
So
basically,
there
was
another
long
conversation
on
the
discord
this
week
about
whether
we
should
use
eth
max
priority
fifa,
gas
to
return
kind
of
a
value
for
the
priority
fee
in
the
clients
or
whether
we
should
just
return
raw
data
and
and
allow
wallets
to
to
kind
of
calculate
their
own
priority
fee,
because
it
will
be
much
simpler.
A
A
You
know,
like
some
issues
that
he
and
others
had
raised
in
in
the
the
the
call
with
wallets
that
if
we
go
with
like
the
max
priority
fee
for
gas
api,
it
kind
of
becomes
a
crutch
and
maybe
wallets
will
like
never
build
better
estimators,
whereas
if
we
just
start
with
the
fee
history,
api
yeah
things-
you
know
it
it
kind
of
forces
people
to
to
actually
build
a
an
estimator.
On
top
of
that
zolt.
I
know
you
had
worked
on
the
fee
history
api.
E
Okay,
yeah,
so
so
the
fee
history,
api
is
well
yeah.
It's
this
road
data
approach
and-
and
like
I
came
to
like
this
this
this
conclusion
that
this
could
be
the
best
solution
based
on
like
this
long
discussions
and
everything.
So
I
also
had
an
initial
suggestion
that
that
tries
to
try
to
to
like
give
like
prices
as
results
and
and
and-
and
I
think
peter
was
also
kind
of
opposed
to
it.
So
what
fee
history
does
it?
Basically,
I
just
just
returns,
so
you
can.
E
You
can
specify
like
a
number
of
blocks,
how
many
recent
blocks
you
want
to
retrieve.
You
can
also
like
specify
that
you
want
to
so
you
you
can.
You
can
also
select
a
block
range
which
can
even
be
an
order
range
or
it
can
go
up
to
the
head
block
or
if
the
the
supply,
the
the
backhand
node,
is
a
minor
or
has
a
or
a
full
node
and
has
a
pending
state
and
even
the
pending
state
can
be
accessed
and
what
it
returns
for.
E
Each
block
is
well,
it
returns
the
the
base
fee,
it
returns
the
relative,
like
guess,
used,
and
so
that's
just
a
number
between
0
and
1,
and
it
can
return
multiple
percentile
samples
of
of
minor
reward
and
by
minor
reward
I
mean
the
effective
rewarded,
effective
tip.
So
what
the
miner
can
keep
and
yeah.
E
I
mean
I
and
when
I
say
percentile
I
mean
weighted
by
actual
gas
used
inside
the
block,
the
ap,
the
the
call
even
even
allows
specifying
multiple
percentile
values
and
and
then
it
can
take
multiple
samples
from
each
block
because
calculating
this
is
basically
zero
overhead
and
it
can
be
useful,
so
yeah.
This
is.
This
is
a
basic
idea.
E
And
by
the
way
about
the
other
thing,
the
max
priority
fee
api.
So
I
can
add
a
little
bit
to
that
and
that's
basically
that
I'm
also
now.
I
also
kind
of
think
that
maybe
it
wouldn't
be
very
good
to
to
just
drive
the
wallet
developers
in
a
way
that
so
that
they
can.
They
just
use
this
single
number
suggestion,
because
I
don't
think
that's
going
to
like
be
a
good
direction.
E
So
the
reason
we
have
this
thing
is
that
we
allow
sending
transactions
where
they,
where
the
price
fields
are
fields
are
not
set
at
all.
So
we
so
get.
Has
this
like
auto
fill
feature
for
prices,
and
if
we
want
to
send
a
1559
transaction,
then
we
have
to
just
fill
in
some
very
dumb
default,
and
maybe
what
we
should
do
is
that
we
should
have
this
number
for
for
for
the
autofill,
but
maybe
not
expose
it
as
an
api
function.
So
I
now,
I
think
this
would
be
maybe
the
best
compromise
and
yeah.
K
Yeah,
so
I
have
some
concerns
with
standardizing
this
type
of
thing,
because
it
requires
nodes
that
serve
it
to
have
access
to
a
like
decent
chunk
of
kind
of.
Like
recent
history
block
data,
I
guess
it's
not
a
huge
chunk,
but
I'm
thinking
about
kind
of
light
nodes
and
light
nodes
that
want
to
be
able
to
expose
json
rpc
still,
and
this
kind
of
thing
is
going
to
continue
to
make
that
more
complicated,
whereas
this
data
is
servable.
K
K
E
You
are
kind
of
correct
so
correctly
if
we
serve
the
so
with
the
like.
Currently
existing
guest
price
oracle.
Yes,
we
need
to
access
a
few
blocks
and
we
need
to
like
fetch
the
transactions
in
order
to
extract
the
data
and
that's
what
the
old
guest
price
oracle
does
and
and
that's
what
the
fee
history
implementation
also
does
and
well
yeah.
It
works
for
the
right
client.
E
Obviously,
if
you
want
to
retrieve
like
a
long
history
which
you
you
are
not
forced
to
do,
you
can
just
if
you,
if,
if
you
just
want
to
operate
a
wallet,
you
can
probably
fetch
the
last
two
three
four
five,
I
don't
know
blocks
and
you
can
do
that
with
a
light,
client
and
yeah.
So
having
an
api
that
that's
theoretically
serveable
by
a
light
client
and
with
some
parameters,
it
could
be
like
expensive
and
take
long.
Well,
that's
true!
E
For
most
of
our
apis,
you
can
do
like
clash
filtering
and
you
can
do
a
lot
of
stuff
that
can
that
does
work
with
the
light
client
and
these
things
do
work
with
the
light
client
without
any
problem.
It's
just
yeah.
If
you
retrieve
like
a
100
block
long
history,
which
you
just
don't
need
for
for
wallet,
but
if
you
do,
then
it
will
take
long
time.
So
I
think
I
think
I
think
I
think
it's
yeah
you.
K
K
Maybe
the
concern
here
is
that
it's
very
much
not
like.
Oh
one,
operation
time
that
that,
like
you
said
you
know
logs
and
points
like
that
that
have
parameters
that
users
might
pass
into
them
that
make
it
that
it
could
have
unreasonable
bounds
in
terms
of
how
many
blocks
they
want
to
process
this
stuff
for,
and
things
like
that,
and
that
you
know
the
end
expectation
for
users.
K
Is
these
things
just
work
right
like
you,
you
say
yeah
give
me
the
average
whatever
for
the
last,
you
know
100
000
blocks,
and
the
expectation
is
that
it
will
return
that
data,
but
on
some
level
it
becomes
undefined
behavior.
Because
what
happens
if
clients
start
even
not
like
clients,
start
dropping
old
blocks
and
things
like
that
or
what
happens
if
they
pass
in
a
10
million
block
range
or
things
like
this.
A
Yeah,
the
biggest
difference
here
is
that
you
don't
need,
like
a
very
large
number
of
blocks,
to
build
a
good
estimation,
because
1559
adapts
pretty
quick.
I
think
it's
like
every
six
blocks.
You
know
the
the
base
fee
doubles,
so
you
can
see
you
can
see
with
like
a
handful
of
blocks,
what
type
of
like
regime
you're
in
and
so
and
and
that's
what
you
could
use
and
set
your
tip.
K
Maybe
something
that
would
make
me
feel
a
little
bit
more
like
less
resistant
to
this
was
if
the
json
rpc
spec
had
some
clear
bounds
on
like
expectations,
for
you
know,
longer
ranges
into
history
or
longer
ranges
of
blocks
or
even
actual
upper
bounds
say.
The
behavior
of
this
is
undefined
above
this
range.
E
Yeah,
that's
that's!
That's
a
fair
point,
so
the
thing
is
that
already
so,
the
my
the
fee,
history,
spec
already
allows
or
optionally
allows
like
giving
data
about
the
pending
block,
which
is
also
obviously
something
that
like
clients,
can
do
so
that's
also
specified
as
some
some
some
backhands
might
support
it,
but
it's
optional
and
the
caller
should
be
prepared
for
that
that
it
might
not
work
with
some
backhands,
and
maybe
we
can
just
do
the
same
thing
with
block
count,
because
it's
yeah,
it's
not
a
one.
K
K
So
whether
or
not
this
is
some
sort
of
like
meta
endpoint,
that
we
start
exposing
that
displays
information
that
that
the
node
can
hit
and
say
how
many
blocks
back.
Am
I
allowed
to
go
for
things
like
this
endpoint
or
logs,
or
things
like
that,
because
that's
the
other
hard
point
here
is
that,
even
if
we
make
it
clear
that
nodes
don't
support
this,
it
still
doesn't
really
quite
address
the
issue,
because
the
wallet
software
still
needs
to
be
able
to
somehow
figure
out.
K
A
E
E
So
maybe
one
thing
that
we
could
do
about
this
thing
is
that
the
the
call
format
already
allows
like
not
supporting
all
the
data
that
the
caller
has
requested,
because
the
answer
contains,
like
the
first
block
number
of
of
the
results,
and
then
the
lists
of
of
base
fees
and
rewards
and
everything.
So
it's
it's
it's
totally
possible
and
we
can
just
specify
that
the
the
back
end
can
any
time
just
limit
and
say
that.
E
Okay,
you
have
requested
20
blocks,
because
maybe
the
full
nose
will
serve
it,
but
the
right
slide
node
only
wants
to
serve
eight
so
yeah.
The
answer
can
just
point
to
a
later
block
as
the
first
block
and
contain
like
eight
blocks
of
results,
and
I
think
that
could
also
work,
because
the
caller
should
be
prepared
that
okay,
now
this
backend
didn't
give
me
so
much
history.
Then
I
have
to
work
with
what
I
have
and
yeah.
A
Yeah
that
amount
of
full
blocks.
You
know
you
definitely
know
that,
like
you're,
in
a
massive
demand,
spike
and
and
you'll
need
to
put
a
big
a
big
priority
for
you
anyways.
So
I
guess
just
to
take
a
step
back.
Would
would
all
the
teams
be
okay
kind
of
going
with
the
fee
history
as
kind
of
a
default
and
capping
the
number
of
bucks
that
it
returns
the
history
for
to
some
small
number
around
you
know
like
eight
or
ten
ish,
I
see
a
plus
one
from
base.
U
any
objections.
L
A
E
A
A
Okay,
if
not
there's
one
more
thing
that
came
up
this
week
with
regards
to
how
we
treat
eoas
and
smart
contract
accounts,
which
could,
under
some
very
tiny
edge
cases,
have
the
same
private
key.
I
know
denkarad
you've
been
researching
this
and
wrote
a
nip
about
it.
Do
you
want
to
take
like
a
minute
or
two
to
kind
of
explain
the
problem
and
and
what
you
see
as
a
potential
solution.
M
M
Just
I
just
want
to
make
clear:
it's
not
like
completely
outlandish
to
think
that
this
could
happen
now.
Basically,
someone
could
specifically
try
to
prepare
this
now
and
now.
Why
is
this
a
problem
so
like
basically
previously,
like
we
thought
about
the
case
where
okay,
like
what
you
could
do,
is
you
like
create
this
collision?
And
then
you
don't
deploy
the
contract,
but
you
somehow
trick
a
user
into
sending
funds
into
it,
and
then
you
withdraw
it
using
eoa
key.
M
However,
like
when
we
started
thinking
about
this
last
week,
suddenly
we
found
that
actually,
even
after
deploying
the
contracts,
you
can
still
do
that
right
now
we
don't
have
any
protection
against
that
like
it's.
Basically,
it
was
assumed,
I
guess,
when
the
spec
and
clients
were
first
built
there,
this
never
happens,
and
so
you
just
yeah
you
just
deploy
the
contract
first
and
then
like
it
could
be
something
that
looks
like
completely
innocent,
like
let's
say,
like
craziest
example,
would
be
something
like
rubbed.
M
If
or
something
like
that,
right,
you
think
it's
just
a
wrapper
contract,
it
does
nothing
and
you
can
always
get
your
e-stack.
Well,
that's
not
true.
If
someone
had
the
end
user
account
key
for
that
contract,
but
luckily
this
very
bad
attack
back
that
we
can
just
stop
by
just
like
making
all
transactions
that
that
have
send
their
equals
and
a
deployed
contract
invalid
and
that
basically
stops
this
yeah.
M
In
my
opinion,
most
serious
attack
vector
and
all
the
other
ones
they're
still
kind
of
annoying,
but
but
they
are
at
least
for
the
next
few
years,
not
really
practical
attack
vectors
and
that's
basically,
what
this
erp
does.
I
think
3607
has
been
assigned
to
it.
Basically,
I
think
like
we
should.
Basically
we
might
not
want
to
treat
it
actually
as
a
full
upgrade.
We
might
just
say
well
we're
kind
of
specifying
what
some
previously
unspecified
behavior
was,
and
so
we
say
like
this:
does
these
transactions
become
invalid
and
and
then
yeah?
A
Site
so
thanks
demprod,
I
think
there's
also
one
thing
worth
specifying:
oh
and
I'll.
Let
micah
speak
right
after
this,
but
one
thing
we're
specifying
is
this:
eip
doesn't
actually
require
a
hard
fork,
but
only
a
soft
fork,
because
it's
like
a
tightening
of
the
rules
that
doesn't
introduce
any
new
features.
A
N
N
D
F
A
Check
so
my
my
proposal
for
this
was
yeah,
given
that
it's
like
three
lines
in
geth,
and
you
know
it
is
like
a
small
change,
but
at
the
same
time
it's
not
something.
That's
probably
gonna
happen
tomorrow.
You
know
there
is
still
like
a
a
pretty
high,
pretty
high,
like,
I
guess,
hash
power
needed
to
to
actually
exploit
this,
and
because
we've
mentioned
in
the
past,
we
wanted
to
see
london
on
test
nets
sooner
rather
than
later.
A
O
Sorry,
I'm
I'm
generally
against
of
dropping
anything
more
to
london,
even
if
it's
small,
so
even
even
if
you
find
those
collisions
I
at
the
moment
it's
it's
just
a
question
whether
it
is
consistent,
behavior
of
all
the
clients
or
not
like
they.
Just
sending
the
transactions
from
the
contracts
is
not
the
problem
of
itself
right.
M
No,
no,
it
is
a
huge
problem
because
you
could
steal
all
the
funds
like
say,
like
someone
had
done
that
for
up
either
like
just
to
be
clear.
I
assume
it's
not
be
done
for
raptor
because
it's
been
deployed
years
ago,
but
like
if
someone
had
premeditated
this
and
deployed
that
contract
with
this
collision,
then
now
they
could
use
their
key
and
take
all
the
ether.
That's
right
now
in
that
contract
and
transfer
to
their
private
account.
J
G
G
M
Agree
that
it's
very
unlikely
that
someone
has
this
right
now
I,
on
the
other
hand,
if
someone
could
start
this
now
that
that
actually
there
might
be
worthwhile
like
one
year
ago,
probably
nobody
would
have
done
that
it's
just
the
whole
ecm
network
wasn't
worth
that
much.
But
now
it's
very
different.
K
So
one
easy,
potentially
low
low
friction
way
to
include
this
would
be
to
get
the
the
fixture
test
ready
for
this.
That
would,
it
would
demonstrate
compliance
with
it
and
then
just
to
get
them
merged
after
london
is
out
so
that
they
are
already
part
of
whatever
comes
next,
and
so
by
the
time
that
we
get
to
our
next
hard
fork
after
that
and
clients
are
working
on
compliance
with
whatever
new
versions
of
the
fixture
tests
are
coming
out.
A
Not
necessarily
because
we're
pushing
back
the
difficulty
bomb
to
december
1st
assume
the
merge
is
not
ready
december.
First,
we're
gonna
need
to
push
back
the
difficulty
bomb
again.
So
that
means
that
would
be
like
I
guess
at
the
latest.
If
we
don't
do
it
now,
we'll
do
it
december
1st,
roughly
martin
you've
had
your
head
up
for
a
while.
G
F
F
Q
So
so
the
only
the
only
thing
blocking
it
from
from
merging
it
right
now
are
the
state
tests,
because
a
lot
of
state
tests
assume
that
the
sender
has
some
kind
of
code.
So
we
need
to.
I
already
rewrote
the
state
tests
so
that
they
don't
do
this
anymore,
so
they
can
be
verified
with
the
with
a
new
change
in,
and
I
now
have
to
write
some
tests,
basically
for
the
change
to
verify
that
a
client
has
this.
Q
N
Just
for
clarity,
if
we
go
with
martin's
plan,
are
we
asserting
that
should
someone
do
this
from
here
on
it's
a
consensus?
Failure
if
anyone
includes
such
a
transaction
and
accepts
that
block,
regardless
of
whether
you
update
your
client
or
not
the
right
or
the
canonical
fork
is
the
one
that
does
not
include
such
a
transaction.
Is
that
correct.
M
N
F
N
F
F
O
Just
didn't
want
to
have
it
as
like
necessarily
tested
change
for
london,
because
that's
that's
what
I
thought
would
be
a
quite
a
big
effort
for
the
testing
teams,
but
I'm
totally
agreed
that
geth
can
go
with
this
change,
that
we
want
to
go
with
this
change
and
we
would
go
with
it
as
fast
as
possible.
Just
didn't
want
to
have
it
officially
in
london.
C
F
A
Cool
okay,
so
I
guess
just
for
the
next
steps,
maybe
you
yeah
so
we'll
do
a
full
sync
verify.
This
never
happened.
Assuming
that's
the
case.
Clients
can
implement
it
whenever
they
want.
We
agree.
That's
kind
of
the
general
herb,
that's
kind
of
the
canonical
behavior.
My
last
question
would
be
like:
where
does
this
get
documented?
So
if
you
know
somebody
wants
to
build
a
client
one
year
from
now.
A
If
this
is
not
in
london,
you
know
it'll
be
kind
of
a
weird
eep.
That's
kind
of
standalone
that
people
need
to
know
is
in
so
is
there
like?
Okay?
So
we
added
to
the
yellow
paper
yeah.
That
seems
like
right
thing:
okay,
so
yeah.
If
we
can
make
sure
to
add
a
pr
to
the
yellow
paper
as
well.
I
think
that
would
be
good
just
so
we
don't
just
forget
that
this
is
implemented
in
clients
thanks
miris.
A
Okay,
so
I
guess
lasting
related
to
london.
It
seems
like
we're.
You
know
in
a
pretty
steady
spot,
I'm
curious,
you
know
when,
if
teams
feel
like
they're
there,
they
know
when
they
can
have
a
release
that
they
would
be
confident
for
to
to
fork
on
the
test
nets.
There's
like
a
few
outstanding,
json
rpc
issues,
I'm
not
sure,
if
they're
all
kind
of
must-haves
for
the
test
nets.
F
A
A
A
A
So
we
can
either
get
the
tuesday
or
thursday
thursday
is
probably
closer
to
10
days,
whereas
tuesday
is
probably
closer
to
eight
days
yeah
that
would
be
june
24th.
And
then
we
could
have.
You
know
the
two,
the
two
other
test
nets,
one
week
after
each
we
mentioned
before.
We
didn't
want
to
set
a
mainnet
block
for
now,
because
we
want
to
see
how
it
goes
on
the
test
net.
So
we
we
don't
have
to
add
that
into
clients.
A
And
yeah
there's
a
comment
in
the
chat
that
none
of
these
scenarios
have
july
14
on
the
main
net
for
sure
we
probably
won't
get
a
main
net
fork
one
week
after
the
last
tested
fork
so
yeah.
It
would
be
later
than
that,
and
you
know
I
have
some
tentative
blocks
here
but,
like
those
are
not
final,
depends
on.
You
know
what
happens
on
the
test
nets
and
and
whatnot
so
yeah.
F
O
F
Yeah,
well
it
it,
it
kind
of
looks
like
it
was
building
up
in
in
priority
I
mean
robson
is
the
most
throwaways.
We
do
that
first,
and
it
looked
a
bit
odd
to
me
that
we
do
girly
and
then
drink
to
be
instead
of
ring
to
be
or
maybe
even
rocks
and
andering.
At
the
same
time,
then
do
girly,
because
I
kind
of
thought
that
girly
was
the
more
used
well-used
and
high
higher
more
valuable
network.
A
A
A
Okay,
great
so
yeah
I'll
make
sure
to
share
that,
and
then
I'll
follow
up
with
the
different
client
teams
next
week
to
see
when
the
releases
are
out
and
when
they
are
we'll
put
out
a
blog
post
to
to
link
everybody
to
the
right
releases
for
every
every
client
and
just
to
make
this
clear
to
anyone
listening,
none
of
these
releases
will
include
a
main
network
block.
So
that
means
that
there
will
be
another
release
that
download,
if
you're
running
only
against
mainnet.
A
A
If
not
so
a
few,
I
think,
months
now
ago
a
light
client
discussed
74
at
eip
3074
on
this
call
and
people
wanted
to
see
an
audit
for
it
to
better
understand
the
security
implications.
So
that's
been
done
and
yeah
the
the
auditing
team
is
on
the
call
with
us
today.
They
wanted
to
give
a
quick
overview
of
their
findings,
so
yeah,
maybe
lifetime.
D
Yeah
that
that
would
be
great
thanks,
tim
yeah.
So
if
I
could
just
briefly
recap
for
people
who
haven't
been
following
us
closely
and
may
have
forgotten
what
3074
does
3074
introduced,
this
two
new
opcodes
off
and
off
call
the
auth
opcode
accepts
a
3074
signature
and
it
returns
the
address
that
signed
the
3074
message.
D
So
we
refer
to
these
contracts
as
invokers,
because
they're
the
they're,
the
contracts
that
are
invoking
auth
and
off
and
30
74
messages
and
signatures
are
domain
bound
to
these
invokers,
and
this
helps
protect
users
from
replay
attacks.
That
might
be
tried
to
have
their
messages
replayed
on
other
invokers,
and
so
this
basically
means
that
all
the
security
functionality
is
implemented
in
the
invoker
contract
and
it's
sort
of
a
extension
of
these
like
protocol
security.
D
In
that
sense-
and
this
presents
some
some
interesting
security
challenges,
which
is
why
we've
had
some
of
these
teams
do
these
audits.
We
believe
that
like
safe
invokers
can
be
written
even
if
it's
a
small
number
of
them
and
that
with
wallets
having
allow
lists
to
avoid
social
engineering
attacks
that
3074
can
be
safe.
D
Even
with
these
security
challenges,
I
think
the
3074
is
really
important
vip
to
consider,
including
because
it
does
allow
for
many
desirable
constructions
and
a
couple
good
examples
of
their
of
those.
Are
it
allows
for
generalized
transaction
batching
from
eoas?
It
allows
for
sponsored
transactions
that
allow
people
to
pay
with
tokens,
not
other
than
eth.
D
You
can
do
social
recovery
mechanisms
for
eoas
that
can
be
signed
off
chain
and
then
only
be
played
on
chain
whenever
the
social
recovery
needs
to
happen,
and
you
can
minimize
on-chain
accounting
for
state
channels,
and
these
are
just
the
things
that
you
know
kind
of
we've
thought
of
and
thought
that
would
be
useful.
But
I
think
that,
because
it's
such
a
flexible,
primitive
that
it
does
allow
for
a
lot
of
other
things
that
I
think
people
will
come
up
with
in
the
future,
and
so
because
of
these
unique
security
challenges.
D
We've
been
working
with
ethereum
foundation
to
have
the
spec
audited,
and
there
are
two
main
components
that
we
wanted
to
focus
on.
The
first
was
an
audit
of
just
the
specification
itself
in
general,
trying
to
think
through
the
things
that
could
go
wrong.
The
security
concerns
that
arise
just
from
the
spec
and
that
has
been
completed
by
leased
authority
and
I'll
have
them
share
their
fines
in
just
a
minute.
D
L
Share
yeah
great
yeah,
thanks
like
client
and
thanks
for
the
opportunity
to
have
us
work
on
this.
It
was
a
nice
experience
with
the
quilt
team,
you're
all
very
helpful,
and
we
had
a
good
month
talking
back
and
forth
about
security
around
this.
This
is
a
bit
of
an
interesting
audit,
since
it
has
a
lot
of
potential
things
that
can
go
wrong
from
the
surface
level.
L
This
you
know
looks
like
opening
up
an
account
to
the
entire
possible
world
of
smart
contracts
and
leaving
yourself
vulnerable
to
any
random
execution,
so
just
to
quickly
go
over
our
structure
and
and
what
we
looked
into.
We
we
looked
at
you
know
current
breaking
changes.
As
you
had
mentioned,
you
have
the
do
bob
team
working
on
checking
the
message.sender
equaling
tx.org
assumption
for
the
frame
of
execution
and
the
use
cases
for
that
being
used
against
flashlight
entries.
L
We
looked
at
the
signed
data
security.
What
is
actually
being
signed,
the
type
prefix
the
importance
of
including
the
invoker
domain,
and
why
that's
necessary
and
and
the
address
manipulation
possibilities.
Social
engineering
attacks
on
that
incomplete
fields,
maybe
in
the
commit
do
we
looked
at?
Are
there
enough
fields
in
the
signed
data
to
assume
that
this
is
reasonable,
went
further
into
some
replay
protection?
Looked
at
human
readability
of
the
signatures
and
and
decided
that
this
was
a
concern
for
the
wallets.
L
We
kind
of
did
some
brainstorming
on
all
the
ways
that
invokers
can
go
wrong.
We
kind
of
made
a
list
of
potentially
bad
invokers
and
how
easy
it
is
for
an
invoker
to
do
the
wrong
thing,
which
again
stresses
the
importance
of
creating
correct,
invokers
and
really
spending
time
to
make
sure
that
these
pieces
of
code
are
doing
what
they're
supposed
to
be
doing
and
you'll
see.
That
stressed
throughout
our
findings.
L
In
our
report,
we
think
a
little
bit
about
the
permanent
authorization
aspect
of
this,
where
you
are
signing
your
account
to
a
piece
of
code,
and
this
piece
of
code
will
have
that
signature
potentially
forever.
This
is
comparable
to
infinite
approvals.
I
think
that
that's
kind
of
a
good
way
to
sort
of
think
about
these
invokers
and
and
compare
and
contrast
to
that
situation
and
infinite
approval
can
be
unapproved,
but
an
infinite
approval
is
still
infinite
and
the
damage
is
going
to
be
done
if
it's.
L
If
it's
taken
advantage
of,
we
look
at
wallet
implementation
security,
because
this
is
particularly
important
since
wallace
will
be
in
charge
of
securing
these
invokers
or
making
sure
that
signers
users
are
signing
the
correct
invokers
and,
and
this
idea
of
allow
listing
and
creating
a
set
of
invokers
that
the
community
and
wallet
implementers
consider
to
be
safe.
We
find
that
very
important.
L
If,
if
we
can
bring
them
to
a
central
point,
then
we
can
have
more
confidence
and
correctness
that
might
bring
up
concerns
about
central
points
of
failure.
The
the
attack
surface
or
the
consequences
might
be
more
drastic
if
a
single
invoker
fails
and
it's
attached
to
a
lot
of
accounts.
However,
it's
also
a
positive.
If
you
are
able
to
trust
that
source
is
valid,
you
don't
have
to
rely
on
every
application,
implementing
something
like
infinite
approvals
correctly.
L
D
Thanks
for
sharing
that
nathan,
I
don't
know
if
anyone
has
any
specific
questions
for
nathan
or,
I
think
ryan
from
lisa.
Thor
is
also
here,
one
of
the
other
auditors,
but
we
also
have
the
dwab
team
here
to
discuss
their
findings,
so
I'm
not
sure
if
it
makes
more
sense
to
just
go
ahead
and
have
them
discuss
and
at
the
end
have
questions
for
both
or
if
people
have
burning
questions
right
now,.
R
L
That's
a
good
question
so
that
I
believe
would
require
some
effort
between
the
wallets
and
yeah.
I
think
that's
a
good
question.
It's
important
that
consensus
is
achieved
and
I
think
that
it's
a
it's
a
very
sensitive
piece
of
code
that
needs
to
be
done
and
implemented
and
white
allow
listed
correctly
right.
So
that
is
a
good
question.
B
F
R
N
P
Yeah,
I
think
it's
really
best
to
think
of
these
as
like
opt-in,
extensions
to
wallets
and
there
will
be
standardized
some
standardizations
so,
like
you
see
like
where
basically
there's
probably
one
one
specific
implementation
for
for
a
simple,
bundling
invoke,
or
something
just
just
so.
It's
easier
for
for
kind
of
wallets
to
to
kind
of
maybe
expose
an
api
that
that
tells
the
website
if
it
supports
the
bundling
or
whatever.
But
it's
always
just
like
opt-in
functionality,
extensions
that
that's
all
it
is
really.
D
S
Sure
so,
just
to
set
up
the
context
again,
we
just
did
the
analysis
on
existing
contracts
like
the
impact
of
3074.
Actually,
the
optional
part
of
3074
on
existing
contracts
and
the
biggest
impact
to
refresh
everyone's
memory
is
that
tx
origin
equals
message.
Sender
is
no
longer
a
reliable
distinguisher
of
voas,
so
anyone
can
impersonate
message
center.
S
S
Bottom
line,
certainly
it
affects
a
lot
of
code.
I
think
that
doesn't
come
as
a
surprise.
Probably
it
affects
around.
We,
we
sampled
around
1.8,
of
actively
transacting
contracts.
Right
now
have
some
kind
of
check
that
combines
tx
origin
and
message
center
now.
Does
that
mean
1.8
of
the
contracts
are
actually
affected?
Actually,
probably
not
in
most
of
those
contracts.
There
are
comments
from
programmers
that
say
just
to
be
extra
safe
or
we
know
that
this
can
be
front
run,
but
I
why
not
check
for
eoas?
S
Some
people
certainly
are
not
aware
that
there
are
issues
already
regardless
of
3074..
Now
what
are
these
issues
with
nav
kind
of
deals?
Anyone
colluding
with
a
miner
can
actually
exploit
contracts
exactly
the
same
way.
So
is
this
code
already
vulnerable?
It
depends
on
where
you
think
mev
attacks
are
going
to
go
in
the
future
and
I'm
not
sure
if
people
have
a
formed
opinion
on
that
already
or
they'd.
Like
me
to
elaborate
on
that,
but
let
me
get
back
to
the
main
story.
There
is
a
significant
impact.
S
S
Not
any
more
than
code
would
be
broken
anyway.
So
that's
our
subjective
opinion.
At
the
same
time,
we
tried
in
the
report
to
be
to
very
clearly
separate
subjective
opinion
from
objective
fact,
so
there
are
measurements
that
are
objective
fact
and
subjectively.
We
assess
that
the
risk
is
not
that
much
greater
than
med.
S
S
They
issue
atomically
the
exploit
transaction
first,
like
they
borrow
from
the
miner
they
tilt
the
pool
and
then
the
attack
transaction
they
make
the
victim
contract
lose
money
by
calling
the
code
that
has
that
nested
sender
equals
dx
origin,
so
that
would
be
a
proactive
mev
attack
that
we
think
there
will
be
coming
within
the
next
few
months.
Mev
attacks
have
become
very
sophisticated
already,
so
I
think
I
gave
a
quick
summary.
Maybe
it
was
too
quick,
and
maybe
I
can
go
over
specific
topics
if
people
have
specific.
S
So,
just
to
add,
we
did
sample
a
few
protocols.
We
did
sample
some
of
the
most
prominent
protocols
inspected
the
code
most
of
the
uses
of
the
guard.
Comparisons
of
tx
origin
method
center
are
for
flash
loan
protection.
There
are
other
uses
like,
for
instance,
for
pricing.
There
are
services
that
give
away
their
their
services
for
free
to
eoas,
but
they
don't
want
to
give
away
everything
to
a
contract,
because
a
contract
can
aggregate
lots
of
customers.
S
So
that's
one
concern.
There
was
also
a
pattern
of
avoiding
briefing
attacks
like
making
sure
that
nobody
can
turn
down
receipt
of
if
because
they
are
an
eoa,
but
all
of
those
are
secondary
patterns.
The
primary
pattern
by
far,
has
been
flash
loan
protection
price
manipulation
protection.
That's
the
the
primary
reason
why
people
check
that
whoever
called
a
function
is
an
eoa
and
not
a
contract.
Reentrancy
was
a
major
concern.
We
found
zero
evidence
of
use
of
reentrancy,
maybe
one
contract,
maybe
gsn,
actually
becomes
re-entrant
if
that
guard
is
removed.
D
A
L
I
F
F
P
P
Would
you,
for
example,
be
willing
to
maybe
sit
down
with
us
sometime,
try
and
really
kind
of
hash
it
out
and
see
if,
if,
if
kind
of,
we
can
find
any
specific
concerns,
or
if
we
maybe
can,
I
don't
know,
alleviate
some
of
your
concerns,
or
I
don't
know,
I'm
just
kind
of
very
hesitant
to
just
kind
of
again
to
just
basically
go
over
something,
because
we
try
it
often
enough
to
make
people
just
not
want
to
reject
it
like
just
keep
giving
up
on
the
objections.
Kind
of
that
makes
sense.
F
It's
a
bit
late
on
the
call
now
but
yeah
I
mean
we're
going
to
talk
about
our
future
calls
right,
because
now
we
passed
the
security
phase,
the
security
reviews
that
we
said
we
were
going
to
do,
and
I
guess
that's
some
future
call
we'll
discuss
when
or
if
to
include
it.
If
or
when
sounds
good
postponed
until
then,.
D
A
Yeah,
I
think,
maybe
like
taking
a
step
back
beyond
this
eep.
You
know
once
london
is
kind
of
out
and
whatnot,
you
know
possibly
in
around
one
month
or
so.
We
should
have
like
the
main
network.
He
says
out
and
at
that
point
we're
kind
of
just
waiting.
I
think
there's
like
the
meta
question
of
like
okay.
What
are
we
doing
next
in
general,
after
london,
you
know.
Will
we
have
like
shanghai
before?
A
Are
we
gonna
try
and
have
the
the
merge
you
know,
and
and
what's
even
there
so
at
least
to
me
it
feels
like
that's
kind
of
the
thing
that
needs
to
get
resolved
like
we
might
yeah
like.
If,
if,
if
we,
if
we
think
we
are
going
to
have
like
another
fork
on
the
execution
layer,
this
fall
before,
there's
a
merge,
then
we're
going
to
need
to
start
playing
that
one
and
then
it
would
make
sense
to
obviously
consider
a
30-74.
D
To
say,
like
one
last
thing
on
3074.,
I
think
that
you
know
I've
had
the
opportunity
to
talk
to
a
lot
of
prominent
developers
and
teams
of
the
application
layer
who
aren't
generally
representing
this
call
and
there's
exceptional
interest
in
the
eep
on
their
side.
And
you
know
I
can
help
if
people
are
unsure
like
who
wants
to
do
and
how
are
they
going
to
use
it?
I
can
happily
connect
people
with
prominent
teams
to
see
like
you
know
why
they
want
it
and
how
they're
going
to
use
it.
D
A
Yeah,
I
I
think
that's
helpful
yet
to
have
that
context,
because
it
we
are
sometimes
pretty
removed
from
like
the
end
users
and
how
they
will
use
this
and-
and
I
agree,
there's
been
like
some
like
there's
been
a
lot
of
enthusiasm
by
app
developers
for
for
this
enscar
asks
in
the
chat.
What
are
the
latest
chances
for
emerge
this
year
with
three
minutes
late
left,
I'm
not
sure
you
can
speculate
on
that
marius.
You
have
your
hand.
Q
Up
yeah,
so
I
don't
think
we
should.
We
should
speculate
on
on
merge
times
and
also
I
don't
think
we
should
take
the
application
land
into
account
in
this
decision.
I
think
this
should
be
a
decision
that
we
make
about
the
security
and,
if
it,
if
it's
secure,
if
it
breaks
stuff-
and
this
should
not
be
driven
by
applications
wanting
to
to
spend
less
gas
or
something.
D
No,
I
100
agree
more.
It's
just
a
motivation
for
people
to
try
and
figure
that
answer
out.
Sooner
than
later.
You
know.
If
there
is
no
interest
in
the
eep,
then
maybe
people
don't
look
at
it,
but
I'm
just
trying
to
convey
that
there
is
a
lot
of
interest
and
I
would
like
us
to
figure
out.
Is
it
secure?
You
know
we
did
these
audits
and
there's
a
lot
of
text
now
to
determine
for
core
developers
to
determine
their
own,
and
so
that's
really
the
yeah.
I
don't
want
to
push
something
through.
D
D
It's
can
you
can
think
of
it
like
a
an
additional
module
on
a
wallet
and
you
might
choose
to
use
one
wallet
over
another
because
of
functionality,
and
so
this
isn't
something
there's
no
charter.
There's
no!
You
know
community.
That
has
to
say
this
is
what
we
think
is
the
best
and
here's
like
a
voting
process.
Now
it's
just
I'm
going
to
use
this
wall
because
it
has
these
functionality
and
I
trust
that
it's
going
to
do
it's
safe
and
if
it
doesn't,
then
I'm
not
people
won't
use
that
wallet.
A
Yeah
we're
kind
of
at
time,
but
clearly
yeah,
we're
gonna,
need
more
discussions
about
this
in
the
future.
There's
two
announcement
that
people
wanted
to
make
before
we
we
cut
off
so
one
I
see
run
in
you're
on
this
call
and
you
post
it
in
the
chat
that
gordy
seems
to
have
issues.
I
don't
know
if
you
want
to
like
take
a
minute
to
just
kind
of
explain
that.
A
S
A
J
We
thank
everyone
who
already
have
responded,
and
this
list
includes
each
takers,
community,
the
developers
and
researchers
and
most,
if
you
haven't
done
it,
already
consider
responding
to
the
survey.
If
you
are
any
anyone
who
is
running
ethereum
one
dot,
oh
node,
two
dot
or
validator,
node
and
otherwise
contributing
to
blockchain.
J
It
also
includes
hobbies,
minor,
wallets
and
launching
projects,
because
this
survey
is
going
to
help
us
create
a
better
infrastructure
for
the
epm
ecosystem.
We
are,
we
will
be
sharing
the
responses
received
in
a
form
of
report.
In
the
month
of
july,
the
survey
link
can
be
found
in
the
all
code
meeting
115
agenda.
It's
there
and
also
at
the
catholic
discord
responses
are
accepted
till
june
30th
midnight
pst
consider
responding.
We
need
your
feedback
to
let
everyone
know
what
is
needed
in
the
system
to
improve
it.
Thank
you
very
much.