Nano-payments on Ethereum

Transcript

[Music] hi my name is petuk I work at imop and I'm going to present you our approach to nanop payments in ethereum and how we believe they can be implemented uh by Nano payments we understand payments that are two orders of magnitude smaller than typical micro payments it's not a formal definition but we believe that typical micro payment is a payment under uh $10 uh we came across this problem when

we tried to implement uh parts of our project the Golem project which is a distributed superc computer in fact it's a distributed peer to Network where each node can participate both as a computer and as a task Center and each Noe uh taking part is computation should be able to receive payment uh eventually and uh this results in nanop payment because tasks can be split into uh pretty small uh pretty substantial amount for example single task can be split into up to 10,000 tasks where a cost of one task is below $1 we try to achieve task payments as small as 1 cent

for a simple simple sub task but we believe that we can approach even one cent of a scent uh to make it attractive to users we believe that cost of renting qu CPU core shouldn't exceed 5 cents on average per hour uh to make it even more attractive we believe that from the user perspective the setting should be that the transaction fees are below the 5% of the total task value uh framework should not require any Central Authority and trusted Authority everything should work inside the peer-to-peer Network Golem Network and in fact also an ethereum Network users Computing notes shouldn't be required to stay online at any

specific times for example due to changes in time zones they should be able nevertheless to get their payments at some point even if they're offline and ideally would like to skip any payments from users so that they don't have to pay up front any FS to start a computation We Believe also that nanop payments can be used in other scenarios for example paying for articles or for streaming content paying directly to artist or for likes on social media also you can donate something on forums and blogs for people who write something that you find useful but there are many more ideas uh why we believe etherum is the solution

well traditional payment systems are simply too costly and they require additional ISM trusted Central authorities we don't want to trust them well people wouldn't have to trust them because there are some Central Central and external authorities that work outside of the network additionally we have Bitcoin which up to some point can solve our problem but first of all it requires additional payments for D transactions additionally there are some penalty fees for many transactions in one block and you have to pay additionally for large blocks possibly we could overcome these

problems in Bitcoin network but we also believe that additional logic would be implemented in a contract attached to Golem which makes Bitcoin a bad choice and ethereum the right one so how the typical payment scenarios look like well we thought about them a bit we investigated all of them and it seems that external service would be the best solution because they would solve the problem to in simply but they require uh the external servers and additional Authority something which is of the network both Golem and ethereum and it is not feasible in our scenario bing up

to some point solves the problem but but it's not scalable well it direct transfer costs approximately 21,000 gas right now or even exactly and batching is two up to three times cheaper but that's that's it you cannot get any better with it U batching boils down to initiating all transaction just with one message in ethereum it's just a loop that sends uh value to all users very promising option is micro payment channels unfortunately this requires the setting when two parties cooperate together for a longer period of time and this is not the case in goem unfortunately and the last one

probabilistic payments described by vital in his on his blog uh seems very promising unfortunately it requires users to send large amount of Val value before starting the calculation and those deposits We Believe may not be acceptable by senders who simply would like to pay the predefined amount of money and be sure that that's enough to make the whole payment so how it looks in ethereum well with the gas price and it costs at the level presented on the slide it looks like this direct transfer cost 21,000 gas whereas batching cost

11,000 it's an improvement but it's not enough for a now no payments micro payment channel would work provided that we could establish a connection between two parties which we unfortunately cannot do when we take Golem uh into mind probabilistic payments would work unfortunately there is no fixed uh cost per user uh expected cost could be calculated but we're not going to do it here our minor minor improvement over batching is sub accounts sub accounts is a simple smart contract which establishes uh a mapping for between

addresses and values and sender transfers values sending a vector of data pairs of addresses and values and they accumulate in uh those accounts stored in the contract from time to time and users can cash out and we believe that on average it should cost cost 8,000 gas per user which give 5K for contract modification uh 2K gas for sending message to the contract and we believe that users should be able to boil down to 1,000 gas for cashing out this still is not a perfect solution it doesn't scale and that's why we come up with

came up with Lottery contract which supposedly solves all the problems and it in principle it looked like this task Center a person who broadcasted the task into Golem network uh sends of chain uh the description of the lottery to all receivers and additionally sends some data to the smart contract so that all receivers can verify that they are treated fairly and contract should be able to verify that some user uh has won the second step is drawing a random number I'll talk about the randomness Source later on we believe that we can provided that we can do it it's just a matter of running the

contract so that it pays the required amount to the winner and so that everyone can verify that indeed that person won um in Ideal World we would be able to draw a random number easily and in a very verifiable way and in that setting the algorithm would be pretty straightforward uh task Center would send very description to everyone in the colum Network so that everyone would be able to verify that it is fair and after that anyone could call a reward winner into the contract which would simply send uh the funds to to the winning node unfortunately we don't know how to do it

because there is no source of trusted source of Randomness but if we could uh draw a random line random number from some external source that can be checked later on on then sender would call start Lottery with Lottery ID Lottery ID Maps uniquely to to the description of the lottery and the ID of the task that was sent to the Golem Network and after the random number is generated someone maybe sender or the winner calls reward winner and just as before funds are transferred to the winning note unfortunately this is still invisible

and we have to come up with something else so we use as suggested by vitalic hases from future blocks an additional method determine winner can be called by anyone and that method stores a predefined hash of a predefined Blog future blog and after that the thing everything goes as before someone calls reward winner and the funds are transfer to the winning note uh the point is that reward winner can be called upon anyone determine winner is required to be called within some amount of time and there is an incentive uh for everyone to do it uh first off the paying Noe task cender pays some small additional

deposit and this deposit is returned if uh the sender calls the termine winner ear on if that note fails to call it anyone can call determine winner in the deposit is transferred to that note so there is an incentive to do it well what's more import what's important here is that winner certificate is uh pretty similar to what we had in sub accounts case it's a list of pairs uh notes addresses and values that correspond to each Noe and each value is proportional to the time that node oh well compute resources that note spent uh for the task or even subtask and this is are in number of

nodes we believe that it should be better and everyone knows what this structure is numerical tree can be used to Simply send logarithmic amount of data with regard to the number of participants uh the only change in the algorithm is that the winner certificate right now consists of triplets uh address a partial sum up to the point where the uh node is in a vector and its value so that it can be determined in a tree so when the path is set the lottery ID is changed to the H of the root of the tree concatenated

with Lotter ID we believe that we can do even better we can keep the cost of the whole Lottery constant but this setting requires some optimistic assumptions that prove the one that is sent in fifth step is sent only when necessary necessary meaning that someone was cheated someone was cheating so a winning note sends lottery winner message without any proof and stores a huge deposit which would be paid to other note if that sending note is a cheater after that

anyone participating in the network can send a proof and if the Tater is revealed then the not sending the proof gets the deposit and the winner gets gets the value gets the price uh we believe that 24 hours is just enough to make it fair the algorithm is pretty similar to the uh first implementation that is not optimistic but uses uh certificates right here we add three additional points in fact two lottery winner and lottery payout lottery winner is used to indicate that a note believes is a winner lottery payout can be called after 24 hours is no one vetos and reward winner is a veto which results in

revealing cheater and sending a deposit to the revealing note and sending prize to the winning note so one very important problem that we have to deal with is how to Generate random value well generating values random values by Future blocks is not a perfect method because it's um prone to minus fraud and at the point of this presentation only 25 and 56 blocks can be well hashes of blocks are available to the contract so within 25 2000 and 56 blocks a block

hash has to be stored in a contract because later on it cannot be verified if that doesn't happen then the next batch of 25 2256 blocks is used and another hash is used it's fair but it changes the winner so it's an incentive to everyone to get that has from the first 256 blocks well so far we don't know any better solution but we're aware of approaches that can in future uh replace our approach run our contracts and alarm clock if when stable and well welld developed may be a better approach to

this problem and may solve it easily we don't know right now there are not very reliable and well more expensive than our approach simply so with know that they exist we know that they can be used but we have to wait until they get a bit more mature so the cost comparison between presented methods like here is like this Bing and sub accounts gross linearly with the number of users Lottery check as you can see gross uh logarithmically lottery winner is a constant cost and for less than 256 users Lottery check is cheaper than Lottery

winner which makes it a preferable method in our setting as you can see for 100 users cost is 6 to7 times higher than for lottery Bing and sub accounts and for 1,000 users it's two ERS of magnitude more expensive which makes it unusable in our setting uh what might be interesting for a user who takes part in a probabilistic setting is how long would well a user would have to wait for the first pay payment and it seems that the probability of not getting a payment during first and number of lotteries drops to zero pretty quickly which means that it goes Rises to one pretty quickly probability of getting a payment Rises Qui quickly to

one what's even more interesting is what's the chance of getting some predefined amount of expected income after a number of lotteries well using a simplified approach with binomial cumulative distribution uh we can show that this is this grows to one with the number of lotteries the way it's presented on this graph and it's pretty convincing that it should work and it should be convincing to users to take part take part in lotteries thank you very much if you have any question please don't hesitate to contact us