status

Understanding Resilient Of Cardano Against Spam Transactions

Published 17.4.2024

Blockchain networks, in their native form, face scalability challenges. The throughput of the network, often measured in transactions per second (TPS), is constrained by the block size and the block production rate. In situations where there's a sudden surge in transactions, the network can become congested, leading to potential difficulties for users attempting to submit transactions. In this piece, we’ll delve into the mechanics of transaction processing on the Cardano network and its robustness in handling spam transactions.

Blockchain Networks Get Clogged Up Often

First, it's crucial to comprehend that there's no foolproof defense against spam transactions. Every transaction that includes a network usage fee is ideally processed by the blockchain network, without any discrimination.

The blockchain doesn't differentiate between a transaction from an individual user and a multitude of transactions from a spam bot aiming to congest the network. From the blockchain's perspective, all transactions are valid. No predefined restrictions are limiting the number of transactions a user (or bot) can submit. At least in an ideal world.

Transaction fees serve as one of the preventive measures against spamming. For instance, a transaction fee of $0.1 would be reasonable for a transaction transferring $1000 worth of value. To flood the network with 1 million transactions at once would cost $100,000.

The blockchain network can become congested due to a sudden surge in demand, such as during the minting of a new NFT series. The author of the NFT series might instruct users to send transactions at a specific time interval. This could result in a flood of 1 million transactions into the network, causing congestion similar to a spam attack. The key difference is that the transaction fees are paid by 1 million users, each paying $0.1.

For other users, the outcome might be similar in both scenarios. They might encounter difficulties in submitting their transactions.

In the case of NFT series minting, the network will eventually process all transactions and return to accepting new transactions. However, in the case of a spam attack, the attacker can persist as long as they are willing to fund the attack.

It's worth noting that the attacker might be able to recoup some of the attack costs through economic gains, such as arbitrage. This, however, depends on various factors and is not guaranteed.

Cardano operates with a fixed transaction fee structure, where fees are determined based on the size of the transaction in bytes. For instance, a 200-byte transaction incurs a fee of 0.164 ADA each time.

Networks that employ a fee market have an edge, as users may opt to pay higher fees for usage when the network is congested. This implies that any attempt to spam the network becomes economically more demanding. The attacker is compelled to raise fees, as nodes can begin discarding transactions once the network capacity (for instance, mem-pools) is reached. These discarded transactions could be older ones with the lowest fees. Thus, the cost of a spam attack is unpredictable.

The cost of a spam attack is further amplified by high TPS and, to a certain extent, decentralization.

The quicker the network processes transactions, the more transactions the attacker must submit and also pay for. Networks with low TPS are easier targets for spamming.

Cardano, with its average TPS and predictable fees (Cardano doesn’t have a fee market so transaction fees never escalate), could theoretically be a prime target for a spam attack. However, Cardano exhibits strong resilience against spam attacks, thanks to the distributed nature of blockchain.

Cardano comprises approximately 3100 nodes, each possessing its mem-pool that is twice the size of the block size. Before the network halts acceptance of all new transactions, spam transactions must first theoretically fill all mem-pools across all nodes.

Why Is Scalability A Challenge For Blockchain?

In traditional server-based systems, scalability is often achieved by adding more servers when one server is unable to keep up with the demand. This is known as horizontal scaling. However, blockchain networks operate differently and cannot be scaled in the same way.

In a blockchain network, every node maintains a copy of the entire blockchain and participates in the consensus process. The consensus process involves agreeing on the transactions to be included in the next block and ensuring that all nodes have the same data. This is crucial for maintaining the integrity and security of the blockchain.

Adding more nodes to a blockchain network does not increase its scalability in terms of transaction processing capacity. It can potentially slow down the network. This is because each additional node increases the amount of communication required to reach a consensus, which can slow down the block-creation process.

Therefore, simply adding more nodes (or ‘servers’) to a blockchain network does not increase its scalability. Instead, scalability in blockchain networks is a complex issue that is being addressed through various strategies such as sharding (processing transactions in parallel), layer-2 solutions (off-chain transactions), and optimizing consensus algorithms. These solutions aim to increase the number of transactions the network can process per second without compromising its decentralized nature and security.

In a client-server model, the server is a single point of failure. If the server goes down, the entire system can become inaccessible. However, in a blockchain network, there is no central authority or server. The network is maintained by multiple nodes, each holding a copy of the entire blockchain. This means that even if one node fails, the network continues to function, ensuring uninterrupted service.

The blockchain trilemma is a challenge for all teams, as it is difficult to achieve decentralization and high scalability at the same time. For a server-client solution, scalability and spam defense are relatively simple.

In a server-client architecture, when the network becomes congested, several strategies can be employed to manage the load:

  • Throttling: This involves limiting the rate at which a server processes requests. It helps to prevent server overload by ensuring that the server does not receive more requests than it can handle at a given time.
  • Load Balancing: This technique distributes network traffic across multiple servers to ensure no single server is overwhelmed with too many requests.
  • Prioritization of Traffic: Some systems may prioritize certain types of traffic over others. For example, a video streaming service might prioritize video data over other types of data to ensure smooth playback.
  • Dropping Transactions: In extreme cases, a server might start dropping incoming requests when it's flooded with too many of them. This is usually a last resort to prevent the server from crashing.

However, these mechanisms are not directly applicable to blockchain networks due to their decentralized, permissionless, and open nature:

  • Decentralization: Unlike a centralized server, a blockchain network consists of multiple nodes, each maintaining a copy of the entire blockchain. This means that throttling or load balancing cannot be centrally managed.
  • Permissionless and Openness: Anyone can join and participate in a blockchain network, and every participant has an equal right to submit transactions. It is possible to prioritize transactions based on fees. However, the network can become exclusive, available only to the rich.
  • Fairness: The blockchain protocol ensures that all transactions are treated equally regardless of their origin and amount.

In a centralized system, a single server or a group of servers can manage the load by controlling the rate of service requests (throttling) or distributing the load across multiple servers (load balancing). However, in a decentralized blockchain network, these tasks cannot be centrally managed. This is because each node in the network handles its requests and there is no central authority to coordinate these tasks.

However, some projects tend to centralize consensus in this regard, as teams try to achieve a high TPS.

Blockchain ensures fairness through decentralization. This means that no single participant can manipulate the system for their own benefit. All nodes in the network have equal power and responsibility in maintaining the blockchain. Efforts to centralize consensus can lead to limiting the autonomy of nodes, i.e. to some form of unfairness in the system.

In the event of a severe spam attack, nodes may start discarding transactions or stop accepting the newly arriving ones. This is not an ideal solution, as it goes against the principle of fairness. But it's a necessary measure to protect the network and ensure its survival.

Every device that is connected to the network, i.e. also a blockchain node, must protect its resources from exhaustion, otherwise the device could crash. A possible crash of several nodes at the same time could endanger the functioning of the entire system. Restarting the network is not an option for blockchain.

However, it makes a difference if a specific node defends its resources autonomously, or if it is done by a central authority.

When a team aims to construct a blockchain with high transaction processing speed (TPS) and incorporate anti-spam mechanisms akin to those in a server-client architecture, they often need to compromise on decentralization. The consensus mechanism may exhibit elements of centralization. Greater centralization facilitates the development of protective measures against spam on the network.

How Resilient Is Cardano Against Spam?

In addition to suitable transaction fees, the decentralized structure of the blockchain network serves as a somewhat effective safeguard against spam attacks. Cardano's objective is to process all transactions that have been accepted.

If Cardano is unable to accept a newly submitted transaction, the user is promptly notified and can attempt to resubmit.

The Cardano network consists of 3,100 pools. Each pool, acting as a block-producing node, is typically connected to 2-3 relay nodes and is shielded behind them. This setup inhibits direct network communication with the block-producing node. Relay nodes function as intermediaries between the core network nodes and the internet, establishing a security perimeter around the core block-producing nodes.

In Cardano, each block-producing node, or pool, maintains its mem-pool. This is where transactions are held before being included in a block. The mem-pool's size is set to be double the size of the current block, allowing it to hold approximately 600 standard transactions or a smaller number of larger, higher-fee transactions.

The mem-pool serves as a network buffer and can cause a slight delay when incorporating transactions into a block. Operating on a "first-come, first-served" basis, a transaction in the mem-pool should be included in a new block within the next two blocks, assuming it has been diffused to all nodes. However, during times of network congestion, a transaction may only be present in a few mem-pools, leading to a longer wait time before it is included in a new block.

Upon submission, a new transaction is passed from a relay node to a block-producing node. This transaction is then diffused to all other block-producing nodes, a process facilitated by relay nodes. We will further discuss how Node-to-Node (NtN) mini protocols are utilized for transaction diffusion.

Transactions are not processed instantaneously. Instead, they are stored in mem-pools across various network nodes. The next slot leader, the node given the privilege to mint a new block, retrieves transactions from the mem-pool and includes them in the new block. As such, all pools in the Cardano network stand ready to mint a new block, enhancing the network's robustness by eliminating a single point of failure.

In the accompanying diagram, you can observe a transaction (represented by a red box) gradually reaching all mem-pools (depicted as yellow boxes) through the gradual diffusion (indicated by red arrows) of the transaction via relay nodes.

At any given moment, the contents of mem-pools across all nodes can differ. This is due to transactions being submitted from various locations simultaneously, and the time it takes for their propagation. Consequently, each mem-pool contains a unique but closely similar set of transactions.

Out of the 3,100 block-producing nodes, each has the potential to generate a new block containing a similar set of transactions. The node chosen as the next slot leader will be tasked with producing this new block.

Cardano operates as a demand-driven protocol. Each node controls the rate of incoming data, the maximum concurrency (number of simultaneous tasks), and the volume of outstanding data (data sent but not yet acknowledged). This means that each node only requests additional work when it is ready, rather than having work imposed on it.

The Node-to-Node (NtN) protocol facilitates transaction transfers between full nodes via relay nodes. NtN encompasses three mini-protocols (chain-sync, block-fetch, and tx-submission), which are multiplexed over a single TCP channel.

NtN employs a pull-based strategy, where the initiator node requests new transactions and the responder node provides the transactions if available. This protocol is ideally suited to a trustless setting where both sides need to be safeguarded against resource consumption attacks from the other side.

In the diagram below, you can observe how block diffusion among pools occurs through mini-protocols. Alice submits the transaction to Node 1 (represented by red arrows). Node 2, having free space in its mem-pool, begins to request transactions from its vicinity. Node 2 sends a request to Node 1 and thereby acquires Alice’s transaction (depicted by blue arrows 1 to 6). A moment later, Node 3 does the same, asking Node 2 (blue arrows 7 to 12). Alice’s transaction is now present in all mem-pools.

Each node is responsible for validating a transaction before it is relayed. If a node sends invalid or unsolicited transactions, it risks being disconnected by other nodes. To maintain its network connections, the node can opt to connect with a different node.

It’s important to understand that mem-pools are populated concurrently from various points in the network. Numerous users submit transactions simultaneously via different relay nodes. These transactions are then gradually disseminated through mini-protocols.

In the accompanying illustration, you can observe the step-by-step filling of three mem-pools. Alice, Bob, and Bot each submit transactions from different locations. At TIME-1, each mem-pool contains a single transaction. By TIME-2, nodes have pulled transactions from their peer nodes. Now, all mem-pools contain one bot transaction and two user transactions. Regardless of which node becomes the slot leader, the set of transactions in the subsequent block will be identical.

Let’s delve into what transpires during a spam attack.

A bot can inundate a single node with valid spam transactions, filling up that node’s mem-pool. Once the mem-pool is saturated, the node will stop accepting new transactions, i.e., it won’t add them to the mem-pool.

Other nodes will only start pulling transactions if they have space in their mem-pools. The transactions they pull could be a combination of those generated by bots and those from users.

A node can receive user transactions from its relay nodes. If a node has enough transactions to fill its mem-pool, it won’t need to pull transactions from other nodes. This is standard practice for all nodes in the network. If a bot targets a single node, it won’t be able to prevent the majority of user transactions from being included in the subsequent blocks.

The probability of successful attacks increases with the number of nodes targeted by the bots, as they would fill more mem-pools with valid spam transactions. However, this significantly complicates the attack and increases its cost.

Each node that opts to reject transactions, considering them to be bot-generated, essentially safeguards other nodes in the network.

In the accompanying illustration, you can see that the bot sends valid spam transactions to Node 1. Node 1’s mem-pool might be filled with valid spam transactions. Simultaneously, Alice and Bob send valid user transactions to Node 3. Node 3, having a space in its mem-pool, pulls only one valid spam transaction from Node 2. If Node 3 becomes the slot leader in the next round, the majority of the transactions in the block will be from users.

If either Node 1 or Node 2 is selected as the slot leader, the resulting block will be filled with spam transactions. However, all transactions will eventually find their way into a block if users can successfully submit them to the mem-pool.

As can be observed, Cardano accepts transactions up to the capacity of individual mem-pools across various nodes at any given moment. It doesn’t differentiate between spam transactions and user transactions.

Upon receiving a new block, a node examines the transactions within the block and removes those transactions from its mem-pool. This action frees up space in the mem-pool, allowing the node to accept new transactions.

If identical spam transactions were present in all mem-pools, all mem-pools would be emptied again within two blocks.

If unique spam transactions filled all mem-pools, only one mem-pool would be emptied after every two newly minted blocks.

If an attacker aims to prevent the submission of new user transactions for an extended period, they must continuously attempt to fill all mem-pools with unique spam transactions. Once a mem-pool is emptied, users might have the opportunity to submit a transaction before the attacker.

If an attacker submits spam transactions at a single location within the network, these transactions will probably saturate the mem-pool of a specific node. Simultaneously, these spam transactions will likely be partially pulled by neighboring nodes after a short delay. However, once these transactions are included in a new block, several mem-pools will be simultaneously emptied. Nodes that are further away are more likely to have a higher proportion of user transactions in their mem-pools.

Approximate Spam Attack Cost

Let’s break down the numbers.

A mem-pool can accommodate 600 standard transactions. Assuming the current market value of ADA, the transaction fees would amount to $50 for filling a single mem-pool.

With 3,100 nodes each having a mem-pool, the cost for an attacker to fill all mem-pools with unique transactions simultaneously would be approximately $155,000. This would require the submission of 1.8 million transactions.

Cardano can process 15 standard transactions per second, which equates to about 1.3 million transactions per day. This implies that within a day and a few hours, Cardano would be able to process all unique transactions in the mem-pool.

However, as soon as space becomes available in the mem-pool, users would promptly submit new transactions. Some of these newly submitted transactions would be processed ahead of older transactions in the mem-pool. Therefore, in reality, it would take longer to clear all spam transactions from the mem-pool.

The attacker has the option to prolong the attack.

An increase in the market value of ADA coins escalates the cost of executing a spam attack. Moreover, if Cardano’s transaction processing speed (TPS) is enhanced, say through the implementation of Input Endorsers, it would further inflate the cost of the attack. Accelerated transaction processing compels attackers to submit valid transactions (including fees) at a quicker pace. The implementation of tiered pricing positively influences resistance to spam transactions, as transactions become pricier in the higher tiers.

Conclusion

It's important to understand that resilience against spam transactions relies on the equitable acceptance of transactions across various nodes in the network. Even in situations where the network is congested, users should have the ability to promptly submit a transaction and have confidence that their transaction will be included in one of the upcoming blocks. Of course, some users may fail to submit the transaction. Well-balanced transaction fees serve as the best protection against spam transactions.

There should not be a central authority with the power to determine which transactions to reject or to restrict the transaction flow in any way. From a blockchain trilemma perspective, the challenge is to achieve high TPS while not sacrificing decentralization. For networks that currently have high TPS and low transaction fees, you will usually find some elements of centralization.

Featured:

Related articles

Did you enjoy this article? Other great articles by the same author