Introducing Web3Torrent

Written June 18, 2020

Today we’re excited to share something we’ve been working on behind the scenes of the State Channels project: Web3Torrent.

Web3Torrent is a browser based torrenting client that supports incentivized peer-to-peer filesharing using micropayments. The micropayments are built using state channels that run on top of the Ethereum blockchain. Users can upload files and begin seeding to earn small, incremental, amounts of money from anyone that downloads from them.

Web3Torrent is running live on the Goërli testnet right now, please try it out!

Downloading a file from several peers at once using micropayments with Web3Torrent.

Why Web3Torrent?

State channels are a layer 2 scaling technique for Ethereum; they enable trustless, instant, and zero-fee transactions amongst fixed groups of users. If you haven’t heard of them before, I recommend reading our recent post: “Do we still need state channels?”.

We have built several layers of the technical stack for state channels. If you’ve read other posts in our blog series you’ll know there is a considerable amount of complexity in designing a state channel protocol and implementing software to execute it.

Recently, we’ve shown that building a simple application like Rock-Paper-Scissors using state channels is certainly possible with the tools we’ve built so far. This application, wherein each state transition corresponds to a single click by the user (i.e., choosing your “weapon” in Rock-Paper-Scissors) demonstrates how state channels can get around having to wait for an on-chain transaction for simple peer-to-peer state updates.

Of course, the promise of state channels doesn’t end at making decentralized Rock-Paper-Scissors slightly nicer to use.

We wanted to demonstrate something more practical that shines a light on the features that state channels offer. So, when we looked at the kinds of applications that could genuinely benefit from the application of state channels, torrenting stood out as a clear candidate for these reasons:

Torrenting is peer-to-peer. A torrent network is comprised of people providing chunks of a file and others requesting those chunks. The network architecture lends itself nicely as a base to overlay peer-to-peer state channel relationships.

Torrenting requires high-frequency messaging. As users share pieces of a file with each other, they communicate constantly. There is already a well established peer-to-peer wire protocol that various torrenting clients use (e.g., uTorrent, BitTorrent, etc).

Torrenting has an incentivization problem. There is sometimes a real lack of incentive to seed a file, especially for obscure files where you may only find a single digit number of people that have it. Adding monetary incentives to the existing torrenting structure should prove to be extremely interesting.

These characteristics suggest to us that introducing a micropayment based incentivization layer would increase the quality of the peer-to-peer network and lead to greater decentralization. If a user just paid to download a file, by leaving their client running and allowing others to pay to download from them they can actually recoup the cost of the download, or even exceed that cost in uploading revenue.

Basics of torrenting

As mentioned, torrenting networks are specifically designed to solve the problem of peer-to-peer filesharing.

Two important roles are seeders and leechers. A seeder has an entire file available to be downloaded, and a leecher is looking for pieces of a file to download. Seeders broadcast to the network that they have all the pieces of a file available to be downloaded and leechers seek out other peers (seeders or other leechers) from whom they can download some pieces of the file.

While a leecher is downloading pieces, they may upload those pieces they have already received to other peers in the swarm. Some users, as pictured below, can even upload and download from each other at the same time as they both have and require different pieces of the same file that can be shared between them.

Integrating micropayments

Since torrenting protocols lend themselves so well to state channels, deciding how to design the state channels application is remarkably simple. Essentially, since peers are already exchanging messages with file data encoded within them at a high rate, we can encode state updates that transfer tiny incremental amounts of a cryptocurrency within those messages.

The functionality we needed then, was the ability to extend a torrenting protocol in such a way that peers can communicate with each other, identify who to open channels with, and then additional to each piece getting sent over the wire, include signed state channel updates constituting crypto payments.

We found a web-based torrenting library called WebTorrent, built by Feross Aboukhadijeh, which implements the BitTorrent protocol over WebRTC so that web browsers can be nodes in a torrenting network. WebTorrent provides a very convenient API to extend the protocol in the way described.

The lifecycle of a single file download between a seeder and leecher then looks like this:

• A seeder broadcasts his willingness to seed a file in exchange for payment
• A leecher interested in that file establishes a WebRTC connection with the seeder
• The leecher then requests the first piece of data from the seeder for the file
• The seeder tells his wallet to create a channel and prompts the leecher to join (the channel is now starting)
• The leecher tells his wallet to join the channel and sends over the countersignature (the channel is now running)
• The leecher then dispatches a state update command to his wallet to send a small bit of ETH to the seeder
• The seeder, upon seeing this bit of payment, sends the data to the counterparty and countersigns the state update

This repeats until the leecher has finished downloading the file from the seeder. Then:

• The leecher tells his wallet to close the channel (the channel is now closing)
• The seeder responds and closes the channel (the channel is now finished)
• The leecher and seeder then close their WebRTC connection

Below you can see all of this happening in just a few seconds.

What’s Next?

We hope that this application will serve as a demonstration of what is possible with state channels today, and inspire more people to use micropayments/state channels as part of their mechanism design. Of course, this is only the tip of the iceberg of what is possible with state channels, and we’ve only covered the implementation details at a very high-level in this blog post.

In the near future we’ll be diving into some of the important infrastructure that is “under the hood” of this demo such as virtual channels and hubs, browser-based funding policies, crash-tolerant wallet design, optimizing micropayments for performance, and much more.

In terms of Web3Torrent itself, we’re looking for your feedback! Presently this application is running on an ethereum testnet to showcase the work we’ve done in designing this protocol and all of the underlying wallet software required to make it work. We’ll be developing our server wallet and hub infrastructure software next and we’re actively looking to integrate all of it with a partner on mainnet. Please reach out to us if you’re interested in discussing possible integrations.

Until next time!

Written by Liam Horne, thanks to George Knee, Tom Close, Georgios Konstantopoulos, and Josh Stark for feedback. Thanks especially to the entire State Channels team for all of the hard work that has gone into making this possible.

---

Contribute

This work was made possible by donations from the Ethereum Foundation and Consensys to fund our team working on State Channels. All of our work is 100% MIT-licensed open source code, and we heartily welcome contributors! If you’re interested in discussing ways you can contribute, or to explore possible projects that would benefit from working with us to integrate state channels, please reach out to us on our discussion forum.