A better incentivization for Swarm

Swarm is a p2p network with incentivization and payments built into it. It’s a very cool project but I find its incentivization discussion in the orange paper to be a bit lacking, namely:

This discussion regarding Swarm’s function as a p2p network — not as a long term storage network — is simplistic in that it doesn’t take into account a congested network situation. When the network is congested, that is the uploaders in the p2p network don’t have enough upload speed to satisfy all the download requests, choices need to be made and resources need to be allocated in a way that can not satisfy everyone. Luckily, there’s a commonplace algorithm named VCG that handles these situations. What VCG basically does is first maximize ‘social welfare’ — that is, it finds the best allocation of resources to maximize overall satisfaction in the system. Then, it imposes the externalities caused by a participant on his co-participants as the price the participant needs to pay. Say that I’m downloading the file and no one else is able to do so because I take all the uploaders’ resources, I will need to pay to accommodate the discomfort caused by me being prioritized. The cost will never exceed what I specified I was willing to pay though, and the way VCG works it can be proven that people will be ‘truthful’ — that is, they won’t try to fake the amount they are willing to pay. Intuitively, they won’t bid higher than what getting the file is worth to them just to get it quicker, because they might end up paying what they bid. They won’t bid lower than what getting the file is worth to them just to pay less, because usually you don’t end up paying what you bid anyway, and if you bid low the VCG algorithm will prioritize your needs lower than other people. A formal proof of these nice attributes of the VCG algorithm can be found online and in the links at the end.

P2P networks always suffered the bad phenomenon of the so called ‘leechers’, and solving it with reputation systems as is done in BitTorrent or KazAA never really worked. I believe that only mechanisms with real money work, and that’s a great market need which Swarm could eventually solve. You can build a very sophisticated system of reputation but it will always be playable because the basic sin in such systems is that people that deserve real compensation — the seeders — are not compensated. It might be true that a normal user of the system ends up on a net positive — he gets to download as well as he’s required to upload, and so he gets the files he wants while using his network connection for which he pays anyway to upload.But as these things are not bundled together, you get to a tragedy of the commons scenario very quickly. By getting money involved in it, these things are naturally quantified and bad behaviors punished.

Another nice property of compensating users for the content streamed from them is certain users will eventually specialize in storing the most needed files and distributing them, thus making the network stronger. By most needed files I mean the files who are served the least well given the demand for them — of course the obvious suspects are the most downloaded files, but given enough agents recognize this and start seeding them, an agent’s best marginal utility could be by seeding other less popular files, so eventually there shouldn’t be starvation for the less popular files.

The analysis model I suggest for the use of VCG for swarm is the following:

The auction for resource allocation is done every time interval, for simplicity every 30 second s
Each downloader agent shares his network download speed, and the amount he is willing to pay for a specific file he wants to download
Each uploader agent shares his network upload speed, the minimum amount he wants for the use of it, and the files he is able to share
VCG is then run by a 3rd party service that swarm may provide. The reason VCG doesn’t have to happen on the blockchain is because by design VCG gets agents to behave truthfully. Computationally it is better to have VCG as a seperated service. Note that some things need to be committed to the blockchain — people shouldn’t be able to go back on their commitments such as declaring having specific files or upload speeds, and then not following through
The uploaders’ bandwidth is segmented into bandwidth-chunks, and they are dedicated for the next time interval to deliver the content to the different downloaders they were assigned

This is a simple model that is meant for a p2p network acting similarly to BitTorrent. Swarm dedicates a lot of attention and efforts around storage — paying for people to store your files instead of paying them when you download. That model can also be incorporated with a VCG mechanism — in fact, it’s even simpler than the BitTorrent-like case, and that’s why I preferred to discuss the more complex scenario in my view.

I have written a simulator for the Swarm VCG auction scenario that can be found on:

https://github.com/yotam-gafni/swarm_vcg

The README file should get anyone who’s interested in running it going.

Running the tests you can see how the mechanism reacts to different scenarios — different prices demanded by the uploaders and whether network is congested or not.

I will analyze one scenario to illustrate the benefits of this mechanism.

In this scenario, we have 3 downloaders (‘Buyers’) and 3 uploaders (‘Sellers’). Each buyer requires either file ‘B’ or ‘A’. All sellers have file ‘B’ but only one has file ‘A’. Their download and upload speeds are given, as well as the prices buyers are willing to pay per 1mbps bandwidth-chunk of file streaming, and minimal reserve prices required by the sellers for a 1mbps bandwidth-chunk. Notice we have a congestion situation on our hands — the aggregate download speed for the buyers is 13mbps, while the sellers can only provide 9mbps in aggregate. Someone will have to compromise.

The final matching set holds the allocation computed by VCG. Buyer0 will download his file at 2mbps from Seller1 and 1mbps from Seller2. Buyer1 will download his file at 1mbps from Seller2. And Buyer2 will download his file at 4mbps from Seller0 and 1mbps from seller1. Buyer2 who was willing to pay the most for his file streaming, by this showing the mechanism he needs it the most, will get the full speed he can download. The others will download at less than their maximum speed. Compensation is now derived not only by the minimum the sellers required but also by the externalities caused by Buyer0 and Buyer1 on each other by congesting the network. Notice that still they pay no more than what they were willing to pay per 1mbps — Buyer0’s end price per 1mbps is 0.66$ and Buyer1’s end price per 1mbps is 2$.

Buyer2 plays for the externalities he caused to Buyer0 and Buyer1 at 1.2$ per 1mbps.

All sellers get more than their required price of 0.5$.

To conclude I will emphasize that as it scales, Swarm will need a mechanism for dealing with congestion and externalities. Its current structure bundles together money, reserve prices, bids and p2p file sharing in a very promising way, but this is a missing allocation component it will require.

Best to all and I would be happy for comments on the theoretic model / participation in the GitHub project.