►
From YouTube: PEEPanEIP #42: Block gas limit with Vitalik Buterin
Description
Topics covered
-----------------------------
1:13 - Vitalik Buterin's message to the community on 6th anniversary
2:22 - Why do limits need to be set on anything?
4:16 - Marginal social cost vs. benefit
6:00 - Important points
08:08 - How is the gas limit set?
10:00 - What are the social costs of high gas usage?
10:30 - Gas pays for three resources
12:00 - Bandwidth
14:20 - Analysis of bandwidth problem
18:14 - Which is the biggest problem?
20:35 - Computation
24:16 - Uncle rates are no longer a big deal
26:24 - Storage
30:00 - Interaction effect
31:27 - Willi increasing the gas limit break Ethereum?
33:22 - Mitigations
37:50 - Q&A
38:00 - Do we want nodes to be run on the laptop or is it okay if it can only be run on PC?
42:56 - Gas limit is decided by miners, why are there frequent changes?
45:25 - Is this a technical question or the question of value? How expensive is it to run a node? How decentralized do you want nodes to be compared to users?
49:20 - How do you go about setting the gas limit?
52:06 - Improve communication channels with miners
Resources:
-------------------
The Limits to Blockchain Scalability: https://vitalik.ca/general/2021/05/23/scaling.html
Accounts, Transactions, Gas, and Block Gas Limits in Ethereum: https://hudsonjameson.com/2017-06-27-accounts-transactions-gas-ethereum/
The History of Ethereum's Block Size & Block Gas Limit: https://blog.mycrypto.com/the-history-of-ethereums-block-size-block-gas-limit/
What’s the Maximum Ethereum Block Size?: https://ethgasstation.info/blog/ethereum-block-size/
Follow at Twitter
-----------------------------------------------
Vitalik Buterin @VitalikButerin | Micah Zoltu @MicahZoltu | William Schwab @William94029369 | Brent Allsop @Brent_Allsop | Pooja Ranjan @poojaranjan19
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herde...
Follow PEEPanEIP earlier episodes at https://www.youtube.com/playlist?list...
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-herde...
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Ethereum
turned
six
today,
many
congratulations
to
the
developers,
users
and
the
entire
ethereum
community.
To
celebrate
this
special
occasion,
we
planned
a
special
episode
in
our
educational
series,
with
a
very
special
guest
welcome
to
the
42nd
episode
of
penny.
I'm
your
host
pooja
ranjan,
and
we
are
going
to
have
an
overview
of
the
key
concept
of
ethereum
blockchain,
the
blog
gas
limit.
A
We
have
some
good
articles
available
on
the
topic,
yet
it
is
one
of
the
poorly
understood
concepts.
Ethereum
community
at
large
lacks
an
understanding
of
how
the
block
gas
limit
is
chosen.
What
factors
must
be
considered
when
sitting
it
and
what
is
the
optimum
level?
With
this
talk?
Our
goal
is
to
share
information
on
the
concept
and
explain
the
reason
why
it
is
the
way
it
is
to
describe
the
notion
we
are
joined
by
none
other
than
vitalik
vitaran,
the
co-founder
researcher
of
the
keem
blockchain.
Thank
you
for
joining
us
metallic.
B
Thank
you
berger,
it's
good
to
be
here,
good
good
to
be
back.
Atlee,
yeah,
lovely
yeah.
Keep
in
eep
also
definitely
excited
to
see
ethereum
starting
six.
Today,
we've
definitely
come
a
long
way
as
a
community.
Since
those
early
days
when
half
the
entire
ethereum
team
got
together
and
was
able
to
fit
in
a
single
room
in
berlin,
when
we
were
actually
seeing
the
blockchain
launch
for
the
first
time.
B
So
you
know,
we've
made
a
huge
amount
of
progress
and
there's
just
a
lot
that
we
should
be
proud
of
and
there's
a
lot.
That
is
of
exciting
things
that
are
going
to
happen
over
the
next
one
to
two
years
that
I
think
we're
going
to
be
able
to
be
yeah
even
more
proud
of,
and
you
know,
scalability
is
definitely
one
of
them,
and
I
guess
the
topic
that
we're
talking
about
today
is
very
much
a
part
of
that.
A
B
Why
can't
we
just
think
about
it
as
hey,
you
know,
the
miner
is
creating
a
block
and
they're
selling
block
space,
and
you
know
if
they're
willing
to
sell
block
space
and
the
person
sending
transactions
is
willing
to
buy
block
space
like
why
not
let
as
many
of
those
transactions
as
the
market
is
willing
to
accept
happen,
and
the
reason
why
that
kind
of
approach
does
not
work.
Right
is
a
negative
externalities
like
basically
when
a
block
gets
included
into
a
blockchain.
B
It's
not
just
the
miner
that
creates
that
block
that
pays
costs.
It's
also
every
node
on
the
network.
Ever
in
the
future,
that's
going
to
actually
have
to
download
and
verify
that
block
and
in
it
and
that's
not
just
winding
nodes.
It's
also
users,
it's
full
nodes
in
the
present
it's
archive
nodes
in
the
future.
There's
it's
also
just
anyone
who
benefits
from
the
network
and
that
benefits
from
it
being
more
decentralized,
instead
of
being
less
decentralized.
B
That,
in
this
case,
arise
as
a
result
of
the
blockchain
becoming
bigger
and
bulkier
right,
and
I
there's
good
reasons
to
believe
that
this
align
is
increasing
right
so
like
in,
if
the
block
size
increased
by
yeah
a
factor
of
10
tomorrow
like
that,
would
not
just
be
you
know,
10
times
more
pain
than
we
have
tomorrow.
That
would
be
like
much
more
than
10
times
the
pain
and
that's
especially
true
in
the
short
run
right
because,
in
the
short
run,
there's
a
lot
of
risk.
B
There
is
a
lot
of
existing
hardware
that
would
break
there's
a
lot
of
things
that
would
become
much
more
difficult.
Eventually,
uncle
rates
would
go
up
and
at
some
point
you
start
hitting
that
wall.
But
in
the
point,
is
right
that
at
some
point
there
is
an
intersection
where
kind
of,
from
the
point
of
view
of
the
ecosystem
as
a
whole.
You
get
this
level
level
where,
after
that
point,
the
like
more
transactions
coming
in
to
be
and
being
accepted
by
the
network
is
no
longer
worth
it.
B
So
some
important
points
right
is
that,
like
this
graph
looks
very
clean
and
mathematically
precise,
but
in
reality
we're
making
very
wild
guesses
about
the
depositions
of
all
of
these
curves
right
like
we
are
just
sort
of
making
a
lot
of
guesses
out
of
the
blue,
we're
making
a
lot
there's
a
huge
amount
of
uncertainty.
We
do
roughly
know
the
shape
of
the
curve,
but
we
only
have
a
vague
impression
of
what
the
curve
actually
looks
like
right.
B
So
there's
a
lot
of
uncertainty,
and
even
if
there
was
a
wasn't
any
uncertainty
about
what
the
curve
looks
like
there's
no
kind
of
hard
boundary
between
safe
and
unsafe
right,
like
it's
not
the
case
that
there
exists
two
worlds.
You
know
the
safe
world
and
the
unsafe
world
and
we're
either
we're
in
the
safe
world
or
we're
in
the
unsafe
world,
and
our
job
is
just
like
coming
up
with
a
limit.
That's
low
enough
to
be
really
really
sure
that
we're
in
the
safe
world,
like
it's,
not
like
that
at
all
right,
there's
trade-offs.
B
B
B
So
if
the
gas
limit
today
is
15
million,
then
they
will
be
able
to
push
the
gas
limit
up
or
down
by
a
factor
of
somewhere
around
like
what
about
thousand
six
hundred
six
hundred
and
like
forty
or
so
something
like
that
and
then
so
the
guess
when
we
can
go
up
or
down
and
it's
the
voting
basically
happens
because
you
constantly
have
minors
voting
it
up
or
down
slightly
in
various
different
directions.
Sometimes
you
see
there's
a
lot
of
disagreements
and
there's
and
you
can
even
see
the
guesswork.
B
That's
kind
of
fairly
rough
during
some
periods
of
time
and
then
sometimes
there's
a
lot
of
agreements
on
a
single
number
and
it
looks
extremely
smooth
in
practice.
Miners
usually
end
up
listening
to
the
core
developers
right.
This
is
just
a
fact
of
like
how
this
voting
ecosystem
has
operated
sociologically
for
the
last
few
years,
like
basically,
miners
generally
get
wait
for
or
wait
and
see
what
you
know,
ethereum
core
developers
say
and
think,
and
they
generally
like
go
based
and
make
their
votes
on
that
basis.
B
I
think
that's,
and
that
comes
from
a
lot
of
motivations,
like
one
of
them,
is
that
miners
themselves
tends
not
to
be
experts
in
all
these
subtle
issues.
Miners
also
like
they
are
part
of
the
ethereum
community,
and
they
do
want
to
see
ethereum
succeed
like
everyone
else
and
score
developers
are
some
of
the
more
most
experienced
people
in
the
community,
and
so
their
perspectives
on
this
are
valued
but
like
this
is
basically
what
happens
today.
B
Now,
what
are
the
social
costs
of
high
gas
usage
right
so
like
here
in
this
great?
I
have
this
kind
of
red
wine
that
shows
like
these
are
there
are
these,
you
know
vague,
nebulous
costs
that
are
paid
by
everyone
in
the
ecosystem.
Everyone
in
the
ecosystem
suffers
more
as
blocks
get
bigger,
but
what
actually
are
these
costs
right?
It's
importance
to
be
able
to
understand
and
quantify
them,
or
at
least
understands
them,
so
so
that
we
can
try
to
quantify
them.
B
I
mean
technically
there's
also
a
couple
of
other
things
to
add
like,
for
example,
gas
pace
for
like
how
full
the
bloom
filter
is,
though,
in
my
opinion,
the
bloom
filter
stuff
is
not
going
to
be
relevant
in
the
long
term,
because
there's
just
going
to
be
a
much
better.
Second
layer
protocols
for
doing
filtering
of
history
and
people
are
just
going
to
start
using
those
so
focus
on
the
three
right.
Bandwidth,
computation
and
storage
and
storage
includes
storage
of
state,
and
it
also
includes
storage
of
history.
B
Bandwidth
and
computation
are
both
real-time
costs.
They
mostly
affect
nodes
that
are
running
at
that
exact
moment
that
the
transaction
was
included
on
chain.
Storage
is
a
cumulative
cost.
A
storage
cost
made
now
is
a
storage
cost
that
has
to
be
paid
by
all
nodes
going
into
the
future
forever,
or
at
least
for
well.
If
the
protocol
never
changes,
then
forever.
If
we
add
state
expiry-
and
we
add
history
expiry,
then
it
goes
down
to
being
one
to
two
years,
but,
like
the
point
is,
it
is
a
cost
that
goes
into
the
future.
B
So
these
are
the
three
con,
the
the
three
main
costs,
and
we
can
analyze
them
individually,
though,
as
it
turns
out,
there
are
also
interaction
effects
between
them
as
well,
so
bandwidth
right.
So
this
is
the
average
size
of
an
ethereum
block
on
the
current
average
is
about
60
000
bytes,
and
this
is
again
not
that
big.
If
we
compare
to
bitcoin,
for
example,
so
ethereum
has,
I
think,
something
like
37
blocks
for
every
bitcoin
block.
B
So
if
you
multiply
60
by
37,
like
you
get
about
2.2
on
2.22
million
bytes
and
bitcoin
blocks
on
average,
are,
I
think,
somewhere
between
1.2
and
1.4,
or
something
like
that?
The
theoretical
maximum
size,
however,
is
937
000
bytes,
so
this
is
based.
The
theoretical
maximum
size
happens
in
the
case
where
the
entire
15
million
gas
in
a
block
is
used
to
pay
for
basically
just
that
data.
There
are
three
three
situations
in
which
something
close
to
that
can
happen.
B
One
is
that
there
are
some
applications
that
just
legitimately
consume
much
more
data
than
everything
else,
so,
for
example,
starks
hash
based
stereo
knowledge
proofs.
They
have
a
fairly
low
comp,
computation
cost
of
verifying,
but
they
have
a
very
large
size,
and
so
a
single
stark
can
often
take
up
a
few
million
gas
and
a
single
star
takes
up
like
more
size
than
an
average
ethereum
block
number
two
is
like:
if
someone
just
wants
to
use
the
ethereum
blockchain
to
store
a
cat
picture,
such
things
were
more
realistic.
B
So
this
is
a
very
naive
way
of
trying
to
analyze
the
bandwidth
problem
right
so
basically
yeah
the
average
user
has
an
internet
bank
connection
of
100
mbps.
Therefore,
clearly
the
blockchain
should
be
able
to
handle
blocks
well
over
10
megabytes
right
wrong.
So
here's
why
it's
wrong
right.
So
naively
speaking,
a
hundred
million
bits
per
second
is
twelve
and
a
half
million
bytes
per
second,
which
is
162
million
bytes
every
13
seconds.
B
But
why
can't
we
have
162
megabyte
blocks?
Well
here
we
go
right,
so
there
is
like
this
cascading
set
of
our
reasons
that
stack
on
top
of
each
other,
so
first
of
all,
internet
connections
are
often
much
slower
in
practice
than
advertised
right,
like
I
have
been
to
lots
of
places
used
lots
of
internet
connections
that
promise
one
number
and
in
practice
sometimes
then
you're
delivering
that
number,
and
sometimes
they
totally
don't
deliver
that
number.
B
Sometimes
this
is
just
some
inexplicable
property
of
the
internet
connection
itself
or
it's
some
kind
of
throttling,
or
sometimes
it's
because
you're
doing
other
things
on
that
internet
connection.
At
the
same
time,
sometimes
it's
other
reasons
so
like
let's
say
you
need
a
5x
buffer
for
that
peer-to-peer
network
overhead
blocks
get
received
multiple
times.
B
I
believe
that
the
way
that
ethereum
nodes
work
now
and
if
I'm
wrong
to
correct
me
in
the
comments
is
that
a
node
actually
when
it
receives
a
block,
it
sends
out
the
full
block
immediately
to
a
number
of
peers
equal
to
the
square
root
of
its
fear
size
or
something
close
to
that
now.
Theoretically,
you
could
make
a
protocol.
That's
more
efficient
right.
You
could
replace
every
single
send
with
a
probabilistic
or
with
a
kind
of
check
and
send
protocol.
That's
like
step
one
ping.
B
Do
you
have
this
already
step
two
reply,
no
step
three
send
and
if
yes,
then,
don't
bother
sending,
but
if
we
actually
did
this,
then
there's
like
this
trade
off
like
having
more
data
efficiency
means
that
there
would
be
more
latency
and
the
latency
is
a
win
c
leads
to
pretty
high
uncle
rates
so
because
of
this
nodes
end
up
sometimes
receiving
the
same
block
multiple
times.
So
there
is
a
peer-to-peer
overhead,
mempool
overhead,
so
nodes
also
end
up
often
receiving
transactions.
They
often
end
up
receiving
transactions
multiple
times.
B
So
there's
a
lot
of
overhead
and
also
in
case
sublocks,
arrive
quickly.
You
need
a
buffer
if
a
node
is
briefly
online,
first
or
offline
for
a
short
period
of
time
or
if
there's
a
very
short-term
network,
glitch
then
nodes
need.
I
need
a
buffer.
So
there's
all
these
reasons.
Why
yeah
these
things
stack
on
top
of
each
other
and
if
just
naively,
let's
say
we
multiply
like
five
times
five
times.
B
B
Here,
at
least,
if
you
know
we
want
regular
users
running
phone
notes
to
be
something
that
remains
possible
and
I
would
argue
it
has
to
remain
possible,
especially
because
in
approved
state
context
like
we
do,
we
definitely
do
not
want
to
go
even
further
in
the
direction
of
incentivizing
everyone.
So,
just
like
entrust
there
a
node
to
a
state
pool.
C
B
I
think
mempool
overhead
is
probably
the
like.
If
we
want
to
solve
that,
then
we
can
just
solve
that
by
using
like
based
like
second
layer
transaction
relay
markets,
peer-to-peer
overhead.
If
we
want
to
solve
that
like
we
can
reduce
that
at
the
cost
of
greater
latency
there's
multiple
ways
to
do
that.
There
are
like
there's,
also
fancier
techniques
that
involve
erasure
coding,
but
I'm
not
sure
if
you
would
want
wants
to
go
that
far.
B
Let's
see
it,
I
can
mean,
like
you,
could
make
an
argument
that,
like
you,
can
stack
or
you
can
kind
of
like
merge.
Your
risk
merge
your
risk
buffers
so
like
you
can
have
one
risk
buffer
of
say,
5x,
to
account
for
both
internet
being
unexpectedly
slow
and
the
possibility
of
your
node
going
offline,
and
just
like
accept
that
you
know
you'll
lose
aliveness
briefly.
If
both
of
those
problems
happen.
At
the
same
time,.
D
One
is
the
biggest
one,
because
realistically
we
want
people
to
be
able
to
run
ethereum
on
their
laptop
and
not
have
to
choose
between
whether
ethereum
works
or
whether
netflix
works
like
they
should
be
able
to
browse
youtube
and
play
world
of
warcraft,
and
you
know
do
whatever
things
you
want
to
do
on
the
internet,
which
is
why
you
bought
your
in
megabit
connection.
Not
just
run
ethereum
node,
24
7,
and
that's
it
and
you
buy
a
second
internet
connection.
So
you
can
actually
use
the
internet
like
that's,
not
a
tradeoff.
B
I
really
disagree
with
that
arguments
right
and
here's
the
reasons
why
I
disagree
with
that
argument.
Basically,
we
need
safety
buffers
both
like.
Yes,
we
need
the
safety
buffer
because
we
have
a
bus
on
distribution
and
because
uncle
rates
go
up,
but
also
we
need
safety.
Buffers
for
spikes
of
block
activity,
300
to
400
milliseconds
is
an
average.
B
Sometimes
sub
blocks
might
just
can
have
more
execution
than
than
average
even
innocently,
but
even
worse,
there
are
going
to
be
some
types
of
execution
that
clients
are
better
at
and
sometimes
the
types
of
execution
that
clients
are
worse
at
and
attackers
that
wants
to
hurt.
The
network
are
going
to
basically
create
blocks
that
are
entirely
full
of
transactions
that
take
a
maximally
slow
amount
of
time
to
execute.
B
Just
in
case
safety
buffers
for
once
again,
users
going
offline
for
short
periods
like
if
my
internet
goes
offline
for
one
minute
like
if,
let's
say
yeah
blocks,
blogs
took
75
percent
of
a
block
interval
to
process.
Then,
if
I
went
offline
for
one
minute,
then
it
would
take
me
four
minutes
to
catch
back
up
to
the
to
the
network
right
and,
like
that's,
also
a
big
uxl
loss
that
we
don't
want
to
see.
So
there's
lots
of
other
reasons
for
safety
buffers.
B
In
addition
to
the
poisson
distribution
argument,
and-
and
so
you
know
like,
basically,
he
had
the
arguments
that
you
know.
If
we,
if
we
just
move
away
from
a
poisson
distribution,
then
that
everything
is
going
to
be
better
is,
like
you
know,
a
little
fishy,
so
good
news
uncle
rates
are
no
longer
a
big
deal.
Actually,
so
uncle
rates
have
been
stable
at
about
five
percent,
but
so
these
other
things
are
still
a
problem.
D
I
add
one
more
thing
to
the
computation
one,
so
this
is
basically
the
same
thing
as
for
the
bandwidth.
We
want
regular
users
with
regular
laptops
to
be
able
to
use
ethereum,
and
that
means
people
with
laptops,
often
close
their
laptops
at
night
or
they
go
on
an
airplane
or
a
train
and
their
laptops
don't
have
internet
for
a
while,
and
you
want
those
people
to
be
able
to
catch
back
up.
D
We
don't
want
to
be
like
you,
sync
ethereum,
and
then,
if
you
ever
turn
your
computer
off,
you
can't
sync
again
like,
and
we
also
want
to
be.
If
you
turn
your
computer
off
for
eight
hours
a
night,
it
takes
you
16
hours
before
you're
caught
up,
so
you
can't
do
any
transactions
until
the
evening
of
the
next
day,
and
so
these
these
things
are
like
having
a
big
buffer
lets
us.
D
Let
regular
users
do
regular
real-life
things
without
having
to
think
about
operating
an
ethereum
client
as
like
a
kind
of
like
you're
running
a
company
like
this
is
just
like.
Oh
it's
just
like.
Like
a
bittorrent,
you
know
it's
just
sitting
on
your
laptop
or
whatever
run
in
the
background,
when
your
laptop's
on
your
laptop's
off
it's
not
running,
and
when
you
want
to
use
it,
it's
there
and
that's
what
you
kind
of
want
ethereum
to
be
long-term.
At
least
that's
why
I
wanted
here
to
be
locked.
B
No,
I
yeah.
I
definitely
want
this
as
well
and
I
think
again,
there's
definitely
arguments
that
you
know
status
quo.
Ethereum
makes
it
difficult
to
run
your
note,
but
it-
and
I
think
you
know
we
have
made
compromises
just
because
the
alternative
would
be
like
half
of
ethereum
activity
and
not
just
not
being
able
to
exist
at
all
and
that,
like
there's
huge
downsides
to
people
like
there's
no
point
in
a
system,
that's
decentralized
if
people
can't
use
it
basically,
but
in
the
like.
B
We
have
all
of
these
amazing
scaling
technologies
coming
including
fancy
roll-up,
shorting
type
stuff,
but
also
I'm
including
more
kind
of
nuts
and
bolts,
see.
You
know,
factor
of
two
improvements
that
stack
on
top
of
each
other,
and
I
think
it
would
be
nice
if
we
could
like
basically
share
the
gains
that
we
get
to
get
from
those
improvements
between
increasing
the
gas
limit
and
actually
yeah
making
ethereum
nodes
easier
to
use
than
they
were
in
the
past.
B
Okay,
so
storage,
so
storage.
Is
I
like
nothing.
Thank
you,
everyone
for
reminding
me
about
time,
because
storage
is
important.
It's
because
it
is
the
specific
thing
that
core
developers
point
out.
Is
that
or,
like
believe,
is
actually
the
dominant
blocker
at
the
moment.
So
there's
two
main
types
of
storage,
there's
state
which
is
30
to
100
gigabytes,
depending
on
what
format
you
store
it
in
so
the
state
in
a
highly
compressed
and
like
zipped
and
form,
is
about
30.
B
But
then,
if
you
want
to
add
a
just
like
an
easily
accessible
address
to
a
data
map,
then
you
know
you
have
to
add
another
like
10
gigabytes,
15
gigabytes.
If
you
want
to
add
the
patricia
tree,
so
you
can
recompute
state
routes
quickly.
You
have
to
add,
like
another
40
gigabytes,
if
you
want
to
add
some
other
some
indices,
you
have
to
add
another
five
gigabytes,
so
it
goes
up
to
100.
B
It
is
1900
if
you,
if
it's
inside
of
an
access
list
now
so
storage
cannot
be
stored
on
hdd
storage
cannot
be
sharded
as
easily
like
history
can
be
sharded
right
because
he
can
just
say
well,
nodes,
don't
have
to
store
it
and
instead,
like
say
the
portal
network
stores
and
history.
Instead,
if
you
want
history,
just
go:
ask
the
portal
network
much
more
disk,
wear
and
tear
for
the
storage.
B
So
the
reason
why
this
all
matters
is
that
a
lot
of
computers
do
have
these
kind
of
hybrid
setups,
where
you
know
you
got
an
ssd
and
then
you
got
a
bigger
hdd
and
in
addition
to
both
of
these
things
sync
times,
and
so
once
again,
the
guest
game
has
done.
I
and
other
client
developer
teams,
like
you
know,
nether
minds
and
others
like
that.
They've
all
been
doing
amazing
work,
making
sync
more
efficient.
B
Last
time
I
tried
syncing
geth
from
scratch
like
asu,
which
was
soon
after
they
introduced
us
snap
sync,
it
was
18
hours
for
me
to
do
a
snapsync.
So
this
is
another
cost
right.
That's
just
like
the
cost
of
spinning
up
a
note
and
the
or
the
time
needed
to
spin
up
a
node
is
not
just
a
ux
issue
that
contributes
to
decentralization.
B
So
sync
times
another
very
important
thing
I
think
they've
been
hovering
close
to
the
kind
of
like
12
hours
to
one
day
level
for
about
a
couple
of
years
and
basically
growing
state
size
as
being
roughly
counterbalanced
by
yeah
improvements
in
improvements
in
clients.
But
eventually
improvements
in
clients
are
going
to
hit
a
limit
unless
we
implement
things
like
state
expiry
that
I'll
talk
about
interaction
effects,
so
the
cost
of
storage
read
and
write
goes
up
with
is
proportional
too.
Actually,
that's
a
bit
of
a
mistake.
B
There's
two
reasons
for
this:
one
is
just
the
way
the
databases
work
in
any
database,
the
like
they're
all
restructured
in
some
way
or
another,
and
so
the
number
of
disk
reads
is
proportional
to
the
logarithm
of
the
number
of
steps
you
have
to
walk
down
the
tree
before
you
get
to
the
cache,
that's
in
ram,
and
so
it's
about
proportional
to
the
log
of
state
size
divided
by
ram
cache
size.
So
if
the
state
size
is
64
gigabytes-
and
let's
say
the
ram
cache
size
is
four,
then
that
number
is
16..
B
So
conclusion
is
that
a
gas
limit
rise
of
a
factor
of
four
may
well
correspond
to
an
increase
of
a
factor
of
six
or
potentially
even
more
in
block
processing.
Time,
so
will
increasing
the
gas
limits
of
30
million
break
ethereum
no
right,
but
it
will
significantly
increase
risks.
It
will
reduce,
it
will
increase
centralization.
It
will
increase
denial
of
service
risks
that
affects
like
bug,
users
and
applications.
B
B
But
now
the
markets
have
actually
calmed
down
a
bit,
but
you
know
at
the
like:
there
is
a
yeah
like
there
is
a
trade-off
and
and
there's
and
definitely
look,
there's
definitely
more
work
that
can
be
done
to
concretely
measure
these
things
right.
So
like
it's,
you
know,
dewey
wants
to
have
say
yeah
like
a
test
net
and
say
you
know
like
on
our
test
debts
we're
just
going
to
have
80
million
guest
limits.
That
might
actually
be
a
good
idea.
B
It
might
actually
be
a
good
idea
to
just
like
increase
the
gas
limit
on
our
test.
That's
from
a
15
or
from
whatever
it
is
now
to
some
high
number
like
80.
Just
so
we
can
have
an
environment
where
people
see
what
it's
like,
what
that's
actually
like
for
a
node
operator
and
maybe
that'll,
give
everyone
on
all
sides,
more
information
to
feel
comfortable,
so
reducing
uncertainty
will
definitely
help
us
kind
of
like
get
get
closer
to
a
value.
That's
actually
optimal.
B
Another
thing
that
will
help
us
get
a
get
to
a
value.
That's
optimal
is
mitigations
to
in
the
the
problems
of
increased
gas
usage,
so
one
of
them
is
verbal
trees
and
statelessness.
So
if
we
have
nodes
can
be
stateless,
then
sync
times
for
those
that
would
stop
being
an
issue
and
hard
drive
space
for
those
node
stops
being
an
issue
but
virgo
trees
and
statelessness
are
also
not
a
panacea
right,
because
there
are
things
that
stateless
nodes
cannot
easily
do
like.
B
B
This
is
this
concept
that
we
reorganize
the
state
so
that
objects
that
have
not
been
touched
within
the
last
one
or
two
years
go
into
a
separate
tree
and
if
they're
at
a
separate
tree,
then
even
state
carrying
nodes
do
not
store
them
anymore,
and
if
you
as
a
user,
want
to
use
that
object
again,
then
you
personally
have
to
go,
find
demoral
proof
for
it
and
provide
that
merkle
proof
as
part
of
the
transaction
peer-to-peer.
Networking
networking
improvements
constantly
happening,
but
you
know
it
can
happen
more
also.
B
Nodes
can
stop
downloading
and
storing
history,
let's
say
older
than
one
year,
so
I
think
I
would
arg
like
what
this
will
actually
happen
automatically
to
some
extent
as
a
result
of
the
merge
right,
because,
as
a
result
of
the
merge
like
potentially
we'll,
have
nodes
to
just
stop
downloading
the
proof
of
work
chain.
That's
before
the
merge,
and
so
we'll
have
a
bit
of
a
reset
to
zero
moments,
which
will
be
nice.
B
They
should
be
using
separate
protocols
that
have
like
simple,
simple
forms
of
sharding
that
have
simple
forms
of
like
torrents
or
like
dht
type
logic.
And
you
know
the
portal
network
once
again,
like
you
know,
piper
miriam
jacob
carver
and
those
people
have
been
doing
excellent
work
pushing
this
forward.
So
that's
also
another
mitigation.
So
you
know,
if
we
have
steel
assistant
state
expiry,
then
I
think
my
impression
from
talking
to
people
is
that
a
lot
of
people
will
be
totally
fine
with
a
yeah.
B
B
So
I
think
we're
far
from
the
points
where
people
feel
like
state
expiry
is
something
that
they've
kind
of
fully
grappled
with
their
heads
or
their
heads
around.
I
think
like.
I
think
people
are
very
supportive
of
the
concept
in
theory,
but
there
isn't
like
certainty
that
it
can
happen
within
any
specific
time
frame
and
the
sooner
we
get
to
that
point,
the
better.
E
F
Can
I
push
back
a
bit
on
this,
like
I
was
holding
until
the
end
of
the
presentation
with
the
questions
on
this
but
vitalik,
I
kind
of
so
everyone,
I'm
worried
from
block
throughout
and
from
eagle
the
theorem
gas
limit
project
vitalik
at
the
beginning.
You
start
by
saying
that
this
there's
no
safer
onset
right.
This
is
a
trade-off,
and
so
I
want
to
push
back
against
like
at
least
the
laptops
argument.
F
F
Do
we
want-
and
maybe
the
answer
is
yes,
but
do
we
want
notes
to
run
on
laptops,
or
is
it
okay
if
they
can
only
run
on
pcs
like
it's
like
if
you're
a
dev,
it's
great,
if
you're
a
participant-
and
I
don't
know
the
answer,
but
the
question
is
who
should
decide
this?
Who
should
decide
whether
it
should
be
able
to
run
on
the
laptop
where
you
always
gonna,
get
on
and
off
or
as
ethereum
matures,
and
you
have
a
lot
of
actors
with
much
higher
like
I.t
budgets
right?
Is
it?
F
B
Yeah
sure
again,
I
think,
like
I
mean
so
like
my
personal
view,
on
the
object
level
question
is
that
there's
like
50
ethereum
killers
out
there
that
are
willing
to
concentrate
on
the
you
know:
500
no
nodes.
This
is
enough
for
everyone,
niche
and
blockchains
that
are
like
committed
to
node
decentralization.
B
There's
you
know
using
kate
commitments
for
data
availability,
sampling
increases
our
vulnerability
to
fancy
moon
math,
cryptography
like
there's
these
kinds
of
trade-offs
everywhere
and
so
coming
up
with
better
ways
of
solving
them
is
just
part
of
this
general.
You
know,
governance
problem
and
the
governance
problem
is
hard
right
and
I
think
there's
like.
F
B
F
No,
so
so
I
would
argue
that
it
isn't
like.
I
would
argue
that,
when
mining
pools
like
40,
one
participates
like
top
three
top
four,
when
they
increase
from
eight
million
to
ten
million
much
higher
junk,
like
a
really
big,
like
25
percent.
I
remember
you
tweeting,
saying
well
sparking
cool
told
me
they're
thinking
of
doing
it.
I
told
them.
F
I
think
it's
not
the
greatest
idea,
but,
like
I
understand
that
they're
doing
it
when
they
increase
it
again
from
10
million
to
12
and
a
half
million
peter
from
guest
was
yelling
at
twitter,
saying
like
they
shouldn't
be
doing
it,
but
they
did
it.
So
I
would
argue
that
hey
they
don't
listen
to
core
devs
and
b.
The
current
changes
are
much
more
drastic.
They
out
of
the
blue,
there's
no
predictability
out
of
the
blue.
They
increase
it
by
a
lot.
B
I
mean
a
factor
of
1.2
is
not
a
lot,
but
I
think
they,
I
would
say
that
miners,
like
they
yeah
well,
okay,
I
do
they
don't
implement
the
exact
same
thing
as
core
developers
preferences,
but
I
do
think
that
they
listen
to
core
developers.
I
do
think
that,
like
if
core
developers
were
to
give
a
hard
no
to
a
number,
then
that
number
would
not
become
reality
right,
like
even
another
example
of
this
is
like
the
increase
from
12
and
a
half
to
15,
like
that.
B
The
gasoline
flux
flexibly
like,
for
example,
it
allowed
a
very
effective
defensive
response
to
the
shanghai
dos
attacks,
but,
like
that's,
that's
different
from
a
kind
of
an
enshrines
architecture
where
they
have.
They
have
the
power
and
they
have
the
legitimacy
to
use
the
power
in
whatever
way
they
want.
F
Attack
but
but
like
we
agree
on
that,
yeah,
okay,
okay,
but
and
last
thing,
because
I
feel
I'm
hugging
the
conversation.
But
is
this
a
technical
question
or
a
question
of
values
like
because
I
understand
I
disagree
with
the
regarding
the
technicality,
but
at
the
general
level
I
agree
with
you,
but
is
the
gas
limit
really
at
the
end
of
the
day,
you
need
technical
people
to
translate
that
into
a
budget,
how
costly
it
is
to
run
a
node
and
then
it's
a
question
of
values.
F
B
There's
definitely
a
point
that,
like
we
need
to
carefully
distinguish
between
technical
judgments
made
by
technical
experts
versus
technical
experts,
kind
of
using
technical
judgments
to
sneak
in
their
own
opinions
on
values
where
they
real.
Where,
like
on
that
question,
they
really
don't
don't
have
or
shouldn't
have
more
of
a
say
than
anyone
else.
But.
B
What
so,
I
guess
like
that
is
a
that
is
a
valid
point
right
and
I'm
definitely
and
I'm
not
like
you're,
defending
a
kind
of
chord
out
like
a
just
structure
where
chord
deaths
have
legitimacy
to
set
the
guest
limit
to
whatever
they
want
either
yeah.
I
think
my
only
real
opinion
is
that,
like
this,
like
these
questions
are
complicated
and
like
the
path
that
we've
taken
so
far,
is
basically
status
quo
but
or
maintain
the
status
quo.
B
Okay,
okay!
No!
No!
This
is
a
conversation
that
needs
to
happen.
I
mean
yeah,
you
can.
You
may
want
to
also
just
like
publish
a
yes,
I'm
a
screed
on
magicians.
I
mean,
I
personally
think
you
know
like
we
actually
need,
might
have
it
just
on
more
people,
publishing
screens
it's.
I
think
it
would
be
nice
to
have
these
ideas
just
discussed
in
in
long
form.
E
F
F
I
have
to
configure
it
and
I
have
no
idea
I
have
no
like,
except
for
peter
saying
being
against
any
single
increase
in
the
past,
like
I
don't
know
two
years
on
one
hand
and
the
oregon
team
being
in
favor
of
increasing
the
gas
limit.
I
have
no
idea
what
court
of
thinking,
I'm
not
sure
even
core
devs,
have
the
answer
like.
I
want
to
know
what
the
community
thinks.
I
think,
and
so
how
do
you
think
about
setting
the
gas
limit
and
how
that
should
should
be
done?
B
Right
so
I
think
like
for
me
my
like
one
ideal
pro
or
like
one
example
process
would
be
like
I
think,
step.
One
is
more
information
gathering
like
one
example
of
information
gathering.
I
would
love
to
just
even
hear
even
offline,
like
what
people
think
of
this
idea
of,
like
let's
increase
the
gas
limit
on
robson
or
gurley
to
40
million
right
like
one
of
those
test
nets,
just
so
that
we
have
one
test
environment
where
the
chain
is
considerably
yeah,
bulkier
and
heavier
than
it
is
today,
and
so
it's
like
it's
not
scary.
B
It's
like
it's
a
much
more
concrete
thing
of
like
what
what
that
world
looks
like,
and
then
you
know.
If
we
have
that
information
then,
like
I
think,
information
gathering
is
step.
One
step
two
is
like.
Like
I
mean,
we've
had
like
various
kinds
of
polling
like
we've,
had
various
ways
of
like
of
just
getting
communities
a
community
sentiment
for
things,
so
I
think
just
use
those
exist.
Those
existing
techniques
like
the
same
sort
of
stuff
that
ended
up
deciding
you
know,
eip1559
the
issuance
reductions.
B
G
I
think
that
there's
also
like
an
element
of
you
know,
there's
this
illusion,
there's
this
vision
that
miners
aren't
listening
to
the
core
devs,
but
I
think
they
actually
are
to
an
extent
it's
just
that.
There's
not
good
communication
channels
open
like
back
in
2016,
when
the
shanghai
attacks
happened,
we
literally
were
able
to
bump
the
gas
limit
down
to
something
like
two
million
and
like
six
hours.
G
G
And
no
much
less
than
six
hours
yeah.
No,
that
was
amazing
yeah.
It
was
really
cool
coordination,
but
now
we
don't
have
those
bridges
and
those
communication
channels.
So
having
that
set
back
up
again
with
some
of
the
major
mining
pools,
I
think
would
be
important
and
we
have
some
people
who
can
probably
do
that
so
yeah
that
would
that
would
be
the
step
I'd
take.
If
I
was
king,
that's.
F
Sounds
good
but
hudson,
just
on
that,
we
like
blocker,
we
work
with
with
the
mining
schools.
We
work
with
all
the
top
20.
and
we
asked
mining
pools
like
why.
How
do
you
decide
on
the
get
like?
What
do
you
want
to
increase
if
you
want
to
decrease
it
and
many
of
them
weren't
even
aware
that
they
controlled
the
gas
limit?
I
think
you're
missing
the
point
that
mining
pools.
B
B
B
A
Really
appreciate
vitalik
taking
out
time
to
join
us
and
provide
great
explanation
thanks
to
micah
james
hudson
for
adding
relevant
information,
and
many
thanks
to
uri
claremont
from
blocks
route
labs
for
joining
and
sharing
his
questions
and
concerns.
I
really
hope
you
may
have
received
answers
to
some
of
the
questions
that
you
were
looking
for.
There
are
some
questions
related
to
governance,
which
I
think
will
not
be
answered
in
this
call,
but
we'll
try
to
organize
a
bigger
community
call,
or
maybe
a
kind
of
ema
session
with
relevant
people.
A
Well,
I
hope
the
recording
of
this
talk
helps
with
the
understanding
of
the
concept
and
would
increase
support
for
important
decisions
like
setting
the
limit
on
this
note
for
our
youtube
viewers,
thanks
for
watching
in
the
description
section,
you
will
find
different
resources
on
the
topic
and
the
twitter
handle
of
the
guest
to
follow.
If
you
like,
today's
episode
hit
the
like
button
and
don't
forget
to
share
it
with
people
of
similar
interests.
If
you
still
have
an
unanswered
question,
leave
it
as
a
comment.
A
I
read
all
the
comments
also,
if
you
have
missed
watching
the
episode.
A
brief
history
of
ethereum's
future
with
bennet
jington.
Please
check
it
out
at
peep
any
playlist
at
ethereum
care
thanks
youtube
as
usual.
I'd
love
to
hear
feedback
and
improvement
suggestions.
Let
us
know
in
the
comment
below
which
proposal
or
topic
would
you
like
to
see
in
the
upcoming
episodes?
We
have
more
interesting
talk
coming
your
way,
so
stay
tuned,
keep
watching
and
keep
sharing
your
love
with
your
cat
holders.
Talk
to
you
soon
in
the
next
episode.
Thank
you.