DAPPCON 2018: Scalable Onchain Reward Distribution - Bogdan Batog

Transcript

so my name is Bogdan I've been a software engineer for 12 years and I want to talk about scalable unchanged the word distributions or dividends [Music] note that this has been my independent work it's not linked to any company and it's a contribution to the community that I want to make so this is the summary of what I'm gonna talk about I'm gonna go over the need of dividends or reword proportionality words that we want to do on chain common applications then go over what I see as current then

I'm gonna talk about my new work that's basically named pool based scalable rewards on chain see how that goes with et reham and touching a few technical challenges so we probably believe that many assets are gonna be tokenized in the future and with them we're gonna see as well assets that are producing rent or yield and this yield or rent has to be distributed back to the total holders so there are plenty of use cases from regular dividends like for example if a company is gonna be tokenized and the

shares of it are gonna be tokens then every actual dividend will have to be distributed to the token holders if we look in the blockchain space or a lot of other cases where you actually need this technical solution to distribute rewards proportionally to each owner share my nipples taking posts you can even think of tokenizing individual items physical items like an apartment so so from my analysis so far it looks like many of the large projects

in the blockchain space haven't actually figured out how to do this effectively and efficiently so most of them are actually triggering a payment for each individual recipient so this is done often basically there's a centralized computer server the ask to trigger those payments or if its own chain it can't actually iterate over all all the recipients when you have many of them mostly because of gas limits so current approaches from what I've researched are rather obtained or are not scalable so

instead of pushing rewards to all the recipients why not we do pool based system so basically we just allocate them their share and then they can claim it later on at any moment so if this is well done this is properly implemented it brings us even new use cases that we can put in practice so the basic idea behind it is that you only do the allocation and it's fully implemented in the smart contract and then you let them claim the rewards later on here I'm just

gonna go over a very simple case so just to give a hint of how this works so for example imagine you have an ERG 20 token and all the balances are frozen nobody can change anything so then you want to distribute I know let's say 100 meter to everyone proportionally you don't actually have to do anything you just remember hey this is the hundred eater here and whenever someone wants to claim their share we just compute their share and send them over so this is very simple but then if you want to distribute in a second step a thousand dieter if no one

claims you've no unclaimed their share so far also you don't have to do anything you just have to add the first 100 to the the 1000 in a second step so now you have one hundred and one thousand and whenever someone wants to claim it claim claim their share you just have to compute their share of this total so this is the very simple thing but it can be made practical to work even if account balances changes and even if you do successive distribution as often as you want like and it works in constant time this means there's no

iteration involved at any of these steps you just update some tricky internal accounting stage this has benefits on the network as well so on one hand so for example as one friend mentioned has been the network has been overloaded with transactions from airdrops this is basically one actor flooding the network with a huge number of transactions that are essentially just replicating a state of one token to another one so this has two issues one

the network is is flooded gas prices increases and it makes the network in entirely I mean in its entirety less reliable for all the participants instead if you'd rather do pool bass viewers not push them the actual transactions are more spreaded over time and you don't get this downsides of gas cost increase in christian also yeah the gas cost is actually transferred on on the recipient side because they have to claim it so when they trigger the transaction they will have to pay for the transaction so because this

algorithm doesn't actually iterate over any list of recipients or history of balances or anything actually it actually works with very fine time granularity it can send zonal dividends right and whatever can be dispatched daily or even per hour or actually this is just a plain smart contract call so it can even go as frequent as every mind block that might not be necessarily useful but I know daily may may really be useful in all of applications so if you decide to do this use case where you

for example instead of paying salaries once a month you paid daily or hourly it's enough to to trigger a single transaction a single smart contract call every day or every hour and then the salaries of all employees are updated in the internal state of a contract then they have to later on trigger their own claim to actually get it so this is described in a paper I've been working with on it's public you can see the interaction and Matt is not that sophisticated but so yeah I can find it here online

but it has some interesting [Music] implementation that are not necessarily covered there so I'm gonna go over them quickly in the next few slides but before that one more comment so this works with what we have right now on a theorem so there's no need of a second layer scaling or whatever you can do dividends to millions of token holders fully on chain no need of an external server and it's really not that expensive in terms of gas so back to the theorem basically we're dealing with two

parts of this system or you have a stake in in an asset or in a investment fund or in anything actually that can be represented by a token and then you have very word or or a dividend or yield or a rent or or a return those two can be looked at on a theorem as either an ether or on the RC 20 token and all four combinations actually are more real useful and the the apply to common cases that we we see in the space so let's let

let's look at them the first one imagine you have your stake is either so basically what you do you just send it to a smart contract address and then this smart contract tracks all the senders and now that you own a share of it then it can basically be used as an investment fund so this investment fund is doing something with ether then it has a return then can send the return back to all to all the funders and this can be very scalable I mean it can work with million of token holders and it can send the return back every

hour so same thing the return back is basically an allocation step but then you as an individual token holder you need to claim your reward back with the transaction that you you trigger so it's all either the second case steak is eater and your word is an ER C 20 talker this is actually a very interesting way to do an IC o---- that is probably I know I it's the first time I come up with this one in a discussion with my friend and co-author of the paper

so this basically imitate the way Bitcoin was distributed to to the miners so you can have a curve of issuance of your tokens over a month or over a year and then at any moment people just send F either to your smart contract address and they are provided with a share of the entire mining capacity mining coated so basically you issue token every day every hour over a longer time and at any moment someone can just capture a fraction of this issuance it's more to discuss about it but I'm

gonna move on then there's this last know if stake is any RC 20 token and the word is eater this is also an interesting application so you imagine for example if create crypto kiddies had a security token so you could buy a share of the crypto Kitty's company let's say then it's actually very feasible to do to distribute a fraction of the revenue they have from each key resale to all the token holders bullion chain without their - just regularly TV them as we have it right now and the first

case you can imagine that both taking every word are here see 20 tokens so we can have basically two years - 20 tokens contracts one acts as a security token one acts as a utility token and you can directly have a revenue-sharing implemented in inside those two years - 20 tokens so stakeholders the holders of the security token can receive a fraction of all the eco-system transactions that are made in the utility token this is actually the one I

implemented as a contract work for for an upcoming guysyou there are a few interesting things to discuss on a technical level as well so for example you have to account to very small units like every single VAE that's the smallest subdivision of an inter has to actually be distributed to someone there's you you can't lose the single day in this process so on certain circumstances this may actually be come a possibility for a front-running attack but it's it's really very marginal last

point I will do I'll make is that given this algorithm is properly implemented it can actually be become an extension of an ER C 20 token with the dividends distribution layer inside it so the simplest case let's say you have an ER c 20 and you just send eater to this here's a granny contract and you want this ether to be proportionally distributed to all the token holders this actually requires only a new additional method on the contract for someone to claim their to claim their

Eater and it works no matter how many transfers are happening and no matter as how frequent to you gonna do the those three words interview words so you can do like every hour you just send the fraction of a meter to this contract user are just standing over the ERC 20 like you do with any RC 20 and it all the accounting is properly made final final remark because this algorithm is not actually doesn't actually do any iteration it's just constant time it even works with non turing-complete

scripting languages so for example I know on Bitcoin if they're gonna launch the simplicity language it will work with that too so that's about it if you have any questions I'll be happy to answer you now or later if you wanna talk privately