status

Transaction Fees and Network Architecture As Spam Protection

Published 10.4.2024

Unlike Bitcoin or Ethereum, which operate on a traditional fee market, Cardano employs a system of fixed and predictable fees. These fees, while not exorbitant, are set at a level that effectively deters spam attacks. On the other hand, Solana’s extremely low transaction fees are a double-edged sword. While they make transactions affordable, they also lead to a high failure rate - currently, about 75% of user transactions do not go through. The network is flooded with transactions generated by bots.

Besides transaction fees, the network layer plays a crucial role in preventing spam transactions. Cardano node employs mem-pool and its protocol is architected in a demand-driven manner. This design allows each node, and every peer linked to it, to regulate the data arrival rate and the amount of outstanding data. On the other hand, Solana does not utilize a mem-pool, instead, all transactions are directed straight to the next validators. This article will elucidate why spamming Solana is relatively easy while doing so with Cardano is challenging.

How To Balance Inclusivity And Security?

Determining the right network usage fees is a challenge every blockchain team faces. These fees should reflect the actual costs of utilizing computing resources in a distributed network. The team must consider the needs of both the network operators, who run the block-producing nodes, and the users. While operators aim for maximum rewards, users prefer minimal fees. Balancing these interests is crucial.

Traditional fee markets, like those used in Bitcoin or Ethereum, have a downside. When network usage increases, so do the fees, making the network exclusive and accessible only to those who can afford high costs. In contrast, Cardano employs fixed and predictable fees. Users pay the same fee for transactions of the same size. The fee comprises a fixed component and a variable component based on the transaction size in bytes.

For a 200-byte transaction on Cardano, the fee is always exactly 0.164271 ADA - no more, no less. This fee equates to roughly $0.1. As the price of the ADA increases, so will the dollar value of the fee.

Compared to Bitcoin or Ethereum, which use a traditional fee market where fees increase with network demand, this fee is low. On Ethereum, fees can range from 1 to 100 USD (and more), even if the transaction fails.

Solana’s fee structure consists of two parts: a base fee and a priority fee. The base fee is a fixed charge per transaction. Currently, the base fee is set to 0.000005 SOL per signature. The priority fee is an optional additional fee that users can pay to increase the likelihood of their transaction being included in a block. This is particularly useful for time-sensitive transactions.

Fees are volatile and may change over time. Similar to networks using the fee market, if the network is used more, the fees increase.

At present, the transaction cost on Solana ranges from 0.00001 to 0.00003 SOL, which is approximately $0.001 to $0.005. When compared to Cardano, Solana’s fees are significantly lower, with a difference of about 20 to 100 times.

While low fees are appealing to users, making Solana an inclusive network, they do not protect spam transactions. Bots can send thousands of transactions per day for just a few dollars. This is why currently, 75% of user transactions on Solana fail.

Another crucial aspect to consider in network usage charges is the long-term economic sustainability of any decentralized blockchain. This implies that the fees should be sufficient to cover operational costs. Low fee yields can be counterbalanced by infinite coin inflation, but this could potentially devalue the coins over time due to endless inflation.

Solana operates on infinite coin inflation, while Cardano has a predetermined number of coins that will be circulated. At this juncture, it’s challenging to determine which strategy is more beneficial.

Returning to the topic of spam transaction protection, the traditional fee market employed by Bitcoin and Ethereum serves as an effective deterrent against spam transactions. Similarly, the fees on Cardano are relatively high, making network spamming attempts costly. However, Solana’s fees are so low that spamming becomes a cheap endeavor.

A blockchain network should be universally accessible and non-discriminatory towards its users. It doesn’t require any Know Your Customer (KYC) procedures. In essence, the network cannot censor transactions.

Any user who pays for a transaction should have a reasonable assurance that their transaction will be included in the upcoming block. Hence, introducing any form of filter is not feasible. The only constraint in utilizing the network is the transaction fees.

Why Do 75% Of User Transactions Fail On Solana?

For a transaction to be included in a block and permanently recorded in the ledger, it must traverse two underlying layers: the network layer and the consensus layer.

Initially, the transaction is processed by the network layer at the node. If it successfully meets the validation criteria of this layer, it proceeds to the consensus layer. The consensus layer is tasked with determining the contents of new blocks and achieving agreement on the block across all nodes in the network.

These principles are common to all blockchain networks, although they may differ in detail.

In certain blockchains where transactions exhibit non-deterministic behavior, a transaction can pass through to the consensus layer and still fail afterward. The reasons for this can vary. For instance, the conditions for executing a smart contract transaction according to the user's expectations may not be fulfilled. So the transaction is executed but fails even though the user has paid the fee.

The present issue with Solana is not that the consensus layer is dropping transactions. Rather, transactions aren't even making it from the network layer to the consensus layer. The network layer is so congested that the node opts to drop a portion of the transactions. A node safeguards itself from becoming overloaded and potentially crashing, which could occur due to resource depletion.

Users attempting to utilize Solana often find their transactions failing. They are then required to resubmit the transaction, which could necessitate multiple attempts. This is primarily because they are competing with bot-generated transactions. Bots, being faster and capable of generating a significantly higher volume of transactions than users, dominate the network. A huge number of transactions that are generated by bots are related to arbitrage. It's estimated that only 10% of transactions are user-generated.

In the picture, you can see how bots and users compete for whose transactions get into the block through the network and consensus layers.

Consider a scenario where out of 100 transactions, 10 are from users and 90 are from bots. If a node decides to drop 30% of transactions, it is possible that all user transactions could be dropped at a given time. If a node is overloaded, it may decide to drop even more transactions. Commonly, it is 50% of transactions.

The Solana network is operational and the computational resources of the nodes aren’t depleted due to the dropping of transactions. As a result, there’s no need for a network restart and the risk of a node crash is low. A restart wouldn’t address the issue with bots either. The main problem lies in the difficulty users face when trying to submit transactions. Despite the network being running, it’s essentially unusable. The majority of transactions that make it into the blocks are generated by bots, with only a few being user transactions.

In the picture, you can see red transactions from bots and users that the node dropped and several black transactions only from bots that reached the consensus layer and have a chance to be successfully processed (and stored in the ledger).

It’s important to note that while each user typically has a single connection for submitting a transaction, bots can maintain multiple connections simultaneously. This gives bots a significant advantage.

Moreover, it's common for a single bot to send spam transactions to multiple nodes. This is because bots aim to have their transactions processed as quickly as possible, and sending transactions to multiple nodes increases the likelihood of this happening.

Deciding which connections a node should drop to avoid being overwhelmed with transactions is a complex issue. At the network layer, analyzing transaction content is challenging due to the computational resources required for parsing message content. Furthermore, distinguishing between user transactions and those generated by bots is nearly impossible. Bots generate spam transactions, but from the point of view of the network and consensus layer, it can be a valid transaction containing fees. It is a valid spam transaction. The most straightforward strategy might be to randomly drop transactions, but this doesn’t effectively address the issue.

When a Solana node drops a transaction, the transaction fee is not paid. This is because the transaction fee is only incurred when a transaction is successfully processed and included in a block. If a transaction is dropped before it reaches the consensus layer, it is as if the transaction was never submitted, and thus no fee is charged.

The challenge confronting Solana’s team is that, even when bot-generated transactions are included in a block, the associated fees are negligible compared to the potential arbitrage profits. This holds even if the majority of transactions fail at the consensus layer and fees are paid.

Calculations

Daily, Solana handles approximately 25 million user transactions. From these transactions, user fees collected range from $25,000 to $100,000.

It's estimated that user transactions make up about 10% of the total, with bots accounting for as much as 90%. This implies that spammers would need to spend around $50,000 (250 SOL) per day on transaction fees.

Ethereum, on the other hand, collects around 400 ETH in daily fees, which equates to roughly $1.5 million. Therefore, spamming Ethereum would cost about 30 times more than spamming Solana.

The Cardano protocol collects about $12,000 in fees each day. This is nearly five times less than Solana. So, one might wonder why Cardano isn't overwhelmed with spam transactions. We'll delve into the network layer to answer this in the next section of the article.

It is necessary to realize that if Cardano could process the same amount of transactions as Solana, and this capacity can be achieved with Input Endorsers, the network would collect approximately 2.5M USD per day in fees. Spam protection would be sufficient.

A single block in the Cardano blockchain can accommodate approximately 250-300 basic transactions. If we consider a transaction fee of 0.1 USD for each, Cardano would receive an income of 25-30 USD per block. Given that Cardano generates a new block roughly every 20 seconds, this translates to a daily production of 4,320 blocks. If all these blocks were filled exclusively with valid spam transactions, the individual initiating the attack would incur daily costs exceeding 100,000 USD in transaction fees.

Solana Network Architecture

In the previous part of the article, we talked about the network layer only from the point of view of the validator node. That was somewhat simplified.

Both users and bots connect to validators through the RPC servers. Users do not directly know who the leader validator is, so they send their transactions to an RPC server that forwards the transactions to the current and next validator according to the leader's schedule. This schedule is known in advance.

Let's trace the lifecycle of a Solana transaction. Solana transactions are not gossiped into a mem-pool like in other networks. Instead, they must be sent directly as a UDP packet to the leader of the consensus protocol. RPC servers that know the leader schedule therefore send transactions directly to those validators that will produce blocks in the next round.

Solana tries to process all transactions that are submitted as soon as possible. Instead of diffusing transactions to all nodes (which takes time), transactions are directed to the next validators with the assumption that they will all be included in the next block.

In simpler terms, validators are vulnerable to bot attacks via a limited number of RPC servers. This is because all transactions are passed on to subsequent validators by these servers. When the volume of a spam attack surpasses the capacity of a handful of Solana blocks, it results in network congestion. Consequently, validators begin to drop transactions.

This means that bots don’t have to target many Solana validators, or rather RPC servers, across the network as by design all new transactions are directed to the next validators who can quickly become flooded with transactions.

In the picture, you can see how the RPC servers forward all transactions to the validator node 1. It can easily be overwhelmed with transactions and start dropping them. As soon as node 1 produces a block, RPC servers analogically push all transactions to the next validator, for example, node 2. I have simplified it for easier understanding.

The location of a transaction submission and the specific RPC server used is irrelevant, as all RPC servers aim to forward the transaction to subsequent validators. When the network is free from congestion, the system operates seamlessly, providing users with near-instant transaction confirmations. However, the network's architecture, coupled with low fees, unfortunately makes it susceptible to spamming.

It is necessary to add that, in addition to user transactions, voting transactions are a crucial part of the Solana network's consensus mechanism. Validators in the Solana network send votes to each other to confirm transactions. These votes are a key part of Solana's consensus mechanism that confirms transactions.

How Is Cardano Protected Against Spam Transactions?

Besides appropriate transaction fees, Decentralization is the most effective defense against spam attacks. With approximately 3,000 pools, Cardano exemplifies this. Each pool, which is a block-producing node, is usually linked to 2-3 relay nodes and is protected behind them. This arrangement prevents direct network communication with the block-producing node.

Relay nodes serve as proxies between the core network nodes and the internet, creating a security barrier around the core block-producing nodes.

A new transaction, once submitted, is transferred from a relay node to a block-producing node. This transaction is then diffused to all other block-producing nodes, a process that also occurs via relay nodes.

In contrast to Solana, transactions are not instantly processed. They are instead held in mem-pools across numerous network nodes. The next slot leader, which is the node granted the right to mint a new block, retrieves transactions from the mem-pool and inserts them into the new block.

In the picture, you can see a transaction (red box) that gradually reaches all mem-pools (yellow box) through the gradual diffusion (red arrows) of the transaction through relay nodes. I have simplified the image for easier understanding.

At any given time, the content of mem-pools across all nodes will vary. This is because transactions are simultaneously submitted from various locations, and their propagation takes time. As a result, each mem-pool holds a unique, yet closely similar set of transactions.

Out of the 3000 block producer nodes, each one has the potential to produce a new block comprising a comparable set of transactions. The node selected as the next slot leader will be responsible for producing this new block.

You will probably get the idea that a bot can easily fill the mem-pools of all other nodes in the network through one node, similar as described in the next image. Through node 1, all transactions reach node 2 and then node 3.

In a demand-driven style protocol like Cardano, each node controls the rate of data arriving, the maximum concurrency (number of simultaneous tasks), and the amount of outstanding data (data that has been sent but not yet acknowledged). This means that each node only requests more work when it is ready, rather than having work pushed upon it.

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

NtN follows a pull-based strategy, where the initiator node queries for new transactions and the responder node replies with the transactions if any exist. This protocol perfectly suits a trustless setting where both sides need to be protected against resource consumption attacks from the other side.

Observe the contrast between Cardano and Solana. In the case of Solana, the RPC servers delegate tasks to validators. However, in Cardano’s scenario, each node proactively safeguards its resources.

Every node is tasked with verifying the transaction before forwarding it. If a node dispatches invalid or unsolicited transactions, it will be disconnected by other nodes. To maintain the same number of connections, it has the option to establish a connection with a different node.

If a bot dispatches valid transactions to a single node, it can saturate that node’s mem-pool. Once the node’s mem-pool is full, it will cease to accept new transactions (it will not add them to the mem-pool). Other nodes will only begin to pull transactions if they have available space in their mem-pools. The transactions they acquire could be a mix of those generated by bots and those from users.

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

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

Each node that chooses to reject transactions, deeming them to be bot-generated, essentially protects other nodes in the network.

In the picture, you can see that the bot sends valid spam transactions to node 1. Node 1's mem-pool may be full of valid spam transactions. Alice and Bob send valid user transactions to node 3. Node 3 had an empty room in the mem-pool and pulled only one valid spam transaction from node 2. If node 3 became the slot leader in the next round, most of the transactions in the block would be from users.

When a bot submits a transaction, it gets added to the mem-pool, effectively reserving the ADA that was used as a transaction fee. The Cardano mem-pool has twice the capacity of a block, accommodating approximately 500 to 600 transactions. If a bot aims to populate 100 mem-pools with distinct transactions, it would result in a total of 60,000 transactions, costing around $6,000 in fees. The network could process this volume of transactions within an hour. Despite this, the network is likely to continue processing a significant number of user transactions via nodes that the attacker did not directly target and that contain user transactions in their mem-pool. However, some transactions may be pulled from other nodes, so they may be valid spam transactions.

Conclusion

In essence, fees and network architecture are the primary defenses against spam transactions. Arbitration bots are required to submit valid transactions including fees. This isn’t a traditional DDOS attack, where the objective is to flood the node with transactions on the network layer. If bots submit a high volume of transactions to the network, nodes may begin to drop user transactions at the network level. This poses a risk to all networks, as these are legitimate transactions that include paid fees. If an attacker can profit more from arbitrage, fees may not provide adequate protection against spam transactions. The attacker won’t run out of funds and can maintain the attack as long as arbitrage remains profitable. Therefore, the next crucial layer of protection is the network architecture.

When discussing decentralization and block production, one could argue that Solana is considerably more centralized (and thus more susceptible to transaction flooding) than Cardano, given that the leader schedule is predetermined and all transactions are routed to them. Note that the number of validators does not matter at all. The Solana team is faced with the difficult task of dealing with this, much like the Cardano team, which has to improve scalability. Neither of these challenges is trivial.

Featured:

Related articles

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