It's no secret that, even for the technically inclined, blockchain technical whitepapers can be a bit dense. Here we create a series of articles that try to break down Taraxa's whitepaper's technical jargon into more reader-friendly vignettes (with more pictures!) for your reading pleasure.
Quest for Speed
As the blockchain space matures, pioneering networks such as Bitcoin and Ethereum are running into performance bottlenecks, such as,
- Throughput: how many transactions the network can process in a given timeframe
- Latency: how long it takes for a transaction to go from being sent out to being finalized
- Scalability: how much does the network throughput and latency degrades as the network increases in size (e.g., the number of nodes)
Of these three perhaps throughput is the one that captures everyone's imagination the most, so let's talk about how this specific metric could be improved. Throughput is usually measured in how many transactions a network can process per second, or transactions per second (TPS).
A Word on Security
In systems like Bitcoin or Ethereum, a single chain of blocks each contain sets of transactions. The network makes forward progress one block at a time (at a given average timeframe), which means the maximum number of transactions the network can process for that timeframe is limited to the transactions within one block.
At any given time, the network on average produces not one but many blocks (how frequently this happens depends on the specifics of a given blockchain). In single-chain systems, miners are actively selecting which block they wish to accept (bet on) and build on for the next blocks in the network. Eventually, only the longest chain on the network, where the largest number of miners have chosen to make their bets on, will win out, and the rest of the blocks on other chains are thrown away, essentially wasted work.
Hence, despite descriptions of a blockchain as a single chain, it in fact looks more like a tree, with many branches. All but one single branch will survive, the rest are discarded.
An attacker that tries to cheat the network will typically attempt to rewrite history by trying to beat the rest of the network in building the longest branch and inserting malicious transactions into blocks on that branch. For example, attacker A buys something from B and sends B 1 coin. B gives A the goods it purchased. A then attacks the network and creates a longer chain which has it send the coin not to B but to C. In this scenario, A now has the goods from B, but B never received payment.
One way that many classic single chain networks use to ameliorate malicious branching is to simply slow down the network progression. This reduces the likelihood that an attacker could, with much less resources, leverage temporary information asymmetry created by networking delay to mislead honest nodes into betting on its malicious branch. In BTC for example, they adjust the proof of work puzzle difficulty to set an average time between blocks, and make sure this delay is far longer than the time it would take for a block to propagate throughout the network to every node.
Some Naïve Ways to Increase Speed
To increase TPS, we present two naïve solutions: increasing the number of transactions in a block or increase the number of blocks processed within the same timeframe. Let's look how they turn out.
Solution A: more blocks
What if the number of blocks within the same timeframe were increased? Instead of on average just 1 block per timeframe, we say 10 blocks per timeframe.
Remember we're still limited to picking one block per timeframe. If you simply increase the total number of possible blocks, that means each miner now simply has a lot more choices, but they still need to pick just only one block, which means more blocks more wasted blocks.
More block choices within the same timeframe of course will also increase branching, making it easier for attackers to take advantage of the network.
This isn't a great solution. Let's look at the next one.
Solution B: bigger blocks
What if we simply had much bigger blocks with more transactions in them? Instead of just 2,000 transactions in a block, let's put in 20,000 transactions, so we stuff way more transactions into the same timeframe than before.
A much larger block, due to its size, propagates through the network much more slowly. Given the same timeframe, once again, we are raising the potential that different nodes will see different blocks at any given moment.
This plan too, leads to more branching and lowers the overall security of the network.
Tough Tradeoffs
In a single chain network, there seems to be a hard tradeoff between throughput and security. However you increase throughput, you end up sacrificing security, and in trying to plug these security weaknesses, you end up erasing the purported gains in throughput. This tradeoff was first investigated in a paper by Sompolinsky and Zohar, whose research inspired Taraxa's ledger design.
How do we address this tradeoff? We transition away from a single chain topology and into a graph, which we'll address in our next article.
Stay tuned.