►
From YouTube: Cost Model Workshop
Description
Workshop recorded May 20th, 2021.
B
B
Okay,
hello,
everyone
and
welcome.
My
name
is
zach
burns.
I
go
by
that
three
percent
on
github
and
on
discord,
the
name
that
three
percent
is
a
reference
to
an
obscure
donald
news,
quote
about
performance
for
computer
science.
Geeks.
It's
not
to
be
confused
with
a
reference
to
the
political
group
having
a
similar
sounding
name.
B
B
The
the
problem
is
that
an
indexer
needs
some
way
to
express
to
a
consumer
like
the
gateway
that
what
the
fee
is
that
they're
going
to
charge
for
a
given
query.
Not
every
query
is
equal.
In
fact,
you
know
some
sub-graphs
have
greater
costs
to
index
than
others.
Some
sub-graphs
can
better
amortize
those
costs
over
higher
query
volumes.
B
Some
sub-graphs
may
be
very
competitive
and
have
competitive
pricing,
because
maybe
they
have
a
lot
of
signal
and
there's
a
lot
of
indexers
competing
for
queries
on
that
sub
graph.
Some
might
not,
and
even
within
a
single
sub
graph.
One
query
may
take
a
dozen
milliseconds
to
execute
and
another
may
take
several
seconds
to
execute.
B
Even
you
know,
beyond
the
differences
of
sub
graphs
and
queries,
not
every
indexer
is
equal
either
right.
An
indexer
which
invests
in
a
low
latency
database
or
invests
in
economic
security,
maintains
an
excellent
reputation
or
attracts
delegation.
Through
their
community
involvement
they
can
and
should
charge
a
premium
for
the
better
service
that
they
offer.
B
Broadly
speaking,
there's
a
lot
of
factors
that
can
go
into
the
fee
for
a
given
query.
So
a
consumer
like
the
gateway
has
a
query
and
they
have
a
choice
to
make
between
the
many
indexers
and-
and
it
would
like
to
pay
a
fee
for
that
query.
That
is
going
to
be
fair
for
the
level
of
service
that
the
gateway
requires
or
the
consumer
requires,
given
the
current
market
conditions.
B
So
the
question
is
that
how
might
the
gateway
approach
this
problem
of
finding
out
what
indexers
are
offering
to
serve
that
query
for
a
competitive
fee?
So
one
way
to
do
that
might
be
to
and
expose
an
endpoint
on
the
indexer
say
get
price
for
query:
that
api
could
take
a
query
and
then
return
the
fee
that
is
being
proposed
by
the
indexer.
B
A
gateway
could
send
their
query
to
each
indexer.
That's
indexing
a
subgraph
and
get
the
feedback
for
all
of
them
and
then
compare
this
has
some
problems.
The
first
problem
is
going
to
be
that
it
introduces
latency
into
the
query
so
an
end
user
who's
waiting
for
data
to
load
in
a
web
page
would
usually
have
to
wait
an
additional
amount
of
time
for
those
fee
proposals
to
come
back
in
practice.
B
This
wait
time
is,
is
always
going
to
be
the
maximum
amount
that
we're
willing
to
bear,
because
some
indexers
will
probably
have
latencies
that
exceed
the
maximum
wait
time
and
where
we'd
be
waiting
for
some
set
of
responses
to
come
back,
and
that
would
add
a
lot
of
time
that
the
user
spends
waiting
for
data.
So
that's
not
great,
and
then
the
other
problem
with
that
is
is
throughput,
while
any
competitive
indexer
may
expect
to
receive
many
queries
for
any.
B
B
So
that's
that's
sort
of
the
the
design,
motivation
behind
cost
models
and
what
we
were
thinking
of
when
when
we
designed
it
so
here's
here's.
What
a
basic
cost
model
looks
like
to
to
express
the
cost
model
succinctly:
we
developed
a
language
which
is
called
agora
and
you
can
think
of
agora
as
essentially
a
price
sheet.
It
lists
all
the
possible
graphql
queries
that
you
might
serve
on
the
left
and
all
the
fees
for
those
queries
go
on
the
right.
B
We
can
break
down
how
that
looks
for
this
specific,
simple
cost
model.
That's
in
front
of
us
right
now
paying
attention
to
the
the
box
on
the
left.
That's
labeled,
agora.
We
can
see
a
simple
graphql
query,
which
is
for
swaps,
I'm
just
using
uniswap
here,
because
that's
a
very
well-known
name
in
the
d5
community.
B
Continuing
the
the
price
sheet
analogy,
the
left
side
of
the
fat
arrow
is
the
service
that
you're
offering
in
this
case
the
graphql
that
you
can
serve
and
the
the
right
side
of
the
fat
arrow
is
your
query
fee
in
grt
in
the
the
agora
terminology
right
leaving
the
the
terminology
of
price
sheets.
For
a
moment,
this
query
fee
listing
is
called
a
statement.
B
B
In
the
examples
box
we're
going
to
have
some
some
queries
and
the
prices
that
they
would
evaluate
to.
You
can
see
from
the
examples
that
the
agora
query
in
the
in
the
box,
labeled,
agora,
that's
in
the
statement-
is
the
the
most
general
form
of
the
query
that
matches
so
in
order
to
match.
Every
part
of
the
query
specified
in
gora
in
agora
must
have
a
corresponding
item
in
the
real
query
so
walking
through
the
first
example.
B
So
it's
not
going
to
be
served
by
the
indexer
it
just
it
just
does
not
match
our
cost
model
all
right
in
in
agora.
A
document
is
going
to
be
a
list
of
statements
right
to
get
get
that
passed,
get
past.
That
problem
of
some
of
our
queries,
not
matching.
We
can
provide
more
statements
to
our
agora
cost
model.
B
The
statement
priority
is
going
to
be
from
top
to
bottom.
So,
given
any
query,
we're
going
to
try
executing
each
statement
and
if
it
does
not
match,
then
we're
going
to
continue
to
the
to
the
next
statement
and
if
it
does
match,
then
we're
going
to
evaluate
the
right-hand
side
of
the
expression
to
find
out
what
that
price
is.
So
that
means
that
your
cost
model
should
order
statements
from
the
most
specific
to
the
least
specific-
and
I
have
some
examples
here-
that's
going
to
show
how
that
works.
B
B
So
in
the
examples,
the
first
query
is
asking
for
swaps
by
id.
We
can
check
each
statement
in
order
to
see
if
it's
going
to
apply
so
the
first
statement
in
agora
is
not
going
to
match
this
query,
because
that
statement's
matches
is
specifying
the
transaction
selector.
But
our
query
is
asking
for
the
id
selector
and
it
does
not
have
the
transaction
selector
so
the
so
it
will
go
on
to
to
try
and
match
the
second
statement.
B
The
second
statement
also
does
not
apply
because
that
statement
is
saying
to
match
an
argument
for
the
first
10
swaps,
and
the
query
swaps
by
id
doesn't
have
that
argument,
but
the
last
statement
does
apply,
because
that
statement's
match
is
only
specifying
that
it
needs
to
to
ask
for
swaps,
and
the
query
does
ask
for
swaps.
So
this
query
is
going
to
be
priced.
B
Looking
at
our
first
statement,
we
see
that
we
are
indeed
asking
for
swaps
which
the
the
statement
says
that
it
must
be
asking
for
swaps
to
match,
and
then
we
must
also
be
asking
for
a
transaction
to
match
and
our
query.
The
second
query
in
the
examples
does
specified.
Yes,
I
want
the
transaction,
so
that's
going
to
be
priced
using
the
first
statement
for
the
price
of
two
hundredths
of
a
jrt,
because
it
completely
matches
what's
being
asked
for
by
agora,.
B
B
B
So
in
this
way
you
can,
you
can
scale
the
the
value
of
a
query
or
the
difficult
difficulty
of
the
query
by
extracting
the
relevant
features
from
that
query
and
then
using
it
in
your
cost
expression
right.
So
in
that
first
example,
we
can
see
that
if
they
specified
first
100
and
then
capture
the
id
that's
going
to
resolve
to
a
price
of
300
of
a
grt
because
that
base
price
0.01
plus
.0002
times
100,
is
that
price
of
0.03
jrt.
B
B
This
is
not
coincidental
because
the
default
value
for
first
in
our
graphql
queries
is
100,
so
it
ends
up
resolving
to
the
same
price
as
the
previous
example,
which
was
asking
for
the
first
100
elements.
If
we
left
that
out,
we
get
swaps
by
id
price
point:
zero,
three
and
then
the
third
example
is
asking
for
more
results.
B
So
one
of
the
utilities
that
we
provided
for
you
is
to
be
able
to
inject
the
value
of
dye
into
your
into
your
cost
model,
which
is
an
approximation
of
the
value
of
a
us
dollar.
So
if
we
wanted
to
have
a
query
that
is
priced
consistently
at
half
of
a
penny,
then
what
we
could
do
is
we
could
take
the
value
0.005
and
multiply
that
by
die,
which
is
a
global
variable
that
I'm
going
to
go
over
more
about
what
that
means
in
a
minute.
B
In
this
case,
the
this
die
global
variable
is
a
bit
magic
because
it's
automatically
injected
by
the
indexer
agent
by
default,
your
index
or
agent,
will
look
up
a
a
price
that
it
thinks
is
a
good
swap
rate
for
die
to
grt,
and
then
it
will
inject
inject
this.
So
in
that
way
you
can
respond
to
changing
market
conditions
very
quickly
in
your
cost
model
without
having
to
go
in
and
then
manually
tweak
a
cost
model.
B
Generally,
that's
what
global
variables
are
for.
Let's
see
here,
I'm
gonna
go
ahead.
Well,
I
guess
there's
a
there's
a
quick
example
there,
which
went
by
really
quick.
I'm
gonna
just
go
over
that.
So
in
this
case
that
example
query
of
asking
for
swaps
by
id,
it
would
would
evaluate
to
0.5
cents
half
a
penny
as
we
as
we
anticipated
all
right.
So
globals
generally
are
there
for
you
to
be
able
to
respond
to
market
conditions
very
quickly.
So
you
can.
B
So
some
examples
of
that
just
to
give
you
some
inspiration
of
what
you
might
use
it
for
it's
going
to
be
totally
up
to
you.
But
these
are
some
ideas.
The
first
statement
says
that
if
today
is
discount
friday,
then
you're
going
to
apply
a
specific
price
for
all
queries,
because
it's
the
first
statement
and
it's
matching
all
graphql
so
going
over-
that
it
says
the
first
word
in
that
statement
is
default.
B
B
B
I
could
think
of
maybe
using
something
like
that,
for
if
there
was
a
conference
coming
up
and
you
expected
there
to
be
a
lot
of
load-
and
maybe
you
want
to
apply
a
discount
for
a
limited
time
say
the
the
next
example
would
be
an
example
of
using
database
statistics
in
order
to
inform
the
price.
So
you
can
see
that
it
says,
give
me
entities
where
the
id
is
greater
than
a
specific
id,
and
maybe
the
cost
of
that
query
would
actually
scale
with
the
number
of
ids
that
are
in
the
database.
B
B
So
then
the
a
result
of
a
query
that
matched
that
statement
would
be
250
times.
Point
zero,
zero,
zero,
zero
one.
So
and
that
way,
if,
if
well
you'd,
be
able
to,
you
know
pipe
information
in
real
time
from
from
the
database
as
new
blocks
are
being
ingested
by
your
indexer
and
quickly
update
your
your
prices
without
manual
intervention
right.
So
maybe
that's
something
that
you
want
to
take
into
account
it's
up
to
you.
B
A
third
example
here
would
be
using
the
load
factor
on
your
server
to
update
the
prices.
Perhaps
you
see
that
load
is
changing
over
the
time
of
day
and
you
might
want
to
restrict
the
amount
of
load
on
your
server
or
maybe,
if
you
have
low
load,
to
try
to
attract
more
queries,
so
we
can.
We
can
then
see
that
this.
This
third
statement
is
just
using
load
factor
directly
as
their
price.
We
could
look
that
up
in
the
globals
and
see
that
load
factor.
I'm
sorry
about
that.
I
tried
to
move
the.
B
I
can't
actually
see
what
load
factor
says
because
zoom's
camera
thing
is
in
the
way.
So
whatever
that
says
it
would
look
it
up.
I
tried
to
move
it
out
of
the
way
and
it
went
to
the
next
slide,
so
I'm
just
going
to
keep
talking
all
right,
so
it
would
look
up
whatever
load
factor
says
and
use
that
as
a
price
and
then
you
could
you
could
dynamically
detect
what
kind
of
load
that
you're
under
and
update
your
price
accordingly?
B
B
All
right
so
once
you've
developed
a
cost
model.
The
next
thing
that
you're
going
to
want
to
do
is
to
test
it
before
rolling
that
out,
and
so
we
have
some
some
tools
to
help
you
do
that
after
after
this
slide
on
and
in
fact
the
last
slide,
I
have
some
some
links
that
are
going
to
show
documentation
for
all
of
these
tools
so
that
you
don't
need
to
furiously
try
to
write
down
these
these
command
line
things
right
here.
B
B
B
So
there's
there's
one
command
in
the
the
indexer
cli
for
setting
the
variables
which
you
are
expected
to
do
fairly
frequently
in
and
according
to
changing
market
conditions,
changing
database
changing
whatever
and
there's
also
a
another
command
for
setting
the
model
itself,
which
you
were
expected
to
do
a
bit
less
frequently,
because
that
would
usually
require
human
intervention
and
a
changing
strategy
of
how
you
want
to
to
do
your.
Your
prices,
again
links
to
documentation
are
going
to
be
on
the
the
last
slide.
B
So
that
we've
looked
at
agora
and
we've
seen
how
to
communicate
your
your
prices,
that
still
leaves
a
pretty
big
question.
That's
on
every
mind
everyone's
mind,
and
that
is
what
should
you
set
your
fees
to?
I'm
not
gonna
during
this
talk
anchor
query
fees
to
any
particular
value,
because
I
think
that
would
do
the
community
a
disservice.
B
The
network
is
going
to
be
comprised
of
many
independent
agents
that
are
all
acting
in
their
own
best
interest
right.
That
includes
d-app
developers,
trying
to
minimize
the
price
that
they
are
paying
for
queries
that
includes
indexers,
trying
to
maximize
the
price
that
they're
that
they're
accruing
from
queries,
and
I
have
no
inside
knowledge
of
what
any
d-app
developer
is
willing
to
pay,
and
I
have
no
inside
knowledge
of
what
an
indexer
would
charge
for
a
query.
B
But
I
can
tell
you
how
I
might
frame
the
problem
if
I
was
running
an
indexer,
and
I
can
hope
that
that
would
be
helpful
to
you
as
a
starting
point.
So,
if
you
remember
at
the
the
beginning
of
this
talk,
I
said
that
many
things
can
go
into
the
the
price
of
a
query.
Right
there
are
many
factors.
One
would
be.
What
differentiates
you
as
an
indexer.
Did
you
splurge
for
that
low
latency
database
and
do
you
need
to
recover
that
cost?
Does
the
subgraph
that
you're
serving
have
a
high
query
volume?
B
B
But
then
all
that's
left
after
taking
to
all
those
things
into
account
is
what
is
going
to
be
the
price
times
the
market
captured
and
making
rather
like
getting
as
much
revenue
as
possible
out
of
the
market
that
you
can
capture,
taking
into
account
that
the
price
that
you
that
you
set
also
affects
the
size
of
the
market
that
you
can
capture.
So
once
you
figure
out
your
revenue
maximizing
price,
then
you
can
decide
which
query
markets
are
the
most
attractive
based
on
your
expected
profits.
B
So
I
think
that
can
can
kind
of
simplify
what
you're,
considering
when
when
writing
your
cost
model.
But
then
it
makes
it
a
bit
of
a
more
interesting
question
when
you're
deciding
which
subgraphs
to
index
you
know,
based
on
how
many
other
indexers
are
indexing.
This
sub
graph,
based
on
you
know
what
is
the
query
volume
and
all
these
other
questions.
B
B
B
Okay,
so
figuring
out
that
that
optimal
price
that
maximizes
your
revenue
itself
isn't
going
to
be
very
easy,
because
the
optimal
price
depends
on
your
quality
of
service.
That's
relative
to
the
quality
of
the
service
offered
by
all
of
the
other
indexers,
as
well
as
their
prices,
the
full
set
of
consumers,
their
selection
preferences,
their
budgets,
the
amount
of
volume
at
the
current
time
of
day
how
much
load
your
server
can
bear
the
gateway,
selection,
algorithm
and
probably
the
phase
of
the
moon.
B
For
all
that,
I
know
it
can
take
into
account
a
lot
of
different
things
for
our
gateway,
a
an
indexer
which
offers
a
better
service
does
have
a
higher
revenue,
maximizing
price.
So
to
drive
this
point
home.
I
want
to
show
this
graphic,
which
demonstrates
a
graph
that
shows
the
expected
revenue
at
different
prices,
relative
relative
to
a
consumer
budget
for
given
our
consumer.
I'm
sorry
given
our
index
or
selection
algorithm
at
one
point
in
time.
B
B
What
I
want
you
to
notice
is
that
by
increasing
the
utility
that
you
offer,
that
is
going
to
have
a
pretty
large
effect
on
the
amount
of
revenue
that
you
can
bring
in
so
as
as
time
increases
that
graph
is
getting
higher,
which
means
that
we're
bringing
in
more
revenue
but
also
as
your
utility
is
increasing,
that
the
price
that
would
maximize
your
revenue
is
also
increasing,
and
so
that's
represented
by
that
the
vertical
line.
That's
intersecting
the
curve
at
its
highest
point.
B
That
is
your
revenue
maximizing
price
because
it
captures
the
most
revenue
when
multiplying
the
the
price
for
the
that
query
by
the
size
of
the
addressable
market.
That
would
be
captured
at
that
price
right,
as,
as
you
increase
your
price
up
to
and
beyond
the
maximum,
that
a
consumer
is
willing
to
pay
that
can
drop
to
zero.
But
as
you
decrease
your
price,
it
also
goes
to
zero
because
you,
even
though
you're
capturing
more
queries,
you're
not
actually
making
as
high
of
a
price
for
that
query.
B
So
what
you
want
to
do
is
figure
out
how
to
discover
what
that
revenue
maximizing
price
is
going
to
be
an
idea
that
you
might
use
to
to
figure.
That
out
is
actually
just
to
go
back
and
use
global
variables.
I
could
imagine
having
a
global
variable:
that's
a
multiplier
for
all
of
your
prices,
so
that
you
can
adjust
it
and
see
how
it
affects
the
the
market
that
you
capture,
as
well
as
how
that
will
impact
your
revenue
and
just
kind
of
try
and
discover
this
information.
B
B
So
that
might
be
another
way
that
I
would
use.
Agora,
agora,
isn't
necessarily
finished
and
in
fact
one
of
the
things
that
we
wanted
to
do
during
the
test
net
was
to
be
able
to
see
how
that
indexers
priced
different
queries
and
figure
out
what
strategies
emerged
and
then
to
update
agora
over
time
to
be
able
to
express
those
strategies
more
efficiently.
But
it
was
not
something
that
we
really
had
time
to
during
the
test
net,
but
we're
because
this
is
extra
protocol.
B
We
still
have
room
to
to
iterate
on
this
design,
so
ways
that
we
might
iterate.
It
include
that,
because
you
can,
you
can
list
every
possible
query
and
price
each
one
individually,
using
agora.
It
is
possible
to
express
any
possible
cost
model
logic
that
you
could
imagine,
but
the
downside
of
that
would
be
that
the
cost
model
would
get
very
long.
B
So
what
we
want
to
do
is
to,
within
the
design
space
of
agora,
give
you
that
flexibility
right
now
to
be
able
to
experiment
and
come
up
with
any
cost
model
that
you
can
imagine
and
as
patterns
emerge
as
we
see
that
indexers
are
doing
the
same
things
over
and
over
again
offer
new
language
features
in
agora.
That
would
allow
you
to
semantically
compress
the
resulting
cost
model
and
express
your
your
strategy
more
efficiently.
B
B
B
B
C
Hey
zach
awesome
presentation:
my
head
is
very
slightly
sore,
so
thanks
for
that
question
about
default
arguments
and
how
they
are
matched
against
agora
rules.
So,
for
example,
if
you
do
not
specify
a
first
argument
in
the
graphql
query,
it
obviously
still
defaults
to
a
value.
So
how
are
defaults
mapped
to
to
rules
in
agora.
B
D
Thanks
zack,
I
was
only
here
for
the
second
half.
Unfortunately,
I
was
in
another
meeting.
So
forgive
me
if
this
is
covered
in
your
first
half,
but
I'm
just
sort
of
thinking
about
right.
The
input
side
of
agora
back
in
the
early
days
of
the
of
the
mission
control
when
we
were
all
sort
of
experimenting
with
the
price
thresholds,
I
I
often
sort
of
compared
it
to
you-
know
stumbling
around
in
a
dark
pitch
dark
room.
Looking
for
over
a
light
switch
right,
so
we
don't
have
the
visibility,
the
host.
D
It
has
right
to
see
the
queries
there.
We
you
know
and
on
the
main
net
you
know
just
thinking
as
an
insular
indexer.
You
only
have
knowledge
of
the
of
the
queries
that
you
are
getting
so
in
this
new
world
that
we're
moving
into
you
know
I
can
see
I
can
see
in
terms
of
the
data
a
need
to
do
things
like
sharing
data
right,
because
I'm
assuming
that
we're
you
know
we're
still
in
that
same
same
situation,
where
we're
not
being
told
how
much
people
are
yeah.
D
B
So
there's
a
broader
question
there
right
about
just
how
are
signals
about
the
broad
market
going
to
be
shared
in
a
decentralized
way
without
you
know
allowing
for
fraudulent
behavior
right
how?
How
do
we
ensure
that
an
indexer
could
share
information
about
the
market?
How
can
consumers
share
their
information
about
their
preferences
and
so
on
and
so
forth?
That
is
a
question
that
we've
been
thinking
about
a
lot.
I
don't
think
that
we
have
a
good
answer
for
for
that.
B
B
This
is
not
something
that
you
would
leave
running
for
very
long,
but
you
can
probably
afford
to
do
it
for
an
hour
and
then
you'd
have
a
decent
set
of
queries
that
at
least
meet
the
minimum
threshold
for
what
your
indexer
offers.
Otherwise,
in
terms
of
say,
economic
security
and
performance,
and
these
other
factors
and
then
figure
out
what
your
revenue
maximizing
price
is
from
there
so
like
until
there
is
a
global
market
signal,
then
you're
going
to
have
to
investigate.
B
Yep,
you
can
use
there's
only
one
sort
of
magic,
global
variable,
that's
automatically
injected
by
the
index
or
agent,
and
that
is
the
conversion
rate
from
die
to
grt
all
of
the
other
global
variables.
You
you
come
up
with
their
names,
you
put
them
in
a
json
file.
You
come
up
with
their
values,
you
put
those
values
in
the
json
file
and
they're
just
supplied
via
the
index
or
cli.
So
you
have
total
freedom
as
to
what
you
want
to
use
for
global
variables.
C
If
we
were
to
implement
kind
of
more
holistic
global
space
strategies,
for
example,
something
like
load
targeting,
is
there
a
true
global?
You
know
some
way
of
defining
like
a
system
load
level
that
applied
to
all
cost
models,
or
would
we
need
to
loop
through
each
of
the
you
know,
subgraph
deployments
and
set
the
globals
individually.
B
Right
now,
you
would
have
to
loop
through
and
set
the
globals
individually
with
some
globals
like
say
the
entity
count
that
could
be
information
that
is
different
per
subgraph
and
but
may
have
the
same
name.
So
we
don't
expose
a
a
way
of
having
global
variables
like
like
a
hierarchy
of
global
variables.