Why BitTorrent survived while eDonkey died, and what does this mean for the future of electronic payments
As I mentioned in my previous article, BitTorrent was not the first network to do what BitTorrent does. So why did it thrive where others died? How did it become the main mode of sharing large files on the internet, even though previous systems were easier to understand and more convenient for their users? What can we learn from it?
Let us look at how those networks work:
In eDonkey 2000, the network I talked about previously, the nodes that keep the list of available files, the “servers”, form a network. A client that wants to share an file (a “seed” in BitTorrent parlance, let’s make it a triangle) connects to one of the servers, and announces that it has a file to share. Eventually, clients interested in the file (In BitTorrent parlance, “peers”) query the servers, find the sources for the file (the triangle, and each other), and begin download.
Like the modern crypto networks, the system was “decentralized”: the directory servers were operated by volunteers, just like miners and full clients on, say, Bitcoin or Ethereum. I say “decentralized”, in quotes, because, while it was distributed all over the world, and seemingly impossible to shut down, it had one central bottleneck, that eventually spelled the end of eDonkey:
In order to download any file, you had to connect to the directory server network, and find all the sources for the file. The query mechanism in the edonkey protocol was primitive, preceding the invention or wide-spread use of DHTs: it asked every server for the file and peer availability. This meant, every client searching for a file queried every single directory server it knew, putting a strain on every one of them. A strain, that, as it turns out, wasn’t necessary.
If you look closely at that graph, there are three separate networks in it: the server network, the “orange file” network, and the “green file” network. In theory, there need to be only two directory servers that need to deal with those file requests at all:
In fact, to track the sources for a file, the servers don’t need to be connected. They don’t even need to know that the other server exists.
This is BitTorrent. This leaves you with a little bit of a problem:
- How do the clients find their respective “servers”, or rather, as they are called in BitTorrent parlance, the trackers, to begin with?
This is where the .torrent file comes in: it contains the addresses of the nodes that keep track of the “seeds” (the original sources of the files) and the “peers” (all the clients who are trying to download a file).
This, of course, introduces an additional layer of complexity and some inefficiencies into the sharing process: first you have to find a trusted source for your .torrent files, then hope that it even has a .torrent file for the particular thing you want to download. There might be hundreds of trackers and sources for the file out there — if your trusted torrent source doesn’t have them, you are out of luck. But along with those problems, BitTorrent introduces something else:
Federation as the better decentralization
If you are looking for the orange file, you don’t care about the green file, its tracker, or its sources. This means, you will never query the green tracker. There are millions of files people might want, and in an extreme case, there can be millions independent trackers that don’t need to know about each other, don’t get hit by each other’s traffic. It is a far more efficient, infinitely scalable system. (It became even better with the introduction of DHTs, where clients themselves serve as trackers, offloading some of the tracker’s work). What it completely lacks, is built-in discoverability.
- You have to find your tracker through sources you can trust
- You have to trust your tracker to deliver you the correct file
Somehow, though, this doesn’t seem to pose a problem in practice. Even despite constant legal trouble, there are always well-known directories where there are torrent files available that get vetted by the public.
Lessons for electronic payments
Can this be done with payments? Some system that, unlike Bitcoin or Ethereum, doesn’t require every participant to take a hit for every new joining client in a part of the world you have never even heard of? Some system that localizes most of the transaction to a trusted shard, so that most transactions are cheap? Some system where the shards are vetted by the public, and maybe even operate legally? Maybe even one, where the shards compete with each other, forcing the other shards to become faster, cheaper, and more efficient?
Surprisingly, a system like that already exists. It is called banking.
Before you object that banking is offline, slow, expensive, and inefficient: if it is for you, it just means that your bank sucks. Even the most technology-challenged of banks in a “developing country” like Thailand can show you that it doesn’t have to be this way:
- Transactions are instant and free, no matter whether you and recipient are the customer of the same bank or not — and both you and the recipient get a text message the moment you press the “pay” button. Again, for free.
- You can pay someone to their phone number (PromptPay). Yep. “Like paypal”, except, once again, free. Now, try that with Bitcoin.
Apart from that, there are many upcoming payment providers that operate “on top” of the banking system, like LINE Pay, or WeChat Pay, that allow instant and — surprise — free payments with your mobile phone — for your train tickets, your breakfast, or your coffee. None of them use blockchain — nor do they need to:
Yes, there is one thing that cryptocurrencies have, that the banking system doesn’t: as Simon Morris wrote in his series, it is the built-in ability to break rules. But let’s be honest: do you want others to be able to break rules with your money?