Daniel A. Nagy: Persistency | Swarm Orange Summit Madrid 2019

okay hello everyone again oh this is going to be much more technical presentation than the previous one and this is about persistence since warm so persistency is about making sure that what you upload to swarm stays there and remains available so first I'm going to show this a little bit of an overview of the talk so I'm going to talk about what the challenges of resistance are in a decentralized system like swarm then I'm going to talk about incentives that have already been implemented and how they play out going to talk about the problem of spam and in the end I will review a few use cases of swarm and how how they relate to the problem of persistency and give a little bit of a roadmap about what to expect in the future and well so what is difficult what makes persistence so difficult number one problem is churn namely that nodes join the network and leave the network and when they join then they don't have up-to-date information and when they leave then all the information that they've been storing becomes unavailable for the rest of the network so that I would identify as the number one challenge in keeping content available in swarm the other problem the other challenge with persistence is spam and in this context spam means content that has been uploaded to swarm and it crowds out other content then opportunity costs so if nodes have a limited storage capacity which they do then the incentives in place might cause storing some content being more profitable than storing other content so the less profitable content is deleted and finally misaligned incentives so certain in certain cases it might happen that for one reason or another nodes decide not to persist certain content so I will go through them in more detail so it takes that when a node joins the swarm Network it takes time for it to download all the information that it needs to have and to upload all the information that other nodes need to have in order for content to be available in swarm in the DHT and until that happens very important that requests to content are not being routed to nodes which either don't yet have that content or which no longer have that content so this is a problem that is fairly difficult to to test and we're currently grappling with it but we're hoping that these kind of problems will be satisfactorily solved soon and basically any change in membership so either when nodes leave or when they join data needs to be moved around and on and it takes time and it's very important to use this transition to to to route requests appropriately during this transitional times and basically since nodes leave and join swarm continually we're never actually in a equilibrium State ever so these corner cases they're actually normal operational conditions they're not exceptional conditions and it's also important to understand that as notes come and go the radius of responsibilities by which we mean that the proximity within which a certain node is responsible for chunks can both grow and shrink so that's those are the challenges caused by by churn and so this this is this is a very important area of both research and development inside swarm spam so there are two kinds of spam there's malicious spam where the objective of the spammer is to either take out specific nodes or to damage the entire network and there's accidental spam which simply results from incentives not being right and nodes just uploading huge amount of information in swarm about which they actually don't even care and in the context of swarm it is difficult to tell a legitimate upload from sinking so when a node receives data it might receive it because it is something that has been newly uploaded to swarm and it can be because you know as the topology of suarez the membership of swarm changed data needs to be moved around that moving around in swarm lingo is called syncing and the two are very difficult to distinguish I will later tell you how they can be but it's difficult and you cannot charge for syncing if you're interested I can later explain why not but basically the short story is that if any part is charged for syncing than syncing will not happen and that's bad however if uploads are free then they might crowd out important data and there need to be some measure in place to prevent that and I will tell you about those measures and it's also important that spam resistance is kind of connected to censorship resistance because spamming is a way of making other data unavailable so in order to be censorship resistance swarm must be spam resistance however it's very important that the classification of what is spam and what is not spam is not arbitrarily done and the network can not be forced into classifying something as spam because removing spam I mean the any mechanism that can be used to remove spam can also be used as a vehicle of censorship so that's the that's the spam problem opportunity costs so obviously all nodes that participate in swarm they have a limited storage capacity and what they do with their storage capacity is their own sovereign decision which can be influenced by incentives but cannot be forced and because of that there are two choices that nodes face one is allocating a certain storage space to swarm versus allocating it for something else so how much stores how much of their storage space nodes make available for swarm is a decision that depends on their objectives and can be influenced by incentives and the other trade of that they have is that even if they allocate some storage space for swarm then it's important to to judge which data do they do they store and of course is the storage space is limited some data gets garbage collected so these are the opportunity costs that they need to need to take into consideration and they that's what influence is a persistent self data and there's misaligned incentives well one is selfish storage when basically if the incentive system is not designed correctly then optimizing for maximum profit might result in not storing something that is important and this is typical so we're trying to avoid these situations and the typical and most important case of this is charging for charging for sinking so if storing some data is profitable and there's a competition to serve this data then nodes might not sink it in order to monopolize the storage of some data this is what I call selfish storage in analogy with selfish mining and this is what does whenever wins we design some incentives for swarm that needs to be avoided and the other one is tragedy of Commons which happens in the opposite direction so these are like the two extremes of misaligned incentives so if we reward certain nodes for responding to certain requests then we will deal with selfish storage whereas if we reward everybody for keeping some data available then there's obviously a tragedy of common situation when every node wants all the others do the storing while they reaped part of their benefits so it's very important to to be aware which costs and which benefits are private and which are shared and design them in such a way that neither selfish storage neither tragedy of common situations arise and I think that with swap we have found the the correct design so swap is the incentivization the incentivization system of swarm which is already implemented it is turned off by default but one of the upcoming releases will actually have it turned on by default first on the on santa's nut and eventually on the main nut and swap is a protocol where payment only occurs between directly connected peers so you don't use swap to pay somebody far away on the network you only deal with swap with your immediate peers and the general rule is that if you want the peer to do something for you you pay but the first option the number one option is also always payment by reciprocal service so basically it's a tit-for-tat protocol largely inspired by BitTorrent which I think deserves a omeka Nobel Prize I mean not our thing but BitTorrent and and so we want to avoid monetary payment of any sort if it can be reciprocated by a service in order to conserve liquidity and if something needs to occur it better happens off chain so we're actually using Chile using payment channels the checkbook that Victor talked about earlier today so basically there's a mutual accounting between connected peers on each connection of who has done how much service to the other peer which because of the properties of the hash function and the distribution of swarm are such that if you don't do anything it will be roughly balanced but if there's a large disbalance because of either different capabilities of nodes or very different usage patterns like for example if you go on a movie watching binge and you always want to download download download without helping others then of course these disbalances need to be settled by a payment which happens repayment channel which is occasionally settled on the blockchain and the sanction for non-payment in swap is simply disconnect so if there's a large dis balance between two nodes and one node feels I mean not feels but actually has an accounting that it is being taken advantage of it's simply disconnects that peer connection and since establishing peer connections is both beneficial and valuable this means that free riding on others cannot become a business strategy for nodes because it cannot it's not sustainable because they will get disconnected so swap is primarily a tool of accounting for bandwidth however because of the way it works there's some emergent behavior that is incentivized by swarm so I would like to give you a quick rundown of what what kind of behavior swarm incentivizes what what is it that it rewards so first of all it incentivizes you to retain profitable chunks a chunk is profitable if it's very often requested of you so if if the same chunk is requested from you often you want to retain that chunk you store it and because of the wake Adamle routes typically but not exclusively these will be the chunks that are nearest to you because all the requests or most of the requests that request those particular chunk will end up in your neighborhood and occasionally it's your note that is going to be asked for those who you are in some device to retain these chunks you're also in some device to cache popular content because if it's requested of you of course you you need to to download it which is a request for which you need to pay so it's kind of like buying but if you cash it means that you only need to buy once you can serve it many times which means which is analogous to selling so you buy it once and you sell it potentially many times which means that swap as it is already incentivizes the cashing storage and dissemination of popular content so for example if there say something like nodejs which is part of almost any JavaScript web app swap alone can be trusted in making sure that that kind of content will be available in swarm and well persisted just because everybody needs it all the time there's a very interesting effect that served which we call the donut effect meaning that popular content moves to the edges precisely because of caching so because everybody is caching popular content it ends up being stored on the nodes that are close to the nodes that are requesting it which might be actually fairly far from where they belong from their neighborhood in the BHT and because it is not requested where in its neighborhood those nodes where which should be storing it according to the according to proximity they might decide that these chunks are not really profitable and garbage collect them but actually it's not a problem because as long as this content remains highly popular it's okay to actually act as a Content distributing distribution network a CDN and just store it in many many instances close to the edges but if the if there's a you know room for for taking a breath for those notes from serving them then they will eventually sink back to where they belong so it's not so this donut effect does not actually make content unavailable just available where it is requested rather than where it is where it belongs according to proximity metric that we use sinking itself namely that you're pushing chunks to towards where they belong is only incentivized weekly so the incentives are not direct they are indirect Emily that first of all you need to make room for other stuff so you don't you you usually so you want to you want to stored other things than the things that you are supposed to be sinking and it kind of helps the like you can rely on others being reciprocal providing this reciprocal service to you so there's a certain element of altruism but as we have learned from peer-to-peer networks as long as it doesn't cost much altruistic behavior for the good of the network can be counted upon so sinking does not have any direct incentives but indirectly its incentivized by not being like there's no reason not to do it garbage collection so if nodes optimized for maximum profit and swap then we have a stick which is a little bit more complicated than what I will explain but like the core of it that there's a guard or acting queue which is consumed from the bottom so whatever is at the bottom of the queue it garbage collected and whatever gets requested it goes to the top of the queue so this is a heuristic of for which chunks are being requested frequently because if chunks if some chunk is relatively often requested it will be very often put to the top of the queue and then it will sing but it will not sink to deep and because of that it will not get garbage collect from bottom it's a well-studied heuristic in queueing theory so there's a lot of mathematical models that accurately describe how this behaves under certain assumptions but it's very important that it is retrieval requests that place chunks to the top but sinking does not do that because what's on the top of the garbage collecting queue is kind of proven profitable because it has been requested so there's some evidence for this chunk being in demand whereas whatever is being synced to you you have no idea whether it's a sink or an upload and it's not known where it goes so it goes to somewhere near the bottom of the queue where exactly is a more complicated question into which I don't want to go here and what could help this heuristic is some credible by which I mean costly signal of profitability if somehow we could look at a chunk and decide whether it will be profitable or not and later on I will tell you what can act as is as just such a signal so now we move on to the question of how does swarm protect itself from spam so what we need is kind of like a postage stamp model so we cannot use swap for instant we cannot use swap for paying for storage but upload should cost so if you want to upload something it should cost you because otherwise your incentive is to just upload as much as it's convenient for you and clog the network with garbage but it's important that uploads only cost to the uploader and not to the singer because as soon as it starts costing to the syncher syncing just won't happen and that we don't want to happen so the way to prevent it is to attach a little piece of data to each chunk which acts like a postage stamp that you look at it and you can decide whether this was paid for or not so this marked chunks is paid for and those of you familiar with whisper you can recognize that this is very similar to proof of work as is used in whisper so that is one example of doing that now we don't use that and swarm and I will quickly I will shortly get into into the reasons for doing that but what I would like to emphasize that the unit of accounting here is the value of that information divide it by the amount of that information and divided by time so you pay for a certain piece of information to be stored for a certain period of time and of course the longer the period of time is the more you need to pay so for example if you want to put some units on it it's either per chunk per second like that's kind of the dimension of the payment for uploads and it's very interesting that because no chunks are distributed to two nodes according to their hash and the hash function is by definition uniformly random just by looking at local information you can actually have draw some global conclusions so what we use is this proof of burn instead of the proof of work because the problem there are two problems with proof of work one is the delay you need by definition you need to spend time for obtaining a proof of work and if you want to upload a large file you might want to just pay rather than spend computational time because you might have money you might not have time and the other problem with proof of word that specialized attackers have a huge advantage and it it makes the entire network vulnerable to a denial of service by specialized attackers so instead of proof of work what we attach to chunks are digital signatures which have this semantics of being a postage stamp and the public key which used for signing these chunks is linked on chain to a payment and an expiration time so for any one key on the blockchain you can find a money overtime dimension value and as in the previous slide I already mentioned just by looking at your local database as a node you can estimate how many chunks have been signed by this same key and most importantly when you're making the decision what to delete you can compare to two chunks two signatures just based on your local data you don't need to know for certain how many chunks have been signed because you know that what you have is a representative statistically representative sample of the whole universe and of course these postage stamps they raise certain privacy concerns because if data is paid if if the digital signature on chunks belongs to the same public key then even an outside observer or the node itself can kind of tell that these chunks belong together so even if they cannot decrypt their content if they're encrypted they still know that they belong together and that might not be a desirable property but we kind of deferred this kind of problems to the more general problem of anonymity and since we're using aetherium keys same kind of techniques that are going to be used for anonymizing aetherium will also work for anonymizing a swarm but we treat it as a low priority right now so in the final part of my presentation I will go through a few use cases and look at how they how they concern persistence so the first use case which is going to be production ready implemented by August by the end of August this is a use case by data fund which is sending large files so Alice wants to send terabytes of data to Bob and what she does is she uploads these terabytes to swarm and then uses some method for sending the handle to all these terabytes of data to Alice and then Alice downloads this data of swarm this is the simplest case because the time horizon on which this data needs to be persisted is very short and the only the only features that need to be implemented to a production level quality for this particular use case is some feedback to when from what point on the data is available so Alice needs to have some notification that okay they upload succeeded she can now disconnect the data is available perhaps it would be nice to signal the availability at the end of the availability of that content but it's not necessary it just a nice to have feature and it's also very important to give some upfront estimates to Alice what is it gonna cost her to send a terabyte of data so once we have these two features implement it to production quality this particular use case is considered ready for ready for primetime the next use case is also a very important one which is hosting dubs static web content so the dubs themselves and their data if they have a name so here important thing is who pays for persistence now eventually obviously it's the audience that use this dap who need to through some mechanism which could be very indirect but eventually like ultimately the cost of persisting that particular piece of data need to rest with the audience and for popular content swap actually does the job so we don't need to do anything in addition to what we have if the content is popular so if it's adapt that everybody uses swap make sure that it will remain available the problem is that nothing begins as being popular popularity needs to be reached and while the content is not so until the content becomes popular the publisher somehow needs to pay for its availability and there are several ways of doing that so one is simulating popularity so basically paying over swap by continually demanding that content from difference addresses and just pretending that it's popular and that way swarm will persist it it can be am i running out of time okay so I will speed up so the other method is regularly reuploading it then we will have swap and so swearin Swindall so later we will implement more complex contract driven incentive systems so that they can pay someone else to do the above and the final vision is to let these entities to create a Dao and from that point on you will basically paying swarm to host your own dunt until it becomes popular and Dan swap takes over as the primary incentive persistency against censorship so in that case you have some malicious actors actively working towards removing the content for that we need two features basically one is forcing the opponent into an arms race that they cannot win and the second is possible deniability I will skip the details for the lack of time I will be very happy to tell you afterwards a very big but somewhat difficult use case is storing aetherium state on swarm there are two different reasons to do that one is to help nodes that wish to become full nodes to bring them up to speed so basically to do what paraty calls warp sync but do it off swarm and the other is helping light clients and basically light servers to offload them so eventually we would like to become integrated with less and converge on certain protocols with them and finally the more the most difficult case for persistence is basically storing encrypted personal beta like imagine a backup which nobody except for you will ever download and probably you will not download it either so that's basically that's the one that is farthest down the road and finally the last thing this is really the last one so what is the opposite of persistence deleting we always get these questions about can you delete stuff from swarm and so fund there's a fundamental thing about data on the internet it's not even about swarm those who ever had read access to data they can always save it and then reshare it there's no way around it this is a fundamental property of digital data on the network and therefore I think that the fair definition of what is what does it mean to delete something is that it is no longer Cybil from a given interface be it a user interface or an API and that of course we can do so you know if you delete something from Facebook then it gets marked deleted in their database and we can do the same in swarm so it so what I want to emphasize here that it's the responsibility of the dev developer to make sure that data that they want to consider deleted is no longer accessible it is not swarms responsibility and that is that's it thank you very much and I'm ready for a QA testing ok so I thank you very much we have some time for just one quick question whoops this okay okay so my question is about the stamping like you you pay for one content to be accessible for let's say a year and then the cost of storing on the network increases rapidly so isn't like older content then kind of privileged super being cheaper because it was paid in advance and the cost of rows could this be a problem for the network since so the short answer is that I don't know so we really would like to see the dynamics of storage costs how they change and how it will play out in practice but definitely by committing in advance you as a user can remove some of the risks of changing cost like how much they will fluctuate I have no idea this will only practice will tell but I think it's fair that if you are willing to pay in advance then you can shoot yourself from this risk hey thank you very much I think yeah is related to incentives to be part of the incentive workshop which is happening after RAF's talk so that's the closing session for today an hour and a half discussion on exactly these problems and we're gonna go really in detail about what swap incentives and persistence in twenties so I had one question which was regarded to the swap protocol and you say at one point what you want to mostly to be for like tit for tat right and if the dots nodes don't play this game then in the end like and measure will be to disconnect right but I mean my question what is the cost for nodes to actually run maybe ten nodes so maybe disconnecting is not costly if it's like cheap - yeah just have multiple entities on the network doesn't matter if you disconnect from me because I just have so you will have this so connecting is costly like building up a connection in swarm is it takes time and just like in the case of BitTorrent you know you as a freshly connected nodes you have all sorts of disadvantages so having maintained a long connection is advantageous there's there's value in every connection and if it gets disconnected then you will have to spend all those resources that you have spent to build up that connection to build up new ones so it's not a sustainable strategy to respond new nodes and and start start new connections yeah last one can I make swarms to my data for free in a way that I upload it and then I keep downloading it well keep if you keep downloading it it means that you will ask other nodes to do something for you which is a service so you need to pay for that over swap and you have two ways of paying for it either by giving your storage and bandwidth capacity to the network or by paying your hard-earned ether those are your two options okay thank you very much thank you and now and now please stay a moment because there is going to be an announcement hello my name is Mark I'm here with Attila on the behalf of the favela foundation we are a nonprofit organization working on a new kind of social network which uses swarm as its back-end and I just like to announce that we are doing lottery during the swarm summit we are going to give you a unique art object which is displayed at the registration table and you are welcome to participate by donating to the appropriate address displayed at the same place thank you [Applause] okay I think you have the final talk of today after only the workshop is