Blockchain Fundamentals: Latency & Capacity — Featuring the Ark Ecosystem
Learning the fundamentals of public blockchains, such as those of Bitcoin, Ethereum and other cryptocurrency networks, can be a daunting task due to the wide-ranging criteria by which they are designed. Similar to trains, planes, and automobiles, public blockchains are machines with many moving parts. Some mechanics appear more complex than others if not explained properly.
In this series, we fundamentally explain and conceptualize the qualities used to benchmark a public blockchain by analyzing their latency and capacity.
Speed — What is the network’s average latency rate (block time)?
Modern Society has grown accustomed to instantaneous communication, but it wasn’t always this way back when the internet was operated through phone lines. A strong comparison to the current state of Bitcoin or Ethereum network latency and capacity is the age of dial-up internet in the 1990s when webpage took minutes, instead of seconds to load.
Network latency also referred to as “block time”, is the time required to generate the next block of transactions in the chain. In other words, it is the amount of time a user has to wait, after pressing the “send” transaction button, to see their transaction appear on the blockchain.
Real World Physics:
Traditionally, most humans visualize data as a continuous flow — like the flow of a river in a physical world.
Question: “How much time does it take for this unique water molecule to move from point A to point B?”
Blockchain Physics:
The flow of data on a blockchain is much different. Flow is now periodical, not continuous. Periodical flow is better described as a refresh rate.
Question: “How frequently is the spreadsheet (digital ledger) refreshing/ updating itself?”
Capacity — How large is the network’s bandwidth?
Bandwidth = Transactions Per Second = TPS
The TPS equation has two constraints/variables:
- Block size
- Block time
How can we visualize blockchain network capacity in a real world setting?
Simple Analogy:
Imagine that you are sitting down in a chair next to a railroad track facing a moving freight train.
Blockchain = freight train
- Each block = freight car
- Block size = # of freight containers stacked per car
- Block time = speed of the train
Each time a freight car travels by you, a new block of transactions has been confirmed by the network. The developers, Proof of Work networks, like Bitcoin and Ethereum, are working everyday to engineer a solution to increase TPS in order to handle exponentially growing network traffic.
It’s important to remember that increasing TPS requires increasing the block size (Variable A) or decreasing block time (Variable B).
TPS = (block size) x (block time)
Block size is a relatively artificial constraint — similar to how a railroad company could choose to stack 5 freight containers (increase block size by 5x) on each car in order to move more goods. TPS would increase by 5x, but this can be just as impractical in a decentralized computing environment as it is shipping freight across country.
Anyone can copy Bitcoin’s open-source code, edit the block size to be a higher value, and then claim their new network has a higher capacity (TPS). Regardless, it will still take an average of ten minutes to interact with their blockchain.
Let’s visualize this!
Notice how ridiculous this looks! As it turns out, drastically increasing block size in a decentralized computing environment is just as impractical as stacking multiple containers on a train cart. Why?
- Larger blocks make full validator nodes more expensive to operate since they require more expensive equipment to process larger batches of data and store more memory.
- The more expensive a node is to operate the less people there are who can afford to run one
- Decentralization of the network is decreased, therefore security and immutability is decreased
- The fewer nodes there are, the fewer bookkeepers there are to manipulate and launch a 51% attack
How is blockchain performance improving?
Engineers in the 1800s were told by their bosses to form a solution to increase the amount of goods that could be sent on the railroad.
Solution: Increase the train’s speed!
By utilizing newer developed consensus mechanisms, Delegated Proof of Stake & Proof of Stake, developers now have the ability to host networks with incredibly faster block times. This decreases the dependence on block size to increase network capacity (TPS).
Interestingly, the physical equivalent of next gen DPoS and PoS networks are more akin to new age passenger transportation systems than freight trains.
Notice that a higher network capacity is achieved with a far smaller block size (150 vs 2020 trans). As mentioned above, block size is a relatively artificial constraint that can be increased if network traffic increases to an amount deeming it necessary.
Although latency has improved and TPS has increased, this is still not an end all solution for improving a network’s ability to scale for mass adoption. To get caught up on solutions used to scale public blockchains, read Blockchain Fundamentals: featuring the Ark Ecosystem — Part 2.
