So there's been a lot of people talking about cryptocurrency. But I noticed that the pro-cryptocurrency people focus on things I think are irrelevant, and the anti-cryptocurrency people are often unaware of what I consider to be the most exciting parts of cryptocurrencies. So what are the exciting parts? I'll try to explain my perspective. I love the idea of just making a utility and distributing the source, so anyone who wants to can download and run it and (if they like) have complete control over what it does. If I die or get bored, I want the tool to live on in the SSDs of people who love it. 1. That's why I like the build system [Nix](https://nixos.org/), which lets you precisely describe how to build your code. Anyone who builds it for a given architecture is guaranteed to get the exact same binary. 1. It's why I like git, which makes it easy for people to share and merge their changes with one another. 1. But most of all, it's why I like BitTorrent, which lets people share files with one another without the need for any intermediary or corporation beyond an ISP. If any of this is appealing to you, I think you might be able to be convinced to like cryptocurrencies for the same reasons I do. ## More about BitTorrent Let's think about the problem BitTorrent solves. BitTorrent is a protocol that allows some people to "seed" a file. Anyone with the file's hash can use the BitTorrent protocol to find that file's seeders and download it from them. So we can say it takes the problem of file distribution (which is quite easily solved with a central file server that you link people to) and makes it _decentralized_, so it doesn't depend on the continued good-faith of any particular person. Someone can pretend to seed a file and maliciously send you some other file, but the hash of their file wouldn't match the hash of the file you asked for, so your client would automatically throw it away. This means only _one_ person needs to seed the file honestly, and all the evil in the world can't stop them from sending it to you.[^dos] [^dos]: Well, they could DOS you or your ISP could cut off your internet connection or the government could arrest you, but this is still a much better situation than "let's just hope our guy/corporation keeps this site up forever". This is actually a pretty complicated problem. How do you go from a hash to an IP address of people who are seeding a file without relying on a centralized server? Well this uses a pretty sophisticated bit of engineering called a [Distributed Hash Table](https://en.wikipedia.org/wiki/Distributed_hash_table), and it does technically involve connecting to at least one central sever to get the root of the table, but if that server starts misbehaving you can just switch to a different one without losing anything. So the bottom line is I can make a utility, throw it up on BitTorrent, and that's all I have to do. Anyone who wants to can seed the file and it'll be available for everyone, no matter what I do. Even if powerful organizations like Disney don't like my utility, they can't stop me from releasing my tool or you from downloading it. Even the government can't stop us as long as they're not willing to block [Mullvad](https://mullvad.net/en/). That's cool! ## Beyond Torrents So the obvious question is: in the context of decentralization, we've pretty much solved this problem of serving files, but can we solve anything else? Even without cryptocurrency, the answer is yes. Any problem which can be expressed as a [CRDT](https://crdt.tech/) can be BitTorrent-ized. You can pretty simply modify BitTorrent so that instead of identifying files that have a certain hash, it identifies files that are signed with a certain private key. That means I can share a file, then update it and sign it with my private key, and re-share it. The same torrent link will now point to both files instead of just the original. (Give every file a version number and add some tooling that automatically downloads whichever file has the latest version, and you're cooking with gas.) But it also means I can, for example, maintain a file with all of my tweets and share the link with my friends. They can then download my file and see my tweets, even ones I added _after_ I shared the link with them. That's how you can make a social network that no one controls, and you can do it without a speck of cryptocurrency. This is the idea behind Paul Frazee's [unwalled.garden](https://github.com/beakerbrowser/unwalled.garden). If you write the code for this, like Paul Frazee has, you've made a social network that truly belongs to the hackers. You can't change a thing about it without their consent – they'll just not download your change. It's like my dream of making a utility that lives on after I die, except it's a social network instead of a utility that lives on your computer and doesn't talk to anyone else. ## Beyond CRDTs Twitter is "easy" because you already know who you follow and can mostly trust them to be honest about their tweets' timestamps, so you can just download their tweets. But anything that really requires an objective and unfakable operation order (like say, a digital currency) can't be implemented with a CRDT[^calm]. [^calm]: If you're curious to know more, the [CALM theorem](https://rise.cs.berkeley.edu/blog/an-overview-of-the-calm-theorem/) precisely specifies what can be implemented with a CRDT and what can't. As a simple example of something that _can't_ be done with a CRDT, let's say we want an app that allows people to create polls, allow others to fill them out, and allows the poll creator to close the poll to ignore further voting. To solve _this_ problem, you need a distributed ledger. A ledger is basically a list of operations, like `["Virgil created a poll", "Chad voted for cats", "Stacy voted for dogs", "Virgil closed the poll", ...]`. To have a general ledger that can support any app, we want the following properties: 1. The contents of the ledger should be in the same order for everyone. 2. Once something is in the ledger, it should never disappear and its position in the ledger should never change. 3. Anyone should be able to add whatever they want to the ledger, up to bandwidth limits etc. 4. Like how anyone can seed a torrent, anyone should be able to participate in the process of coming to consensus about the contents and order of the ledger. And it should be very difficult for any organization (even a powerful one) to stop disrupt the consensus process. Everyone should agree on the ledger state, which means this is a problem of "distributed consensus". We don't want a small number of bad nodes to be able to ruin it for everyone, which means we want our consensus protocol to be byzantine fault tolerant (BFT). Byzantine fault tolerance means that the consensus algorithm works correctly even if some nodes misbehave, no matter what they do. Unfortunately, the first two of our desired properties mean a CRDT won't work, because CRDTs can't give an objective order to events that come from different users. The fourth requirement means we can't use Paxos, because then any misbehaving node could mess up the consensus process. And you can't just use a simple byzantine fault tolerant consensus protocol, because an attacker could just spin up a ton of sybil nodes and get past the byzantine threshold. So it seems like our dream is almost impossible... ## It's almost impossible, but it can be done We're going to start with a regular byzantine fault tolerant consensus protocol. BitTorrent is _very_ fault tolerant, you only need one honest node seeding the file for a file to be available. We can't quite live up to that standard, but we can take a threshold like 50% or 33% and say that our consensus algorithm will behave correctly as long as there are fewer dishonest nodes than that threshold. "No more than 33% of nodes can be dishonest" is a bit of a worse situation than "we only need one honest node". It means we need some barrier to making nodes, because otherwise an attacker would just spin up an arbitrary number of nodes until they hit our threshold. For "proof of work" currencies like Bitcoin and present-day Ethereum, that barrier is acquiring computing power. For "proof of stake" currencies like Algorand and someday-but-hopefully-soon Ethereum, that barrier is liquidity of some asset. (For those curious, proof of work gives you a 50% byzantine threshold, and proof of stake usually gives you 25% or 33%) ## Why do these have to be currencies though? Couldn't we just have distributed systems that hackers spin up as needed? Well, nothing stops you from doing that, but remember, being in the network has to _cost_ something or it can be trivially taken over, and the fear is that not enough people will volunteer to pay that cost. There has to be more honest people paying the cost than dishonest people for the network to work. The resolution is to make _users_ of the network pay the honest nodes. In practice, you do this by creating a token, and maybe even using the network to track who owns the token. When someone runs an honest node, the network mints tokens from nothing and gives it to them. To use the network you need to have a token and destroy it, so people who want to use the network have to buy the tokens from people running honest nodes. This token is what makes it a "currency", although it's not really a currency anyone would want to use – it's just a roundabout way to get people who use the network to pay the people who make it work. But that's just a practical consideration. Nothing stops you from taking any cryptocurrency design and removing the incentivization schemes. Your version will still benefit from all the other research that's being done. ## But a centralized server would do this all way better! Yeah, but I don't like centralized servers, I like BitTorrent. ## But it's mostly just used for crime! So is BitTorrent. Even encryption is used for crime. Both are useful for crime because they take power away from powerful organizations and give it to individuals, and sometimes individuals do bad things. That doesn't mean we should give up on giving power to individuals. ## But it's too expensive! Yeah it is. The issue is that all distributed ledgers are limited in how many operations you can add per second, and there's a mini-bidding war to see how many tokens you're willing to lose to get your transaction in. If you want distributed ledgers to be usable for something like a social network, it's no good if it costs $60 to make a post! So the main problem that remains to be solved before we have practical distributed ledgers is scaling them up so the number of operations the ledger can support is much much higher. Remember, we want this to be a community effort where anyone can contribute to the network on their home computer, so we can't ask everyone who wants to participate to buy a beefy server farm. We need something like BitTorrent that works fine on a normal computer with a normal internet connection, but can scale to tens of thousands operations per second. Bitcoin currently supports about 5 operations per second, and Ethereum supports about 10, so we have a long way to go. It's been 13 years (or something like that) since the original bitcoin whitepaper and this still isn't solved, but scaling is really hard! I swear that we're working on it! Let's briefly go over some of the problems and their solutions. ### There's a lot of redundant computation Let's say the ledger has operations like `["Alice paid Bob $1", "Carol paid Danny $5", ...]`. You might want to compute everyone's balance, but if the ledger is very large, that might take a while. In general, the ledger is a list of operations that modify a state, but what you're really interested in is the current state. Currently, every cryptocurrency has everyone recompute the entire state themselves, but that leads to a lot of redundant work! The obvious solution is to have one person compute the state and share it, but then you'd have to trust that they weren't lying. The trick to make this work is to use a technology called ZK-snarks or ZK-starks (among others). These let you run an arbitrary computation and compute its result along with a _cryptographic proof_ that that result really is the result of running the computation. The beautiful thing is that this proof is small, a few bytes (for snarks) to a few kilobytes (for starks), and can be checked in a snap. So you can let anyone calculate `(balance, proof)`, and as long as one person is willing to do that, no one else needs to redo their work. The problem was, although the proof can be checked almost instantly, the overhead of generating the proof used to be enormous. If it takes 100,000x longer to generate the proof than it does to run the computation, you're not really saving that much work compared to having everyone do the computation themselves! However, this is such an important problem that the cryptocurrency industry has poured billions of dollars into optimizing the proof-generation process, and we now have awesome tools like [Plonky2](https://blog.polygon.technology/introducing-plonky2/) and [Kimchi](https://minaprotocol.com/blog/kimchi-the-latest-update-to-minas-proof-system) that make the overhead more like 100x than 100,000x. There are ZK-based layers on top of Ethereum _today_ that increase the operations per second dramatically, so this isn't some hypothetical solution. Making a fully-general solution is really hard, but despite that [zkSync](https://zksync.io/) has a very fast public test network that you can try out today. ### Everyone redundantly stores the full ledger If you want to support a lot of operations per second you quickly run into storage problems if you ask every node to store the full ledger. That's why one of the biggest research area is _data sharding_, which allows you to split up the ledger between multiple nodes. It's harder than it sounds because, just like how you can check that a file you get from BitTorrent is the right one, you want to be able to check that someone is really storing the part of the ledger they're claiming to. The obvious way to check that is to just download the ledger, but then you run into serious bandwidth problems! The trick is to use [data availability sampling](https://notes.ethereum.org/@vbuterin/r1v8VCULP), which allows you to check that someone is storing a whole piece of data while only downloading a tiny fraction of it. This is being implemented on Ethereum with a project called [danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq). ### The ledger just keeps getting bigger Usually you care more about what's happening now than what happened 10 years ago. For example, instead of storing everyone who ever up- or down-voted a 10 year old post, it's much more efficient to compute a total upvote and downvote count and discard the individual votes. Despite how inefficient it is to keep the full history, that's how current blockchains are designed, because it keeps things much simpler. Simplifying a little, we have now have really good schemes for: 1. "State rent", where you have to continuously pay to keep something stored in the network. 1. "State expiry", where old stuff is deleted after a time. In both cases, a hash of the deleted data is kept, and if it's important anyone who has the data saved can restore it later. ## What about replacing USD or the gold standard? Trying to replace USD is dumb, and the gold standard was dumb. Those have nothing to do with why I like cryptocurrency. ## What about carbon emissions? Like I said, proof of stake is the future and requires orders of magnitude less energy consumption, and zero graphics cards. ## What about all the scams? The scams really suck :( but I don't think they take away from how cool the technology is. ## Isn't cryptocurrency all about getting rich quick? That's definitely why 99% of people are into cryptocurrency, but we're hackers and we don't have to be interested in cryptocurrency for the same reason as everyone else. We can be into it just because it's cool! <Minisection> Disclosure: I'm a protocol developer for a major cryptocurrency (not any of the ones mentioned in this post though). But I'm a protocol developer because I like cryptocurrencies, not the other way around. </Minisection>