#Cardano recently faced a DDoS attack, but the network performed as anticipated, merely experiencing a slowdown. Most services, including SundaeSwap, which processed 5013 orders, operated effectively during the attack. The attacker incurred transaction fees, ultimately losing money without causing significant disruption. Cardano is the winner because its resilience has been proven. Come see how complicated it is to commit a DDoS attack on Cardano. The intent behind a DDoS attack on a blockchain is to hinder user access by overwhelming the network with spam transactions. These transactions are valid but costly due to the fees the attacker must pay. Invalid transactions would not be diffused. In contrast to client-server networks where attacks are directed at one or a few servers, Cardano's distributed structure comprises numerous nodes, each with its own mem-pool, making such attacks more complex. An attacker would need to simultaneously target hundreds of nodes. Each block-producing node in Cardano maintains a mem-pool, a kind of waiting room for transactions before they are included in a block. By default, the mem-pool is sized to hold double the number of transactions of the current block size, which equates to roughly 600 standard transactions. Transactions are processed on a first-come, first-served basis. A newly submitted transaction is passed from the relay node to the block-producer node, where it is stored in the mem-pool and then diffused to other block-producing nodes. Cardano operates on a demand-driven protocol, allowing each node to manage its data rate, concurrency, and data volume. Nodes request additional work only when they are ready to process it. The work is not pushed on them. The Node-to-Node (NtN) protocol manages transaction transfers between full nodes through relay nodes. It includes three mini-protocols: chain-sync, block-fetch, and tx-submission. These are multiplexed over a single TCP channel. NtN uses a pull-based strategy, where the initiator node requests new transactions, and the responder node supplies them if available. This protocol is well-suited for a trustless environment, protecting both parties from resource consumption attacks. Figure 1 demonstrates block diffusion among pools via mini-protocols. Alice sends a transaction to Node 1, marked by red arrows. Node 2, with space in its mem-pool, requests transactions from nearby nodes. It receives Alice's transaction from Node 1, illustrated by blue arrows 1 to 6. Later, Node 3 does the same with Node 2, shown by blue arrows 7 to 12, ensuring Alice's transaction is in all mem-pools. Nodes are responsible for validating transactions before relaying them. Invalid or unsolicited transactions can lead to disconnection. Mem-pools are concurrently populated from different network locations, with transactions disseminated through mini-protocols as needed. Figure 2 shows the sequential filling of three mem-pools. Alice, Bob, and Bot submit transactions from various places. Initially, each mem-pool holds one transaction. As time progresses, nodes pull transactions from peers, resulting in mem-pools containing both user and spam transactions. No matter which node becomes the slot leader, the transaction included in the next block will be the same, emptying all mem-pools. A bot could flood a node with spam transactions, filling its mem-pool and preventing further transaction acceptance. However, this doesn't stop other nodes from processing user transactions. Don't forget that slot leaders are randomly drawn based on the stakes of pools. The likelihood of a successful attack grows with the number of targeted nodes, as more mem-pools would be filled with spam. Yet, this also increases the attack's complexity and cost. Figure 3 shows a bot sending spam transactions to Node 1, while Alice and Bob send valid transactions to Node 3. If Node 3 becomes the slot leader, the block will mainly contain user transactions. When a new block arrives, nodes remove the included transactions from their mem-pools, freeing up space for new ones. If all mem-pools contained 600 identical spam transactions, they would be cleared within two blocks (40 seconds). If the spam transactions were unique, only one mem-pool would be cleared in the same timeframe. An attacker aiming to damage the network must submit unique transactions and incur fees. Flooding all 3000 mem-pools with unique transactions would require 1.8 million transactions, costing approximately 300,000 $ADA. The network could process this volume of transactions in about 33 hours (6,000 blocks). High throughput is a deterrent against spam attacks, as it requires more transactions to be submitted, raising the cost of the attack. For instance, if the Ouroboros Leios protocol increased Cardano's throughput by 100 times, the network could handle the same volume of spam transactions in just 30 minutes.