►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/6/supporting-the-ethereum-roadmap-with-a-decentralized-blockchain-data-supply-chain/index
The original Ethereum vision was for users to run full or light clients to use the network, yet today the most widely used block explorers and JSON-RPC APIs are centralized.
Decentralizing the blockchain data supply chain is more important now than ever, as it supports key parts of the Ethereum roadmap, such as Stateless Clients and “The Purge”, which unlock major gains in security, scalability, and decentralization.
Join us to learn about decentralizing this core part of the Web3 stack.
Speaker(s): Brandon Ramirez
Skill level: Intermediate
Track: Developer Infrastructure
Keywords: Ethereum Roadmap,The Graph,Web3 Infrastructure
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
A
Simply
put
it's
everything
that
happens
between
you
as
a
user,
sending
a
transaction
to
modify
the
state
of
the
blockchain
and
another
user
reading
that
modified
State
based
on
the
transaction
that
you
sent
and
at
a
high
level,
we
can
break
that
up
into
three
kind
of
stages.
You
know
on
the
left.
We
have
writing
state.
So
it's
everything
that
happens
with
you
sending
a
transaction
getting
it
included
in
a
block
on
the
canonical
chain,
which
is
through
consensus
and
then
Downstream
of
consensus.
A
You
have
everything
that's
required
for
that
state
to
be
read
for
the
various
applications
that
you
might
use,
that
state
for,
for
example,
on
a
decentralized
application
and
I
think
most
of
us
are
probably
more
familiar
with
the
right
side
of
the
supply
chain,
because
it's
gotten
a
lot
of
attention
in
the
last
few
years
with
things
like
Mev,
some
of
the
proposals
like
Builder
proposer,
separation
and
Meb
boost.
So
this
is
like
an
example
of
what
the
right
side
of
the
blockchain
data
supply
chain
will
look
like
in
ethereum
in
the
future.
A
You
know
where
you
have
a
transaction
going
to
a
private
or
a
public
mempool.
You
have
people
bundling
that
into
larger
transaction
bundles.
You
have
block
builders
that
might
be
these
specialized
actors
trying
to
kind
of
extract
as
much
Mev
as
possible,
and
then
you
know
eventually
it
makes
it
to
a
proposer
and
validated
as
part
of
consensus
Downstream
of
consensus.
Then
we
have
everything,
that's
required
to
get
that
data
into
a
useful
place
for
you
to
do
something
with
it.
As
a
user.
A
Broadly
speaking,
we
can
break
that
up
into
extract,
transform
and
load,
and
you
don't
always
need
to
go
through
all
those
steps
like,
for
example,
you
know,
Json
RPC
is
a
form
of
extraction.
There's
many
use
cases
that
just
consume
Json
RPC
directly.
Many
people
today
consume
blockchain
data
through
subgraphs,
in
which
case
they're,
using
subgraph
mappings
as
a
transform
step,
and
then
loading
into
a
database
or
a
store.
That's
optimized
for
graphql
queries
later
in
this
talk,
I'll
be
touching
briefly
upon
two
technologies:
fire
hose
and
substreams,
which
are
Next.
A
Generation
versions
of
the
fire
hose
and
extract
logic
and
and
the
the
supply
chain
got
some
autonomous
lights
over
here
at
a
high
level,
we
can
sort
of
categorize
the
different
approaches
to
decentralizing
the
blockchain
data
supply
chain.
The
first
approach
and
I
would
say
for
a
long
time.
This
was
kind
of
the
conventional
thinking
was
what
we
call
Web
2.5
and
in
web
2.5.
Basically,
what
you're
saying
is
we
do
all
the
things
that
we've
been
talking
about?
A
You
know
the
last
few
years
to
decentralize
the
right
side,
so
you
know
protecting
against
Mev
keeping
good
stake.
Decentralization
and
keeping
good
validator
decentralization,
but
then
Downstream
of
that
we
let
the
reads
be
you
know
through
proprietary
apis,
centralized
servers,
Etc
and
I
think
the
reason
that
there's
been
so
much
more
attention
to
the
web.
2.5
vision
is
because
failures
on
the
right
side
of
the
supply
chain
tend
to
be
a
little
bit
more
visible,
or
at
least
a
little
bit
more
intuitive.
A
So
it's
like
you're
getting
your
transaction
censored
from
being
included
in
you
know,
consensus,
that's
something!
That's
going
to
be
very
apparent
and
you
can
point
to.
Similarly,
if
there's
actually
like
a
determinism
issue,
Upstream
of
consensus,
like
some
kind
of
data
or
execution
inconsistencies,
that's
actually
going
to
lead
to
a
consensus.
A
Data
Downstream
of
consensus
impacts
you
as
a
user,
but
it
doesn't
show
up
in,
for
example,
a
consensus
failure.
So
the
other
approach
is
the.
What
we
call
the
web
3
approach
web
3
simply
put
is
full
stack,
decentralization
in
the
context
of
the
blockchain
data
supply
chain.
What
that
means
is
decentralized
rights
like
what
we
just
talked
about,
but
also
decentralized
reads.
A
A
lot
of
my
thinking
on
this
is
obviously
influenced
through
my
work
on
the
graph,
but
I
want
to
note
that
there's
other
projects
in
this
space,
like
portal,
Network
pocket,
Network,
true
blocks
that
are
all
taking
varied
approaches.
I
definitely
recommend
you
checking
out
sort
of.
You
know
this
landscape
of
you
know
the
decentralized
reads.
A
So
why
do
decentralized
reads
matter
to
the
ethereum
vision
or
to
the
web
3
vision
I
think
we
can
start
by
just
reasoning
about
it
from
first
principles
and
like
what
it
looks
like
to
access
a
decentralized
system
through
a
centralized
intermediary
by
a
quick
show
of
hands.
Does
anyone
see
something
wrong
with
the
diagram
on
the
right
side
of
the
screen.
A
I'm
glad
I
can
educate
you
today,
so
you
know
what
we're
showing
on
the
right
is
basically
a
decentralized
system
kind
of
on
the
top
right
being
accessed
through
a
centralized.
You
know
intermediary
so
like
so
much
of
the
work
that
you
guys
have
heard
about
in
the
ethereum
ecosystem
from
ethereum.
Researchers
is
really
about
maintaining
decentralization
at
the
blockchain
layer
at
you
know.
You
know
at
the
consensus
layer
and
then
what
we've
effectively
done
in
many
instances
is
taking
this.
A
You
know
decentralized
system
with
all
its
benefits,
all
its
advantages,
put
it
inside
of
a
box
and
then
accessing
that
box
through
a
centralized
gatekeeper
and
at
that
point,
what's
inside,
the
Box
really
becomes
irrelevant
right
all
the
work
that
that's
been
done
to
like
actually
build.
This
beautiful
decentralized
system
is
sort
of
opaque
to
the
end
user
into
the
applications
that
are
built
on
top
offeree
I.
Think
put
it
really
concisely,
he's
one
of
the
you
know
early
prominent
ethereum
core
developers
that
just
you
know
if
dapps
are
still
accessing.
A
You
know
the
blockchain
through
centralized,
you
know
hosting
you
know,
then
the
ethereum
vision
has
effectively
failed.
Is
the
way
that
he
the
way
that
he
put
it
I
was
working
on
an
analogy
to
describe
kind
of
the
web
2
dilemma,
and
hopefully
this
isn't
too
soon,
but
one
analogy
that
kind
of
made
this
stick.
For
me,
a
little
bit
is
that
if
web2
is
someone
sneezing
on
you
during
the
pandemic
and
web3
is
a
properly
fitted
n95
mask
then
web
2.5
is
kind
of
like
a
chin.
A
Diaper
right
and
like
I
know,
there's
a
lot
of
different
opinions,
and
you
know
ideas
on
the
efficacy
of
you
know:
mask
mandates,
Etc,
but
I
think
we
can
all
agree
that
the
chin
diaper
really
didn't,
make
a
lot
of
sense
and
that's
kind
of
web
2.5
right
it
just
doesn't
make
sense.
It's
sort
of
you
know
it's
incongruous
with
the
goals
of
of
you
know,
blockchain
and
web3.
Specifically,
it
undermines
a
lot
of
the
value
propositions
that
you
know
the
ethereum
founders
and
a
lot
of
the
early.
A
A
Building
on
Open
Standards,
the
composability
of
your
applications
and
of
the
stuff
that
you've
built
goes
down
quite
a
bit,
and
even
if
there
was
a
standardization
on
these
centralized
servers,
there's
a
limit
to
how
much
composability
you
can
get
when
you're
building
on
centralized
building
blocks,
because
the
more
centralized
building
blocks
you
compose
the
more
brittle
your
system
becomes
because
now
you're.
Basically
you
know
if
one
centralized
building
block
in
your
giant
compose
system
goes
out.
A
Well
now
that
ripples
to
breaking
your
entire
system,
as
opposed
to
you,
know,
Unstoppable
smart
contracts
running
on
ethereum
the
way
those
work
where
you
know
a
new
D5
protocol
can
come
along
integrate
with
an
existing
Unstoppable
D5
protocol
and
that
composition
can
keep
you
know
playing
out
until
you
get
this.
You
know
this
really
rich
tapestry
of
you
know
decentralized
applications.
A
It
definitely
hurts
for
usability.
You
know
if
you're
just
doing
one-offs
all
the
time
and
then
I
think
you
know
on
ownership,
censorship,
resistance,
fairness,
I'm,
gonna,
try
and
paint
this
a
little
bit
in
a
few
examples.
The
first
is
how
many
people
saw
the
the
article
that
Moxie
Marlin
Spike
from
signal
wrote
earlier
this
year.
Okay,
like
let's
say
30,
so
he
he
wrote,
I
recommend
you
look
it
up.
A
He
wrote
a
very
well-intentioned,
well
thought
out
critique
of
web3
from
someone
actually
trying
to
make
a
good
faith
attempt
at
building
some
decentralized
applications
in
the
space,
and
so
one
of
the
things
that
he
did
was
build
an
nft
app
and
to
sort
of
kick
the
tires
on
like
the
guarantees
that
we
think
we
have
when
we're
building
on
nfts.
He
basically
built
a
single
nft,
but
depending
on
where
you
viewed
it,
whether
you
viewed
it
on
openc
wearable
or
in
your
own
wallet.
A
You
got
one
of
the
three
images
shown
on
the
screen
so
like
when
you're
actually
buying
the
nft
or
looking
at
it
in
a
collection
you're,
seeing
like
this
cool
piece
of
artwork
and
then
by
the
time
it
makes
it
to
your
wallet.
You
get
a
poop
emoji
and
that's
possible
because
the
nft
was
not
hosted
on
decentralized
data
and
using
a
decentralized
data
supply
chain.
It
was
using
centralized
servers
to
serve
that
that
nft,
you
know,
and
and
for
a
lot
of
us
who
are
sort
of
inspired
by
the
ownership
vision
of
web3.
A
You
know
that
web3
is
enabling
digital
ownership.
You
know,
how
can
we
own
things
when
the
actual
information
artifacts
that
we're
owning
are
controlled
by
centralized?
You
know
intermediaries,
so
this
experiment
also
highlighted
a
a
way
in
which
we
have
censorship
in
quote-unquote
web
3
today,
because
once
openc
realized
that
Moxie
had
done
this,
they
actually
de-listed
his
nft
from
openc,
which,
if
openc,
was
doing
that
as
a
individual
application
and
doing
that,
for
you
know,
sort
of
their
own
purposes
and
I.
Think
that's
you
know
fine,
like
we
believe
in
choice.
A
You
know
at
the
at
the
level
of
projects
and
individuals,
but
the
problem
was
that
so
many
other
projects
in
the
ecosystem,
we're
building
on
the
open,
C
API
that
him
getting
delisted
from
the
openc
application,
also
made
it
so
that
the
nft
stops
showing
up
in
wallets
and
all
these
other
places
where
you
would
expect
to
see
an
nft
that
you
had
purchased
right.
So
this
is
a
real
example
of
censorship.
A
That's
happened
just
this
year
in,
in
the
context
of
you,
know
the
blockchain
data
supply
chain
for
a
use
case
that
we
all
I
think
care
a
lot
about
another
one
that
this
is
a
little
bit
more
speculative
but
I.
Think
it's
an
interesting
one,
just
as
a
thought.
Experiment
is
index
or
extractable
value.
This
was
an
idea
that
was
put
forth
by
someone
in
our
community.
A
You
can
think
of
this
as
being
a
little
bit
analogous
to
like
Mev
or
also
payment
for
order
flow,
which
is
which
got
a
lot
of
attention
this
past
year
or
two
when
people
realized
that
Robin
Hood's
business
model
for
offering
free
you
know,
stocks
trading
to
retail
investors
was
that
they
sell
the
order
flow
to
Giant
hedge
funds
like
Citadel
and
then
Citadel
with
its
privileged
access
to
these.
To
this
order,
flow
can
then
like
extract
all
this
value
at
the
expense
of
the
retail
investor.
A
You
know
our
financial
lives
as
it
exists
on
the
blockchain
okay,
so
that's
kind
of
where
the
web
3
vision
is
at
today
and
sort
of
the
importance
of
you
know
the
keeping
the
blockchain
supply
chain
decentralized.
Let's
talk
about
where
ethereum
is
going
and
the
ways
in
which
a
decentralized
blockchain
data
supply
chain
supports
that
Future
Vision.
A
So
for
those
that
saw
vitalik's
ECC
talk
earlier
this
year,
you
might
have
come
across
these
new.
Let's
call
them
work
streams
that
are
all
happening
in
parallel,
so
you
know
they're,
not
sequential
Milestones,
but
they're.
All
all
parallelized
work
streams
that
are
happening
in
the
ethereum
ecosystem,
the
merge
The
Surge,
The
Verge
and
the
splurge,
and
the
diagram
on
the
left
can
look
a
little
intimidating.
A
We're
just
going
to
focus
on
a
few
aspects
of
this
roadmap,
specifically
parts
of
the
Verge
The
Purge
and
parts
of
sort
of
the
light,
client
vision
of
ethereum.
So
a
brief
overview.
The
Verge,
one
of
its
sub
goals,
is
around
supporting
stateless
clients.
Stateless
clients
allow
validators
to
sort
of
be
small
and
light
while
having
like
heavier
specialized
Builders
in
the
you
know
the
right
side
of
the
blockchain
data
supply
chain.
A
There's
different
approaches
to
this
weak
statelessness,
strong,
statelessness,
weak
statelessness
is
where
Builders
sort
of
provide
the
the
witness
of
state
that's
being
used
by
a
transaction
and
strong
statelessness.
The
end
user,
actually,
when
they
submit
a
transaction,
they
would
also
have
to
submit
the
state
that
that
transaction
is
going
to
access
as
a
witness
to
the
network.
The
Purge
is
about
history
expiry
as
well
as
state
expiry.
A
They'd
allowed
to
be
allowed
to
prune
historical
blocks,
basically
keeping
the
the
storage
footprint
of
these
nodes
lighter
and
then
State
expert
expiry,
basically
attacks
the
unbounded
state
growth
of
ethereum,
where
certain
state,
if
it's
not
touched
frequently
enough
again,
would
be
allowed
to
expire
and
then
like
clients,
we're
going
to
touch
on
a
little
bit
in
the
next
screen.
But
I
think
they're
interesting
to
bring
up
here,
because
they
share
a
lot
of
the
same
requirements
as
sort
of
those
previous
two
milestones
and
they're
also
part
of
the
solution.
A
Space
right,
because
a
lot
of
this
stuff
boils
down
to
being
able
to
access,
State
and
and
data.
But
the
problem
with
like
clients
is
that
today,
at
least
like
clients
rely
on
altruism
from
the
full
nodes
in
the
ethereum
network.
So
if
those
full
nodes
decide
to
support
the
light
client
protocol
and
serve
data
to
these
like
clients,
then
it
works
out
great.
But
the
reality
is
that,
because
of
that
lack
of
incentives,
as
you
know,
Piper
one
of
the
researchers
working
on
this
noted.
A
Basically,
the
the
light
client
protocol
in
ethereum
is
a
vast
desert
of
starved
clients,
desperate
for
data.
It's
not
working
right.
It
works
nice
in
theory,
but
in
practice
you
need
incentives
or
some
way
to
make
that
data
available
to
support
these
light.
Clan
protocols
which
mind
you
is
very
important
to
the
vision.
You
know,
ethereum's
founding
vision
of
you
know
decentralization
so
the
common,
the
common
threads.
You
know
without
going
too
deep
into
the
the
weeds
of
any
of
these
sort
of
proposals
in
the
road
map.
A
There's
some
common
threads
that
we
can
kind
of
paint
here
in
terms
of
requirements,
and
it's
basically
that
all
of
these
proposals
are
going
to
need
to
depend
on
some
way
of
reliably
efficiently
and
verifiably
accessing
either
historical
blocks
or
pruned
blocks
from
the
you
know
the
blockchain
or
expired
or
uncached
state.
So,
in
the
case
of
State
expiry,
it's
expired
state.
In
the
case
of
stateless
clients,
it
might
be
just
state
that
the
Builder
or
the
user
needs.
That's
not.
A
You
know,
cached
locally
and
the
solution
space
breakdown
here
I
think
you
know,
can
be
broken
into
two
larger
categories.
One
is
financially
incentivized
approaches
you
we
mentioned
those
like
those.
You
know
like
clients
needing
cooperation
from
the
full
nodes
which
right
now
don't
have
an
incentive.
A
You
know
that
you
get
and
that's
the
approach
being
explored
by
projects
like
portal
network,
using
things
like
gossip
protocols
and
dhts,
which
again
are
techniques
from
BitTorrent
and
now
ipfs
as
well,
and
so
why
are
we
doing
all
this
like?
Why
are
we
getting
rid
of
all
this
state?
Why
are
we
getting
you
know?
What
are
we
doing
it
for
the
fun
of
it?
A
No
we're
getting
rid
of
this
state
in
this
history
for
a
purpose,
and
that
purpose
is
scaling
ethereum
in
a
decentralized
way,
so
simply
put
what
that
means
is
being
able
to
fit
more
transactions
into
a
block
being
able
to
have
bigger
blocks,
while
maintaining
a
small
footprint
for
validating
clients
and
and
like
clients,
and
as
an
example
of
this
one
of
the
eips
that's
out
there
right
now
is
called
eip4488.
It
proposes
a
approximately
5x,
cheaper,
5x
reduction
in
gas
costs
for
call
data.
A
This
is
about
supporting,
like
the
ethereum
like
roll
up.
You
know
Centric
future,
but
the
reason
that
they
feel
comfortable
doing
this,
which
was
inevitably
going
to
lead
to
bigger
blocks
or
more
full
blocks,
is
because
it's
intended
to
be
paired
with
eip44s,
which
is
one
of
the
proposals
in
The
Purge,
which
specifies
dropping
this
requirement
for
full
nodes
and
validator
nodes
to
keep
around
all
this
historical
blocks
past
a
certain
point.
A
Okay,
so
this
last
one
is
kind
of
a
bonus
section.
I
think
this
is
really
interesting
from
both
a
couple
standpoints.
One
is
that
the
fire
hose
which
we
we
briefly
noted
earlier,
is
a
Next,
Generation
extraction.
Technology
I
think
it's
interesting
a
because
I
think
it.
It
should
impact
the
way
that
ethereum
clients
get
built
in
the
future,
but
I
also
think
it's
interesting,
because
it's
an
example
of
sort
of
this
positive
externality
coming
from
an
ecosystem.
That's
tackling
the
blockchain
data
supply
chain
in
a
decentralized
open
source
way
right.
A
So
this
is
fire
hoses
technology
originally
created
by
streaming
fast,
which
is
another
core
developer
in
the
graph
ecosystem.
Before
we
get
into
how
it
works,
it's
worth
calling
out
some
of
the
problems
with
Json
RPC
and
the
way
that
it
works
today.
So
you
know,
most
of
you
I
think
are
show
of
hands
people
that
are
familiar
with
Json
RPC,
okay,
most
people
in
the
room.
So
this
is
how
you
access
you
know,
data
from
like
a
Geth
or
an
Aragon
client.
Today
it
basically
depends
on
a
running
program
to
read
data.
A
So
if
you
look
at
this
diagram
on
the
left,
you
kind
of
have
this
fan
in
architecture
where
all
the
users
are
sort
of
hitting
a
running
process.
That
process
consumes
CPU.
That
process
becomes
the
bottleneck
for
getting
data
out
of
the
node
and
then
because
you
need
to
have
heavier
nodes
to
serve
all
the
data
that
people
want
like
archive
nodes,
potentially
running
Purity
Trace.
It's
also
incredibly
intensive
on
memory
and
solid
state
disks,
because
in
order
to
actually
efficiently
access
that
data,
you
need
to
provision
a
lot
of
of
both
of
the
latter.
A
It's
difficult
to
get
query
intermediate
States,
so
Json
RPC
really
only
lets
you
query
data.
As
of
a
block,
you
can
get
a
little
bit
more
by
using
the
parity,
Trace
API,
but
it's
still
incomplete,
also
very
cumbersome.
It
can
be
difficult
to
debug.
So
if
you're
using
you
know
a
subscription
to
like,
if
get
logs,
for
example,
via
inferior,
like
we've
encountered
this,
you
know
in
our
own
stack
that,
like
sometimes
you
know
in
the
past,
messages
will
just
get
dropped.
A
You
can
get
a
Merkel
proof
for,
but
other
data
like
if
you're,
using
like
the
eth,
get
logs
interface,
for
example,
there's
not
a
really
easy
way
to
get
a
compact
proof
that
says
you
didn't
miss
any
logs.
You
know
in
within
some
range
of
within
some
range
of
blocks.
So
what's
the
solution,
we
think
the
solution
is
the
fire
hose
approach.
It's
streaming
first.
So
if
you
look
at
the
diagram
on
the
left,
data
is
being
on
like
as
soon
as
it's
available.
A
It
is
being
broadcast
out
in
a
fan
out
approach,
rather
than
this
fan
in
it's
being
distributed
as
flat
protobuf
files.
So
these
can
be
distributed
across.
You
know
commodity
Hardware
like
and
using
things
like,
you
know:
Google
Cloud,
object,
storage
or
Amazon
S3,
because
you
know
now
we
have
these
distributed
flat
files.
Now
we
can
parallelized
workloads
on
those
files.
You
know
all
without
even
touching
the
blockchain
node.
A
So
this
is
much
more
akin
to
like
what
you
would
see
in
like
a
Hadoop,
you
know
big
data
architecture
where
you
have
all
these
flat
files
distributed
across
commodity
hardware,
and
then
you
have
you
know
these
compute
clusters
that
can
be
scaled
independently
and
spin
up
concurrent
and
parallelized
access
for
doing
this
sort
of
transform
steps.
You
know
on
that
data,
and
so
so,
when
you
do
that
stuff,
you
get
you
know
compared
to
the
approach
of
using
Json
RPC.
Today,
you
you
know,
you
get
a
one
to
two
order
of
magnitude.
A
A
So
you
know
you
could
imagine
sort
of
the
fire
hose
instrumentation
logic
running
as
a
wasm
process
that
is
implemented
as
a
read
oriented
roll-up,
so
like
an
optimistic
roll-up
or
even
a
ZK
roll-up.
That
actually
gives
you
some
guarantees
on
the
validity
of
the
sort
of
data
that
is
extracted
through
that
fire
hose
instrumentation
process
and
then
the
Final
Approach
that
you
know
and
again
these
are
still
very
early
and
US
thinking
about
this,
but
the
Final
Approach
is
you
could
even
potentially
integrate
fire
hose
files
into
the
consensus
process
itself.
A
Now
you
probably
wouldn't
want
to
do
that
initially,
because
initially
there's
a
strong
benefit
to
having
what's
called
like
data
agility
being
able
to
evolve.
The
schema
evolve.
The
instrumentation
logic
based
on
sort
of
a
changing
understanding
of
what's
needed,
but
as
those
Integrations
stabilize
there
might
come
a
time
and
point
where
blockchain
core
developers
decide
to
say:
hey
we'll,
you
know
we'll
reference.
You
know
a
maybe
the
fire
hose
files
from
the
previous
Epoch.
A
Another
integration
story
here
related
to
eip44
called
shim
clients,
but
we're
out
of
time.
So,
if
you're
interested
in
that,
you
know
feel
free
to
come
up
to
me
and
find
me
afterwards
highly
recommend,
checking
out
Alex
B
from
streaming
fast
talk
this
week
on
substreams
and
then
also
Vincent
from
asari
has
a
talk
on
standardized
subgraphs,
but
they're
heavily
using
fire
hose
and
substreams
as
part
of
their
as
part
of
their
dog
footing.
So
yeah.
Thank
you
guys
very
much.
That's
my
talk.
A
B
A
B
For
oh,
thank
you
for
the
the
stateless
clients
in
like
eip444.
Is
there
any
way
to
estimate
or
predict
like
how
like,
basically,
what
I'm
trying
to
understand
like?
Can
the
graph
Network
itself
as
a
whole,
essentially
like
earn
income
from
providing
a
service
of
like
you
know,
basically,
the
the
current
ethereum
nodes
retiring,
the
state,
but
then
graph
notes
serving
up
that
and
then
as
a
whole,
like
the
network,
getting
some
profitability
from
that
yeah.
It's
a
really
good.
A
Question
so
this
is,
these
are
sort
of
emerging
ideas
in
our
ecosystem,
but,
like
increasingly,
my
view
of
the
graph
is
that
it
is
going
to
be
like
a
multi-service
ecosystem.
So,
like
today,
the
primary
service
is,
you
know
you
do
ETL
into
a
subgraph
and
query
it
via
graphql,
but
there
might
be
a
range
of
services,
for
example,
accessing
fire,
hose
data
directly
or
Json
RPC
data
directly
or
data
in
a
key
value,
store
or
a
SQL
store
and
I.
A
Think
all
of
those
could
potentially
be
supported
side
by
side
in
different,
like
name
spaces.
If
you
will
within
the
graph
ecosystem,
and
in
that
context,
then
you
could
imagine
yes
graph
indexers
and
service
providers
being
the
the
endpoint
that,
like
light
clients,
use
to
to
get
their
data,
it
could
also
be
what
blockchain
nodes
themselves
use
to
hydrate.
You
know
data
and
some
of
these
other,
you
know
related
to
these
other
Milestones,
so
yeah
I
think
I
think
it
will
be
a
source
of
query
volume.