►
From YouTube: EIP-1559 in Filecoin - Juan Benet
Description
For more information on Filecoin
- visit the project website: https://filecoin.io/
- or follow Filecoin on Twitter: https://twitter.com/Filecoin
Get Filecoin community news and announcements in your inbox, monthly: http://eepurl.com/gbfn1n
A
We
are
using
eip1559
in
falcon.
Many
of
you
will
be
familiar
with
it
if
you're
in
the
ethereum
community,
but
if
you're
not
I'm
going
to
give
a
short
introduction,
I'm
going
to
move
pretty
fast
through
this,
because
we
only
have
about
15
minutes
and
there's
a
lot
to
cover.
I'm
going
to
give
a
very
brief
intro
to
the
gas
pricing
model
of
falcon,
which
is
based
on
ethereums
I'll.
A
Give
a
brief
introduction
to
eip1559,
then
I'll
talk
about
how
we
adopted
it
and
why
we
adopted
this
gas
pricing
structure
in
filecoin,
then
we'll
get
to
look
at
some
data
of
how
it's
been
performing
in
the
network.
You
know,
epa
1559
is
is
driving
the
the
gas
pricing
of
platform.
A
Today
it's
live
on
the
main
mainnet
and
then
we'll
talk
about
some
of
the
pros
and
cons
of
the
user
experience
of
of
using
ap
1559
and
then
we'll
talk
about
kind
of
the
the
the
effects
on
on
supply
and
community
and
and
so
on.
A
After
that,
I'll
talk
a
bit
about
some
outstanding
problems
and
questions
specific
to
filecoin.
A
I
think
maybe
some
of
these
some
of
these
might
be
relevant
for
ethereum
as
well
and
for
other
adopters
of
of
this
of
gas
scheme,
but
most
of
them
will
be
will
be
specific
to
falcoin
from
there
I'll
talk
a
bit
about
some
of
our
future
work,
especially
some
contributing
some
of
our
thoughts
back
upstream
into
the
ethereum
community,
great
so
lightning,
fast,
introduction
to
the
gas
model
of
ethereum,
so
suppose
that
there's
a
blockchain
here's
drawn
from
the
going
from
the
right
is
the
past
to
the
left.
A
Each
block
carries
a
whole
set
of
transactions.
You
can
think
of
them.
Sorted
hereby
by
transaction
fee,
so
say
that
the
green
ones
have
a
higher
transaction
fee.
The
red
ones
have
a
lower
transaction
fee
and
the
miner
decided
to
order
them
that
way.
In
practice
it
looks
very
different
per
block,
but
this
is
just
a
simplified
toy
model
for
us.
A
So
when,
when
the
blocks
come
in,
the
transactions
are
effectively
ordered
and
fed
into
the
into
the
evm,
which
then
executes
each
transaction
and
changes
the
state
tree.
Those
transactions
as
they
execute,
spend
computational
resources.
That
computation
is
measured
in
gas,
and
so
gas
is
a
resource
that
the
ethereum
community,
the
ethereum
blockchain,
spends
in
order
to
run
the
computations
in
the
blockchain.
A
So
summarizing
there
are
blocks
that
carry
transactions
which
are
function,
calls
executed
in
a
virtual
machine,
changing
state
in
the
state
room
and
each
transaction
costs
gas
paid
to
miners,
and
so
the
original
sort
of
model
was
that
there
was
a
transaction
fee
associated
with
with
a
transaction,
and
this
is
inspired
by
bitcoin.
A
Where
there's
a
gas
fee
times.
The
amount
of
gas
used
right.
So
each
function
call
will
use
a
whole
bunch
of
of
gases
hard
to
predict
what
how
much
that
will
be
and
then
a
that'll
be
multiplied
by
by
kind
of
a
fee
denominated
in
gas
units
and
then
it'll
will
get
a
price
in
in
so
users
would
have
to
select
a
gas
fee
and
would
be
subjected
to
a
first
price
auction.
A
So
this
means
that
all
the
transactions
that
are
in
the
in
the
pool
of
available
transactions
for
miners
to
mine
into
a
block
would
then
be
sorted
by
miners
and
be
picked
in
terms
of
which
are
the
the
highest
highest
fees.
This
led
to
all
kinds
of
tricky
ux
problems,
so,
for
example,
he
made
it
so
that
if
there
was
any
kind
of
strong
network
ingestion,
then
it
would
incentivize.
A
Maybe
a
few
parties
to
jack
up
the
the
transaction
fees
fill
the
blocks
for
a
long
time
and
then
kind
of
back
up
all
kinds
of
other
really
critical
operations
in
the
network.
So
it's
difficult
to
to
understudy
operations
schedule
running
processes
in
a
solid
way.
It
also
made
it
difficult
to
deal
with
the
fact
that,
when,
with
with
this
kind
of
first
price
auction
model,
this
is
not
a
very
efficient
way
to
allocate
resources
to
standalone
capital.
A
A
So
all
kinds
of
other
systems
and
tools
have
to
execute
this
vm
code,
and
so
every
transaction
that
goes
into
the
network
spends
lots
and
lots
of
network
resources,
including
wallets
and
whatnot,
and
that
gas
fee
that
was
paid
to
a
single
miner
ends
up
hurting
the
the
rest
of
the
network
so
yeah.
This
is
just
kind
of
like
a
picture
view
of
the
first
price
auction
model
transactions
go
into
a
pool,
they're
sort
of
sorted
by
transaction
fee.
A
Then
they
get
put
into
blocks
and
and
off
you
go
so
this
is
some
of
the
so
now
emp
1559
came
to
to
radically
change
change
this
model.
The
quick
view
is
so
not
going
to
go
in
in
full
detail
here,
but
the
big
sort
of
critical
change
is
there's
now
a
base
fee
idea
and
the
base
fee
is
a
fee.
A
That's
associated
with
a
network
stayed
at
a
particular
moment
in
time
and
that
base
fee
will
either
go
up
or
down
based
on
congestion,
so
it
allows
the
blocks
themselves
to
flex
in
terms
of
the
total
amount
of
gas.
So
if
there's
a
particular
network
congestion
and
there's
a
lot
of
transactions
that
have
funds
above
the
base
fee,
more
transaction
fee
caps
above
the
base
fee,
more
will
be
led
into
the
block.
The
block
will
expand
and
that
will
trigger
the
increase
of
the
base
fee.
A
So
for
the
next
block
over
that'll
increase
the
price
threshold
of
transactions
that
get
in
eventually
the
blocks
will
start
shrinking
in
size
and
be
less
than
than
say
a
hundred
percent
utilization,
and
then
the
base
fee
will
will
come
down.
So
this
turns
it
into
a
market
into
much
more
efficient,
efficient
market.
A
So
efp1559
is
not
in
the
main
night.
Yet
it's
been
implemented
by
a
number
of
folks,
but
it's
not
you
know,
live
in
the
live
in
the
network.
It
may
potentially
come
into
eth1
people
may
wait
until
e2,
there's
lots
of
r
d.
I
highly
encourage
you
to
read
the
papers.
There's
lots
of
really
great
great
resources
around
and
the
the
summary
that
I
showed
was
from
this
great
paper
that
came
out
recently
by
tim
rock
garden.
A
That
is
a
whole
report
on
the
entire,
an
in-depth
analysis
of
the
eip1559
construction
and
here's
like
a
a
set
of
key
takeaways
from
from
the
report
we'll
go
into
them
great,
so
that
was
a
longer
enter
than
I
than
I
expected
to
give.
But
let's,
let's
race
through
the
through
the
rest
of
the
stuff,
so
happy
to
report
that
the
falcon
team
implemented
erp
1559
into
the
popcorn
code.
It's
live
in
the
network,
it's
running
and
managing
all
our
transactions.
A
We
switched
to
this
primarily
because
we
were
using
the
old
model
and
we
had
a
whole
bunch
of
hard
problems
with
it,
because
falcons
especially
is
tuned
for
certain
kinds
of
transactions
that
need
to
get
into
the
chain
quite
quickly
and
on
regular
cadence,
and
so
that
made
eip
1559
very
attractive
right
now.
You
can
see
this
chart
in
the
bottom.
We'll
look
at
this
in
more
detail
later,
but
this
is
a
a
graph
of
the
utilization
in
red.
A
A
It
has
way
easier,
ux,
so
better
estimation
and
fee
setting
both
for
programs
that
are
running
in
the
network
and
for
users
who
are
trying
to
use
the
network
so
window
post
falcon
has
a
specific
type
of
message
that
needs
to
get
into
the
chain
within
a
very
short
time
limit.
So
the
first
price
auction
congestion
is
way
too
bad
for
this.
A
So
if
there's
anything
kind
of
exciting
happening
in
the
network
and
any
kind
of
congestion
hits,
then
all
of
those
window
posts
are
gonna
get
dropped
unless
miners
are
paying
very
close
attention
and
kind
of
hiking
up
prices
along
the
way
and
so
on
so
and
in
addition,
we
also
want
to
make
sure
to
pay
the
network
for
transactions,
there's
all
kinds
of
operations
that
are
dependent
on
these
transactions,
so
we
needed
to
pay
the
network.
A
We
had
been
researching
different
kinds
of
models,
and
then
we
found
the
ap
1559,
so
we're
like
great,
let's,
let's
standardize,
so
we
have
to
make
some
adaptations
for
file
points
and
number
one
is
that
we
use
tip
sets
which
means
that
transactions
go
into
onto
the
chain
before
they're
executed
and
they're
executed
on.
A
And
then,
when
that
estimate
actually
gets
executed,
we
can
diff
the
estimate
to
the
actual
amount
of
gas
that
got
used
and
then,
if
there's
a
margin
above
if
the
overestimation,
if
the
estimation
is
over
by
a
significant
margin,
then
there's
a
there's
some
associated
punishment
for
for
doing
that,
because
that
kind
of
adds
inefficiency
to
the
network.
A
So,
let's
get
into
the
evolve
part
so
for
performance
wise.
You
know
this
is
a
snapshot
view
into
a
bunch
of
the
transactions
that
are
going
through.
The
falcon
network,
so
you
can
see
most
of
it-
is
proof
commits
and
pre-commits.
So
this
is
storage,
onboarding
and
then
a
tiny
fraction
of
the
rest
of
the
messages
and
are
a
are
all
the
other
kinds
of
other
kinds
of
things
like
window
posts
and
message
sends
and
all
that
kind
of
stuff.
So
this
is
a
view
by
by
count.
A
This
is
a
view
by
gas
usage.
So
window
post
is
a
small
amount
of
messages
relatively,
but
actually
quite
high
usage,
because
you
have
to
verify
a
bunch
of
snarks
and
so
on
and
also
deals
require
a
bunch
of
gas
usage
as
well.
So,
and
these
will
start
creeping
in
so
window
posts
and
publish
sales
will
take
more
and
more
fractions
of
the
block
over
time
as
the
network
network
scales.
A
A
The
good
news
is
that
eip1589
allows
the
window
post
messages
to
be
to
have
a
you,
know:
high
gap,
gas
cap
and
then
be
able
to
get
in
without
having
to
pay
exorbitant
prices
all
the
time,
and
instead
only
do
so
when
the
base
fee
goes
up,
and
so
this
is
a
much
much
much
better
model
so
really
kudos
to
the
to
the
whole
ethereum
team
for
building
a
really
good
system
that
works
very
well
for
us.
A
Here's
a
snapshot
of
that
that
graph
that
I
showed
before
here's
a
period
of
24
hours.
You
can
see
that
the
red
line,
the
use
capacity,
is
actually
a
hundred
point.
Seventy
three
percent,
so
so
this
means
that
the
base
fee
is
working
very
well
to
keep
the
gas
usage
actually
at
exactly
around
100.
So,
even
though,
in
some
cases
the
block
sizes
jump
up
to
a
130
percent.
In
our
case
it
comes
back
down
nicely.
A
Ethereum
recommends
going
up
to
200,
potentially
with
with
with
the
basic,
basically
hiking
hiking
up,
and
we
we
are
also
in
that
regime,
but
because
of
tips
as
the
sense
of
being
we
have
it's
somewhat.
We
have
the
intuition
that
there's
lower
elasticity
in
in
this
regard
in
popcorn,
but
remains
to
be
to
be
proved,
you'll,
see,
though,
the
basic
variations
are
really
high.
A
So
these
are
these
jumps,
are
really
big,
we'll
see
them
in
in
another
graph
in
a
moment,
so
that
change
rate,
if
you
see
that
basically
jumping
up
and
down
in
a
bunch
of
spikes,
that's
not
very
good
for
the
network
and
we'll
talk
more
more
about
why
so,
maybe
this
is
intrinsic
to
a
p559
and
that's
just
how
it's
going
to
be.
But
ideally,
if
we
could
smooth
this
out,
I
think
it
would
perform
better.
A
Some
interesting
results
with
a
bunch
of
the
fee
schedules
there
were
a
bunch
of
this
is
a
track
of,
I
think,
a
few
yeah
about
a
month
of
operation
that
red
line
is
overestimation
burn
and
so
over
time
all
kinds
of
parties
got
way
better,
estimating
burn
and
then
adjusting
their
their
code
to
make
to
make
sure
that
they're
not
wasting
wasting
things.
A
The
green
is
the
gas
premium
and
then
the
bit
you
can
see
the
base
fan
in
gray,
and
this
is
a
a
a
a
logarithmic
graph.
So
you
can
see
the
base
fee
is
moving
large
amounts,
here's
a
view
into
the
burn,
so
this
is
the
base
fee
burn.
So
this
is
what
what
the
what
the
participants
are
paying
to
the
network
and
we
can
see
the
the
kind
of
overestimation
burn
as
well
and
then
minor
tape
on
the
bottom,
so
this
is
dominated
by
the
base.
A
Speed
burn
great
so
in
terms
of
supply,
this
is
sort
of
like
the
hourly
burn
rate
plotted
over
the
last
two
weeks.
This
is
over
the
last
two
months,
like
a
total
amount
of
burned
popcorn.
This
means
you
know.
Millions
of
falcons
have
been
paid
to
the
network
to
pay
for
the
continued
running
of
that
transaction
forevermore
right.
A
So
all
kinds
of
programs
and
people
will
have
to
continue
running
that
transaction
and-
and
this
file
point
has
paid
for
that
for
that
future
future
execution,
and
so
that
burn
you
know,
as
we
saw
in
the
last
last
talk
this
kind
of
affects
the
the
kind
of
models
about
circulating
supply
and
so
on.
I
think
this
is
the
current.
A
I
think
this
is
the
current
just
just
the
current
data
up
into
where
we
are
today,
so
you
can
see
sort
of
the
circular
supply
and
the
other.
The
other
factors
that
affect
it.
Graphed
here
also
interesting
to
note
that
if
you
charge
sort
of
a
a
proportion
chart
between
circulating
supply,
the
log
factor
and
the
network
fee,
you
get
this.
This
set
of
curves,
where
we
now
the
amount,
that's
locked
and
the
amount
that's
going
to
the
network
fee
seems
to
be
catching
up
to
the
amount.
A
That's
minted.
So
again,
this
is
this
is
a
a
bunch
of
these
calculations,
and
charts
may
be
totally
wrong.
This
is
totally
research
or
this
is
you
know
our
notes.
This
could
be
totally
wrong,
so
don't
rely
on
any
of
those
at
all,
but
this
is
interesting,
interesting
observations
that
we
we
might
be
reaching
so
great.
So
in
terms
of
user
experience,
let
me
talk
about
the
good
and
the
bad
hey.
A
It
works
very
well
in
a
lot
of
regards,
it's
really
easy
to
get
transactions
into
the
network.
We
have
had
very
serious
congestions
from
for
a
very
long
time
now
and
it
is
very
nice
and
easy
to
get
spends
and
you
know
kind
of
really
important
messages
get
through
the
chain
without
without
a
hitch
and
it,
and
so
it
works
very,
very
smoothly,
so
great
work.
So
this
there's
this
very
nice
fast
lane
for
these
high
value
transactions
the-
and
this
also
gives
us
a
much
easier
ux.
A
So
it's
very
easy
for
programs
and
and
and
and
tools
to
just
calculate
the
the
the
the
fee
based
on
kind
of
the
the
suggestions
from
from
the
falcon
implementation
and
they
kind
of
said
that
or
if
the
user
wants
to
indicate
some
some
higher
higher
rate.
That's
that's
easy,
but
you
don't
have
to
think
very
much
about
like
the
actual
prices
or
anything
like
that,
and
you
know
it's
way
better
in
terms
of
optimizing.
The
fee
spans.
A
So
if
we
had
been
using
the
for
the
first
price
auction
model
way,
more
falcon
would
have
been
would
have
been
paid
in
in
fees
to
fees
in
kind
of
a
silly
way.
So
I
think
that
overall,
this
has
been
saved
a
lot
of
a
lot
of
spending
now,
for
the
user
experience
the
bad
parts.
So
this
this
is
kind
of
like
a
view.
So
this
is
fill
fox
one
of
the
block
explorers.
A
You
can
see
the
the
24
hour
chart
on
the
variations
of
the
of
the
base
fee,
and
this
is
jumping
quite
a
bit
pretty
significant.
So
when
you
see
a
jumps
of
that
magnitude,
they're
having
very
dramatic
impact
on
on
people's
people's
mining
operations
and
and
so
on,
especially
for
small
miners,
you
can
see
here
a
bunch
of
the
responses
from
the
community
and
we
feel
the
pain.
A
This
is
a
really
bad
place
to
be
in
so
right
now,
the
onboarding
rate
and
the
congestion,
because
of
onboarding
rate,
is
pricing
out
a
lot
of
the
window
posts
that
are
required
for
for
continuing
to
onboard.
So
this
is
so
continuing
to
prove
the
storage
online.
So
this
is
a
pretty
serious
problem
that
we
have
to
deal
with
fairly
quickly.
A
So
this
is-
and
you
know,
a
lot
of
the
communities
mobilizing
against
this
and
there's
a
bunch
of
solutions
that
are,
you
know,
unrelated
to
to
the
base
fee,
but
but
are
sort
of
caused
by
the
just
the
fact
that
congestion
makes
makes
these
transactions
very
expensive,
but
but
it
means
that
the
basic
gets
blamed
by
this,
because
when
the
base
fight
jumps
up
the
entire
community
response
the
base
fee-
and
so
it
becomes
very
frustrating
in
the
same
way
that
that
congestion
in
the
in
the
normal
gas
model
gets
really
frustrating.
A
And
so
this
is
a
plot
over
the
last
three
months-
and
you
know
it
probably
feels
like
this
for
for
a
lot
of
people,
and
so
this
is.
This
is
not
good.
It's
a
problem
that
we
we
gotta
solve,
especially
for
window
post.
A
You
can
also
imagine
this
correlating
very
highly
with
the
blood
pressure
of
a
lot
of
people
in
the
network,
so
great
so
now
some
remaining
problems
and
I'm
meeting
a
little
bit
into
the
q.
A
time
at
I'll
borrow
a
little
bit
more
time,
we'll
hit.
A
So
so
we
hit
really
bad
conjunction
with
for
window
post,
and
that
means
that
these
daily
window
posts
that
need
to
happen
become
very
expensive
when
the
fee
spikes,
and
so
that
needs
very
significant
improvements
and
those
improvements
can
be
specific
to
popcorn
or
it
can
be
improvements
that
are
pretty
general
in
terms
of
the
gas
model.
So,
for
example,
something
that
could
be
general
for
the
gas
model
is
that
we've
been
thinking
about
splitting
the
the
gas
model
into
two
independent
lanes.
A
So
one
would
be
a
control
plane
for
operations
that
are
critical
to
the
function
of
the
protocol
so
and
the
other
would
be
the
data
plane
that
which
are
you
know,
kind
of
new
transactions
that
parties
are
adding
in.
So
this
would
be
a
way
of
of
of
giving
and
prioritizing
access
to
a
few
transaction
types
that
have
to
be
appearing
at
certain
time
frames
and
so
on.
So
you
can
think
of
them
as
ambulances
going
through.
A
You
know
a
very
crowded
freeway,
which
you
know
ambulances
get
to
do
that,
not
because
they're
paying
more
but
because
they're
sort
of
critical
to
the
operation
of
the
system,
and
so
that's
that's
a
a
a
creating
a
different
market
for
for
the
this,
and
then
you
can
sort
of
set
a
a
percentage
of
a
block
that
should
be
dedicated
to
the
control
plane
versus
the
percentages
should
be
dedicated
to
the
data
plane
and
the
idea
of
a
control
plane
and
a
data
plane
comes
straight
from
networking,
so
computer
networks
deal
with
this
distinction,
specifically
because
of
a
network
congestion.
A
So
this
is
a
tried
entry
method
for
dealing
with
congestion
in
systems
like
this,
especially
because
problems
in
the
control
plane
might
cause
more
congestion
or
less
congestion.
So
if
you,
if
you
make
sure
that
the
control
plane
is
served
well,
then
then
the
rest
of
the
protocol
should
operate
correctly.
A
We're
also
looking
at
potentially
creating
message
type
fee
structures
where
this
is
not
looking
at
just
the
raw
gas
directly,
but
instead
starting
to
price
and
create
a
market
for
how
we
think
about
which
messages
should
be
how
those
messages
should
be
priced.
So,
for
example,
it
allows
the
network
and
the
community
to
create
some
sort
of
policy
oriented
towards
hey
should
be.
Should
we
be
prioritizing
kind
of
like
the
maintenance
of
small
miners
which
will
be
prioritizing.
A
The
onboarding
storage
rate
of
in
the
larger
scale
should
be
prioritizing
deals,
and
so
these
different
kind
of
fee
structures
could
help
with
the
network
create
some
levers
to
orient
what
the
network
should
should
be,
should
be
aiming
to
to
price
out
and
there's
also
a
whole
bunch
of
specific
things
that
we
need
to
do.
This
is
unrelated
to
the
to
to
the
gas
model,
so
we
gotta
scale
proofs
make
it
you
know,
do
batch
verification
of
snarks.
A
We
do
slash
oriented
verification,
so,
instead
of
verifying
everything,
just
actually
introduce
the
snarks
and
then
create
a
slashing
oriented
way
to
to
spot
spot
failures.
We
also
scaling
consensus
is
the
other?
The
other
big
thing
that
we
that
we
need
to
do
so
we
need
to
go
to
sharding.
So
it's
very
clear
that,
given
the
congestion
rate
of
outline
already,
we
gotta
move
towards
starting
very
very
quickly.
A
So
a
lot
of
a
lot
of
us
are
already
starting
to
to
work
on
that
great,
so
some
other
important
thoughts
here
one
is,
it
would
be
really
nice
to
to
get
to
a
better
change
rate
and
kind
of
reduce
the
spikiness
of
of
the
base
fee
change,
that'll,
probably
smooth
out
some
operation,
so
some
future
work
data
analysis.
We
have
a
lot
of
data
about
the
network,
so
we
we're
doing
a
bunch
of
this.
A
We
invite
other
researchers
interested
in
this
to
work
with
us,
especially
all
the
ethereum
community,
go
come
look
at
our
data
and
inform
your
your
decisions
for
for
ethereum
we'd
love
to
explore
some
improvements
to
the
gas
model,
especially
this
control,
plane
and
data
plane
distinction.
A
We
might
also
end
up
implementing
the
escalator,
which
is
another
gas
structure.
One
explained
here
and
one
one
final
thought
here
is:
it
would
be
really
great
to
introduce
a
lot
more
queuing.
A
Theory
into
the
gas
model
of
these
systems,
there's
a
lot
of
so
certainly
when
it's
bounded
and
constrained
by
computation,
then
this
model
works
when
it's
not
bounded
by
computation,
then
this
model
will
actually
leave
a
lot
of
potential
bandwidth
up
for
grabs
and
there
would
be
really
nice
to
establish
some
qos
guarantees
for
certain
kinds
of
transactions
and
certain
kinds
of
message
types
in
the
network.
A
So
I
think
it
would
be
really
useful
to
to
think
about
how
to
how
to
establish
certain
kinds
of
guarantees
directly
in
the
key
model.
So
this
is
sort
of
future
work,
not
not
urgent,
but
but
will
be
helpful
for
blockchain
systems.
The
last
one
I'll
mention
is
we
a
lot
of
schemes
that
we
have
come
up
with
rely
on
encrypt
and
execute
transactions
where
any
participant
could
introduce
a
message
into
the
network
anonymously.
A
Have
that
message
be
added
onto
the
chain,
then,
at
a
future
point
in
time,
be
decrypted
and
executed,
so
we're
starting
to
think
about
how
to
how
to
add
this.
In
fact,
some
of
the
solutions
that
we
have
to
our
current
problems
that
I've
described
now
rely
on
this
model.
So
this
is
some
some
stuff
that
we're
thinking
about
the
last
thing
I'll
leave
you
with.
A
During
the
test
net,
we
had
a
bug
that
actually
caused
some
crazy
inflation
of
the
base
fee,
and
so
we
at
some
point
the
base
fee
wasn't
measured
in
four
billion
file
coins.
So
you
can
you
can
see
this
in
the
data
it's
all
in
the
chain,
and
so
this
was
kind
of
like
this
crazy
explosion
and
a
lot
of
us
remember
that
day
as
a
pretty
funny
day.