Scaling Many to Many Payments with Probabilistic Micropayments by Doug Petkanics, Yondon Fu

[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]