Three solutions to the blockchain scaling problem

Blockchains are very slow implementations of shared databases. The biggest and best — bitcoin and ethereum — achieve 10 to 20 transactions per second. In comparison, the Visa network is designed to handle up to 50,000 transactions per second. Small fixes proposed to the bitcoin architecture will still leave the network under 100 tps. It just takes a long time to get thousands of distributed nodes to agree on the next block and distribute it. This places a limit on the types of applications that can use a blockchain database or accounting.

It is possible to make blockchain-style systems with much higher transaction rates, and/or larger data handling capabilities. I have seen three basic strategies.

  1. Push most activity off the chain. You can do a lot of transactions off chain, or in “sidechains”, and only record the final result in a bigger and slower blockchain like bitcoin. This is how the “lightning” network functions. It is also how big files are stored in almost any blockchain system, with only the file hash being saved to the distributed blockchain.
  2. Make a much smaller network with a small number of nodes. If you only have to get consensus and update 10 nodes, that will happen a lot faster than doing it for 2000 nodes. This is how “private” blockchains achieve their higher speeds. However, it is not clear that these systems have significant benefits over the more standard clustered databases that they come to resemble.
  3. Break your data into “channels” or “applications” that can go into different blocks that are being simultaneously assembled. This is the “horizontal” scaling strategy. If you are clever, you can take a bunch of similar transactions and figure out if any of them are related or not (where a double spend would qualify as “related), and find unrelated sets.

EOS combines tactics 2 (only using 21 nodes at a time) and 3 (breaking data into “applications” so one chain system can handle more data). BigchainDB uses strategy 3. I think that any high volume system will have to use strategy 3, as there is a limit to the amount that can be serialized into one block being processed by one computer. My proposed Trust but Verify system uses tactics 2 (defaulting to central DB cluster with monitoring) and 3 (if the db or world can be divided into independent areas, you can make a much bigger db or world). It also uses a vertical scaling strategy (not in this list of common tactics), where the underlying services can be broken into pieces, and storage can fall into layers with indefinitely increasing volume and decreasing speed.

SaaS entrepreneur/engineer. Founder of MAXOS, Real World DeFi. Previously founded Assembla, PowerSteering Software, on team at SNL Financial.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store