Blockchain Network and its Security issues underneath

Estimated read time 10 min read

This blog post is another continuation of Navigating the Financial Revolution: AI, Blockchain, and Traditional Banking and Exploring the Depths of Blockchain: Decentralization, Smart Contracts, and Beyond. Now, I will further iterate on Blockchain database processing and the data in the network. There are millions of nodes in a distributed decentralized blockchain. So the issue here is latency when there are too many nodes in a decentralized system. Data might get propagated later than usual when dealing with this system. In this blog post, I am going to focus more on the distributed database decentralized system like Bitcoin.

Are there Gossip in the Network?

So there are mechanisms implemented to overcome it. In a blockchain network, there are networks of nodes. Some nodes such as Bitcoin, have participants who perform the process of validating transactions and adding them to the blockchain. However, not all Blockchain have miners. Some networks use alternative consensus mechanisms like Proof of Stake, Delegated Proof of Stake, Proof of Burn, etc. In the Bitcoin Blockchain, someone performing a transaction will send the blockchain data to a few miners that are closest to the network to overcome the network latency. This is what is called a Peer-to-Peer networking protocol.

  1. Transaction Broadcasting: A person (node) in the town initiates a piece of gossip (Bitcoin transaction). They share it with their neighbors (connected nodes) in the town.
  2. Propagation: Each neighbor who receives the gossip (transaction) spreads it to their neighbors (connected nodes). This process continues until most people in the town (nodes in the network) are aware of the gossip (transaction).
  3. Memory Pool: Each person in the town maintains a personal “gossip pool” (mempool) where they store unconfirmed gossip (valid but unconfirmed transactions) they’ve heard.
  4. Block Broadcasting: Now, let’s say the town decides to have a meeting (mining process) to compile the most popular gossip (transactions) into a newsletter (block). The newsletter is then distributed to everyone in the town.
  5. Consensus: The townspeople (nodes) validate the information in the newsletter (block). If the gossip is accurate and everyone agrees, the newsletter is added to the town’s archive of newsletters (blockchain).

SHHHhhhh… Don’t say that Loud…

The idea is not to shout the “gossip” to everyone but just “whisper” silently. Although the data is large, most blockchains have variations and they implement it differently. For instance, a 10-minute cut-off might not be enough. The conflict has to be resolved.

In Blockchain technology like Bitcoins, most transactions are in the form of puzzles that need to be assembled in the form of “Blocks”. The blockchain is essentially a linked list of blocks, where each block contains a set of transactions. There are several components in a block such as transactions, timestamps, the hash of the block, etc. but the most important is the consensus. Only after a consensus is received despite all kinds of cyberattacks and difficulties, only one block at a time will reach the Blockchain at a time. This is because the node does not require a “first come first serve” to organize the block, but it has a notion of how to organize it. Weird, it even knows if it needs to receive the block or not! Another interesting component is how blocks are assembled in the system and this can be compared to “batch processing”. In that way, it improves efficiency to overcome latency issues in the network of nodes. Some companies doing heavy transactions pay for this service to check what they sent and what they received in the Blockchain. In that way, running a node can bring a side business growing although there are lots of challenges to that.

Consensus means no more fight, but still, it’s not that beautiful…

It kind of means it! Without consensus, nothing gonna build the blockchain. Nodes are located all across the world with different latency and hardware designs. Sets of data on the network are always different. There is no restriction to become a Node. Anyone can become a node and start mining which can be a security aspect. Decentralized record-keeping systems rely on a mix of good and rogue nodes using an algorithm to ensure that there is a unique record that is valid and shared across all nodes on the network. It’s an automated process that is distributed across the node. This is why even “consensus” is not trustworthy as it’s a “decentralized” system in the sense that one copy of data is not sufficient! Only when comparing and reconciling the differences Consensus is somehow valid – But in my point of view it’s still not promoting security but just a “feature-like” system that tends to be claimed as something in a secure namespace.

Some people might be skeptical asking: Which country controls most of the nodes? Or which Internet Network controls most of the nodes? Is there enough distribution? Is it trustworthy? Here is a capture from bitnodes.io

 

As from 2024, Countries with most nodes

Network with most nodes

A generic consensus model in the context of blockchain refers to a high-level framework or approach that outlines how participants in a blockchain network agree on the state of the distributed ledger. Different blockchain platforms may use various consensus models, and they can broadly be categorized into several types.

We just want to know the facts!

Who doesn’t want to know which piece of information is true? Since thousands of nodes are getting different pieces of information, despite ‘consensus’, there must be a way to come to a consensus. right? One way is to have a central validator, but this is not the case as this applies to the centralized system, which is the Fed. Another way is to make a majority voting system. The node posts their transaction and the node which was majority heard is voted. But still, this happens in private blockchain where each node knows each other before voting. There are also problematic situations if the central node is not a known entity!

In a random consensus model, all the nodes recognized each other nodes as “anonymous”. Still, how to trust each other? So a random anonymous node is picked up, broadcasts its transaction, and will say what is its other block. If that matches what others have, it’s accepted and added to the blockchain. This process keeps on repeating with other nodes as well. Whilst one mode is being verified, the other stays passive! This is how the data stays unified. There are still questions as to what happen if a few malicious systems or one malicious system were picked up. Can there be a compromise? It’s possible but the damage is way less in terms of stealing.

Prone to Attack – Double Spend Attack

However, a DDOS attack on the blockchain can start to be an issue where consensus is delayed which leads to some sort of backdoor to legally delay certain transactions in a decentralized system. This can be prone to further attacks such as the “Double Spend attack”.

A double-spend attack is a potential threat in digital currency systems, including cryptocurrencies like Bitcoin. It occurs when a user attempts to spend the same amount of cryptocurrency more than once, essentially trying to use the same funds for multiple transactions. The challenge in digital currencies is ensuring that once a unit of currency is spent, it cannot be spent again.

  1. Transaction Initiation: Imagine you go to a restaurant and hand your credit card to the waiter and tell them to charge $100 for the meal. The waiter takes your card to the payment terminal.
  2. Confirmation Delay: While the waiter is processing your payment, you quickly take out a duplicate of your credit card and hand it to the waiter at the same time, saying it’s for an additional $100 charge. The waiter starts processing this second payment.
  3. Race Condition: Both transactions are now in progress simultaneously. The first payment is being processed by the waiter, and the second payment is also being processed.
  4. Parallel Broadcasting: Both transactions are now in progress simultaneously. The first payment is being processed by the waiter, and the second payment is also processed.
  5. Forking the Blockchain: In an unexpected turn of events, the restaurant universe splits into two identical copies. In one universe, the first payment was processed first, and in the other universe, the second payment was processed first.
  6. Confirmation of One Branch: The majority of the restaurant staff (representing the network nodes) in one universe agrees that the first payment is valid and finalized. The other universe, where the second payment was processed first, becomes a parallel reality but is not widely accepted.
  7. Successful Double-Spend: In the universe where the second payment was processed first, you managed to trick the system into accepting the duplicate payment. Now, in this universe, you essentially spent the same $100 twice.

The technical reality is not equal to the financial truth. However, it is still possible to manage the blockchain properly to prevent this from happening. But someone might question whether to accept this kind of possibility in either a Centralized system or a Decentralized system!! The idea is to identify orphaned blocks in the system, but if acts too late, this will compromise the blockchain. You might be thinking about it in terms of Bitcoins or Money. But, if you have read my previous blog posts, you would now think about Security Tokens, which can also be used in a blockchain.

More attack – Sybil Attack

A Sybil attack is a type of attack on a network where an adversary creates multiple fake identities or nodes to gain a disproportionately large influence or control over the network. The act of inundating the system or nodes with many addresses can be simply referred to as that.  Any consensus algorithm must address this by looking deeply into the algorithm.

  1. Node Identity: Let’s again take an example of a restaurant: Each table (node) represents a diner. The waiter relies on the majority of honest diners to maintain the integrity of the dining experience.
  2. Creation of Multiple Fake Identities: An adversary enters the restaurant and decides to orchestrate a Sybil attack. Instead of being a single diner, the adversary creates multiple fake identities by occupying several tables. These tables are controlled by the same entity, representing the Sybil attacker.
  3. Influence and Control: With a significant number of tables (identities), the adversary can disproportionately influence the waiter. They might attempt to manipulate the order of dishes, influence the waiter’s decisions, or even control the overall dining experience.
  4. Undermining Trust: By controlling a large portion of the tables, the adversary undermines the trust and integrity of the restaurant. Other diners may find it challenging to trust that their orders are being processed fairly and that the overall dining experience is compromised.
  5. Double-Spending: In this restaurant, diners pay for their meals after consuming them. The adversary, with control over multiple tables, might attempt to manipulate the payment process by submitting conflicting payments for the same meal, similar to a double-spending attack in a blockchain system.

In summary, a Sybil attack in a blockchain system involves an adversary creating a large number of fake identities to gain undue influence, potentially compromising the security and trustworthiness of the network. Various countermeasures and consensus mechanisms are implemented to guard against the risks posed by Sybil attacks.

The way consensus model is improved by “weighting the node”. For example, measuring something costly to fake such as mining. Virtual mining is another way of weighting the total wealth.

I will further expand on these in some other blog posts. Thanks for the reading and please comment.

Nitin J Mutkawoa https://tunnelix.com

Blogger at tunnelix.com | Founding member of cyberstorm.mu | An Aficionado Journey in Opensource & Linux – And now It's a NASDAQ touch!

You May Also Like

More From Author