Blockchain and Its Commitment Issues

We have taken a huge leap, starting from the barter system to generating paper notes to transact for goods. The barter system, funnily enough, can be thought of as the closest cousin of Bitcoin, since both these forms of exchange include decentralized transactions without a centralized authority overseeing them to ensure they are atomic. Hence, over the past 5,000 years, we have taken a leap from decentralized systems to centralized systems, and back to decentralized systems again. Moreover, we were eventually able to make the centralized systems of paper currency electronic, encouraging the scaling up of businesses and increasing their customer base to the whole world via the internet.

It would be fair to make a direct comparison between blockchain and the barter system, given they share a common thread — they are both decentralized. If we were to think of the downsides of the barter system, there are many. It was highly localized; neither did each person have access to a customer base willing to exchange, say, “a horse for 10 bags of wheat”. However, in blockchain, we are exchanging cryptocurrencies with each other (can exchange multiple currencies with each other, or exchange currencies for money depending on the exchange rate), without a central entity overseeing this transaction. While the brains behind this, Satoshi Nakamoto, was able to build this wonderful “internet-supported” decentralized system, the real question is whether the benefits of a decentralized system outweigh the security vulnerabilities introduced by the coordination of multiple blockchain nodes — artificially resulting in an eventually consistent blockchain that does not include transactions that have already been executed, thus resulting in a transaction showing as complete even though the payer never lost money and the payee never received money (a.k.a. double spending).

The blockchain, after all, is a “Big Mathematical Beauty” (the only ‘Big Beautiful’ thing I’ll be talking about), and I say that having built a prototype myself. Before I dive into the specifics of my own project, I want to talk a little more about how this decentralized system works, and I am willing to confess the few errors I made during its architectural ideation.

The decentralized system relies on a few artifacts that make transactions irreversible, thus negating the possibility of a “half-done” transaction, which would be another variation of double spending. While rollbacks are impossible by design, vulnerabilities in the system can still produce the same damaging outcome — the point where things get interesting. I’ll come back to how that vulnerability can be combated later on, or in a follow-up article. But for now, I would like to focus on the upsides of decentralized systems (blockchain), mainly emphasizing how these rollbacks are prevented.

The chain of events can simply be explained as follows —

Every transaction has a set number of attributes, including a digital signature generated by the private key of the payer and the public key of the payee. It would be helpful to understand why this is so, instead of simply assuming it as a given. Each blockchain node stores a local “linked list” that need not be consistent with the version stored in other blockchain nodes. This is a common feature in distributed systems, where inconsistent data structures are stored across all nodes, eventually becoming consistent via protocols like the “gossip protocol”, as can be seen in Kafka and other big data tools. In fact, the whole of blockchain can be thought of as very similar to Kafka, including the broadcasting of events to multiple queues, the sequential ordering of those events, and the eventual consistency of data across all participating nodes. Much like Kafka’s commit log, the blockchain maintains an append-only record of transactions. While they share a lot of mechanical similarities, Kafka is not decentralized. While Kafka guarantees ordering via “Zookeeper”, the ordering in blockchain is contingent on the ordering of timestamps on the node that successfully solved the PoW puzzle and hosts the longest blockchain (this will become clearer in the next two scenarios).

1. Now, let us assume a scenario where there are only two nodes — Node A and Node B — that store inconsistent versions of the transaction history. Person A wants to execute transaction i with Person B. Node A happens to solve the Proof-of-Work (PoW) puzzle faster than Node B, and hence Node A appends the transaction to its own local linked list before broadcasting it to Node B.
2. There could be two specific scenarios in the scenario mentioned in Point 2. In the first, the timestamp of the previous block in Node A to which transaction i gets appended is an earlier timestamp than the latest timestamp of the transaction on Node B. Since Node A was able to solve the PoW puzzle first and, for the sake of this example we will assume it hosts the longest blockchain version, the blocks with timestamps falling between Block A(n-1) and the timestamp of transaction i, which were originally not in Node A, will get dissolved/orphaned from the eventually consistent version of the blockchain adopted by both nodes after appending transaction i. However, if it were the other way around, where the latest timestamp on Node B was earlier than that of Node A prior to appending transaction i, Node B would need to pull those missing blocks from Node A via the gossip protocol before Node A broadcasts transaction i to Node B. Hence, all in all, the chain that represents the most cumulative computational effort (i.e., the longest chain built through the most successful Proof-of-Work solutions) decides the fate of each transaction.
3. For all those who are confused about the PoW puzzle that is to be solved by each of the blockchain nodes, it can simply be understood as a “game” or a “puzzle piece” where you are to guess the number of zeroes that are prepended in the hashed version of a specific number (hashed using SHA-256). This is the component of distributed systems alongside the hosting of a peer-to-peer distributed network that consumes the most amount of compute and hence implicitly consumes the most amount of power, water, and electricity.
4. Now, let us carefully simulate an attack in this decentralized system. In the case where my friend and I consumed a majority of the power supplied to the entire peer-to-peer distributed system, for the sake of this scenario, we must consider a larger number of participants. For simplicity, let us consider three participants — me, my friend, and a third random blockchain node. Let us say Person A has the resources to collude with my friend and me, while Person B is naive and simply wants the transaction to go through! My friend and I are indeed consuming a majority of the CPU power (66%). Person A would be considered lucky if he manages to execute a transaction i without a deduction from his crypto wallet!
5. I (Block x) begin colluding with my friend (Block y) on how we can somehow dissolve transaction i from the eventually consistent blockchain. Block x unexpectedly solves the PoW puzzle and broadcasts it to Block y — but the version of the blockchain we are privately growing does not include transaction i. At this point, two competing chains exist — the honest chain, held by the third node, which includes transaction i, and our fraudulent chain, held by Block x and Block y, which does not!
6. The network always adopts the longest chain as the truth. Since Block x and Block y together control 66% of the hash rate (a.k.a. a majority of the total computational power on the network), we will statistically solve subsequent PoW puzzles faster than the honest node controlling only 33%, thus aggressively growing our fraudulent chain until it becomes the longest. Once it does, the network adopts our version as the truth, transaction i gets dissolved, Person A never loses his crypto, and Person B never receives it. This is what is known as the 51% attack!

(Please note that the linked paper suggests the upper threshold that enables a double-spending attack can be as low as 33 and a third percent, which is far below the 50% requirement for a classic attack. However, for ensuring intuitiveness and uniformity across the article, we will assume the lower threshold for double-spending to be 51%. We can dive deeper into this in the subsequent articles)

1. The next time you want to execute a transaction, you might want to wait for at least 6–10 confirmations (for transactions ranging around $10,000 to $1,000,000 according to the linked website) from blockchain nodes confirming that your transaction has successfully been appended to the blockchain. This in turn reduces the chances of a 51% attack, since most nodes have already accepted the broadcasted transaction — giving it greater statistical importance and making it far more likely to be chosen as the eventually consistent blockchain!

I will be talking more about my implementation of Satoshi Nakamoto’s paper in the next article, and as promised, I will be revealing the errors in my architectural ideation. I wanted to get a little creative by utilizing lambda functions (serverless architecture) to solve the PoW puzzles. Any guesses for why that would not work? Check out my next article if you’re still curious — or just ask Chat haha.

Funnily enough, the 51% attack could also be realized in the barter system, which only brings these two systems closer in commonality than one might otherwise assume. If I were to send a pigeon to a faraway land with a small chit stating that I am willing to ship 12 bags of grain in exchange for 7 cows, but never ship those commodities in the first place, while the 7 cows make their way to me, would that not be double-spending in its most ancient form?

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

References

1. Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf
2. High Scalability. (2023). Gossip protocol explained. https://highscalability.com/gossip-protocol-explained/
3. Confluent. (n.d.). ZooKeeper and Apache Kafka explained. https://www.confluent.io/learn/zookeeper-kafka/
4. MIT Digital Currency Initiative. (n.d.). 51% attacks. https://www.dci.mit.edu/projects/51-percent-attacks
5. Eyal, I., & Sirer, E. G. (2013). Majority is not enough: Bitcoin mining is vulnerable. arXiv. https://arxiv.org/pdf/1311.0243
6. Lopp, J. (2023). How many Bitcoin confirmations is enough? https://blog.lopp.net/how-many-bitcoin-confirmations-is-enough/

Blockchain and Its Commitment Issues was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.