►
From YouTube: Saturn Aliens - Maria Silva, Amean Asad
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
I'll
start
with
an
introduction
to
the
design
and
how
we
ended
up
with
such
a
design
and
then
a
mineral
pickup
and
talk
about
the
implementation,
but
before
going
deeper
into
the
design,
I
want
to
discuss
a
little
bit
about
the
value
flow
within
Saturn.
So
we
are
all
on
the
same
page
and
the
design
choices
are
a
bit
clearer.
A
A
They
may
have
any
sort
of
financial
relationships
with
the
content.
Publishers
such
as
ad
revenue
or
subscription
models,
but
this
will
be
completely
independent
of
Saturn.
Okay
and
then
we
have
the
final
piece
of
the
puzzle,
which
is
the
node
operators,
and
these
are
the
servers
that
are
committing
resources
to
the
CDN,
and
so
they
every
time
there's
a
request
to
Saturn.
A
A
They
can
fake
traffic,
and
this
is
a
fact
that
guided
a
lot
of
the
final
design
choice
and
because
of
this,
we
have
to
have
this
module,
which
is
a
fraud
detection
module
in
place
that
is
essentially
trying
to
flag
and
cache
and
catch
this
type
of
behavior.
So
these
type
of
logs
or
nodes
that
are
faking
traffic
or
changing
and
doctoring
their
unlocks.
A
And
then
we
have
the
reward
calculator
and
this
module
is
essentially
responsible
for
Gathering
all
the
statistics,
the
performance
metrics
and
the
flags
coming
from
the
fraud
detection
system
and
defining
the
final
rewards
and
payouts
to
the
node
operators.
And
then
at
the
end
we
have
the
monitoring.
So
the
monitoring
piece
is
collecting
statistics
out
of
the
fraud
detection
and
the
reward
calculation,
and
the
goal
here
is
to
have
an
iterative
process
where
we
can
keep
improving
on
the
whole
system.
As
we
move
forward.
A
Now,
when
we
talk
about
incentives,
a
first
important
step
is
always
to
think
about
what
behaviors
we
want
to
see
in
the
network,
and
this
means
thinking
about
what
good
behaviors
we
want
to
incentivize
and
what
bad
behaviors
we
want
to
avoid
on
the
side
of
the
good
behaviors.
We
have
three
and
the
first
is
a
high
bandwidth
service.
So
this
means
that
we
want
a
network
as
a
whole
to
serve
as
much
content
as
possible.
The
more
content
we
serve,
the
most
content,
Publishers
we
can
engage
and
the
more
users
we
can
serve.
A
The
first
is
the
time
to
First
byte
and
the
second
is
the
total
download
time
and
finally,
we
have
the
reliability,
so
we
don't
put
nodes
going
offline
and
leaving
users
without
their
content,
and
so
apptime
is
another
metric
that
we
care
about
then
on
the
side
of
the
bad
behaviors.
These
are
essentially
those
behaviors
I
described
before
so
nodes
doctoring
their
own
logs
faking
traffic
in
order
to
get
a
bigger
share
of
Rewards
from
these
two
sets
of
behaviors.
A
We
have
these
two
questions
that
we'll
try
to
answer
in
this
presentation,
and
the
first
is
based
on
the
performance
metrics
we
Define:
how
can
we
better
distribute
Rewards
and
secondly,
how
much
should
we
penalize
notes
in
case
of
bad
behaviors?
So
how
much
do
we
Define
penalties
so
that
nodes
don't
are
incentivized
to
behave
in
that
way?.
A
So,
on
the
side
of
the
rewards,
we
ended
up
using
this
sort
of
concept
of
service
scoring
functions.
These
are
functions
that
map
specific
service
metrics
such
as
bandwidth
uptime,
all
those
metrics
I've
discussed
before
into
a
ratio
of
rewards,
and
why
a
ratio
and
the
reason
is
at
each
payout
window,
we
will
have
a
fixed
amount
of
fill
that
will
be
Distributing
for
the
nose
that
participated
participated
during
that
payments
window,
and
so
we
need
to
get
the
metrics
of
performance
of
those
nodes
during
that
window
and
transform
that
into
a
share
of
Rewards.
A
And
here
we
have
an
example
for
the
bandwidth,
but
the
final
function
is
the
same
for
all
the
metrics,
so
we
ended
up
using
adjusted
version
of
a
share
of
performance
and
is
adjusted
because
it's
using
this
exponent
K
that
is
essentially
controlling
how
much
we
reward
over
performers.
Okay,
to
make
it
more
concrete.
An
example
would
be
using
a
linear
function
and
this
means
using
a
k
equal
to
1,
and
essentially
here
we
are
rewarding
proportionally
on
the
performance.
A
So
we
got
all
these
functions
and
all
these
possible
values
for
case,
and
we
did
a
full
simulation
of
how
these
would
play
out
with
different
types
of
of
nodes,
and
we
ended
up
with
this
final
proposal.
So
we
are
still
using
those
three
behaviors
I
discussed
before
bandwidth,
speed
and
uptime,
and
then
we
have
different
coefficients
for
some
of
them.
A
Now
for
the
penalties,
so
when
we
were
thinking
about
penalties,
we
thought
about
a
way
to
define
some
sort
of
theoretical
bounce
for
these
penalties,
and
for
this
we
started
with
two
assumptions,
so
the
first
assumption
led
to
a
lower
bound
on
the
penalty,
and
this
assumption
essentially
says
that
the
penalty
needs
to
be
large
enough.
So
it's
not
economically
advantageous
to
cheat
okay.
What
does
this
mean?
So
we
have
a
lock
that
the
fraud
detection
system
in
place
this
fraud
detection
system
will
never
be
perfect,
so
sometimes
it
will
have
some
node.
A
That
is
cheating
and
it
won't
cache
it.
Okay,
and
so
this
probability
of
a
cheating
not
being
cash,
is
also
known
as
the
true
positive
rate
of
the
system,
and
we
can
use
this
probability
to
build
this
equation
where
we,
what
we
are
essentially
saying
is
that,
on
the
long
run
such
a
note,
that
is,
that
is
consistently
cheating.
The
network
will
sometimes
be
caught
other
times
will
pass
through,
but
on
the
long
run
the
overall
rewards
need
to
be
negative.
A
Okay.
So,
on
the
long
run,
this
node
is
not
incentivized
to
participate,
and
if
you
solve
this
equation,
you
get
that
the
penalty
depends
on
the
true
positive
rate
of
the
system
and
also
which
is
nice.
The
average
reward
before
penalties,
so
you
can
actually
compute
these
lower
bound
for
for
each
node
and
then
for
the
upper
bound
assumption.
A
And
once
again,
this
gave
us
an
interval
of
some
possible
values
for
penalties.
We
could
use,
we
run
some
simulations
and
we
settle
on
these
five-time
multipliers.
So
this
means
that
if
you
are
flagged
by
the
detection
system,
your
penalty
will
be
five
times.
Your
average
long-running
rewards.
Okay,
and
this
again
reaches
a
balance
between
guaranteeing
that
cheating
notes
don't
extract
too
much
value
while
at
the
same
time
making
sure
that
the
honest
operators
are
not
overly
penalized.
B
Hello,
everyone,
my
name
is
Amin
and
I'm.
One
of
the
engineers
on
the
Falcon
Saturn
team
and
over
the
past
few
months,
I've
been
working
really
hard
to
turn.
Maria's
Roar
design
functions
into
a
working,
live
payment,
supplementation
and
Maria
showed
you
the
value
and
I'm
here
to
show
you
the
money.
B
So
first
I
want
to
start
by
describing
all
the
moving
pieces
that
are
part
of
Saturn
payments,
and
the
idea
here
is
to
get
a
fine
grasp
of
the
data
flow
that
has
to
happen
before
a
payment
is
made.
I
know,
there's
a
big
diagram
and
what
I'm
going
to
try
to
do
here
is
break
each
component
piece
by
piece
and
explain
what
it
actually
does.
B
So
to
start,
the
Saturn,
the
Saturn
payments
pipeline
officially
starts
at
the
retrieval
clients
in
L1
nodes,
and
hopefully
this
interaction
is
already
familiar
to
the
audience
from
the
previous
presentations.
But
just
to
recap,
what
happens
here
is
retrieval.
Clients
send
retrieval
requests
to
L1
nodes,
L1
nodes,
send
files
to
these
retrieval
clients
and,
as
a
result
of
that
transaction,
two
important
things
happen
now.
These
are
one
notes.
Well,
the
first
thing
is
now:
these
L1
nodes
are
owed
money.
So
how
do
we
pay
them?
B
Well,
as
it
happens,
I
know
the
answer
to
that
question,
and
the
second
thing
that
happens
is
there's
data
generated
from
that
transaction.
So
what
do
we
do
with
that
data
and
how
does
that
data
factor
into
Computing
payments
and
the
first
part
of
the
answer
that
question
is
the
log
processor,
so
the
job
of
the
log
processor
is
that
it
ingests
all
the
data
from
transactions
between
L1
nodes
and
retrieval
clients,
and
what
it
does
essentially
is
that
extracts
meaningful
information
from
it.
B
An
example
in
this
information
includes
time
to
First
byte
the
time
for
the
request
to
be
served.
The
download,
speed,
Etc,
it's
essentially
trying
to
quantify
and
I
want
node
performance
while
serving
files
and
it
formats
that
data
and
stores
it
in
our
Saturn
storage.
Now
the
second
part
of
the
answer
to
that
question
is
the
orchestrator.
Now
Diego
introduced
the
orchestrator
and
it's
one
of
the
core
components
of
Saturn
and
in
the
context
of
payments.
B
We
have
no
performance
from
the
orchestrator,
we
have
node
uptime
and
reliability,
and
with
that
we
finally
have
the
required
metrics
that
we
that
enables
us
to
use
the
reward
functions
that
Maria
just
described
to
process
payments,
and
with
that
we
can
finally
introduce
the
Saturn
Treasury
and
the
job
of
the
Saturn
treasury
is
very
simple.
It
ingests
all
that
data,
computes
fraud,
computes
payouts
and
issues
those
payouts
to
our
nodes,
so
I'm
going
to
try
and
break
down
this
architecture
a
little
bit
more,
so
the
data
flow.
B
Just
to
recap,
the
data
flow
on
the
Saturn
treasury
is
that
you
receive
all
the
transactions
from
these
logs.
You
detect
fraud,
you
calculate
payments
and
all
of
that
is
being
monitored,
and
then
you
issue
those
payments.
So
this
essentially
breaks
down
to
two
serverless
functions
that
we
run
payments
aggregator
and
a
payments
issuer.
The
job
of
the
payments
aggregator
is
that
it
runs
very
frequently
currently
every
30
minutes,
and
what
it
does
is
that
it
collects
key
payment
metrics
and
calculates
aggregate
payments
for
L1
nodes
for
that
period.
B
A
good
analogy
here
is
that
you
can
think
of
the
payment
aggregator
as
sort
of
a
bookkeeper
that
patrols
a
network
frequently
observes
the
state
and
makes
payment
calculations
based
on
that
state.
Now.
The
second
function
is
the
payment
issuer,
and
that
runs
every
month,
and
the
job
of
that
function
is
to
Simply
sum
up.
B
First
of
all,
the
aggregator
gives
us
a
lot
of
visibility
and
monitoring
over
key
payment
metrics
and
allows
us
to
use
to
generate
data
that
we
can
use
to
improve
that
Pipeline,
and
the
second
thing
is
decoupling.
Payment
issuing
sorry,
payment
calculation
and
payment
issuing
allows
us
to
change
one
of
those
components
without
impacting
the
other.
B
So
the
final
breakdown
here
is
I
want
to
walk
you.
The
final
breakdown
of
payments
I
want
to
walk
you
through
the
logic
of
what's
Happening
as
logs
are
processed
through
these
functions.
So
just
to
recap,
everything
goes
to
the
payment
aggregator
first,
so
the
payment
aggregator
process,
all
logs
first
thing
it
does-
is
that
it
computes
fraud
on
the
network
based
on
our
fraud
detection
model.
If
fraud
is
detected,
we
flag
logs
and
then
penalties
are
computed
for
the
nodes
that
are
responsible
for
these
fraudulent
logs,
and
then
it
assigns
reward
scores
for
nodes.
B
These
reward
scores
are
assigned
per
the
functions
that
Maria
was
just
discussing
and
finally,
it
computes
fill
earnings
and
fill
penalties
based
on
the
reward
scores
and
the
fraud
that
we
just
detected
and
it
stores
all
that
information
in
our
Saturn
storage
and
then
at
the
end
of
the
month.
Payments
issue
a
run
again.
It's
like
our
second
account
in
here
and
it
essentially
retrieves
all
the
the
it
retrieves
all
the
all
the
the
stuff
that
we
just
stored
from
the
payments.
Aggregator
retrieves,
the
penalties
and
the
payment
Aggregates.
B
It
computes
the
final
node
warnings
for
that
month
and
it
updates
a
global
penalty
value
and
the
reason
we
have
a
global
penalty
value
is
to
keep
track
of
fraud
if
it
accumulates
on
the
network.
So
if
you
commit
fraud,
a
lot
Saturn
will
not
forget
and,
as
you
may
have
guessed
it,
we
also
store
that
information.
B
So
I
want
to
walk
through
a
little
bit
of
what
the
next
steps
for
Saturn
payments
are
and,
as
Maria
mentioned,
the
design
is
going
to
evolve
the
the
way
we
design
payments
that
something
we
want
to
iterate
on
a
lot
to
improve,
and
accordingly,
the
implementation
must
change.
So
the
first
two
things
that
or
the
first
substantial
things
that
we
want
to
look
at
is
moving
towards
decentralization.
If
you
may
have
noticed,
payments
is
not
currently
a
decentralized
service.
B
That
is
not
a
bug,
but
merely
a
temporary
feature
that
we
have
but
yeah
we're
looking
to
to
change
that,
and
the
second
thing
is
enable
some
form
of
learning
in
our
Pipeline
and
by
learning
here
I
mean
that
we,
as
you
may
have
noticed,
we
store
a
lot
of
data.
We
extract
out
all
the
useful
metrics.
We
ought
to
use
that
data
and
feed
it
back
into
our
system.
Do
some
form
of
analysis
and
use
that
to
improve
our
mechanisms.
A
great
example
of
learning
is
implementing
like
a
machine
learning
based
raw
detection
model.
B
That
would
be
like
a
great
example
of
implementing
learning
in
our
in
our
pipeline.
So
I
want
to
go
over
that.
What
kind
of
that
looks
like
on
the
network?
So
this
is
currently
our
current
setup.
We
have
retrieval
clients
on
one
side,
L1
nodes
and
we
have
the
transaction
going
between
them
and
then
retrieval
clients
submit
all
the
data
to
Saturn
treasury
Saturn
treasury.
B
It
invokes
the
serverless
functions
to
compute
everything,
and
then
it
pays
the
L1
nodes
and
this
is
kind
of
what
we
want
it
to
look
like.
So
we
want
the
network
of
nodes
to
communicate
with
each
other.
We
want
the
network
to
invoke
its
own
payment
function
to
compute
what
payments
will
be
for
each
node
and
issues.
Those
as
you
see,
there's
a
one
lonely
node
there,
but
I
just
wanted
to
be
realistic.
B
And
the
the
final
thing
here
is
describing
how
how
we're
going
to
move
towards
learning
and
that's
a
it's
a
very
simple
step.
This
is
what
we
have
for
for
our
pipeline
now
retrieval
logs,
detecting
fraud,
payments
calculation
then
issue
with
those
payments
and
implementing
a
a
feedback.
Loop
is
as
simple
as
that,
and
it's
simply
feeding
back
taking
that
output,
feeding
it
back
analyzing
it
and
using
that
analysis
to
improve
our
mechanisms
and
the
beauty
of
the
feedback
loop
is
it's
one
of
those
simple
engineering
features
that
have
yielded
remarkable
engineering
results.
B
The
feedback
loop
has
enabled
it's
really
like
the
fundamental
feature
that
feels
like
machine
learning
is
built
on
the
feedback.
Loop
has
also
quite
literally
guided
our
spaceships
to
space
and
Saturn
is
nothing
short
of
that
and
with
that
I'd
like
to
officially
conclude
our
Saturn
launch
I'd
like
to
invite
Marie
back
to
the
stage
for
questions.
B
C
A
C
A
The
the
idea
behind
the
penalties
is
not
that
you
will
slash
a
little
bit.
You
slash
time
five
times
the
average
reward,
and
so
you
could
implement
this
in
two
ways.
You
could
either
ask
for
a
collateral.
This
is
how
falcoin
does
it,
but
we
wanted
to
make
onboarding
new
nodes,
at
least
at
the
start,
as
smooth
as
possible
and
to
eliminate
as
much
barriers
as
possible.
So
the
way
we
are
doing
it
is
kind
of
adding
a
buffer
window.
So
at
the
start,
nodes
will
not
earn
any
rewards,
while
they
are
accumulating
enough.
A
Past
rewards
to
account
for
future
penalties
and
then,
once
that
buffer
is
built,
they
will
start
getting
paid,
and
so
so
what
what
we
expect
is
is
a
cheating
note,
will
get
flagged
and
so
we'll
never
reach
or
will
reach
very
unlikely
that
point
where
a
payment
would
would
be
made.
Of
course,
we
can
then
think
about
if
these
guys
being
flagged
all
the
time.
D
A
A
So
what
I
mean
by
these
is
if
the
client
would
be
happy
to
pay
for
that
self-dealing.
So
you
imagine
I'm
I'm,
I'm,
a
node
and
I'm
visiting
a
website
and
I'm
paying
for
visiting
that
website.
Then
that's
not
really
self-healing
right,
and
so
that's
what
I
mean
sorry.
It
was
a
bit
confusing.
They
didn't
answer
your
question.
Yeah,
okay,.
E
Sorry,
yeah
good
for
it.
I
I
have
a
I,
have
a
question
on
that
diagram.
You
had
the
retrieval
client
and
the
L1
node,
both
reporting
to
the
orchestrator
when
onscard
demoed
earlier
it
looked
like
he
was
using
curl.
How
does
the
actual
like?
How
does
the
retrieval
client
report
I
I?
Guess
if
you
have
a
service
worker
they
could
but
like
if
the
URL
is
available
without
it?
What
what
happens
might
be
a
question
for
Alaska.
F
F
H
A
Yeah,
so
it's
it
that's
an
interesting
point.
So
the
way
that
we
are
implementing
the
speed
performance
specifically
is
such
that
it's
so
it's
it's
sort
of
a
step
function
in
a
way.
So
what
this
means
is
we
have
a
sort
of
threshold
for
time
to
First,
byte
and
total
download
speed,
and
if
you
are
above
that
threshold
x
amount
of
times,
then
that
will
be
your
sort
of
performance,
your
your
final
metrics.
So
it's
how
many
times
you
are
above
that
minimum
and
threshold.
A
A
So
yeah
yeah
it
it
makes
sense.
But
what
I'm
trying
to
say
is
that
that
will
only
be
meaningful
to
you
as
another
operator,
if
that
will
be
a
big
part
of
your
traffic.
So
if
it's
just
one
request
in
a
million
it
will,
it
will
barely
change
your
your
the
percentage
of
times.
You
are
above
the
speed
performance
and
if
you
are
being
ddosed
like
that,
in
a
way
we
we
will
have
the
fraud
detection
system.
A
Yeah,
so
our
initial
idea,
it's
really
just
to
look
at
the
so
first
we'll
start
by
at
the
moment.
We
have
some
rules
in
place
and
first
is
looking
at
what
are
those
rules
flagging
and
is
this
like
true,
truly
fraud
or
not?
We
also
have
some
requests
that
are
being
no
being
done
by
trusted
nodes,
so
we
can
use
that
to
have
a
sense
of
the
false
positive
rate
and
so
we'll
get
some
labels
from
that
as
well.
A
C
What
are
your
thoughts
on
the
Privacy
properties
of
this
system?
As
far
as
I
understand,
the
orchestrator
gets
the
HTTP
access
log
from
from
the
L1
nodes
and
then
also
the
to
do
your
your
fraud
protection.
You
need
the
the
logs
from
the
retrieval
clients,
so
the
the
orchestrator
would
have
a
pretty
much
Universal
overview
of
what's
being
retrieved
in
the
network.
Apologize.
B
B
Yeah
I
mean
like
it
is.
It
is
a
setback
at
the
moment
but
like
because
the
orchestrator
does
see
everything
on
the
network,
but
we
try
to
implement
like
some
forms
of
privacy
like
as
Diego
was
saying,
with
like
double
hashing,
IPS
and
stuff
like
that.
But
it's
something
that
we're
working
towards.
Okay,.