►
From YouTube: Graph Day: Trust-minimized Services, Work Tokens & A Decentralized Query Protocol w/ Brandon Ramirez
Description
Brandon Ramirez, Graph Protocol's co-founder and Research Lead, gave a presentation at Graph Day on January 25th, 2019 in San Francisco. He explains what "Trust-minimized Services" are and why they are important, gives an overview of Work Token Economics, and finally, presents an initial design for a Decentralized Query Layer for Web3. The publication and open-sourcing of The Graph's research is announced.
Sections:
0:00 Intro: what is The Graph
1:30 Trust-minimized Services
15:48 Work Token Economics
26:33 Decentralized Query Layer for Web3
Link to slides: https://www.slideshare.net/secret/iNtK1lI2IETZOG
Follow The Graph on social media
Twitter: https://twitter.com/graphprotocol?s=20
Instagram: https://instagram.com/graphprotocol
LinkedIn: https://www.linkedin.com/company/thegraph/
GitHub: https://github.com/graphprotocol
Website: https://thegraph.com
#web3 #dapps #thegraph
A
That
really
validated
the
idea
that
we're
working
on,
and
so
what
I
want
to
talk
to
you
guys
today
about
is
what
is
the
graph,
that's
kind
of
like
my
main
job
as
research
leader,
I,
just
answer
this
question
and
some
of
you
guys
might
think
it's
strange
framing
it
in
that
way.
Like
me
asking
what
is
the
graph
there's
actually
like
an
apocryphal
story
about
Michelangelo
the
time
Renaissance
artists
being
asked
a
similar
question?
How
did
he
design
and
build
the
Statue
of
David
and
he
responded
that
it
was
easy.
A
He
just
chipped
away
all
the
parts
that
weren't
David
and
so
this
kind
of
notion
that
the
the
correct
design
is
already
in
there
and
it's
sort
of
just
waiting
to
be
discovered,
and
so
for
the
past
year,
I've
been
approaching
my
work
in
much
the
same
way
and
I
want
to
share
three
dimensions
of
how
I've
come
kind
of
come
to
understand
the
graph.
The
first
two
of
them
are
sort
of
these
foundational
concepts.
A
A
I
I
see
one
I
see
we
want
to
end.
Do
you
speak
Chinese
or
not
yet,
okay,
ambitious,
so
the
the
reason
I
would
contend
that
you
wouldn't
use
the
Russian
or
Chinese
version
of
these
services
is
because
these
services
are
trusted
and
when
I
say
that
I
mean
two
different
things.
I
mean
that
you
trust
the
reputation
and
the
legal
jurisdiction
of
like
the
these
three
particular
companies,
but
also
that
to
use
these
services
effectively.
A
They
require
trust,
and
so
this
is
kind
of
like
a
confusing
thing
in
crypto,
especially
the
people
that
are
like
new
to
it.
We
talk
through
these
words
around
a
lot.
Trustless
trusted
trust
minimized,
and
it's
especially
confusing
because
we
we
use
these
terms
in
a
way,
that's
a
little
bit
different
from
how
we
use
them
in
the
dictionary.
A
So
in
the
dictionary
you
might
see
a
definition
like
this
says:
trusted
is
regarded
as
being
reliable
or
truthful,
and
trustless
is
not
deserving
of
trust
and
when
we
say
it
in
crypto
land,
we
actually
mean
something
very
different:
that
a
trusted
service
is
one
that
requires
trust,
to
use
it
and
a
trust
list
service
or
a
trust
minimized
services,
one
that
minimizes
the
amount
of
trust
required
to
use
it
effectively
and
a
lot
of
people
kind
of
treat.
Trust
is
like
a
four-letter
word
as
sort
of
like
it's.
A
This
bad
thing
to
be
avoided
out
at
all
costs.
I
actually
think
Trust
is
quite
good
in
certain
contexts.
So,
like
imagine
a
situation
where
you
have
Alice
and
Bob
and
like
some
small,
remote
village
and
they're
unbanked,
neither
of
them
is
creditworthy
and
they
don't
have
like
the
local
currency,
but
they
do
want
to
do
business
with
one
another.
A
It's
actually
really
nice
that
they
can
exchange
I'll
use
and,
like
you
know,
the
economy
doesn't
grind
to
a
halt
just
because
neither
of
them
can
get
access
to
like
banking
services,
and
indeed
that,
like
would
maybe
even
work
for
their
entire
village
right,
like
they
all
kind
of
live
next
to
each
other.
They
see
each
other
face-to-face
they
exchange
and
accept
one
another's
I'll
use
and
that
kind
of
speaks
to
the
nature
of
money.
But
the
problem
is
when
we
try
and
apply
those
same
sorts
of
patterns
to
larger
systems.
A
A
You
know
with
the
kind
of
a
huge
sort
of
range
there,
but
where
it's
a
sort
of
natural
maximum
for
these
human
groups
to
wear
like
cooperation,
sort
of
breaks
down
and
if
you
think
about
it,
computationally
it
sort
of
makes
sense,
like
you
have
this
sort
of
exponential
growth
in
like
one-to-one
communication
that
you
need
to
manage,
and
so
what
we've
done
historically,
because
being
able
to
cooperate
on
a
large
scale
is
so
useful.
Is
that
we've
divided
it
into
hierarchies
right?
So
at
each
layer
and
the
hierarchy
we
can.
A
You
know,
deal
with
the
manageable
number
of
like
interpersonal
connections,
and
we
apply
this
all
over
the
place.
Right
governments,
companies,
services,
religions,
you
can
all
think
of
them
as
being
organized
into
these
hierarchies
so
that
we
can
achieve
global
scale.
And
if
you
see
that
the
the
King
Hat
at
the
top,
like
that's
just
kind
of
like
a
an
acknowledgment
that
like
with
this,
you
know
great
power
of
you-
know:
hierarchy
and
social
scalability
when
you
use
hierarchy.
A
A
This
is
really
just
asking
the
question
like:
can
we
build
systems
out
of
global
scale
without
resorting
to
hierarchy
and
all
the
things
that
that
come
with
that
another
way
to
think
about
trust
and
in
the
context
of
information
technology
is
sort
of
with
this?
Like
age-old
philosophical
question
of
like
how
do
you
know
that
you
know
that
you
know
or
that
you
know
what
you
know?
Excuse
me,
and
most
of
us
don't
ask
us
this
ourselves.
A
This
question
very
often
it's
kind
of
a
fun
game
to
play
like
how
do
you
know
how
much
money
is
in
your
bank
account
right
now
like?
Is
it
because
you
saw
it
on
the
screen
somewhere
like
just
and
like
just
kind
of
on
so
another
example?
That's
come
up
quite
a
bit
recently,
for
me
is
like
hey:
did
you
see
that
thing
the
president
said
and
then
like
I
go?
You
know,
try
and
verify
that
for
myself
and
I
and
then
I
end
up
on
Twitter,
calm
and
I.
A
Look
at
you
know,
maybe
a
typical
tweet
from
our
president,
and
you
know
how
do
I
know
that
the
president
really
said
this?
Is
it
because
his
name's
Donald
J
Trump
on
on
Twitter
and
like
the
picture,
looks
like
the
president?
Or
is
it
because
you
know
he
has
the
username
real
donald
trump,
or
maybe
it's
because
of
the
badge
right?
He
has
this
like
twitter
verification
badge
that,
like
I
really
want,
but
don't
have.
A
He
has
and
like
who's
who's,
giving
out
the
badges
like
there's
some
like
smoke-filled
room
where
people
are
giving
out
twitter
badges.
Like
I
don't
know
what
the
process
is.
How
do
I
know
even
on
twitter,
calm
right
like
who's
controlling
the
DNS
servers
that
are
taken
the
address,
twitter.com
and
mapping
that
to
a
physical
server
somewhere?
That's
sort
of
me
this
page
and
you
like
the
the
really
like
tech
savvy
people
in
the
river
like.
A
Well,
no,
you
know
there's
an
ssl
certificate,
because
google
chrome
is
telling
you
that
you
know
this
is
actually
twitter
calm
but
like
who
is
the
certificate
authority
that
they're
using
you
know?
Are
you
sure
that
you
really
downloaded
the
right
version
of
google
chrome
like
what
was
that
download
link
from?
Did
someone
give
it
to
you?
A
This
is
by
no
means
a
comprehensive
list,
but
I
think
the
most
foundational
of
these
is
values.
We
don't
talk
a
lot
about
values
in
the
context
of
the
web,
but
we
have
this
sort
of
intuitive
understanding
of
what
a
value
is
right,
like
the
number
5
is
a
value.
The
first
edition
of
The
Great
Gatsby,
is
a
value.
A
That's
not
how
we
do
things
on
the
web.
When
the
web,
we
share
references
to
values
right
and
it
like.
We
share
them
all
over
the
place
and
we
build
things
out
of
references
of
references
and
so
actually
rich
Hickey
has
a
really
great
talk
on
this
I
highly
recommend.
You
check
it
out.
It's
called
value
of
values
and
he
calls
that
what
we're
doing
today
place
oriented
programming
or
plop,
and
it's
kind
of
defined
by
this
notion
of
just
overriding
data
in
place,
and
so
you
know
the
benefit
of
values.
A
Is
that
they're,
unchanging,
they're,
immutable
and
so
rich.
Like
even
know
a
lot
about
this,
he
he
designed
the
programming
language
closure,
as
well
as
which
is
a
value,
oriented
programming
language
and
he
built
the
database,
the
atomic,
which
is
one
of
the
few
databases
at
the
time
that
had
this
immutable
information
model
and
it
actually
inspired
a
lot
of
our
design
thinking
at
the
graph
I'll.
Let
him
tell
you
a
little
bit
about
this.
Oh.
A
Well,
alright,
so
most
of
you
guys
know
that
this
is
a
rickroll,
it's
kind
of
a
cheap
joke,
but
it
kind
of
highlights
the
point
that
I'm
making,
which
is
that,
like
this
joke,
was
so
funny
for
so
long
because
literally
you
just
never
know
what
you're
getting
like
a
link
doesn't
tell
you
anything
about
the
data
that's
contained,
underneath
it
right.
It's
like
the
two
basic
primitives
of
the
web.
A
I
would
argue
or
like
the
URL
and
like
the
sequel
database
ID,
and
if
you
think
about
it,
like
the
places
right
like
URLs,
get
mapped,
IP
addresses
that
get
mapped
to
actual
servers.
They
don't
actually
tell
you
anything
about
the
values
that
they're
meant
to
represent
and
the
same
thing
with
sequel
database
IDs
right
like
if
I
tell
you
to
go,
find
this
table
and
go
to
the
tenth
row
and
like
get
me
the
data,
that's
there
like.
A
A
We
just
accumulate
values,
we
kind
of
accrete
them
like
layers
of
sediment
and
once
the
value
has
been
referenced,
you
can
always
go
back
and
know
that
that
reference
is
going
to
refer
to
that
same
value
and
one
nice
thing
about
values
is
they're
invariant
to
time
and
space
right
like
because
they
don't
change.
Like
I
know
it's
going
to
be
the
same
value
next
week
or
if
I
access
it
from
Mars,
which
is
why
I
PFS,
you
know,
call
themselves
the
interplanetary
file
system.
A
Another
primitive
we
want
to
have
to
do
anything
useful
on
the
web
is
messaging,
that's
trust
minimized.
So
you
know
in
the
example
of
Twitter
you
guys
kind
of
took
it
for
granted
that
there's
like
all
these
ways,
I
mean
we
take
it
for
granted
every
day
that
there's
all
these
ways
that
we
know
that
someone
said
something,
and
it's
sort
of
this
like
flimsy
house
of
cards,
of
layers
of
trust.
A
But
you
know:
we've
had
the
technology
for
decades
now
to
just
cryptographically
signed
messages
like
isn't
it
kind
of
weird
that,
like
the
way
that
you
verify
the
president
said
something
isn't
that
it's
signed
by
the
president,
like
when
we've
had
that
technology
for
decades,
so
I
think
Tripp.
Those
sort
of
bringing
this
to
the
forefront,
we're
building
better
UX
is
on
top
of
these
tech,
bold
technologies,
but
web
3
very
much.
You
know
treats
messages
as
a
core,
primitive
and
related
to
that
is
message
ordering.
A
It's
important
for
us
to
have
a
division
of
labor
right,
like
you,
don't
if
you
had
to
compute
everything
on
your
home,
PC
that
you
did
on
the
web
like
the
web,
would
be
this
really
clunky
experience
right,
like
you
want
to
be
able
to
offload
that
to
other
people
while
having
confidence
that
the
results
of
that
are
correct.
So
we
have
these
primitives
called
snark
Stark's
bullet
proofs,
they're
cryptographic
primitives,
and
they
basically
let
you
prove
that
a
computations
been
done
correctly
without
doing
that.
A
Work
yourself
so,
like
I,
could
ask
you
for
the
10
billion
Fibonacci
number.
You
could
like
go
work
for
like
a
few
minutes.
Come
back.
Give
me
the
result
and
I
would
just
quickly
tell
oh
yeah.
This
is
right.
It's
it's
kind
of
like
magic!
So
I'm,
not
gonna!
Explain
it
in
this
in
this
talk,
but
it's
a
primitive
that
we
work
with
actually
Jackson
on
our
research
team.
Is
it's
working
full-time
on
that
services
are
further
up
the
stack
and
they're
a
unique
primitive
and
that
they
they
balance?
A
A
It's
not
really
a
trust,
primitive,
but
it's
sort
of
this
top
layer
and
in
the
stack
of
like
trust,
minimization,
which
is
like
how
do
you
like
what
Bitcoin
client
to
download
or
what
you
know?
Aetherium
note
implementation
to
download
or
what
boot
nodes
to
connect
to
like,
no
matter
how
good
we
design
these
systems,
there's
always
going
to
be
this
sort
of
metal
layer
of
social
trust
that
that
really
is
exists
at
the
boundaries
to
these
systems
and
that
kind
of
goes
back
to
what
I
said
earlier.
A
In
the
talk
where
I
don't
think,
Trust
is
a
bad
thing.
It
just
needs
to
be
put
in
its
in
its
place.
So
the
next
kind
of
dimension
that
I
want
to
explore
is
the
work
token
economic
model
and
we've
heard
from
a
few
projects
today
that
adopt
this
model
and
one
way
to
think
about
the
work.
Token
economic
model
is
as
a
new
business
model.
A
A
You,
like
customer
acquisition,
just
don't
innovate
on
your
business
model
like
everyone
want,
like
investors,
just
want
to
see
like
one
of
the
you
know,
three
or
four
like
established
business
models,
and
the
irony
of
course,
is
like
a
decade
later,
like
we're
working
in
crypto
and
like
a
huge
part
of
what
we
do
is
innovating
on
the
business
model,
because
we're
designing
systems
were
the
way
that
the
system
captures
value
is
actually
integral
to
the
way
that
the
product
works.
First,
I
kind
of
want
to
discuss.
A
So
when
I
started,
my
career
I
was
on
a
three-year
release
cycle
at
Microsoft,
and
we
were
shipping
physical
disks
to
like
two
customers,
which
now
would
be
like
inconceivable
to
most
people
in
this
room
and
that
was
driven
by
a
whole
set
of
you
know.
Enabling
technologies-
and
you
know
you
had
one
vendor
manual-
install
and
there's
sort
of
this
planned
obsolescence.
A
You
know
this
was
kind
of
enabled
by
data
center
technology
virtualization
a
massive
increase
in
JavaScript,
runtime
performance
and
browsers,
and
this
pushed
things
a
little
bit
further
to
a
model
where
we
have
one
service
provider,
it's
cloud
based,
but
it's
still
sort
of
finite
availability
right
like
if
that
service
provider
goes
out
of
business,
the
apps
building
on
it
shut
down.
If
they,
you
know,
the
firehose
gets
closed
off,
they
get
shut
down.
A
I
think
you
Neve
talked
a
lot
about
some
of
the
downsides
of
this
model
and
what
we're
moving
towards
now
is
what
some
people
have
referred
to
as
like
the
utility
model
right.
So,
if
you
think
of
like
the
things
we
think
about
as
public
utilities
now
water
power,
increasingly
the
internet,
it's
these
things
that
are
just
sort
of
ubiquitously
available
and
even
if
you're,
paying
PG&E
or
like
you
have
a
service
provider
like
you,
don't
think
of
the
service
you're
getting
as
being
directly
tied
to
that
entity
like
it's
sort
of
bigger
than
them.
A
Right
and
like
you
have
this
network
of
of
suppliers
that
that
really
are
providing
the
service,
and
if
one
of
those
goes
down
like
you,
don't
think
of
it,
it's
like!
Oh,
you
know
the
Internet's
or
the
power
is
gonna,
go
down
because
some
grid
station
in
Connecticut
went
down
like
it's.
We
sort
of
think
of
these
things
as
being
bigger
than
that
and
we're
trying
to
in
web
3
we're
trying
to
design
an
Internet
that
has
a
lot
of
these
same
properties.
A
So,
let's
get
in
to
a
quick
description
of
how
work
token
economics
works.
One
analogy
that
I
like
to
use
is
that
of
taxi
medallions
in
New,
York
City.
So
the
way
that
that
worked
was
there
was
a
finite
supply
of
taxi
medallions,
and
if
you
wanted
to
do
work
in
that
system-
and
you
know
providing
rides,
you'd
have
to
buy
one
of
these
medallions
and
these
things
accrued
a
lot
of
value
because
of
both
dear
city,
but
also
the
right
to
do
work
in
that
system
right.
A
Anyone
who
had
one
of
these
medallions
could
collect
fees
and
collect
fares
from
all
the
people
that
they
were
driving
around
New
York
City.
To
make
this
analogy
really
complete
would
be,
if
also
in
those
systems,
those
taxi
medallions
could
be
forfeit
when
you're
a
cab
driver
did
a
terrible
job
or
took
you
to
the
wrong
place,
which
maybe
would
have
made
getting
a
cab
in
New,
York,
better
I,
don't
know,
but
that's
kind
of
that's
kind
of
the
basic
premise:
it's
this
carrot.
Stick
you
know
you
have
the
medallion
you'll
lose
it.
A
If
you
do
your
work
incorrectly,
but
you
collect
fees,
if
you
behave
well,
so
on
that
note,
it's
important
for
these
things
to
have
value
the
the
way
that
we
value
work.
Tokens
is
through.
What's
called
net
present
value,
it's
essentially
the
valuing
the
future
discounted
cash
flows,
minus
the
initial
investment.
A
Two
of
the
things
we
talk
about
a
lot
in
the
context
of
distributed
systems
is
safety
and
liveness,
and
to
build
an
intuition
around
that,
like
we
can
switch
switch
metaphors
to
a
light
bulb,
Factory
and
safety
is
basically
the
idea
that
you
would
never
produce
a
bad
light
bulb
in
your
light,
bulb
production,
service
and
liveness.
Is
that
this
idea
that
you
eventually
do
produce
a
good
one?
A
A
We
have
these
data
monopolies
that
keep
shutting
people
out
or
these
platforms
that
keep
you
know
turning
down
app
developers,
but
web
3
also
has
platform
risk.
It's
just
different.
We
need
to
make
sure
that
we're
designing
systems
where
the
incentives
exist
to
keep
running
the
services
and
data
that
we're
relying
on,
and
so
this
is
that
liveness
guarantee
right.
We
want
to
make
sure
that
these
things
stay
available
for
people.
A
Right
we're
designing
these
small
economies,
you
know
if
you
will,
and
so
we
have
the
micro
economic
toolkit,
which
is
like
designing
supply
and
demand
and
market
dynamics.
We
have
the
macro
economic
toolkit,
because
these
systems
have
their
own
native
token.
We
can
actually
control
things
like
inflation
and
set.
You
know
monetary
policy
basically
for
these
systems
and
both
of
these
things
are
just
falling
under
the
umbrella
of
Krypton,
which
is
kind
of
a
fake
word
that
just
describes
economics.
A
That's
where
the
the
rules
of
the
system
are
backed
by
you
know
programmable
incentives
and
like
cryptography,
notably
there's
a
few
things
that
are
in
our
tool
belt,
which
are
worth
calling
out.
But
Alex
talked
a
lot
about
this,
but,
like
you,
we
can't
stop
people
from
doing
things
outside
of
the
realm
of
our
code.
Right
like
we
can't
stop
things
like
bribery.
A
One
difference
from
the
taxi
medallion
you
know
analogy
is
that
in
New
York
City
they
were
actually
enforcing
that
you
had
a
taxi
medallion
to
do
this
work
and
you
know
cryptosystems.
We
can't
do
that.
You
know
we
need
to
design
systems
that
are
fair
and
don't
incentivize
people
from
forking
the
protocol
and
doing
the
work
outside
of
the
bounds
of
the
system,
and
that
kind
of
brings
me
into
the
last
part
of
this
section
of
the
talk
which
is
network
parameterization.
A
So
this
kind
of
really
speaks
to
the
heart
of
designing
systems
that
are
fair.
Is
is
making
sure
that
the
parameters
are
tuned
based
on
the
needs
of
service
providers
and
also
customers
in
the
community?
So
there's
four
basic
ways
that
we
can
do
this.
They
could
be
fixed,
you
know,
so
they
can.
It
can
just
be
in
the
code
of
the
protocol.
It
can
be
set
through
governance.
It
can
be
set
by
the
free
market.
So
like
things
like
price
prices
are
better
set
through
like
market
dynamics,
and
it
can
be
variable.
A
There's
trade-offs
to
all
of
this
right.
Like
so,
you
know
Bitcoin,
you
know
they
set
their
inflation
rate
at
the
inception
of
the
network
and
that's
pretty
much
fixed
for
all
time,
and
they
chose
to
do
that.
So
they
could
avoid
the
issues
of
governance.
You
know
at
the
base
layer
protocol
for
other
systems.
It
might
be
more
favorable
to
actually
have
these
things
be
responsive
to
like
macro
conditions.
I'd
argue
with
the
service
layer.
A
Its
governance
plays
more
of
a
role
than
we
would
want
to
see
it
at
the
at
the
base
layer
all
right.
So
those
were
the
two
foundational
concepts.
I
kind
of
wanted
to
cover
the
next
one
we're
gonna
get
into
our
particular
protocol.
Does
we're
gonna
get
a
little
bit
into
weeds,
so
I
apologize
for
that,
but
I'm
sure
there's
gonna
be
people
on
YouTube
that,
like
just
fast-forward
to
this
part
of
the
talk,
so
let's
get
into
it,
sup
see
some
more
concrete
words
now
for
these
building
blocks.
A
So
a
naive
solution
would
just
be
to
put
a
query
engine,
so
the
naive
solution
would
be
to
just
put
a
query
engine
like,
let's,
you
know,
give
a
single,
unified
interface
to
the
dap
and
we'll
just
have
the
query.
Engine
do
all
that
work,
and
this
is
certainly
better,
but
you
know
we're
we're
still
limited
by,
like
the
underline
semantics
of
the
blockchain
and
like
the
fragmentation,
so
like
we've,
just
kind
of
pushed
the
problem
down
a
layer.
This
works
well
in
some
context.
A
So
I
think
it's
really
useful
when
we're
designing
these
systems
in
web
3
is
to
look
at
analogies
in
the
enterprise
software
world
or
like
the
big
data
world.
So
this
is
effectively
what
distributed
query
engines
do
like.
This
is
a
good
analogy
for
the
graph
projects,
like
presto
Apache
drill.
They
provide
you
like
a
unified,
seek
Warner
face
to
data
that's
stored
across,
like
Hadoop
in
all
sorts
of
different
places,
but
getting
back
to
to
the
graph.
A
Basically
they
create
indexes
that
organize
the
data
in
a
way,
that's
specific
to
how
you'd
want
to
access
it
in
your
application,
and
so
for
those
of
you
who
aren't
familiar
indexing,
you
can
kind
of
think
of
it
as
just
like
a
phonebook
for
your
data
right
like
if
you
just
put
names
in
the
phonebook
and
like
any
random
order.
It
would
take
you
a
really
long
time
to
find
a
name.
It's
like
just
guessing
and
checking
in
10,000
pages.
A
A
Now,
when
I'm
talking
about
the
graphs
protocol,
design
I
want
to
be
clear
what
I
mean,
which
is
that
specifically
we're
concerned
with
the
boundaries
to
the
indexing
nodes.
So
the
the
read
interface,
that's
provided
to
the
indexing
nodes,
as
well
as
the
indexing
interface
from
the
block
chains
to
the
indexing
nodes
and
how
those
indexing
jobs
are
defined
and,
and
a
lot
of
that's
been
demoed
already
on
stage
today
by
an
even
Yanis.
A
What's
extra
protocol
is
actually
the
interface
to
the
query
engine.
This
is
a
place
where
we
expect
a
lot
of
innovation
in
the
community.
We
plan
on
releasing
a
graph
QL
reference
implementation,
but
I
would
be
shocked
if
you
know
there
weren't
fast
followers
that
implemented
a
sequel.
You
know
interface
on
top
of
the
graph
and
by
the
way,
just
kind
of
as
an
aside.
A
The
decentralized
apps,
despite
querying
data
through
the
graph,
are
still
making
transactions
directly
to
the
underlying
blockchain,
and
this
is
actually
a
really
neat
pattern
from
the
enterprise
software
world
called
CQRS.
It
stands
for
command,
query
responsibility.
Segregation
is
kind
of
the
long
word
that
means
like
you
can
have
write
semantics,
like
the
way
that
you
write.
A
Data
is
different
from
the
way
that
you
read
data
and
it's
a
subtle
point,
but
that's
really
useful
in
the
blockchain
space,
because
we
want
to
build
a
common
interoperability
layer
where
the
people
that
are
deploying
smart
contracts
aren't
necessarily
gonna,
be
the
only
ones
consuming
that
data.
So
having
this
ability
to
decouple
the
right,
the
right
semantics
from
the
read
semantics,
it
was
actually
a
really
powerful.
It's
a
really
powerful
feature.
A
So
the
information
model
for
the
graph,
as
has
been
demo
today,
is
we
have
sub
graphs.
So
these
are
kind
of
like
the
views
on
your
data,
so
this
is
sort
of
all
of
this
needs
to
be
deterministic.
We
express
all
of
this
stuff
as
ipfs
files
that
can
have
unique
content,
hashes,
so
that's
sort
of
the
determinism.
The
mapping,
is
something
that
runs
in
wasm,
which
provides
deterministic
indexing.
A
You
define
your
data
sources,
which
are
like
the
locations
where
you're
streaming,
events
from
that's
how
you
you're
processing
data
that
gets
indexed
and
you
define
a
data
model
which
has
already
been
demo
today,
which
we
define
in
the
graph
QL
interface
definition
language.
So
this
is
like
what
someone
would
deployed
to
like
the
graph
Explorer
that
you
guys
saw
earlier
today,
separate
from
that
we
have
indexes-
and
that's
what's
nice
about
decoupling
in
this
way.
A
A
So
this
extensibility
basically
allows
you
to
get
all
the
benefits
of
these
different
data
base
models,
while
kind
of
getting
reused
in
the
places
where
it
really
matters
and
by
the
way
we
take
advantage
of
the
fact
that
these
things
can
be
uniquely
identified
in
other
parts
of
our
information
model
which
we'll
touch
on
later.
But
things
like
read:
operations
proofs
at
two
stations.
They
all
relate
directly
to
one
of
these
indexes.
That's
defined.
A
A
The
way
that
we
make
sure
valuable
datasets
appear
on
the
graph
in
the
first
place
is
through
a
curation
market,
and
we
also
have
what
are
called
fishermen
and
they
play
a
role
in
securing
the
network
and
they
basically
check
the
work
that
indexing
nodes
are
doing
and
they
get
rewards
when
they
correctly
find
a
fisherman.
That's
or
excuse
me
when
they
find
an
indexing
node,
that's
done
work
incorrectly
or
maliciously
and
a
final
one
is
token
holders.
A
So,
in
order
for
this
market
to
be
dynamic,
it's
important
that
we
can
do
efficient.
You
know
micro
payments
to
pay
for
the
service,
that's
being
provided
we
actually
take
on
the
the
current
version
of
our
protocol.
We
actually
take
a
different
approach.
Then
then
Eric
was
discussing
on
stage
earlier
with
the
probabilistic
micro
payments,
a
good
intuition
for
how
payment
channels
work
are
sort
of
like
when
you're.
A
When
you
have
a
bar
tab
running
at
a
bar
right,
like
you,
don't
want
to
swipe
your
credit
card
every
single
time
that
you
pay
for
a
drink.
Instead,
you
open
a
tab
once
so
that's
kind
of
like
a
transaction
on
Shane
and
then
as
you're
using
the
service
which
is
getting
you
know,
drinks
from
the
bar.
It
just
keeps
getting
added
to
your
tab,
so
that's
kind
of
like
the
the
simple
analogy
that
gets
used
a
lot
between
payment
channels
and
and
the
bar
tab,
but
we
can
actually
take
it
a
little
bit
further.
A
A
Is
this
kind
of
canonical
market
interaction,
so
the
user
of
the
protocol
is
going
to
find
nodes
that
are
serving
data
on
the
sub
graph
or
the
view
that
that
they're
interested
in
the
service
discovered
layer
is
going
to
respond
with
a
set
of
nodes,
the
indexes
that
they're
maintaining
as
well
as
their
deposits.
So
the
deposits
in
this
case
are
the
amount
that
they
would
lose
if
they
told
a
lie
to
the
user
right.
So
it's
like
there's
a
word
for
this
economic
security
margin.
It's
basically
the
amount
that
the
node
has
at
stake.
A
They
respond
and,
in
parentheses,
here
I
have
latency.
This
is
something
that
the
user
could
implicitly
be
observing
right,
like
what
nodes
are
responding
to
to
me,
the
quickest
and
combining
these
three
different
properties
of
you
know,
latency
or
performance,
economic
security
margin
and
the
prices
they
can
narrow
down
the
index.
You
know
that
they
want
to
interact
with
down
to
a
single
node,
then
they're
going
to
send
a
read
operation.
A
Does
the
user
follow
up
with
it
an
unlocked
micro
payment
and
by
the
way
that
unlocked
micro
payment
is
just
so
that
they
can
kind
of
keep
doing
business
as
usual?
If,
for
some
reason,
the
user
didn't
respond
with
the
unlocked
micro
payment,
then
the
node
could
take
its
verifiable
response
on
Shane
and
still
get
paid
and
in
a
lot
of
systems.
You
know
micro
payments
are
being
done
for
like
really
trivially
small
tasks.
But
one
thing
to
keep
in
mind
is
like
we're
designing.
A
You
know
database,
essentially
that
you
can
think
of
it
as
like,
a
database
where
you're
running
arbitrarily
expensive
queries.
So
it's
important
that
that
there's
no
counterparty
risk
that
the
indexing
node
can
be
guaranteed
payment
for
the
work
that
they're
doing
so
talking
a
little
bit
more
about
the
the
read
interface
as
I
mentioned
before
we're
kind
of
agnostic
to
the
higher
level
query
language,
so
we're
gonna
have
a
graph.
Ql
implementation
comes
into
the
query
engine
and
that
produces
a
bunch
of
low-level
read
operations.
A
A
It
would
probably
based
on
like
the
relational
algebra,
which
is
like
kind
of
a
theoretical
foundation
for
query
languages,
and
so
like
this
would
be
as
far
as
I'm
aware,
like
the
first
instance
of
a
like
relational
algebra
based
DSL,
that
incorporates
like
computation
cost
in
using
gas.
So
I
know
that's
kind
of
a
mouthful,
but
this
is
actually
really
cool
stuff
and
we're
excited
to
be
working
on
it.
A
So
there's
a
few
different
ways:
we
can
tackle
verifying
queries
and
the
network.
A
simple
construction
is
using
at
two
stations.
So
in
this
construction,
when
a
user
gets
a
query
response
from
an
index,
they
also
get
an
app
to
station,
and
this
is
basically
just
a
signature.
We
talked
you
know
earlier
about
trust,
minimize
messages.
This
is
basically
a
signed
message
that
says
like
for
the
data
you
asked,
for
this
is
the
correct
response,
and
what
that
does
is
it
puts
that
indexing
node
on
the
hook?
A
If
later
it
turns
out
that
that
response
isn't
correct,
they
can
be
slashed
on
Shane
by
creating
a
dispute,
and
so
in
this
the
construction
users
would
maybe
send
those
out
to
stations
to
fishermen
who
are
doing
the
work
of
checking
like
the
light
bulb
example.
Maybe
some
random
sampling
about
two
stations
in
hopes
of
finding
one
that
would
earn
them
a
large,
slash
and
reward.
So
this
works,
but
you
might
already
kind
of
you
know,
suspect
it
as
the
network
scales
and
we're
handling.
A
Hundreds
of
thousands
of
queries
like
this
does
become
a
lot
of
work.
An
alternate
construction
is
to
do
the
verification
right
at
at
the
indexes
themselves,
and
so
what
this
gets.
You
is
this.
This
massive
amount
of
leverage
right.
So
like
every
time
you
update
the
index,
you
get
this
new
version
of
the
index
and
by
checking
that,
once
by
giving
you
like
economic
security
guarantees
on
that
thing,
once
now
you
can
serve.
A
All
you
need
is
the
the
leaf
node
kind
of
at
the
bottom
there
and
the
path
that
takes
you
all
the
way
up
to
the
root
of
the
tree.
So
that's
called
a
Merkel
proof,
and
so
a
big
part
of
the
research
that
we're
doing
is
actually
designing
Mirk,
alized
versions
of
traditional
database
indexes
that
have
a
lot
of
these
nice
properties.
A
couple
that
I
mentioned
is
being
persistent
and
supporting
like
efficient
time
travel
queries.
So
this
is
something
that
also
like
databases
like
the
atomic
do.
A
A
If
the
only
way
that
you
can
be
sure
you
were
getting,
the
right
count
is
if
all
ten
thousand
entities
went
over
the
wire
to
the
query.
Engine
like
that'd
be
really
problematic
right.
It's
like
it's
kind
of
a
non-starter
really.
You
were
just
interested
in
that
count
going
over
the
wire,
so
we
have
a
cryptographic
primitive
that
can
help
us
out
here
we
discussed
it
earlier.
A
In
addition
to
the
result
of
these
like
filtering
and
aggregation
operations,
it
doesn't
come
for
free,
there's,
a
cost
to
both
the
proving
time
and
the
verification
of
these
primitives
and
all
all
the
ones
that
I
had
mentioned
earlier.
Snorks
tarps
bullet
proofs.
They
all
just
kind
of
differ
on
sort
of
trade
offs
they
make
on
like
proving
time,
verification,
time
and
payload
size.
A
So
we
don't
want
to
use
it
all
the
time
right,
like
I,
keep
coming
back
to
this.
This
light
bulb
factory
analogy
like
we
don't
want
to
check
every
light
bulb
on
the
conveyor
line.
Right,
like
that'd,
be
a
non-starter,
and
this
is
like
an
area
where
trusts
minimize
services.
We
have
a
chance
to
innovate
and
kind
of
strike.
A
So
at
that
point
the
user
has
two
options:
one
is
the
user
can
just
say
you
know:
okay,
I'm
gonna!
Take
it
on
faith
that
this
thing
is
correct
and
I'm
just
gonna
send
you
the
unlock
to
payment,
the
other
thing
the
user
can
do.
They
can
say
you
know
what
I
don't
trust
this
response,
I'm
gonna
challenge
you
and
I'm
you're
not
going
to
get
paid
until
you
provide
a
proof
that
that
thing
is
correct,
and
only
after
the
user
gets
the
correct
proof
from
the
indexing.
A
Node
will
be
user
unlock
the
payment,
and
so
the
important
property
here
is
that
the
indexing
node
doesn't
know
a
priori
whether
they're
going
to
be
challenged
or
not
on
any
given
response
and
payment
is
locked
up
all
the
way
until
the
end
of
this
game
being
played.
This
is
actually
getting
into
the
realm
of
another
primitive
into
space
called
state
channels
which
I
won't
get
into
in
depth
in
this
talk.
But
these
are
the
sorts
of
games
that
you
can
play
with
this.
With
this
primitive.
A
So
there's
a
bunch
of
verticals.
You
know
from
payment
channels
to
governance,
to
no
discovery
where
we
can
kind
of
start
centralized,
and
then
we
can
incrementally
decentralize
only
as
those
primitives
are
mature
enough
to
to
do
so
without
significantly
sacrificing
consumer
grade
performance.
So
today,
I
want
to
share
a
little
bit
more
with
you
about
that
set
of
milestones.
As
you
nev
mentioned
earlier
back
in
august,
we
open
sourced
a
local
node
implementation.
Basically,
this
includes
a
lot
of
what
we've
showed
you
today.
A
Already
the
index
are
defining
your
mappings
and
wasum
ipfs
integration,
it's
an
aetherium
index,
or
it
has
the
graph
graph
QL
API,
but
you
had
to
run
it
yourself
and
some
projects
were
really
successful.
Doing
that
a
live
peer,
I
think
shipped
it
to
production
like
massively
sped
up
their
DAP
but
running
your
own
docker
container.
Your
own
Postgres
database
is
a
big
hurdle
for
a
lot
of
people.
So
today,
as
you
know,
we
see
we
launched
the
hosted
version
of
the
graph
which
we're
really
excited
about.
A
This
should
massively
decrease
the
the
barrier
to
entry
for
developers
that
want
to
build
on
aetherium,
smart
contracts
and
that
you
know
the
big
features
there
were
the
graph
Explorer,
these
sort
of
atomic
sub
graph
deployments.
The
live
deployment
updates
all
the
the
really
beautiful
UX
that
we
saw
on
stage
today.
A
The
next
milestone
that
we're
targeting
is
an
intermediate
milestone
and
it
kind
of
speaks
directly
to
that
tactical
path
to
decentralization.
It's.
What
we're
calling
the
hybrid
network
and
all
the
economics
of
the
protocol
are
decentralized
in
this
milestone,
and
the
network
is
also
permissionless,
so
any
indexing
node
can
come
along
and
start
stating
tokens
and
providing
work
on
the
network
what's
still
decent.
A
What's
still
somewhat
centralized
is
the
governance
dispute
resolution
and
for
performance
reasons,
the
the
payment
channel
network-
and
these
are
things
that
kind
of
speaks
to
what
Eric
I
think
was
talking
on
stage
earlier?
Is
there
are
trade-offs
on
the
payment
channel
construction
that
you
use
and
a
lot
of
the
implementations
of
payment
channel
networks
are
still
pretty
immature.
The
space
and
I'm
happy
to
announce
that
that
specification
is
now
open
source.
It's
on
github.
Today
you
can
check
it
out
at
grap.
A
You
can
check
it
out
at
graph
protocol,
slash
research,
it's
in
a
draft
stage,
and
so
I'd
really
encourage
you
guys
to
like
take
a
look
file.
Issues
join
us
on
discord,
we'd
love
to
get
feedback
on
this
stuff.
We
think
it's
really
exciting.
The
next
day
is
basically
just
to
decentralize
everything
that
hasn't
been
decentralized
and
there's
a
massive
amount
of
work
that
that
entails
I'm
not
going
to
read
everything
on
this
list,
but
we're
really
excited
about
this
roadmap,
and
you
know
if
you're
distributive
systems
engineer
a
database
architect.