►
Description
Follow the latest from NEAR Protocol on:
Website: https://near.org/
Discord: https://near.chat/
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
#Blockchain #FutureIsNEAR #NEAR #nearprotocol
A
Or
well,
I'm
leo
I'm
the
core
developer
as
a
node
and
I'll
be
talking
about
to
you
today
about
our
collaboration
of
new
year,
which
has
been
going
on
for
well
at
least
this
entire
year
and
eager
to
share
all
of
our
results.
A
So
first
I
want
to
tell
you
a
story,
and
here
you
can
see
two
near
the
app
developers.
You
have
one
front
end
guy
and
one
let's
say
a
data
science
guy,
so
they
you
know
they
are
building
their
d
app
and
it's
already
they've
got
the
the
smart
contracts
all
built
on
on
deployment
ear
and
they
need
to
get
the
data
out.
A
So
they
look
at
this
wall
of
blocks
and
they
know
the
data
is
there
somewhere,
but
they
don't
know
how
they're
going
to
get
it
out
or
how
they're
going
to
organize
it
to
do
their
data
analysis
or
build
out
their
front
end.
A
So,
looking
at
this
wall
of
blocks
very
confused,
so
they
they
asked
their
their
friends
in
the
blockchain
ecosystem.
You
know,
how
do
you
build
your
d
apps?
How
do
you
build
your
front
ends?
How
do
you
get
the
data
out
of
all
these
blocks
and
they
asked
around
and
all
of
the
you
know
the
ethereum
people,
yellow
people
avalanche
phantom?
You
know
bsc
and
so
many
other
networks
that
polygons
so
many
other
networks
that
the
graph
already
supports.
They
all
pointed
him
at
the
same
direction.
A
They
told
them
use
the
graph,
but
the
near-death
developers
told
them
well
like
well,
we
don't
have
the
graph.
You
know
we're
we're
lost
here
so
today
we're
very
happy
to
announce
that
the
graph
has
come
to
near
so.
A
The
app
developers
rejoice,
you
have
been
saved
by
the
graph
yeah,
so
let's,
let's
get
into
how
all
that
works.
A
Depending
on
how
familiar
your
subgraphs,
you
know,
a
subgraph
carries
a
definition
of
a
graphql
schema
because
we
expose
a
graphql
interface,
which
is
just
what
those
d
app
developers
want
when
they
are
dealing
with.
Data
is
something
that
a
technology
that
they
already
know,
possibly
from
different
backgrounds
even
from
web
2.
Graphql
is
very
it's
widely
widely
used.
A
So
we
just
want
to
give
you
a
single,
well
hd
app
develops
a
subgraph,
and
the
subgraph
contains
a
graphql
api
that
is
tailored
to
their
use
case
and
to
their
needs
and
the
subgraph
to
provide
the
data
that
backs
the
graphql
api
will
track
data
sources.
So
when
you
talk
about
a
subgraph
in
foreign,
you
need
to
define
what
a
data
source
for
that
subgraph
looks
like.
A
So
this
is
a
this
is
a
data
source,
so
you
know,
kind
has
the
same
year
and
network
near
mainnet,
and
so
the
source
is
an
account
right.
So
because
that's
how,
for
example,
you
know
in
this
hero,
it
would
be
a
contract
address
here,
it's
an
account,
so
you
have
the
account
string,
start
block
in
case
you
don't
have
to
sync
through
the
entire
chain
from
genesis.
A
And
then
there's
something
interesting
at
the
bottom
there,
which
is
the
the
hands,
are
kinds
so
at
launch.
We're
supporting
two
and
two
types
of
triggers.
Two
types
of
henders
vernier,
which
are
block
handlers
and
received
handlers,
so
block
handler
is
something
that's
going
to
trigger
on
every
block.
In
case
you
need
to
update
something
on
every
block.
It's
going
to
have
access
to
the
block
header.
A
So
this
is
an
example
of
a
handler,
so
the
data
sources
define
what
data
you're
going
to
take
as
an
input
and
but
then
you
can
transform
the
data.
You
know
you
don't
just
because
you
need
to
organize
that
to
to
suit
your
your
graphql
api.
We
don't
just.
We
know
we're
not
just
exposing
the
raw
data
so
with
the
mapping.
This
is
going
to
be
very
familiar
to
assembly
script
developers
because
it's
an
assembly
script.
A
So
you
write
your
mapping
assembly
script
and
you
handle
that
that
data
and
store
it
store
it
as
entities
into
your
into
the
graph
store
right.
The
store
for
your
subgraph
and
those
energies
are
what's
going
to
be
queries
through
graphql
api,
so
here's
an
example
handler
a
handler
for
a
receipt.
You
can
grab
the
rc
id
and
just
to
this
just
to
illustrate
one
very
common
use
case,
which
is
to
parse
the
logs.
So
you
can
parse
the
receipt
logs
and
use.
A
A
So,
of
course
everybody
wants
to
know
okay,
so
when
can
I
use
this
and
that's
basically
today
we
have
our
docs
already
live.
You
can
check
them
out
start
building
out
your
subgraph.
A
It's
going
to
be
live
in
our
hosted
service,
which
means
that
on
the
graph.com
you
need
to
head
to
the
legacy
explorer
to
see
to
deploy
those
sub-graphs
and
yeah
and
later
today
it's
not
you
cannot
just
right
now.
You
cannot
deploy
them,
but
later
today
it's
already
going
to
be
available
and
yeah.
Please
start
hacking
and
let
us
know,
let
us
know
what
you
think.
A
You
know
you
can
contact
us
at
near
the
graph.com
if
you're
in
a
billion
know
we're
very
eager
to
know
what
you're
building
and
you
know,
help
you
out
in
any
way
that
you
can
and
show
up
on
our
discord
as
well.
A
But
yes,
when
right
now,
but
you
know,
I
must
give
the
beta
alert
there's
you
know,
there's
like
the
v
zero
of
the
near
end
graph
integration,
it's
very
much
beta,
you
know
things
might
know,
subgroups
might
stop
thinking,
things
might
break
things
might
change,
but
that's
also,
you
know
in
a
way
it's
a
good
thing,
because
it
means
that
developers
can
give
us
feedback
and
we
can
incorporate
it
quickly
because
we
really
want
to
iterate
at
this
beta
stage.
A
And
now
I
wanna
tomorrow,
my
colleague,
who
also
also
I
don't
know
adam,
is
gonna,
be
also
giving
a
talk
and
he
was
to
you
know,
give
more
of
an
overview.
But
I
want
to
dig
today
into
a
bit
of
the
the
weeds
of
how
the
disintegration
went
and
how
he
built
this
over
the
last.
You
know
six
months
or
more
really.
A
So
this
is
a
collaboration
between
three
development
teams.
Near
core
team
was
very
important
because
of
the
near
industry.
Framework
streaming
fast,
also
hugely
important
because
they
built
the
fire
hose,
which
I'm
going
to
explain
in
a
moment
what
the
fire
hose
is,
but
it's
a
new
architecture
to
feed
feed
data
into
the
graph.
No,
the
graph
is
what
does
the
core
subgraph
indexing
and,
of
course,
an
edge
node,
which
you
know
maintains
the
graph
node,
which
is
what
our
indexes
run
to
keep
the
graph
network
running
and
indexing.
A
So
you
know
what
are
you
interested
in
a
near
block?
So
this
is
a
near
block
from
the
point
of
view
of
what's
relevant
to
the
graph
right
now,
and
so
it
has
block
header,
has
a
bunch
of
receipts
that
have
been
executed
at
that
block
and
the
receipts
have
the
logs
or
they
have
function,
calls
and
things
that
are
relevant
for
developers
to
handle
in
their
subgraphs.
A
So
this
is
our
the
fire
hose
architecture.
So
over
there
we
have
the
near
deepmind.
A
The
deepmind
component
is
an
instrumented
node,
which
takes
the
data
directly
from
the
near
node
and
communicates
it
over
grpc,
and
here
the
indexer
framework
by
near
was
fundamental
because
it
basically
already
provides
you
with
an
instrumented
node
and
submitted
a
new
node
with
the
hooks,
so
you
just
have
to
plug
in
the
the
grpc
streaming
directly
into
the
indexer
framework.
So
that
was
the
you
know
very
important
part
from
the
near
chord
that
was
used
and
then
all
of
those
the
arrows
are
just
blocks
flowing
through
grpc
through
the
system.
A
So
when
the
when
we
have
the
instrumented
block,
it
goes
to
the
block
store
so
that
from
the
next
time
we
scan
because
no
bunch
of
new
sub
graph
has
deployed.
We
need
to
scan
the
chain
again
next
time
that
we
scan
it's
going
to
be
in
the
store
so
that
it's
quickly
accessible
and
but
also
we
need
to
listen
to
the
network,
live
to
the
new
events
and
the
new
blocks.
A
A
So
that's
the
firehose
architecture
and
that's
what
streaming
fast,
which
is
a
core
team
at
the
graph.
As
you
know,
this
one
core
team
streaming
faster,
another
car
team
and
figment-
is
a
third
core
team
which
is
also
working
on
the
we
are
all
working
on:
the
stack
on
the
firehose
stack
yeah
and
that's
the
technology.
That's
the
streaming
fast
brought
to
the
table
and
I'm
gonna
drive
a
bit
into
a
graph
node,
which
is
yeah
a
bit
more
of
my
personal
expertise.
A
So
how
does
graph
node
become
multi-chain
right?
How
do
we,
because
now
so
far,
the
graph
was
only
ethereum
and
evm
compatible
networks,
so
we
had,
you
know
ethereum
written
all
over
that
code
base.
So
how
did
we
change
things
so
that
now
it
can
be
compatible
with
just
about
any
blockchain
in
principle
and
on?
Here
is
the
first
example
of
that,
so
the
the
structure,
if
you're
familiar
with
frost,
you
have
the
crates
which
are
packages.
A
A
So
we
have
a
nice
separation
and
know
to
abstract
the
blockchain.
First,
you
must
abstract
the
block
and
it
turns
out.
The
graph
now
doesn't
need
to
know
a
lot
of
specifics
about
a
block.
We
need
a
block
pointer,
which
is
just
you
know,
a
number
and
hash
which
you
can
expect
from
just
about
any
blockchain
and
the
block.
A
block
must
have
a
pointer
number
and
hash,
and
it
must
have
a
parent
pointer
if
you're
familiar
with
first
syntax.
A
An
option
means
that
it's
nullable,
you
know
the
parent
pointer,
is
notable
simply
because
genesis
doesn't
have
a
block,
a
parent
right
so
to
handle
genesis.
It
must
be
an
option,
but
that's
really
all
the
assumptions
that
we
do
about
a
block.
Everything
else
can
be
entirely
up
to
the
specific
chain,
and
this
allows
us
to
have
all
the
flexibility
to
you
know
have
any
sort
of
custom
handles
or
triggers
like.
We
have
the
receipts
for
near.
A
So
this
is
the
blockchain
trade,
so
a
trait,
if
you're
not
familiar
with
us,
a
trait
is
like
an
interface
from
other
languages,
so
we
just
defined
the
block
trait,
so
the
blockchain
trait
has
a
block
type
which
must
implement
the
blockchain,
which
we
just
saw
yeah.
So
this
is
going
to
be
the
essence
of
what
what
a
blockchain
is
to
to
graph
node
right-
and
I
really
at
the
end-
don't
don't
need
to
assume
a
lot.
A
We
need
to
have
a
data
source
that
we
just
saw
in
the
previous
slides
the
definition
of
a
data
first
from
here
we
need
triggers
such
as
the
receipts
and
the
block
handlers,
and
they
need
to
have
an
order,
because
graphical
needs
to
execute
things
deterministically,
so
they
need
to
have
always
a
deterministic
order.
A
You
need
to
be
able
to
have
a
block
stream
which
is
fed
by
the
fire
hose
which
you
just
saw,
and
you
need
to
be
able
to
pull
the
blocks
from
a
specific,
the
triggers
from
a
specific
block
and
when
you
have
a
trigger
in
a
data
source.
You
need
to
know
if
that
data
source
is
interested
in
the
trigger,
and
it
has
a
handler
for
that
trigger
and
that's
really
all
we
need
from
the
no
the
specific
blockchain
package.
The
the
near
package
has
an
implementation
of
blockchain
for
the
foreign
year.
A
You
know
reality
is
more
complicated,
of
course,
but
this
is,
you
know,
pretty
reasonably
accurate
for
each
block
and
block
stream
for
a
trigger
in
the
block
using
those
functions
that
we
just
saw
for
each
data
source
in
the
list
of
data
sources
in
the
subgraph
that
we
just
saw
in
the
yaml
syntax.
A
You
know
if
that
data
source
matches
that
trigger.
If
it
has
a
handler
for
that
trigger
then
process,
it
send
it
over
to
the
run
time
the
assembly
script
wasm
to
be
processed.
So
that's
it.
Then.
If
you
have
that
blockchain
trade
defined
note,
the
graph
number
gives
you
the
graphql
interface.
It
will
give
you
the
store,
it
will
handle
reorgs
for
you.
A
So
we
don't
care
if
your
chain,
you
know
it's
like
a,
has
crab
claws
and
answer
horns
or
if
your
chain
has
the
feet
of
a
platypus
and
the
horns
of
her
rhinoceros
or
if
it
flies
or
if
it
walks
or
if
it
crawls.
If
it
can
conform
to
that
interface,
very
simple
interface,
the
graph
is
gonna,
be
able
to
index
it.
A
So
what
do
we
have
in
store
for
the
future
function?
Call
handlers
for
near
because
we
do
have
the
receipt
handlers,
but
that's
the
function
calls
are
a
bit
more
granular
level.
A
So
no
because
you
know
emitting
the
logs,
the
receipts
are
great
for
parsing
the
logs,
but
emitting
the
logs
has
a
gas
cost
for
the
contract.
So
if
we
could
just
parse
the
function,
call
arguments
directly
that
would
save
gas
for
the
apps.
So
that's
something
that
we
want
to
include.
A
Data
source
templates,
if
you
have
like
a
factory
contract
pattern
where
you
don't
know
of
hand
which
accounts
exactly
you
want
to
track,
or
maybe
you
want
to
track
an
account
and
it's
sub-accounts,
that's
something
that
we
also
see
as
an
extension,
the
decentralized
network,
of
course,
because
we
have
the
launcher
decentralized
network
right
now,
the
only
we
only
support
ethereum
mainnet
on
it,
but
we
are
working
on
extend,
bringing
the
full
support
for
all
of
the
things
that
we
support
on
the
hosted
service
gradually
and
eventually,
also,
of
course,
near
on
the
decentralized
network.
A
So
now
we
can
benefit
from
the
reliability
of
having
indexers
distributed
around
the
world
indexing.
Our
subgraph.
A
A
And
also
a
new
type
of
handler
that
you
could
think
of
as
like
state
change
handlers,
which
means
you
track
like
a
specific
state
variable
in
the
contract
and
whenever
that
changes
you
have
a
trigger,
so
that
could
be
like
the
most
granular
possible
level
of
trigger.
But
it's
a
as
you
guys
saw
you
know
in
our
architecture
any
trigger
that
you
can
pull
off
a
block
any
deal.
That's
there
you
can.
A
If
the
near
indexer
exposes
it
and
the
firehose
can
pull
it
off,
pull
it
out
of
the
the
block.
It's
a
very
extensible
interface.
So
you
can,
you
know,
give
us
feedback
on
what
type
of
triggers
you'd
like
to
see
in
near
subgraphs.