Kadena's Chainweb Series (Part 2): Bitcoin's Nakamoto Consensus and Its Limitations

In this article, we're laying down the groundwork for what's to come in how Kadena’s Chainweb is expanding on what Bitcoin started. Our aim here is to establish the basics that will serve as our guiding principles throughout this blog series. Whether you're new to blockchain or a seasoned enthusiast, these foundational blocks pave the way for a profound understanding of what makes blockchain truly exceptional.

If you have not read the first part of our Chainweb series, you can read it here.

Basics of Nakamoto Consensus

Nakamoto Consensus is a set of rules that verifies the authenticity of a Proof of Work (PoW) blockchain network. This system ensures fairness and keeps the whole network running smoothly without a central authority. It's named after the creator of Bitcoin, Satoshi Nakamoto.

For more information, you can refer to the Bitcoin Whitepaper.

Blockchain

Blockchain transactions are grouped into blocks by miners. Each block has two parts: a header with protocol info and a payload with transactions. In this article we are not so much concerned with the payload; we will instead focus on the consensus protocol. Miners solve cryptographic puzzles to win blocks and get rewards, using specialized hardware called hash power. This process can consume significant electricity. Once solved, blocks are shared in the network. Miners build new blocks on top, forming a chain, hence "blockchain."

Blocks in a blockchain have two main things to know about them: height and weight. Height is like counting how many blocks are in a line, one after the other. It shows how tall the tower of blocks has grown. Weight, on the other hand, is about how tough the cryptographic puzzles were to add each block and all the ones before it. These challenges are like puzzles, and solving them is what keeps the blockchain safe. The difficulty of these puzzles changes now and then, so new blocks keep getting added at a steady pace, even if the number of people trying to add blocks changes. So, height and weight are like the backbone of the blockchain, keeping it steady and secure.

Block Validation

Sometimes people try to disrupt the chain by adding blocks that aren't right. They might do things like give the wrong answer to the puzzle or try to use money they don't have. So, before miners can add a new block to the chain, they have to make sure all the previous blocks are valid. If they find a bad block, they have to reject it, making the block unusable.

Miners spend a lot of time and energy making blocks. So, they wouldn't want to waste their effort by building on a bad block. If they did, other miners might not accept their work, and it could all be taken off the chain.

Block Confirmation

When a miner adds a new block to the blockchain, they're saying that all the blocks before it are legitimate. So, if a block references the latest one in the chain, it's like approving all the blocks before it. We call this confirming the blocks.

And if other blocks reference a particular block, directly or indirectly, they're also confirming it. As a block receives additional confirmations, its validity becomes more trustworthy which provides proof that it should be a part of the chain.

Now, the difference in height between a block and the latest one in the chain is called its confirmation depth. Usually, the confirmation depth matches the number of confirmations a block has. But sometimes, two miners might add new blocks on top of the same one. In that case, the block still has a confirmation depth of one but gets two confirmations because two miners agreed it's good to go.

Orphans

Since miners are spread out on the internet, it takes a bit for a new block to get to all of them. Because of this, sometimes different miners solve and share new blocks at the same time. When this happens, the miners go with the block that has the most confirmations. The other block, with less confirmation, gets taken out of the chain and ignored. We call this kind of block an orphan block. (Some people also call them stale blocks or uncle blocks)

Forks

Miners earn rewards by adding blocks to the blockchain, so they work to avoid creating "orphan" blocks by quickly sharing new ones across the network. Sometimes, slow connections or network problems cause miners to create competing blocks, leading to a fork in the chain. In such cases, the longest chain wins, with miners switching to the branch with the heaviest block — a process known as a reorg.

Forks are usually short. Bitcoin's P2P network and the Internet's decentralized design minimize long-lasting network partitions. Additionally, the PoW consensus protocol splits mining resources during a fork, slowing block creation on each fork. This delay allows time for operators and users to address issues, although it also prolongs transaction confirmation times. Despite this, the mechanism ensures the reliability and robustness of Nakamoto Consensus, making Bitcoin's system exceptionally secure.

Double Spend Attack

What if someone tried to cheat the system? Let's say a person named Eve has 1 Bitcoin and she deposits it into an exchange's wallet. Then she trades it for regular money and withdraws it. But here's the tricky part: she manipulates the system to erase the record of her deposit, so she keeps both the Bitcoin and the money she withdrew, leaving the exchange at a loss.

Eve has two ways to pull this off: First, she could create a fork and mine a separate branch where her deposit never happened. By isolating the exchange from the honest network she tricks the fork to trust her branch. After receiving the money, she ends her attack and the exchange joins the honest network again, where her deposit never happened. This attack would be slow and could raise suspicion because Eve’s branch would receive only a little hash power.

Alternatively, she could use a 51% attack. After making the deposit, she creates a hidden branch of the chain where the deposit does not occur. Controlling more than half of the hash power, her branch will be longer than the branch of the honest network. After receiving the money, she reveals this branch, which now becomes the main branch. This would be harder to detect, especially if she acquired new hardware for the attack. However, both methods have risks and could trigger alerts, giving the exchange a chance to catch on and protect itself.

Limitations of Nakamoto Consensus and Bitcoin

Bitcoin's Proof of Work consensus is exceptionally secure and robust, making it the gold standard for permissionless and decentralized blockchains. However, this high level of security and robustness comes with a trade-off: lack of scalability.

Effective Hash Power

During a 51% attack, both the honest network and the attacker race to build the longest chain. Thus, honest miners strive to maximize their hash power. When miners collaborate on the same block, they work effectively. However, when a miner finds a block, it takes some time until it reaches everyone and other miners can switch to it. This inefficiency leads to wasted hash power on orphan blocks. Being centralized, the attacker avoids producing orphan blocks. The effective hash power of the honest network is its total power minus that spent on orphans. Therefore, for a 51% attack, the attacker needs to surpass only the effective hash power of the honest network, which is less than the total power.

As the time it takes for blocks to propagate across the network increases relative to their production speed, the effective hash power decreases. For instance, if a network generates one block per minute, and it takes 10 seconds for each block to reach another miner, miners spend about two-thirds of their time mining orphan blocks. Consequently, the network's effective hash power is only two-thirds of its total power. Hence, only approximately 33% of the total power would be necessary to execute a 51% attack.

Transaction Throughput

The network's security relies on its effective hash power, determined by the efficiency of block propagation and validation. To control block propagation overhead, there must be limits on size of blocks and the time it takes to solve each block's puzzle. These limits need to be set cautiously due to the unpredictable nature of mining, potential attacks, and the variability of the public Internet. It's crucial for the effective hash power to closely match the total available hash power.

Bitcoin, for instance, has a block time of 10 minutes and a block size limit of 1MB (4MB with SegWit). These limits are conservative and serve other purposes besides just ensuring mining security. With the block size limit, each block can only accommodate a certain number of transactions, which, along with the block time limit, defines Bitcoin's maximum transaction throughput. Therefore, Bitcoin's scalability is restricted by these limits.

Transaction Fees

As the volume of transactions nears capacity, the system experiences congestion. In this congested state, users compete for slots within blocks to include their transactions. Each transaction included in a block incurs a fee payable to the block's miner. Miners prioritize transactions offering higher fees. When demand surpasses the hard limit on transactions per block, transaction fees soar, rendering the system prohibitively expensive for all but the most valuable transactions.

Block Rate and Confirmation Times

Block times also impact security in another aspect: it's easier to target a few slow blocks than many fast ones. Essentially, it's more probable to strike lucky once than multiple times consecutively.

For a successful attack, the attacker needs to solve more blocks within a given timeframe than the honest network. The expected number of blocks one can mine within a specific timeframe follows a Poisson distribution, depending on the available hash rate. Let's denote r_a as the expected block rate of the attacker and r_h as the expected block rate of the honest network. For an attack attempt, let X(r_a) represent the actual number of blocks solved by the attacker and X(r_h) represent the number of blocks solved by the honest network in the same timeframe. Therefore, P[X(r_a) > X(r_h)] signifies the probability of the attacker succeeding in producing more confirmations than the honest network.

For example, having 30% of the total computing power is enough to launch an attack with a 10% success chance on a confirmation depth of five blocks. This isn't just important for deliberate attacks; it also affects the probability and extent of reorgs due to accidental events like network splits or software bugs. Faster block times mean quicker confirmations for the same mining effort.

In essence, a blockchain's security isn't solely reliant on the economic investment in mining. It's also crucial to generate numerous confirmations rapidly.

Finality

When can a transaction be considered final? First of all, it must be included in a block. Due to the limitations of transaction throughput, this can either take a long time and/or cost a lot of fees. Yet, merely being included in a block is not enough. As we have seen, blocks can become orphaned and there can even be forks in the chain for different reasons.

Reasons for forks include:

• (bad) luck, when concurrently resolved blocks race to be propagated and validated throughout the network,
• accidents, like network partitions or bugs in the protocol or its implementation, or
• attacks by bad actors that take advantage of reorgs.

The result of forks is reorgs, during which valid blocks are forsaken and removed from the blockchain. Typically, a transaction achieves finality when the block containing it accumulates ample confirmations, making the possibility of involvement in a reorg highly improbable.

We saw that a blockchain that produces smaller blocks more quickly can offer shorter confirmation times for the same amount of hash power. But this goal conflicts with the loss of effective hash power that results from shorter block times. This conflict requires a conservative selection of the parameters for block rate, block size, and confirmation times to minimize the harmful effects of forks.

By 2022, the largest known Bitcoin reorganizations were 53 and 24 blocks, both stemming from bugs in block validation code. Nevertheless, even smaller reorgs are infrequent, with no known instances of reorgs exceeding a depth of 4 in Bitcoin's history, aside from the bug-induced reorgs. Reorgs of depths 2 or 3 are also exceedingly rare.

For Bitcoin transactions, three to six confirmations are generally deemed sufficient, with the exact number contingent on the transaction's economic value and the potential harm associated with an accidental or malicious reorg. Ultimately, the appropriate confirmation count is influenced by the user's risk tolerance. Consequently, it typically requires about 30 to 60 minutes for a Bitcoin transaction to attain finality.

Conclusion

As we bring this article on Nakamoto Consensus to a close, it's evident that Bitcoin pioneered something revolutionary. The remaining articles in this blog series will spotlight Kadena's Chainweb technology and go in-depth on how it has taken inspiration from Bitcoin and innovated a more scalable and secure solution for Proof of Work.

Catch the rest of Kadena's Chainweb Series:

• Part 1: Expanding on What Bitcoin Started
• (Currently reading) Part 2: Bitcoin's Nakamoto Consensus and its Limitations