Blockchain Myth 6: Proof of Work is slow

brrabski
8 min readMay 29, 2022

--

This is the sixth and final post in a six part series about prevailing myths in blockchain implementations. The previous myths are on:

  1. Blockchain vs bitcoin,
  2. Blockchains and data sharing,
  3. Blockchains and privacy,
  4. Blockchains and speed,
  5. Blockchains and security offered by Proof of Work.

In this article you will find out that Proof of Work is not only not slow, but that it is the fastest consensus algorithm possible, bar none.

First, a short mention of the last article, where I described how PoW is efficient in what it does, which is to provide security. Yes, it uses lots of energy, but that energy is directly proportional to the security it provides. Any decrease in use of energy, and security goes lower. What is the optimum level of security, and therefore energy use? How secure should a decentralized protocol which no one party can control be? These are things you should consider for yourself.

Now its time to consider, whether with the high energy use comes a speed penalty? When talking about speed in computer systems there are two measures: throughput and latency. Throughput is measured in the amount of data that can be sent every second, while latency is measured in time. How long does it take between when a piece of information is sent and when it is received?

Throughput is a matter of technology more than a matter of physics. It is about how much data we can cram into a transmission channel in a short span of time. While physics are a limiting factor, the technology is about all kinds of tricks we can use to cram more in before the physical limitations of the medium start to limit us.

Latency, especially at large distances, is a matter of physics more than of technology. It deals with how long it takes for the data to travel in a medium. Once we have figured out how to make data travel at the speed of light, the fastest speed there is, we lost the ability to improve much on latency. It takes light 0.07 seconds to travel along the equator to the other side of the Earth from where we are. Data cannot travel faster than that. How long is 0.07 seconds in computer time? Eons. Average internet connected computers can pack a network wire with about 70MB in that time (the speed of a 1Gbps connection) and the first bit will be halfway across the world before the last bit is sent. This is about an hour’s worth of music. Can we send more data in that period of time? Yes, but it won’t get halfway across the world.

Engineers have a saying that one can never underestimate the throughput of a stationwagon full of blueray discs. Average BD disc stores 4.5 terabytes (TB) of data, which is a very high quality full feature film or about 8.5 years’ worth of music! If we pack a car full of BD discs, we end up with… you get the picture and I don’t want to calcuate how many BD discs fit in a car.

So a car carrying BD discs has, quite literally, billions of times the throughput of a network wire. But it can only travel about 100km/h (60 mph), so it will take a while to get across the world, if it can find a road.

A very high throughput, but high latency (slowly travelling), data packet.

This is the difference between throughput and latency and computer networks require two way communication, so the limiting property of global networks are not throughput, but latency. Not technology, but physics.

Now to the point. Computers operating blockchain networks need consensus algorithms to agree on what history is the only correct history to store. How quickly can they do this? There are many ways that people have tried to synchronise databases over distances, but most ways invented involve the computers talking between each other to agree on what is the final record. The fastest databases in existence rely on a single source of truth in one location; a centralised database. This type of solution assumes there is an authority and that authority receives information that it needs to record then decides on what sequence it will be recorded in, and sends it out to everyone interested. This is arguably the fastest way to sequence transactions and it’s probably well accepted that centralised databases with authority are quick.

The financial industry relies on the centralisation concept to settle transactions, but not at all in the way most people think. That is to say, the credit card companies do not process money quickly. It actually takes days or weeks for the money to reach the recipient. More on that in a bit, but let’s first get back to the topic on how to make a distributed database fast.

If one wants to arrive at a distributed consensus algorithm, some compromise in speed is required. The physics of latency demand it. For example, in proof of stake consensus algorithms transactions are collected by nodes that have vote weights determined by their token balance, or stake. This requires that all voting nodes send their vote to all other voters on the network, a tally is made (probably by each node), and then the nodes agree that a certain majority of them have the same opinion. There is no one-way communication algorithm that:

  • would allow the nodes to set up the voting candidates,
  • agree on what is the subject of the vote (a proposed block),
  • collect all eligible votes, and
  • penalise or exclude misbehavers / attackers

that would be quicker than a single authority with no voting requirement.

Except there is such an algorithm, and it is Proof of Work, where each block is actually proposed by a single authority that gets to dictate what everyone else must accept without question.

PoW does not require any chatter, because the winning block is determined only on its own merit in that it solves a difficult puzzle and the receiver must only decide if they have received a better proposal from anyone else.

This mechanism is predicated on the assumption that it is difficult enough to generate a block that in a given span of time there will realistically only be one candidate new block produced on the entire network, and so we can accept it as the official history and wait for the next one. If sometimes there is a competing block produced, we just wait for which of the equal competitors gets another valid block added and go with that while throwing away the “shorter” chain.

What is the latency of a PoW consensus algorithm? It’s the quickest that a new block can travel one way across the network. Coincidentally, this is the quickest way that physics (not technology) allows. For example, in a blockchain that spans the solar system up to Mars, the time for a block proposal to travel one way is equal to the time it takes light to travel across the maximum possible distance that can separate Earth and Mars, which is about 20m. Any back and forth, and the latency of each new block goes up in 20m increments.

So, the lowest latency long range synchronisation protocol must be the one, where a valid true history is instantly known by any member of the network, without even knowing how many members of the network there are. This is only possible in schemes, where the party sending the proposed new block can “prove” that they have the authority to determine that it is valid and that a competitor is not likely to exist. Centralised arrangements are the best at this, because there is only one authority, but PoW comes close in that if another authority (with a valid solution to the PoW puzzle) arises, we just wait for a tie-breaker. I.e. a block added to either one or the other candidate.

Now on to throughput. How much data can a block contain? That’s a matter of agreement. Considering that relevant portions of history must be stored by all nodes on the network, this question can be answered by the storage capability of the average network node and how much it can receive in the time it takes to generate a new block on the network. For Ethereum the block size limit (throughput) is how much can be sent in about 15s, which is the average block time. Since this is about 1GB of data and we need to store all of it, the throughput limit more about the answer to the question, how much are we willing to store rather than how quickly can we receive it?

For bitcoin, whose block latency is 10m, the maximum possible block size is … you can transmit a lot of data every 10m. But the answer is more or less the same. And is determined by how much data is the community willing to store with each new block. On Bitcoin the amount of data is roughly 2500 transactions every 10 minutes (about 4 transactions per second) while on Ethereum it’s roughly 1M gas every 15s (which is about 47 transactions per second if ethereum stopped processing smart contracts for a moment). These values were chosen purely on the appetite for storage that was considered reasonable by their communities and not by the speed of the consensus technology.

In summary because of their lack of chatter requirement, PoW networks present the fastest consensus algorithm possible in terms of latency and are limited in throughput only by the appetite of its community to store all the transactions.

Now back to the often cited speed of credit card networks. What is their throughput and what is their latency? Credit card networks rely on decentralization and separation of authority to do their trick, but they don’t actually do settlement, which means they solve a completely different problem than blockchains do. The 20k tps number often cited is just the sum of all the transactions happening at any given time, but on that network each bank is its own authority on what money it authorises to be promised and relies on a system of pre-approvals. There is no one master sequence of transactions like a blockchain will have, because the card networks do not handle settlement. Cards tps and blockchain tps are apples and oranges.

All the banks participating in a payment network still need to synchronise settlement transactions between each other in a process that is conducted for each national currency with their central bank. The credit card companies brag about speed, but that is just the speed of as-yet-unrealised promises to pay. Actual settlement of card transactions, the equivalent of a blockchain transactions, happens on national and international inter-bank settlement networks like SWIFT or SEPA and usually takes days or even weeks for reasons that are out of scope of this discussion. Note that SWIFT is an international messaging system and most SWIFT messages aren’t actually settlement messages, and while SEPA is able to settle faster, it does so because it was delegated with the authority to handle EUR settlements.

Suffice it to say, credit card companies could use blockchain settlement to improve some of their settlement times if they wanted to, but as discussed in Myth 2, blockchains are not actually a competitor to credit card transaction processing and anyone promising a blockchain settlement network that operates at credit card messaging speeds is, at best, misinformed.

--

--