►
From YouTube: The Graph's Core Devs Meeting #6
Description
The Graph’s Core Devs Meeting #6
This video was recorded: Tuesday, August 3 @ 8am PST, 2021.
Sections:
0:00 Intro
1:15 Introducing Figment to The Graph community
3:50 GIP & Governance Updates
19:45 Streaming Fast- Integration update & Firehose
27:35 Semiotic- Automated prosocial negotiations in The Graph protocol
45:05 Q&A
The Graph's Media:
Twitter: https://twitter.com/graphprotocol?s=20
Instagram: https://instagram.com/graphprotocol
LinkedIn: https://www.linkedin.com/company/theg...
Website: https://thegraph.com
A
Very
good
good
morning,
good
afternoon,
everyone
wherever
you
are
welcome
to
the
core
devs
meeting
number
six.
Today
we
have
an
exciting
agenda
with
a
lot
of
interesting
subjects,
and
we
will
be
starting
out
today
by
sharing
with
you
the
latest
announcement
on
the
grant
with
figment
who
joined
us
as
our
third
core
devs
team
and
at
the
graph.
A
B
Awesome,
thank
you
so
much
oliver.
So
I
just
wanted
to
take
a
few
minutes
to
you
know,
discuss
with
the
community
how
excited
we
are
about
decentralizing,
our
core
developers
and
our
ecosystem.
You
know
we
launched
the
graph,
you
know
with
the
initial
edge
of
node
team
streaming
fast.
You
know
now
welcomed
in
and
now
figment
and
I
couldn't
be
more
excited
just
to
see
the
diverse
caliber.
You
know
that
each
of
these
teams
bring.
I
think,
it's
very
easy
to
think.
B
You
know
we're
all
competing
or
you
know
we're
all
self-interested,
but
there
is
a
reality
where
you
can
align
multiple
teams
around
one
mission
on
a
protocol,
and
you
know
what
the
edge
of
node
streaming
fast
and
figment-
and
you
know,
semiotics
sommelier.
All
these
teams
bring
is
very
unique
and
I
think
it's
really
going
to
set
the
graph
forward
in
the
future
for
long
term.
So
with
that
we'll
hand
it
back
to
oliver.
C
Hello,
everyone
I'm
joseph-
and
I
am
the
core
dev
pm
on
fitment
and,
as
ever
said,
we
are
super,
excited
and
happy
to
be
joining
forces
with
the
graph
for
the
last
couple
of
months,
I've
been
working
alongside
some
community
members
and
that
showed
me
how
the
community
is
special
and
we
are
so
lucky
to
have
it.
So,
as
you
know,
our
decision
about
our
5
million
grant
was
the
easiest
decision
that
we
made
and
one
of
our
proudest.
C
We
are
really
happy
to
be
joining
forces
here
and
just
to
give
you
a
bit
of
color
on
what
we're
going
to
be
bringing
to
the
graph
ecosystem.
So
for
the
last
couple
of
years
we've
been
indexing,
multiple
blockchains
and,
as
you
know,
the
graph
is
indexing
as
of
today
indexing
ethereum.
So
we're
going
to
be
taking
this
presses
and
lovely
technology
that
everyone
loves
and
we're
going
to
be,
bringing
it
into
other
blockchains
to
enable
more
applications
being
built
in
the
web3.
C
So
we
really
look
forward
to
doing
this
and
for
everyone
that
is
interested
to
know
more
and
have
a
deeper
dive
on
our
work.
We
invite
you
to
join
the
indexer
office
hours,
which
is
going
to
be
happening
in
two
hours
and
our
lead
engineer.
There
is
going
to
give
you
a
deep
dive
and
you
can
see
the
amazing
work
that
we're
going
to
be
bringing
exciting
times.
A
Thank
you,
awesome,
well
welcome,
and
for
those
of
you
who
don't
know
about
the
indexer
office
hours,
they
happen
in
discord.
There's
a
dedicated
channel
there,
jim
cousins,
hosts
those
and
should
be
a
very
exciting
session.
Today,
it's
going
to
be
an
hour
dedicated.
You
know
to
this
to
this
announcement
so
tune
in
on
that
highly
recommend
joining
okay.
Let's
move
on
to
gip
and
and
governance
updates.
You
do
see
on
the
screen
everything
that
is
currently
sort
of
in
the
pipeline.
A
What
is
mostly
actively
discussed
in
the
community
is
around
curation
and
no
surprise.
We've
just
launched
curation
last
month
and
there's
a
number
of
things
that
are
different
stages
of
of
the
discussion
and
I'd
like
to
start
with
the
batch
gns
transactions,
which
is,
in
other
words,
the
deploy
and
signal
proposal,
which
has
also
been
reviewed
by
the
council
last
week.
And
you
can
see
that
in
the
forum
notes
and
it
is
fairly
far
along.
D
D
That
means
that
you
can
batch
an
arbitrary
number
of
different
transactions.
You
can
signal
multiple
different
subgraphs,
but
at
the
same
time
enables
by
deploying
and
signaling.
So
I
think
it's
a
pretty
good
addition
to
the
to
the
gns,
but
I
invite
everyone
to
take
a
look
at
the
implementation
and
send
any
feedback
in
the
pr
okay.
D
The
other
one
is
something
that
is
being
also
raising
the
in
in
some
of
the
feedback
in
the
community.
That
is
changing
the
ownership
of
subgraph.
It
happens
with
some
of
the
teams
that
they
use
a
different
address
and
they
wanted
to
move
a
sub
graph
to
a
multisig
or
some
other
place,
or
even
people
created
a
subgraph
and
and
they
wanted
to
transfer
it
to
the
to
the
official
team.
But
it's
not
easily.
It
can
be
done
easily.
D
Now
so
there's
this
investigation,
where
we
are
looking
into
an
implementation
of
our
ownership
for
some
graphs.
So
whenever
you
create
one,
you
can
easily
transfer
to
to
someone
else.
So
these
these
two
are
the
the
main
things
that
are
one
one
is
already
implemented.
The
other
one
is
under
candidate
implementation,
looking
into
the
best
way
to
implement
it
about
curation,
and
then
we
have
this
stable
delegation
yield.
That
is
something
that
we
talked
in.
D
E
Yeah,
so
this
proposal,
funnily
enough,
is
to
lower
the
curation
tax,
which
I'm
sure
most
of
you
are
aware,
is
a
tax,
that's
paid
on
deposit
to
the
bonding
curves
for
a
subgraph
the
impetus
for
writing.
This
was
based
on
feedback
that
come
to
me
from
a
number
of
places
that
the
costs,
the
total
costs
to
a
subgraph
developer,
were
a
bit
onerous,
especially
with
respect
to
upgrades
and
changing
versions.
E
So
what's
interesting
about
this
proposal,
is
that
it
also
the
gip
for
it,
which
you
can
find
in
the
forums
also
outlines
a
previously
undisclosed
economic
attack
that
we
call
the
subgraph
withholding
attack
and
the
curation
tax.
One
of
the
primary
functions
of
the
curation
tax
was
making
this
attack
unprofitable
and
the
base.
Basically,
the
way
that
this
attack
goes
is
that
an
attacker
signals
on
a
brand
new
sub-graph,
then
they're,
the
first
and
only
indexer
to
that
subgraph,
because
they
do
not
actually
release
the
subgraph
manifest
for
that
subgraph
to
the
network.
E
So
no
other
indexer
can
come
and
index
it.
They
monopolize
indexing,
rewards
on
that
subgraph.
Basically,
you
know
as
long
as
the
attack
you
know
goes
on
and
other
indexers
are
unable
to
come
in
and
dilute
the
the
profits.
You
know,
if
you
will
from
that
attack
the
mitigation
for
this
attack
that
we've
already
had
in
the
protocol.
Basically
from
day.
E
And
then
the
curation
tax
also
mitigates
this
attack
by
making
it
essentially
penalize
someone
for
trying
that
attack
because
they're
paying
the
only
cost
of
trying
this
attack.
You
know,
in
addition
to
the
gas
costs
is
the
is
the
curation
tax
and
right
now,
we've,
you
know,
monitored
the
subgraph
oracle,
that's
running
on
the
live
network.
It
catches
most
attacks
within
about
eight
to
nine
minutes,
which
is
quite
good.
E
That's
we
have
quite
a
bit
of
margin
of
error
in
our
analyses
and
so
that
you
know
with
respect
to
that
attack.
Specifically,
we
could
lower
lower
the
curation
tax
from
where
it
is
today
in
the
network.
I
think
josh
from
I
believe
from
streaming
fast
pointed
out
that
that
doesn't
necessarily
prove
that
we
should
lower
the
curation
tax
right,
and
there
might
be
other
reasons
to
to
think
that
this
could
have
knock-on
effects.
You
know.
E
One
knock-on
effect,
for
example,
would
be
that
and
if
indexers
in
equilibrium
had
like
a
baseline
level
of
curation
tax
that
they
wanted
subgraph
developers
to
pay,
it
could
just
be
that
the
amount
signaled
per
sub
graph
increases
in
response
and
in
absolute
terms,
the
cur
the
amount
that's
paid
as
curation
tax
doesn't
end
up
changing
much.
I
suspect
that
wouldn't
be
the
dynamic,
but
that's
there
are
counter
arguments
to
be
made
here.
If
you
want
to
play
devil's
advocate.
E
I
think
this
is
definitely
one
that
needs
a
lot
more
input
in
the
forums
and
we'll
probably
end
up
doing
a
snapshot.
Vote
I'd,
especially
like
to
see
input
from
curators
and
subgraph
developers.
You
know
how
you
feel
about
this
change,
given
that
there
could
be
dynamics
that
might
increase
the
equilibrium
signaling
amount,
which
you
know,
decreases
the
curation
tax
relatively
speaking,
but
it
could
increase
like
cost
of
capital
and
opportunity
cost
so
yeah.
We
can
follow
that
up
in
the
forums
and
feel
free
to
ask
questions
in
the
q
a.
A
Yeah,
thank
you
for
that,
so
great
great
segue
into
the
next
topic,
which
is
dynamic,
curation
text.
Let
me
just
set
that
up.
We
have
probably
one
topic
right
now
in
the
curated
community.
That
seems
to
be
the
most
burning
one
which
presents
itself
as
an
issue
where
we
have,
you
know,
bought
front
running
the
bonding
curve.
So
the
incentive
seems
just
too
high
right
now
to
just
instantly
signal
without
doing
a
curator's
job,
which
is
to
validate
the
quality
and
economic
values
of
a
sub
graph,
and
there
have
been
a
number
of
discussions
around.
A
F
A
A
We
start
out
with
a
curation
tax.
That
is
not
one
percent
per
new
proposal
right
now,
two
and
a
half
percent,
but
we
start
out
with
a
value
that
is
much
higher.
Call
it
something
like
50
and
what
it
should
be
doing
is
to
deter.
You
know
wins
to
be
gained
from
very
quickly.
You
know
curating
and
signaling
on
the
bonding
curve
and
then,
as
time
goes
by
with
each
epoch,
that
number
that
curation
tax
then
goes
down.
A
There
are
two
proposals
out
there
in
terms
of
how
that
curve
would
look
like
there's
one
with
a
straight
line
where
it
reduces,
I
think,
by
seven
and
a
half
percent
with
with
every
day
until
it
hits
that
two
and
a
half
percent,
and
I
think
that
is
day
seven,
and
at
that
point
it's
just
continuously
two
and
a
half
percent.
So
what
you
would
have
to
decide
as
a
curator
is
first
of
all,
it's
supposed
to
give
you
time
to
do
your
job
right.
That
is
one
goal
that
we
currently
don't
seem.
A
You
know
to
be
able
to
provide,
and
then
you
know,
depending
on
how
strong
your
confidence
is,
you
know
in
in
that
sub
graph.
You
can
then
decide
at
what
point
in
time
to
to
move
in
knowing
that
the
earlier
you
move
in
the
higher
you
know
the
taxation
will
be
so
you
start
to
create
a
risk
reward
profile.
So
to
say,
based
on
the
time
that
you
join,
I
I
find
it
certainly
interesting
provide
feedback
in
the
forum.
A
There
is
going
to
be
more
discussions
that
I
know
that
slim
chance
is
having
with
in
the
curated
community.
To
me
this
seems
to
be
the
most
pressing.
You
know
issue
right
now,
and
this
proposal
seems
to
be
the
one
that
seems
to
address
it
in
the
best
way
possible
if
there
are
other
ideas
out
there.
Please
come
forward
share
with
us
in
the
forum
and
if
you
like
that
idea
or
have
other
thoughts
to
that,
please
also
provide
feedback
in
the
forum
as
well.
A
E
Yeah
this
one
will
be
quick.
I
just
want
to
make
sure
folks
were
kept
in
the
loop.
So
basically
there's
two
main
pieces
of
engineering
work,
that's
kind
of
blocking
fully
adopting
the
arbitration
charter
and
the
api
and,
like
the
subgraph
feature
version
in
gips,
one
is
actually
tweaking
the
graph
node
to
produce
a
valid
poi
in
the
case
of
a
field
sub
graph
right
now
it
just
returns
null,
and
so
this
was
a
a
change
to
the
arbitration
charter
that
came
out
of
discussions
in
the
forums
where
you
know.
E
Basically,
the
community
reached
a
consensus
that
actually
it
did
make
sense
for
indexers
to
be
able
to
receive
rewards
for
failed
subgraphs,
but
right
now
the
graph
note
just
isn't
equipped
to
produce
pois
for
failed
subgraphs
and
so
there's
work.
That's
ongoing
right
now
to
change
that
and
the
other
piece
is
feature
detection.
So
we
have
a
gip
that
the
arbitration
charter
depends
on
that
outlines
how
to
tell
if
a
sub
graph
is
supported
in
the
protocol
for
indexing,
rewards
disputes
and
other
features,
but
there's
no
way
of
actually
detecting
those
features.
E
You
know
that
subgraph
oracle
that
we
mentioned
earlier
another
one
of
its
jobs,
is
to
disable
indexing
rewards
for
subgraphs
that
are
ineligible
for
those
rewards,
and
so,
as
an
indexer
before
you
do,
the
work
of
you
know
spending
you
know
hours
indexing,
something
that's
that's
helpful
helpful
context
to
have
so
both
of
that
is
are
coming
in
the
near
term,
and
so
I
would
say
just
stay
tuned
for
that.
You
should
probably
have
more
updates
by
the
next
cordes
call.
A
G
Very
interesting,
okay,
thank
you
from
alex
and
the
cto
at
the
streaming
fast,
faster
and
happy
to
have
recently
joined
this
ecosystem
to
to
bring
our
focus.
Let's
say,
of
increasing
indexing
performance,
that's
for
the
short-term
aspects,
so
maybe
integration
progress.
We
can
say
that
we
have
worked
hard
on
bringing
a
few
insights
directly
into
the
graph
node
recently.
So
we
have
a
few
pr's
up
and
running
there.
Upgrading
libraries,
some
some
very
low
level
work.
G
Actually,
some
you
know,
futures
and
tokyo
library
updates
are
there
to
enable
the
next
stage
of
you
know:
performance
increases
in
the
graph
node,
so
we've
been
been
doing
some
work.
There
also
the
same
time
integrating
the
fire
hose
as
a
source
of
data,
and
maybe
I
could
just
switch
swap
to
the
fire
hose
quickly
here,
so
we've
posted
on
the
forum.
If
you
go
to
the
forum
you
search
fire
hose,
I
think
it's
just
a
sticky
name
right.
It's
a
thickening!
G
It's
a
it's
a
pattern
rather
than
a
product
because
it's
your
product,
it's
our!
It's
our
thing
together!
It's
just!
We
know
what
we
talk
about
and
we
say
that,
but
we
posted
like
some
of
the
rational,
the
ideas
around
it's
a
little.
You
know
a
different
way
to
produce
and
consume
blockchain
data
and
there's
a
few
lists
of,
I
think,
fair
points
that
have
excited
those
who
have
read
it.
G
You
know
also
increases
in
linear
indexing
performance,
but
maybe
I
don't
know
if
it's
appropriate
the
sort
of
people
we
have
here
to
to
get
into
some
details.
So
the
reasons
for
that
you
know
as
if
we
have
files
or
unpacked
in
some
threads.
The
data
is
always
ready
to
be
processed
and
indexed
in
memory
when
it's
when
it
arrives.
So
it's
it's
very
fast.
It's
a
fast
way
to
push
data
down
to
the
indexer
instead
of
the
index
for
going
fetch
for
it.
G
G
G
G
You
know
performance
improvements
and
and
for
that
we'll
see
that
we're
gonna,
so
first
of
all,
we're
gonna
be
open
sourcing.
All
that
stacks
up.
Some
of
them
are
not
yet
open.
So
I'm
gonna,
we're
gonna
sort
of
just
make
sure
they're
easily
consumable,
and
I
wanna
work
with
some
of
the
indexes
so
that
you
guys
run
fire
hoses
and
you
get
an
understanding
of
what
what
what
what
it
is
right.
G
I
think
that
kuhn
was
telling
us
that
the
bsc
archive
node
was
was
it
close
to
10
terabytes
on
the
nvme,
like
getting
closer
to
the
limits
that
he
can
have
on
the
nvme
and
that
the
the
packed
version
of
the
data
which
we
use
for
indexing
when
we
do
the
pancake
swap
thing
is
close
to
1.2
terabytes,
so
much
smaller
and
also
much
less
cost
because
they're
just
on
storage?
And
if
you
don't
read
those
files,
you
can
put
on
cold
storage
on
an
icy
storage
on
a
low
kelvin
storage.
G
I
don't
know
like
that.
With
these
cloud
providers
they
have
monkey
names
right
so
so
that
we're
gonna
bring
some
of
that
to
you
as
soon
as
possible.
My
goal
is
to
get
that
feedback
from
you
guys
as
soon
as
possible.
So
when
you
get
to
the
firehose,
if
you
could
try
it
give
us
some
feedback
see
how
to
impact.
G
G
A
Of
course,
and
if
there's
anything
that
we
can
help
with
just
to
to
connect
with
folks
that
you
want
to
get
feedback
on
reach
out
to
me,
I'm
more
than
happy
to
facilitate
that.
If
we
want
to,
you
know,
maybe
schedule
a
workshop
session,
you
know
where
you
can
have
deeper
discussions
around
that
you
know.
We've
got
different
ways
where
we
can
get
feedback.
A
H
H
Okay,
so
reinforcement
learning
is
a
branch
of
artificial
intelligence
and
it
is
focused
on
making
automated
decisions
in
uncertain
environments,
and
the
graph
has
many
opportunities
where
we
can
apply.
Rl
too,
for
example,
we
can
build
tools
for
indexers
to
automatically
select
prices
which
lead
to
the
best
long-term,
profitable
outcome
for
the
indexers.
H
So
why
why
this
care
for
pro-social
behavior
for
our
rl
agents?
Well,
we
certainly
don't
want
to
be
deploying
agents
that
are
maximally
extractive
at
the
expense
of
the
health
of
the
protocol
and
on
the
other
hand,
we
need
robust
behavior
to
give
our
agents
the
ability
to
basically
defend
against
adversaries
that
may
exist
inside
the
protocol.
I
All
right
so
as
a
part
of
this
reinforcement
learning
effort,
we
wanted
to
do
a
deeper
investigation
into
how
we
can
actually
get
the
behaviors.
We
want
in
the
agents
that
we
train
so
to
do
that.
We
took
a
look
at
this
paper
pro
social
or
selfish,
which
explored
a
sort
of
generalized
negotiation
format
where
two
deep
neural
network
agents
negotiate
over
the
inclusion
or
exclusion
of
six
different
clauses.
I
So,
at
the
beginning
of
one
of
these
negotiations,
each
agent
will
be
given
a
randomly
generated
utility
vector,
so
this
utility
vector
will
have
six
numbers.
Some
of
them
will
be
negative,
denoting
that
the
agent
would
actually
get
punished
if
that
clause
was
included
in
the
final
deal,
and
some
of
them
are
positive,
meaning
the
agent
would
benefit
from
that
clause
being
included
in
the
final
deal.
I
Now,
it's
important
to
note
that
both
of
these
are
randomly
generated
every
single
negotiation.
So
sometimes
these
utility
vectors
will
be
very
similar
and
there
will
be
a
lot
of
common
ground
between
the
agents
and
thus
it'll
be
a
lot
easier
for
them
to
come
to
a
a
good
agreement
and
sometimes
they'll
be
very
different,
in
which
case
it
will
be
very
hard
for
them
to
come
to
an
agreement
that
works
for
both
of
them.
I
I
So
in
this
case
agent
a
sent
over
offer
sub-zero,
and
in
this
case
he
wants
to
include
clause
4
and
clause.
6.
agent
b
can
then
look
at
that
offer
and
he
can
propose
a
counteroffer.
So
in
this
case,
agent
b
proposed
that
clause,
2
and
clause
4
be
included
in
the
final
deal
once
again,
agent.
A
can
look
at
that
and
propose
a
counter
offer
if,
at
any
point
agent,
a
or
agent
b
proposes
the
same
offer
that
they
were
just
given.
I
Then
that
is
an
agreement
and
the
negotiation
ends
and
the
final
contract
is
the
offer
that
they
agreed
on.
If,
however,
they
continue
going
back
and
forth
and
don't
reach
an
agreement
eventually,
they
hit
a
deadline
that
we
imposed,
which
in
this
case,
is
when
they
have
each
offered
15
different
offers.
I
I
The
first
one
is
a
selfish
reward
function.
This
one
is
simply
the
utility
that
an
agent
is
getting
out
of
the
deal.
So
if
a
deal
is
made,
this
is
shorthand
for
the
total
utility
that
an
agent
is
getting
out
of
the
deal
and
if
no
deal
is
made,
then
a
small
punishment
is
given
to
disincentivize
stalemates.
I
The
pro-social
reward
function
on
the
right
here
is
very
similar.
With
the
only
change
being
that
a
pro-social
agent
only
gets
rewarded
for
the
utility
it's
getting
out
of
deal
if
the
deal
is
optimal,
so
a
prosocial
agent
still
wants
to
maximize
its
own
benefit,
but
it
will
not
do
so
at
the
cost
of
the
other
participants
in
the
environment
which,
as
you
can
imagine,
is,
is
very
desirable
in
a
network
that
we
want
to
maximize
the
overall
health
of.
I
I
I
I
So
on
the
right.
I
actually
have
a
visualization
of
this
negotiation,
so
this
will
graph
the
total
utility
that
each
agent
is
getting
in
the
negotiation
over
time
at
the
top.
You
will
see
the
current
offer
highlighted
in
the
color
of
the
agent
that
is
proposing
it
and
on
the
left
and
right,
you
will
see
the
utility
vectors
that
have
been
assigned
to
each
agent,
as
well
as
the
current
proportion
of
the
maximum
utility
they
can
get
that
they
are
getting
out
of
the
current
offer.
I
I
One
important
thing
to
note
here
is
that
the
selfish
agent
is
reaching
much
higher
peaks
all
along
here,
because
it
only
cares
about
itself.
It's
trying
to
offer
rewards
that
will
maximize
its
own
gain,
while
the
pro-social
agent
is
offering
agents
offers
that
are
not
perhaps
the
best
for
themselves,
but
actually
reach
an
optimal
deal
for
both
of
them,
and
you
can
see
in
this
particular
case
on
time,
step
20.
I
This
one
is
very
interesting.
You
can
see
in
this
animation.
There
is
a
lot
less
agreeable
they're
actually
for
most
of
the
beginning,
they
are
just
going
back
and
forth,
proposing
the
same
set
of
offers
to
each
other.
It's
not
until
the
very
end
when
there
is
about
to
be
a
deadline
that
they
actually
start
trying
to
work
with
each
other
and
eventually,
on
the
last
time
step.
They
do
come
up
with
a
deal
they
can
make.
I
Now.
These
statistics
here
are
somewhat
interesting.
You
may
expect
that
two
selfish
agents
would
not
be
able
to
agree
much,
but
actually
when
they
are
trained
against
each
other.
They
learn
that
if
they
don't
compromise,
they're
not
going
to
get
their
selfish
reward,
because
no
agreement
will
be
made.
So
actually,
when
you
train
these
two
selfish
agents
against
each
other,
they
do
learn
to
compromise
a
bit
and,
as
a
result,
you
actually
have
a
pretty
decent
optimality
rate
and
agreement
rate.
I
I
So
if
you
watch
this
sample
negotiation
here,
this
one
is
actually
one
of
the
longer
ones.
Usually
they
end
after
only
a
few
time
steps,
because
these
two
agents
are
able
to
very
quickly
come
to
an
agreement
on
what
they
want,
and
you
can
see
in
this
case
that
they
did
come
to
a
good
ingredient
for
both
of
them
as
they're,
both
getting
positive
utility.
I
So,
as
we
said
before,
these
agents
are
completely
selfless
and
just
want
to
maximize
the
total
benefit
of
everyone
within
the
network
and
as
a
result,
when
you
match
two
of
these
up,
you
get
a
pretty
much
100
percent
agreement
rate.
They
always
come
to
a
deal
and
you
also
get
the
highest
optimality
rate
that
we've
seen
and
correspondingly.
You
can
see
the
highest
combined
average
score
as
well,
and
the
shortest
average
dialogue
length,
which
shows
that
they're
even
more
agreeable
than
the
two
pro
social
agents.
I
So
if
we
play
one
of
these
sample
negotiations,
it's
very
quick.
You
can
see,
interestingly,
that
it
ended
with
total
one
getting
no
utility
out
of
the
deal,
but
he
doesn't
care
because
the
other
agent
got
a
ton
of
utility
out
of
the
deal.
So
he's
still
very
happy,
because
overall,
the
network
really
benefited
from
this
negotiation.
I
I
So,
lastly,
I
want
to
look
at
a
pro-social
agent
first
in
adversarial
agent.
So
as
I've
highlighted
before
the
pro-social
agent
is
trying
to
be
pro-social.
But
it's
not
selfless.
It
does
care
about
maximizing
its
own
utility,
as
well
as
the
overall
health
of
the
network,
and
as
such
you
can
see
in
these
statistics.
I
Those
are
just
a
few
examples.
Overall,
we
see
a
ton
of
applications
of
reinforcement,
learning
and
more
specifically,
these
goal-driven
reward
functions
at
the
end
of
the
day.
We
think
a
lot
of
these
tools
will
have
a
very
large
impact
on
the
overall
health
and
profitability
for
everyone
of
the
graph
protocol.
I
A
A
I
A
I
Sure
so,
we've
already
done
a
little
bit
of
work
with
the
isa,
formulating
it
as
an
rl
environment
or
an
rl
agent.
So
moving
forward
with
that
would
be
quite
interesting.
I
do
think
there's
a
lot
of
potential
in
training
that,
with
this
sort
of
total
good
of
the
environment,
because
the
gateway
should
be
impartial
so
maximizing
the
total
good
of
the
environment
is
a
little
less
hard
to
take
advantage
of.
In
that
scenario,
and
also
the
sort
of
direct
negotiations
are
quite
interesting
because
that
moves
further
towards
decentralization.
E
A
A
Very
good,
thank
you
again,
matt
and
sam.
So
don't
see
any
any
more
questions
at
this
point
and
also
no
other
questions
for
the
call
itself
outside
of
semiotic.
So
we
can
actually
leave
a
little
early
today.
Nine
minutes
left
give
you
back
the
time.
Thank
you.
Everyone
for
joining!
You
are
going
to
see
the
notes
posted
here
in
the
next
couple
of
days
and
we
try
to
be
as
fast
as
we
can
with
posting
the
video
also
on
youtube.
Thank
you
all
for
joining.