►
Description
Livepeer is a decentralized video streaming infrastructure project.
Eric Tang, CTO of Livepeer, gave a presentation entitled "Designing The Livepeer Protocol" at Graph Day in San Francisco on January 25th, 2019. In this talk, Eric discusses technical details of the Livepeer Protocol.
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
Sections
0:00 Intro
0:26 What is Livepeer?
1:14 How Does it Work?
3:26 Decentralized Networks
5:12 Streamflow
8:04 Probablistic Micropayment
#web3 #livepeer #ethereum
A
So
my
name
is
Eric
tang
and
I.
Am
the
co-founder
and
CTO
of
live
secure
before
I
get
into
my
talk
today?
I
just
want
to
see
a
show
of
hands
of
who,
in
the
audience
has
heard
of
live
pure
or
know
what
life
gear
does
alright
about
half?
Okay,
so
that
that's
good
information
for
me
to
have
so
life
here
is
a
decentralized
video,
streaming
infrastructure
project
and
even
though
the
project
itself
is
really
on
the
infrastructure
level,
people
have,
in
the
past
few
years
have
built
some
interesting
applications
on
top
of
it
right.
A
Currently,
the
most
popular
use
case
for
life
here
is
event
streaming.
So
what
we
see
here
are
some
examples
of
people
streaming.
You
know
concerts
events
around
etherium
and
decentralisation,
for
example,
last
year
during
the
during
Def
Con
in
Prague,
most
of
the
tech,
technical
tracks
or
streamed
on
live
fear
to
to
to
audience
around
the
world.
A
So
at
the
core
live
pure
is
a
decentralized
network
that
processes
video
to
understand
how
kind
of
life
here
works
on
a
high
level,
we
have
to
sort
of
take
a
step
back
and
look
at
how
video
works
on
the
Internet.
So
video
on
the
Internet
today
covers
80%
of
all
the
traffic,
and
that
is
a
huge
amount
of
bandwidth
being
used
a
huge
amount
of
data
being
delivered
of
that
80%
of
all
the
traffic.
A
The
vast
majority
of
the
video
has
to
go
through
this
process
called
transcoding,
and
what
that
means
is
the
original
video
needs
to
be
transcoded
in
two
different
formats
and
bit
rates
in
order
to
be
delivered
to
any
device
at
any
network
condition
around
the
world,
and
this
is
a
bottleneck
in
the
entire
video
workflow,
because
the
operation
of
transcoding
is
a
very
expensive
computationally
expensive
process.
Currently,
it
costs
around
$3
per
prestream
to
transcode
a
video
Amazon.
A
So
so
the
traditional
workflow
goes,
like
the
broadcaster
sends
a
video
into
a
transcoding
cloud,
hosted
on
Amazon
or
wowser,
or
some
of
these
SAS
services,
if
they
transfer
the
video
and
then
send
the
video
to
a
content
delivery
network
that
then
gets
delivered
to
their
client
viewers
around
the
world.
How
live
care
changes
this
equation
is
that
it
plugs
into
the
workflow
very
seamlessly
and
instead
of
using
a
cloud
hosted
service
to
transcode
your
video,
you
use
the
decentralized
network
to
do
the
same
thing
now.
A
But
the
central
but
decentralized
networks
can
also
be
applied
to
you
know
many
different
verticals
right.
They
can
be
applied
to
supply
chains
for
us
to
track
products
across
the
chain.
They
can
be
applied
to
finance
use
cases
like
we
talked
about
before,
and
they
can
be
applied
to
create
different
new
internet
infrastructures
that
can
really
power
not
only
decentralized
applications
but
also
current
applications
that
people
are
already
using
that
and
have
millions
and
millions
of
users.
A
Of
course,
we
have
this
one
bottleneck
currently
and
that's
the
scale
blockchains
are
known
for
having
just
not
having
enough
scale
and,
as
a
result,
a
lot
of
our
current
decentralized
protocols
are
stuck
in
a
prototype
and
beta
phase,
because
we
simply
cannot
serve
the
millions
of
users
that
who
want
to
use
them
who
wants
to
use
the
network.
So
since
life
here
has
launched
only
here
in
Maine
that
in
May
last
year,
the
team
has
really
been
focused
on
working
on
research
and
engineering
to
bypass
all
of
these
scalability
challenges.
A
And
a
few
months
ago,
we
released
a
new
wipe,
a
new
improvement
proposal
for
the
life
year
protocol
that
we
codenamed
stream
flow.
Now,
the
in
the
the
whole
purpose
of
stream
flow
is
to
introduce
more
scalability
into
the
life,
your
network,
so
that
the
network
can
be
deployed
and
handle
real
live
video
applications
that
millions
of
users
can
use.
Our
goal
is
to
have
tens
and
thousands
of
concurrent
video
streams
going
through
the
networks
at
the
same
time
and
have
that
to
be
ten
times
cheaper
than
would
current
cloud
services
services
can
provide.
A
So
we
have
will
have
these
four
core
tenants.
Affordability
is
really
important
because
video
again
it's
one
of
those
Kate
one
of
the
use
cases
that
that
can
really
benefit
from
people
sharing
their
resources.
In
fact,
in
stream
flow
streamers
we'll
be
able
to
tap
into
the
current
cryptocurrency
mining
industry.
A
A
A
Today,
I
want
to
dig
in
and
talk
a
little
bit
about
the
payment
mechanism
that
we've
been
working
on
called
probabilistic
micro
payment.
The
reason
I
want
to
dig
into
here
is
because
I
think
the
payment
mechanism
is
something
that
unlocks
all
the
other
opportunities,
because
until
we
have
reliable
and
scalable
payments
service,
service
providers
will
not
be
able
to
get
paid
and
nothing.
Nothing
will
ever
work
as
soon
as
we
have
a
really
good
payment
mechanism,
we
can.
We
can
work
on
all
the
other
types
of
optimizations
to
make
the
network
work
really
well.
A
A
That
kind
of
reignited
the
discussion
in
the
etherium
ecosystem
about
this,
and
also
want
to
credit,
London,
foo
and
dark
annex
for
doing
a
lot
of
the
research
for
the
live,
pure
version
of
probability
of
micro
payment.
So
this
works.
Let's
take
a
simple
example:
right:
Alice
wants
to
pay
Bob
using
aetherium.
What
Alice
has
to
do
is
to
write
a
transaction
onto
the
etherion,
blockchain,
well
notice
and
Alice
has
to
pay
for
transaction
fee.
Now.
A
If
Alice
wants
to
pay
about
twice,
Alice
has
to
run
two
transactions
and
of
course
this
does
not
scale,
because
we
have
millions
of
Bob's
analysis
around
the
world
and,
if
they're
all
trying
to
pay
each
other
at
the
same
time.
No,
but
we
will
have
too
many
transactions
and
the
and
the
network
will
be
blocked,
and
you
know
no
one's
transactions
will
go
through.
A
But
let's
take
a
look
at
how
this
will
work
in
the
real
world
right
if
Bob
is
providing
a
service
and
both
Alice
and
Eve
wants
to
use
Bob's
service
Bob
has
to
open
two
two
channels,
one
with
Alice
and
one
with
Eve.
Now,
if
there
are
thousands
of
people
who
want
to
use
Bob's
service,
Bob
has
to
open
thousands
of
strands
of
channels
and
of
course
we
get
back
to
the
same
scalability
challenge.
Bob
cannot
cannot
afford
to
incur
this
cost
just
to
even
start
providing
the
service
for
everybody.
A
So
you
know
people
came
up
with
another
mechanism
called
payment
channel
networks
where,
instead
of
everybody,
have
to
create
a
direct
payment
channel
with
each
other,
they
create
they
each
create
a
channel
with
a
node
on
a
network
and
expect
the
nodes
on
a
network
to
be
able
to
figure
out
how
to
route
their
payments
to
one
another.
Now,
of
course,
this
sounds
very
great
in
theory,
but
it
introduces
a
lot
of
complexity
right.
How
how
do
these
payments
get
routed
through
the
network?
Is
there
incentives
in
the
in
the
network
routing
these
payments?
A
What
if
Alice's
transaction,
gets
routed
in
different
ways
and
it
gets
rowdy
in
the
circle?
Does
that
mean
Alice
ends
up
paying
a
lot
of
transaction?
Whose
fault
is
this?
What
if
what
if
one
of
the
node
is
faulty
and
they
go
down
right
and
as
a
result,
we
haven't
yet
seen
a
really
great
payment
network
that
actually
work
in
the
real
world.
Today,
even
though
a
lot
of
a
lot
of
teams
are
working
on
really
interesting
solutions.
So
what
do
you
for
Tait?
A
What
if
we
take,
take
away
all
that
and
and
take
a
look
at
this
mechanism
from
a
different
angle
right?
Imagine
in
the
probable
list
of
micro
payment
world
Alice
when
Alice
wants
to
pay
Bob
only
Alice
has
to
write
a
transaction
on
chain
to
put
down
a
deposit,
and
as
soon
as
that
happens,
she
can
ask
Bob
for
random
number
and
Bob
would
generate
a
random
number,
but
instead
of
giving
that
random
number
to
Alice
Bob
gives
the
hash
of
the
random
number
to
Alice
and
as
soon
Alice
as
soon
as
Alice
gets.
A
This
piece
of
information
Alice
can
start
sending
transactions
to
Bob
and
these
trendies
transactions
we
call
them
tickets
and
the
reason
they're
probabilistic
is
because
not
every
ticket
will
actually
represent
a
transaction.
There
will
be,
there
will
be
a
winning
ticket.
So
if
we
look
at
the
information,
that's
included
in
this
ticket,
it
includes
Bob's
address.
A
All
he
has
to
do
is
to
hash
the
ticket
itself
with
the
random
number
that
he
has
kept
secret
before
and
if
this
hash
is
less
than
the
winning
probability.
That
he
got
from
Alice,
then
this
is
a
winning
ticket
and
he
can
get
he
can
use.
The
cryptographic
prove
that
he
got
from
Alice
to
claim
this
on
chain
now.
A
This
is
interesting
because
we're
kind
of
we're
kind
of
squishing
all
the
transactions
into
one
single
transaction
and
then
Bob
can
just
take
this
on
chain,
and
another
interesting
thing
is
that
Bob
here
can
has
total
control
of
how
much
overhead
he
wants
to.
He
owns
the
pay
right,
so
imagine,
Bob
Bob
is
a
transcoder
on
the
live
peer
network
and
every
every
video
segment
cost
a
penny
to
transit
to
process.
A
Bob
can
can
say:
I
want
to
I
want
to
have
a
$1
ticket
when
I'm
claiming
but
I
want
to
I
want
to
have
a
won
one
out
of
a
hundred
winning
winning
chance
that
that
means
for
for
Bob
to
get
a
winning
ticket.
He
has
to
get
a
hundred
tickets
and
each
ticket
is
worth
a
penny,
but
at
the
same
time
he
can
also
say
you
know
what
I
wonder:
I
want
the
winning
ticket
to
be
$10
and
I
want.
The
winning
percentage
should
be
one
out
of
a
thousand
in
this
way.
A
Bob
only
has
to
incur
the
the
transaction
cost
every
1000
tickets,
and-
and
he
can
he
can-
he
can
set
that
number
to
be.
However,
he
wants-
and
another
interesting
thing
here
is
that
Bob
can
keep
the
ticket
and
and
claim
it
at
a
later
time.
Maybe
right
now
there's
a
gas
hike
on
the
etherium
network.
He
can
just
say:
I
will
wait
for
the
gas
price
to
come
down
and
then
claim
this
ticket.
A
So
we've
been
working
on
this
for
a
while
and
been
running
some
experiments
on
our
test
test
network
and
some
of
the
benefits
that
we
got
is
that
it's
a
very
easy
way
for
us
to
scale
to
thousands
of
transactions
per
node
on
each
life
year.
Transporting
node
and
each
in
each
of
those
nodes
can
easily
control
their
their
transaction
overhead.
A
We
set
it
to
be
less
than
5%
and
that's
a
very
conservative
estimate,
and
then,
if
each
payer
has
almost
zero
percent
cost
overhead,
because
all
they
have
to
do
is
create
one
deposit
on
chain
and
that's
it
and
they
can
start
paying
whoever
they
want.
However,
many
times
they
want,
and
the
important
thing
is
here:
there's
no
intermediary:
this
is
a
direct
action
between
the
payer
and
the
payee
they
don't
have
to.
They
don't
have
to
rely
on
a
third-party
service
and
or
in
the
different
network,
for
their
payments
to
go
through.
A
But
there
are
plenty
of
use
cases
on
aetherium
or
in
the
blockchain
in
general,
where
a
service
is
being
provided
on
a
continuous
way
and
the
and
the
service
user
has
to
continuously
pay
for
these
services.
So
if
we've,
of
course,
with
being
a
being
an
open
source
project,
everything
we
do
is
open
source.
So
we
have
created
these
aetherium
smart
contracts
and
right
now
we're
we're
ready
to
start
collaborating
with
the
ecosystem.
So
I
really
invite
everyone
in
this
room
to
come
and
check
it
out.