Scaling Cryptocurrency Protocols

The last year has seen a lot of discussion and effort put towards the goal of scaling cryptocurrency protocols.  I will review the reason and difficulties in scaling a crypto protocol and do a quick round-up of these efforts to date.

The Scaling Problem

The term “blockchain” can be thrown around in the non-technical press with a cachet as if it’s some sort of rocket science brain surgery non-linear quantum cryptographical artifact from hyperspace bequeathed to us by the glacial intellect of a benevolent demi-god.  There are, however, two undeniable truths that any serious student of cryptoassets will eventually come to understand:
Financial journalists investigate the Bitcoin genesis block. Footage from MGM studios.
1) Blockchains are incredibly simple.  I spend a breezy ten minutes in talks to finance professionals explaining what blockchains are, but that’s just because it’s out of their domain of expertise, not because it’s difficult.  If the audience was a bunch of folks with some training in computer science, it would take seven words: “blockchains are linked lists with hash pointers.”

2) The distributed-ledger blockchains used in cryptocurrencies are very inefficient.  Firstly, they are somewhat inefficient in terms of the time it takes to update them. This is due to the large number of network participants (nodes) located all over the world who maintain copies of the ledger.  Secondly, cryptocurrency blockchains are incredibly inefficient in terms of file storage. Imagine that each of the 10,000 employees in some hypothetical company had to store and update the same copy of a giant Excel spreadsheet.  Further, the spreadsheet cannot have any entries deleted, only added. Now imagine that this spreadsheet holds every official document generated by anyone in the company. This is the paranoiac redundancy that allows cryptocurrencies to function without any (on-chain) fraud or any centralized control.

In fact, you eventually suspect that that there is a fundamental tradeoff between efficiency and security in digital assets.  The Bitcoin protocol, as currently implemented, maxes out at about 10 transactions per second. The Byzantine consensus protocol used by Stellar and Ripple claims a hundred-fold greater transaction rate.  Using the “Excel spreadsheet” analogy described above to explain how Ripple manages to do this, suppose that only the employees in the accounting department, instead of all 10,000 employees of our fictitious company, needed to keep and maintain the super-spreadsheet.  Obviously, the updating is now easier, however the probability that this, smaller, number of people make a mistake, forget to include an important document, or “defect” en masse increases.

Even if you try to scale a public blockchain using some other parameter, it seems like security is affected.  Increase the blocksize? Sorry, you lose nodes (spreadsheet custodians) because bigger blocks require better computer hardware.  Keep the blocksize, but have more frequent blocks? Sorry, you have an increased risk of timing attacks from miners and stakers and you still effectively lose nodes due to latency issues.  It’s hard to quantify these tradeoffs precisely since they are tradeoffs between different types of failure, but it really seems like the tradeoff is a fundamental one. Perhaps there is an unproven law of information theory, the Nakamoto Uncertainty Principle, if you will, that looks something like this:
(transactions per second) x (resources required to attack blockchain) > some constant
That is more transactions, less security and the converse.  This idea or suspicion lurks ominously in the background of the scaling discussion.  

Why is scaling so important?  People compare cryptocurrencies and credit card payment networks all too frequently and it’s not a sensible comparison in the sense that Bitcoin is not intended to replace Visa.  However, the following is a fair statement: if a cryptocurrency is going to be a globally-adopted payment network it should be able to handle a transaction volume on par with something like Visa which, at peak, can clear over 50,000 transactions per second.  

This rather grim metric, therefore, indicates the Bitcoin protocol, with its current parameters, handles approximately 0.025% of the transaction rate it would need as a true global payment network.  The developer community understands this and the implications for scaling colors every decision they make. Ramping up transaction volume has been discussed since the inception of the Bitcoin protocol and these are well-known problems.  In fact, one of the precursors to Bitcoin, DigiCash, was essentially brought down by a scaling problem since the DigiCash protocol required a central authority (namely, the DigiCash company) to verify every single transaction on the network.  

While there is no overwhelming consensus about how to scale Bitcoin, in the last year a lot of progress has been made and some solutions have been tried out, so it is worth doing a scaling roundup.

The Proposed Scaling Solutions

For the reasons outlined in the previous section, scaling Bitcoin (or any other cryptocurrency) by squeezing factors of two out of block sizes and block rates would not get you the overall factor of 1000 you need, nor would it leave Bitcoin’s security uncompromised.  The Summer 2017 fork which spawned Bitcoin Cash, which is an attempt to scale the protocol through blocksize increases is increasingly looking like a failure from both a technical and a user adoption standpoint.

Additionally, changing the consensus rules or introducing “trusted” nodes to scale Bitcoin is out of the question for philosophical reasons, although niche crypto projects which aren’t trying to be an apolitical global currency may do so.  Therefore, the set of options for scaling solutions involves only “second layer” solutions in which a high volume of transactions can occur off of the primary blockchain and then settle up on the primary or “root” blockchain as needed to ensure that all the currency is properly accounted for.  

Off-chain scaling is necessary as a solution in large part because that’s simply how networks scale.  When you send a packet of information through your router at home to the internet, you don’t send it to every other router on earth, you send it where it needs to go.  This is obviously because if you’re interacting with two different websites, the information you exchange with one is irrelevant to your interaction with another. However, things are more difficult in a cryptocurrency network since each transaction you make needs to be resolved in full knowledge of the others.  That is, each party needs to know that their counterparty is solved and not double-spending funds. The basic technical challenge, therefore, of off-chain scaling is to keep people from double-spends without settling everything on-chain. That is, to break the Nakomoto Uncertainty Principle.

Presently, there are three major proposals for off-chain scaling.  I will review their essential features and give an update on how the technology and/or adoption is progressing for each.  Before we begin, however, let’s set the rules of the scaling game. In order to keep the essential properties of a blockchain-based cryptoasset, the scaling protocol must have these three properties:
  1. Trustless – there is no special party or group required to make the system work
  2. Decentralized – anyone can participate in making and verifying transactions
  3. Immutable – valid transactions cannot be “rolled back” by anyone
For example, cryptocurrency exchanges facilitate huge amounts of crypto changing hands and some even allow fee-free transactions between two users of the exchange. Further, all of this transaction volume is off the blockchains, settled up only when a user makes a withdrawal.  We won’t, however, consider this as true scaling because there is a trusted third party (the exchange) which could roll back trades and transactions, violating all three of the criteria above.

Atomic Swaps

Atomic swapping allows users to trustlessly exchange cryptocurrencies from two different blockchains.  As an example, imagine that Alice has litecoin and wants bitcoin, so Bob agrees to trade her 1 bitcoin for 100 litecoin.  The usual way to make this happen is through a cryptocurrency exchange which has a LTCBTC market, but that violates our trustless scaling rule.  

Atomic swap protocols allow Alice and Bob to make the exchange remotely and trustlessly though a password-exchange trick where essentially, in order for Alice to claim her bitcoin, she needs to reveal the key phrase that allows Bob and only Bob to claim the litecoin that Alice had to cryptographically escrow.  More technical details can be found in this article and this video.

What do atomic swaps have to with scaling?  Well, simply, by allowing trustless interoperability between different cryptos, you can transact on a lower-fee blockchain if one of the blockchains has a transaction backlog.  Think about it like changing lanes while driving if one gets too slow. Alternately, you can think about atomic swapping like exchanges between the currencies of virtual nations and realize that in between the US dollar, yen, yuan, and euro you’d have a large enough monetary base to cover all global commerce.  Similarly, between Litecoin and Bitcoin, you now have a combined transaction rate of about 80 transactions per second.

Atomic swaps are not a research project, they have been performed in between the Litecoin and Bitcoin protocols.  However, this is not necessarily a convenient or total solution by itself – remember we need tens of thousands of transactions per second, however it is progress.  Atomic swaps are also worth mentioning because they are progress towards another really important technical project, decentralized exchanges, and also offer the cryptocurrency holders some degree of safety against one particular protocol becoming compromised.

It’s also worthwhile to note that the Lightning Protocol, discussed below, can support atomic swaps between crypto protocols with similar enough consensus rules.  


Plasma is a protocol to link “daughter” blockchains to a parent blockchain.  At the risk of straining the analogy, these daughter blockchains are college-age daughters which don’t require 100% supervision, only periodic infusions of currency and intervention in times of crisis.  The participants in these daughter chains mint and use internal “tokens” which can be used for transactions in the daughter chain. The main blockchain or “root” chain does not have to, therefore, verify every transaction.  In the extreme case, the daughter blockchains may be permissioned allowing the burden of proof or work or stake on that chain to be very minimal. At some agreed upon time or in the case of suspected fraud or attack, participants can cash out their side-chain tokens for the native currency of the root chain.  A reasonable analogy is exchanging money for chips to have a night in the casino. You have two sovereign currency transactions as you enter and leave, but an arbitrary number of chip transactions governed by internal rules of the games that you play.

The Ethereum protocol and similar projects are particularly well suited to scale through a Plasma daughter-chain schemes since Ethereum has the native and robust smart-contract functionality that Plasma requires.  It’s possible Bitcoin can use daughter chains, but the support is not as native to the protocol.

The main criticism of this is that it doesn’t really exist yet outside of proof of concepts and testnets.  Even if the technology shows up, there is a serious economic issue. Since each daughter blockchain is its own isolated ecosystem, then while it could greatly increase the number of transactions in theory, in practice it reduces the number of people with whom you can interact by pushing activity into little side-chains.  Again, using the casino analogy, you can’t use the chips outside of the casino, which seriously limits their economic utility. Finally, Plasma implementations are a bit complicated which means more modes of failure or, as the security nerds say, a “larger attack surface.”

Lightning Network

The Lightning Network (LN) is a collection of linked payment channels. The basic unit of the LN is a contract that two users open with each other though a special, but straight-forward, script which is posted on-chain.  To be more concrete, let’s say that Alice and Bob are planning on doing a lot of bitcoin-denominated business with each other. Instead of making an on-chain transaction of Alice to Bob or Bob to Alice for each and every one of these manifold transactions, the two simply keep a tab with each other and close it out at some predetermined time.  In order for this to happen according to our three rules, Alice and Bob need to escrow funds upfront. For example, imagine that Alice and Bob put 4BTC each into a contract. Each transaction updates the contract until one of them closes it or it “times out” at a point specified when it was opened. If for instance, Bob spent 1.5BTC more than Alice did in their set of transactions, the final contract will close and return 5.5BTC to Alice and 3.5BTC to Bob.  

Even though the funds in these payment channels are denominated in bitcoin instead of a token, like those of Plasma networks, you may have noticed that this seems to suffer from a much much more extreme version of Plasma’s economic insulation problem, where the contract only lets two people transact.  For instance, maybe it would make sense for me to open a contract with Amazon to handle holiday shopping, but I really don’t do too much repeated business with other parties. Why would I open a payment channel with some party I’m only going to transact with once? Instead of paying miners once for the single transaction, opening and closing a payment channel would incur at least twice the amount of mining fees.  Here’s the clever part of the LN solution, and the reason it’s called a network: Alice can not only transact with Bob, but also with anyone who Bob has an open payment channel with …and anyone that those people have payment channels with themselves, and anyone who those people have open channels with, and so on, and so on…. This happens by Alice sending a payment to Bob, who then routes it on to one of his other channels who can keep routing the payment to any destination in the network.  
Simplified LN payment network
Specifically, imagine that Alice wants to pay Charlie 0.25BTC.  Alice doesn’t have a lightning payment channel open with Charlie, but Bob does.  Alice pays Bob 0.250001BTC for the service of sending a lightning payment of 0.25BTC to Charlie.  Voila! Through the miracle of network effects, in a network that mimics real social networks, there should be an efficient path between any two participants.

If you’re just getting used to the implications of pseudonymity and how open your financial life can be on the Bitcoin network, this might seem like it’s way too public and open – for instance, who would want to call a stranger and tell them the details of their purchase every time they used a credit card?  However, the transactions themselves can be shielded at each hop by the onion routing like that used in the Tor network so that all the entities who route the transaction know is the fee they get for passing along the transaction.

Overall, the idea of a lightning network is pretty slick and the interest from the development community is really high.  There was a Lightning test network in place in late 2017 and there are already stores and services on the main network with new services and payment channels popping up constantly.  The growth is fairly exponential and in a nod to history, Lazlo Hanyecz used lightning to order two pizzas with bitcoin (this time paying 0.00649BTC instead of 10,000BTC).  Lightning apps are being written and the open source community ethos behind it means that progress will .  For example, a coder wrote a LN-powered gumball machine where users can remotely dispense candy for him and another person could fork and change his code to something more useful.  Events called “hackathons” are regularly held for LN coders to work and collaborate on tasks like this.  Currently the most popular LN-powered application is (the possibly NSFW! an online graffiti board where users pay per pixel to doodle on a million-pixel space.
Your future checkbook, bank branch office and credit card terminal?
What are the issues with the lightning network?  There are a few. Firstly, one is – as always – tempted to use the analogy of a credit card.  In this case LN is like a credit card insofar as you use your credit card all you want with whomever and then settle up at the end of the month.  Likewise, you can open a payment channel with a well-situated node and then spend (or *receive* something credit cards don’t let users do) all you want until you’re spent out or the channels close.  However, the analogy doesn’t work in the sense that a credit card is, as the name suggests, a credit or debt-based instrument. Lightning network payment channels, however, need you to escrow funds up front in order to open connections.  In that sense, lightning is more like a pre-paid debit card that other users can refill. As a matter of consumer preference, pre-paid anythings are decidedly less popular since you need to know what your fiscal needs and preferences are ahead of time when you get the card.  In this case, the choice is how much bitcoin are you going to put into the payment channel and will you know in time to refill the channel if needed.

The next, and rather more serious objection is the fact that the lightning payment channel must be online to send and receive payment.  In the parlance of cryptocurrencies, lightning payments are routed through nodes which contain queryable hot wallets. Queryable hot wallets have a much different security profile than what most people prefer for keeping large amount of funds safe.  To un-euphemism that last statement: hot wallets are less secure. In fact, most of the famous exchange hacks in the history of cryptocurrency have been due to the fact that the exchange was keeping large quantities of crypto in a hot wallet. As such, people tend to store small amounts in hot wallets and only connect to transact.  The highly security conscious only use hardware wallets, again, only connected in order to transact. I suspect that someone will come up with a solution that allows the lightning node to spend non-routing transactions (i.e. ones which diminish the balance) only with some additional two-factor or hardware verification similar to how Yubikey works.  Even with robust security on the LN nodes, since the ability to route a payment of some particular size depends on each node having that amount in their channel, albeit for only a microsecond, the amount of bitcoin which you can transact will be limited by the amounts your connections have decided to stake in their LN hot wallets.

Finally, there is a really interesting legal ramification for the role of payment router that each lightning node must play in order for the who scheme to work.  The is no case law specifically in the context of crypto here, but the structure of the payment passing LN uses does raise of issues. Because each node routes transactions, someone could make the case that they are subject to any money transmitting, know your client or anti-money laundering regulations which are relevant in that jurisdiction.  Let me just offer a wild example to give a sense of how the non-physical network connections of the LN is at odds with the rules of “meat-space.”

Going back to our little network, imagine that Bob lives in Seattle, in the United States.  Bob happily transacts through the Lightning Network with Alice, taking payments to send merchandise and routing her payments to Charlie.  It turns out that Alice lives in Canada, so suddenly Bob needs to make sure that he’s in full compliance with all the rules governing international commerce.  No real problem there because he gets a shipping address from Alice and is therefore made aware of his obligations and Alice presumably knows enough about the goods and services Bob offers to know whether she’s eligible to purchase them.  The problem arises if, for example, Charlie lives in North Korea. There is no way that Bob knows this because he’s simply routing encrypted payments from Alice to Charlie and earning some small fees for doing so. There is no information in that about the size and purpose of the payments, let alone what the geographical location of the node is.  Do you know the physical location of the server which just sent your email inbox updates? If we translate this situation into meat-space from cyber-space, you can obviously see how this can be an issue. Bob is paid $1000 to deliver a package of currency from Vancouver to Pyongyang.

Who knows whether this is an issue, or how it might resolve, but there is a legitimate concern.  In practice, payment networks are uncensorable and Bob should have as much criminal liability as a UPS driver does if there’s a package full of illegal goods in her van, but legislators have a spotty history of clearly understanding this technology.

This was pretty whirlwind, but that’s where scaling stands at the moment.  In particular, Bitcoin’s lightning network, which – given a properly-funded topology – could handle more transactions than the global economy needs, has been attracting a lot of attention from the community.
Growth of the Lightning Network mainnet, screenshots from:
Finally, what if it all fails?  I interpret that question as “how much of the energy and money invested in cryptocurrency right now is based on the promise of a true global (~50,000 transaction per second) network?”  Or, “how much valuation will vanish if global-network-quality scaling is proven to be impossible?” I don’t know. Bitcoin won’t go to zero anytime soon since it’s still much more efficient than the current system to send international remittances and at any given time, a country somewhere on earth is experiencing high to hyperinflation.   With a combined network value close to Microsoft’s market cap during the peak of the tech bubble, however, there is definitely some hope of global transformation priced into the cryptocurrency market.  While one or none of these solutions might not be the answer, what is obvious is there is no shortage of substantive work being done to fulfill this promise.