[Applause]
yes you'd be fine but but the the mic
would be Lauren look thank you everyone
for joining this talk and duck mechanics
I'm the founder of a project called live
here live video streaming infrastructure
project built on interior this is my
colleague youngin who works with us on
protocol design research implementation
we're giving a talk today about scaling
payments on etherium using a protocol
called probabilistic micro payments and
the reason that we chose to be into this
protocol and implemented and tested is
because it's actually a scaling solution
for micro payments that works today on
ethereum without requiring any layer two
solution or any reliance on a trusted
third party like a hub so for many use
cases it's really compelling really
powerful there allows you to send micro
payments look around to many receivers
without a lot of overhead and without
exposure to gas price fluctuations in
the area so I think it's pretty
interesting so what are PMS I like to
think of it as paying for services or
content with lottery tickets and a
traditional kind of micro payment
solution the mental model that people
have is well you lock some value on
chain and so does another party and then
you send payments I kind of
cent signatures around option between
these two parties and they keep track of
the balance and then when someone's
ready to leave and cash out and take
their payment they submit the proof
unchain and leave and kind of close the
closure channel so it probabilistic
micro payments or you're paying fiery
tickets it's a totally different mental
model it's thinking if you are going to
be paying someone or people what you do
is you run a continuous lottery and
everyone who you're paying your decision
lottery tickets to the playing the
lottery against you and eventually some
of those tickets become winners and the
recipients get to cash in the winning
tickets on unit to receive their their
payments so this colloquy in a kind of
good overview of PM's and scalable
payment requirements talked about other
men we're going to compare it to payment
channels we'll talk about the security
models and how you secure these systems
he has double spends and finally we'll
give a quick look into our
implementation some benchmarks that
we've seen running this and point to the
open source code cool okay so there's a
measure the model here is a sender needs
to send some value to a recipient in
exchange for some service or some
content so you could think of it as if
you're streaming music you might want to
be sending a pan in every couple of
seconds to the person who's providing
music in our case in my view you're
encoding video and you're paying the
fly so as I mentioned instead of sending
an actual value doing either transfer
what you do is you send to this kind off
chain lottery ticket to the recipient
and the recipient checks to see if the
ticket is a winner and if it's not a
winner
they just discard the ticket it's worth
zero
they went to cash it in on Channel and
this is kind of the default case this
happens most of the time but when they
get a ticket the ticket may be a winner
and it's a winner it's worth if and in
this case they just catch that ticket in
on Chan to redeem their winnings and the
kind of interesting thing the way this
works is if you think it's a lottery a
lottery ticket has an expected value you
know that if you win the jackpot
you know in the real world lottery it's
going to be 100 million dollars but you
know the odds of winning the jackpot are
say you know one in a hundred million
and therefore you can calculate all the
expected value of this ticket is $1 so
here with probabilistic micropayments it
works the same way the ticket in this
case as a face value of 1/8 doing
probability could be set to one in a
thousand and so the recipient knows well
this is worth a thousand seventeen and
they're willing to do as much work as
they want to do
I mean or provide as much content that
would provide for a thousandth of it
even and the second example
it as a different face value teni and we
probability of one in 10,000 but the
expected value of the ticket is the same
it's one thousandth of any and what's
powerful about this kind of mechanic is
that because a recipient can tell us
under what they want these parameters to
be they can actually control kind of the
overhead that they have to pay in order
to cash these tickets in a routine them
on the blockchain and so what that means
is if gas prices are really low you
could say oh I'm willing to accept one
Eve its value tickets or even less
because I can cash them in it doesn't
cost me a lot but when gas prices rise
you can say well I don't want to be
doing a lot of transactions to cash in
these tickets I'm going to change the
parameters around cash them in less than
frequently and still earn the same
amount of value that I expected to earn
so what's cool is it lets you control
how much overhead you have in cashing in
tickets because I'm never going to pay
more than one percent of my earnings to
use the blockchain to cash in tickets
and you had to control that regardless
of where at their gas prices go that's
pretty powerful that 1% example is just
the number I made up but if you think of
accepting a credit card for example as a
merchant usually paying you know three
three percent less 30 cents per
transaction so we can do much better on
the blockchain with micro vanna's cool
so in summary you guys are just opinion
you can charge what you want you can
adjust today's values to kind of remove
any reliance on gas and congestion
network and overtime you earn exactly
kind of what you wanted to earn with the
high probability one of the interesting
mental models that here you're not
guaranteed to get the exact amount of
payment for the service you provided but
over a long period of time due to kind
of a lot of large numbers and
probabilities the amount you earn the
amount you pay will be very close to you
know what was intended so that's the
that's the model so brief acknowledgment
to this is not something we invented it
by Pierre Ron Rivest of RSA Fame
actually proposed this back in 1996
number of people have proposed it at
Bitcoin the orchid protocol proposed
this a couple years on etherium I think
we've done the first open source
implementation that people could use
that's running today but you know this
is a idea that's been around for a while
as peruse there so it's worth asking the
question now rpm is a good solution for
micro payments until everyone looking at
what are the requirements for good
payment solution so first of all they're
low latency you can send these payments
around very quickly it's all a chain you
never need to go to the blockchain to
check if but you need to submit a
transaction to the blockchain in order
to pay someone it allows you to switch
recipients seamlessly so you can send a
payment to multiple providers one at a
time or pay them simultaneously all at
the same time you don't need to go on a
chain to add a new recipient so for
example in my dear you're encoding video
on this network and
hundreds or thousands of people who can
enter a video for you you don't need to
go on into the blockchain to open a
channel with each of them you can just
start sending payments to them as they
come available and finally this one's
also really important there's no
expectation that you have to have a long
lived relationship with the recipient or
that you have to sometime a live value
for it to be worth it
in payment channels for example if you
never closed a channel with one user if
you were only going to be cashing out
you know
five cents worth of value because the
transaction cost would be too high where
is it micro payments you don't have to
assume that you're going to be earning
five cents 10 cents a dollar hundred
dollars a thousand dollars you can just
you know the expected value of a ticket
if it wins it's always worth whatever
face value you moderate it to be to make
it worth your while
so those really nice property so
probabilistic micro payments support all
of these properties which makes a really
nice food for streaming data use cases
next up what I want I just have already
on did so you can compare probabilistic
micropayments to traditional payment
channels like we've heard a lot about
this conference this week alright so
before we talk a little bit more about
the security model for all the state
micropayments is where it's doing a
comparison with some common
constructions that are used in the
national space so before in order to do
this comparison you actually need to
highlight specific characteristics of
their character construction so there's
different types
Peyman channel instructions ranging from
individual vanilla channels to more
complex network channels that solve some
of the problems that are present in
individual channels and then even within
that category you have different types
of routing you have h TLC based routing
and you also have virtual channel based
routing and on top of that you can also
distinguish between different types of
network topology so you might have a
multi hot type network or you might have
a hub-and-spoke type network the full
details of these types of constructions
are kind of out of the scope of this
presentation but there's a lot of good
presentations at this conference that go
into more detail so for the comparison
for individual image channels we can see
that the two main cons of using just
vanilla payment channels are around
additional launching setup involved with
each counterparty that you want to work
with so in a network where you might
have open entry and exit into the
recipient set you would prefer not to
have to incur an on change setup cost
that rises linearly with the number of
new recipients packages of this set and
as it's mentioned previously there is
the possibility of dust being in your
channel balance so if you have a small
amount in your channel such that it is
considered dust and the launching
transaction cost is going to exceed the
cost of actually withdrawing that dust
from that channel and it's not
be worth it so in that case you actually
have some minimum value transacted
requirement where it's not worth it
below that amount so with hdl-c
multi-hop channels this is the paradigm
that you might find in a network like
Bitcoin lightning so here I have a
question mark next to low latency mainly
because in the happy case it definitely
is low latency if your payment can be
relayed across multiple intermediaries
without any delays but if there's any
delay in the revelation of the hash used
in the HPLC then there's the potential
for that to be slowed down so the longer
the path the higher the risk of slowing
down the payment flow is in addition to
that we also still have minimum value
transacted requirements so if you have
dust in your channel then you can
actually use this hdl-c mechanism in
action to trustus leak through your
payment so in that case the on J
transaction costs are closing the
channel on chain might actually exceed
the dust in that regard our channel and
lastly there's this bonus column here
this is a there's a spot is right here
which is minimal third party
infrastructure dependence this isn't a
strict requirement but it would be nice
if you can accomplish direct
peer-to-peer payments without
infrastructure and a network like
lightning you need two reliable real air
notes which might be okay but a
nice-to-have is if you didn't need to do
that the second construction that's
worth talking about is virtual channel
hub-and-spoke
type networks so the general idea here
is that rather than using HDL C's to
connect different payment channels
across the network you have a hub
sitting in the middle all parties
connect to and they block off funds to
be used in these virtual channels that
are connecting to counterparty so as
long as you have funds with the hub and
as long as the hub has funds with
another counterparty you can create a
direct channel between those two parties
and the hub just needs to have adequate
amount of funds in order to block those
off to be used in that channel but
similarly there is still the possibility
of dust accumulating in the channel so
you can imagine a scenario where you
have multiple channels connected with
the same counterparty but if you end up
in a scenario where your counterparty
goes offline or is unresponsive in order
to gather the dust in those channels
you're going to end up needing to
actions for each of the channels so in
that case a solution to this would just
to be half of it just to have a minimum
value transacted requirement which is
something that we're curious if we can
go without and similarly we rely on the
hub in this case so there is their party
data structure depends so in summary I
think some of the advantages of public
micro payments to payment channels is
the no minimum value transacted
requirement and then also that no third
party and construction dependents but
there are disadvantages as well so they
do exit lottery technics is something
that you need to deal with you might not
have an application that can't deal with
that do X in an adequate way and it only
works in high volume use cases so if
you're not sending a lot of tickets for
a lot of small chunks of service and it
might not work out for you because you
can never rely on the law of large
numbers for the payments to be fair in
the long term and something that I'll
talk about a little bit is you might
have higher personal collateral
requirements as well because you can't
rely on a third party to provide equity
for you so moving on to the security
model there's different aspects into
this but I'll focus on two particular
components so the first one is the
winning ticket selection protocol so
this is really important because if you
don't have a fair winning ticket
selection protocol then if someone can
influence which tickets win then this
isn't going to be a fair payment scheme
so this is just one way to do it there's
multiple different ways that you can
achieve this fair selection protocol and
the way that we do it is via this
command reveal scheme and the command
reveal scheme basically has the
recipient defined a hash of random
number data keeps secret and the sender
includes a monotonically increasing
sender nuts and it maintains a separate
counter for each of these hashes and the
idea is that the ticket will win if we
have these two random numbers thing
where we hash the recipients random
number and then we use the signature
over the ticket as the random number for
the sender and the idea behind the
sender nots
is that we need something that makes the
hasha to take it unique such that once
you produce a signature or that hash
it's unpredictable to the recipient and
then if that hash number is below the
winning probability that we consider the
ticket opener so the basic idea here is
that the recipient should not be able to
manipulate selection as long as it
cannot predict the signature that the
sender's gonna produce over the ticket
hash and then the sender should not be
able to manipulate selection as long as
it does not know the secret number that
the recipient has generated so the only
thing that recipient repeat we're
dealing here is the hash of that number
it's important to note that the
recipient also needs to defend itself
against replay attacks so it should
never accept the ticket if it's using a
hash such that that poppy image has
already been revealed because then you
know the secret number and it should
also not accepting its width and already
used nots so if it's using and already
use nots then the person already knows
that it's not going to produce a winning
ticket so you want to make sure that you
defend yourself against those types of
attacks as well and the on chain
contract makes sure to record the use
tickets to prevent replace so we want to
make sure that you can't redeem a
waiting to get more than once the second
problem that's worth highlighting is
double Spence so in the past literature
the most common naive protocol is using
a single launching deposit but the
problem here is that a malicious sender
can't send multiple tickets to multiple
providers and if they all win you might
not have enough
your deposit to fund all those many
tickets so the classic double spent
problem and this is just an illustration
of this where we have three recipients
they all receive winning tickets with a
face value of five but the on to deposit
only has five ether in it and we can see
that it's fine for the first redemption
that a second their redemptions are
happy to be able to clear because
there's not enough funds so the idea as
you solve this is setting a collateral
apartment that is greater than or equal
to that maximum utility or double
spending so when I only used in other
types of protocol is washing the
collateral but instead we can have the
recipients claim from a reserve that
guarantees the recipients up to a
predefined amount I'm gonna skip over
this because we're running a little low
on time but the general idea is that the
reserve basically presents a maximum
allocation committed to each recipient
and as a result we can keep track of a
float for the senator where the float is
money that the payee receives but due to
processing delays it's still accounted
for both recipient and sender balances
and as a recipient receives winning
ticket it's gonna increase its flow as
it observes on chain successful
redemptions
is going to decrease the flow and the
max flow is essentially the reserve
allocation that you provide a recipient
from the reserve you've defined the MA
chain so I'm just through this but this
basically demonstrates the simplest flow
with a single reserve
to a similar recipient but the last
question we need to solve is how do you
actually bound the ability from double
spending so the way that we do this is
that we commit each Reserve to a
well-defined recipient set and in the
light of your protocol we can actually
take advantage of an existing provider
set rotation process so each round or
time we talk we have a specific set of
providers and we just commit the reserve
to that particular set of providers and
then we split the reserve into equal
size allocations committed to each
member of the set so we can see here
that in round one we split it three ways
because there's three recipients in
round two we have new recipients so we
increase the we decrease the allocation
for each because there's more recipients
and similarly when we recipients exit we
have to split it two ways because now
there's two recipients instead of four
and that's reflected in the reserve
allocation that's committed to each
recipient so in summary this helps us
avoid additional on champions actions to
update recipients a commitment some of
the downsides are that you can't update
the allocation for each particular
recipient so if you want to allocate
more it's about the clitoris again you
can and then also this will likely
increase the reserve requirement overall
as the number of recipients increase
because some recipients might
allocation but some of this may be able
to be solved with alternate
constructions that and probably talk
about after the presentation and with
that I'm going to pass it back over to
Doug to talk about network sense and
there was a source of indecision
thanks John and say I'll just wrap up in
the last minute as I mentioned my peers
p2p live-streaming infrastructure and so
we use these micro payments to send to
infrastructure operators on the network
coding video and running on the you know
we've been violent in debt with NASA
that doesn't use this mechanic we've
been using this mechanic intestines
about to go a lot of short they I bet
you're some graphs from our tests that
that it's a little small but basically
everything's going up into the right
which is usually good there's no number
two it's N and belly cent increase in
tickets redeemed and value indeed
received increasing and then in the
yellow
it's kind of winning tickets and valuing
team gone chain and the kind of the key
takeaway to the key benchmark is that
we've fluctuated gas prices in
simulation to how they fluctuate is a
maintenance and we've observed that the
recipients you know the software will
automatically update their ticket
parameters to ensure that wherever gas
prices go
they never have more than one of the 1%
overhead for cashing in on chance
$3,100 and everything more than $1 in
order to cash the tickets a knot chin
and that's just a target that we picked
but we think that that's acceptable
relative to a kind of traditional
mechanics in the blockchain so working
well yeah open-source implementation
will share these links out on Twitter
after the talk black beard or go get a
specification smart contract
implementation solidity and client
implementation in go length this is able
to be used for general use their cross
program projects in the ecosystem it
means a little bit of work to separate
out some of the library specific
implementation details around these
global recipients assumptions but it's
not far off surrounded to collaborate
with people who want to use this make
development for the whole ecosystem so
thank you very much for attending the
talk I said live here dot work and we're
around the conference all week
[Applause]