Recently, we saw Solana bombarded with trolls about failed transactions onchain.

Before I start, it's important to understand that the issues Solana is facing are not unique to this blockchain. Every major blockchain platform has faced scalability and congestion challenges at some point in its evolution. Ethereum and its L2s experienced periods of severe network congestion and high fees during the CryptoKitties craze and the recent inscriptions rush earlier this year. Even the Bitcoin network has experienced transaction backlogs and high fees during periods of heightened activity.

At the core of the problem is the discrepancy between Solana's transaction processing capacity and the actual demand during periods of high network activity.

Unlike Ethereum, which employs a mempool to hold pending transactions before they are included in a block, Solana's design allows transactions to be sent directly to the block leader. While this approach reduces latency and improves efficiency under normal circumstances, it also makes the network more susceptible to congestion and overload.

So, Solana transactions were failing primarily due to issues with the network's networking stack. The networking stack is the underlying infrastructure responsible for handling communication between validators and propagating transactions across the network.

What's concerning in Solana's case is the fundamental nature of its issues.

1. The Networking Stack problems, and

2. the inability to effectively manage connections during high-demand periods

point to potential architectural flaws or limitations in Solana's design.

The problem arises when the demand for transactions exceeds the capacity of the block leaders (validators). In Solana's architecture, when a user submits a transaction, it is sent directly to the block leader responsible for producing the current block. This is different from other blockchains like Ethereum, where transactions first go to a mempool before being picked up by validators.

When there is a surge in transaction volume, such as during periods of high market activity or when bots are spamming the network with transactions, the block leaders can become overwhelmed. If the number of incoming transactions exceeds the block leader's capacity to process them, the networking stack starts to struggle.

Dropped transactions occur when a user's transaction fails to be included in a block and seems to disappear without any feedback. This is considered a worse user experience compared to failed transactions, which at least provide some indication of what went wrong.

From a user's perspective, a failed transaction is like sending a message into the void. You think your transaction went through, but it just disappears without a trace. No confirmation, no feedback, just a whole lot of uncertainty. It's a far cry from the seamless experience we all hope for when interacting with a blockchain.

Solana's networking stack is responsible for handling the communication between validators and the propagation of transactions. When the demand for transactions exceeds the capacity of the block leaders (validators), the networking stack struggles to cope. Solana uses QUIC protocol to manage network congestion, but it is not properly optimized. As a result, connections are dropped unintentionally, leading to transactions being dropped.

The issue of failing transactions on the Solana network is complex and multifaceted, highlighting the challenges of scaling L1s and L2s alike. Solana's unique architecture, which aims to achieve high throughput and low latency, has exposed certain vulnerabilities in its networking stack.

Solana uses "QUIC" to manage network congestion. However, the implementation of QUIC in Solana's networking stack is not optimized properly. When the block leader is overloaded with transactions, QUIC is supposed to prioritize and handle the connections efficiently. But, due to the suboptimal implementation, QUIC ends up dropping connections that it shouldn't be dropping.

But here's the kicker: the implementation of quic in Solana's networking stack isn't quite up to par. It's like having a traffic controller who's a bit too trigger-happy with the red light. Quic ends up dropping connections that it shouldn't, leading to those frustrating failed transactions.

As a result, even legitimate transactions from users get dropped. When a transaction is dropped, it means that it fails to be included in a block, and the user doesn't receive any feedback or confirmation. The transaction seems to disappear as if it never happened. This is a worse user experience compared to a failed transaction, where the user at least receives an error message indicating that something went wrong.

One of Solana's key value propositions has always been its low transaction fees and high throughput through its novel PoH mechanism and data propagation model. However, these very features, which were meant to provide scalability, seem to be causing bottlenecks and vulnerabilities when faced with high demand and network spam from malicious actors.

This issue exposes a fundamental weakness in Solana's current design. The network's ability to handle high transaction loads is limited by the performance and efficiency of its networking stack. As a result, users experience dropped transactions, which is a frustrating and unintuitive outcome. The lack of feedback or confirmation leaves users uncertain about the status of their transactions, undermining the overall user experience.

To address this problem, I could see Solana working on probable solutions:

• One approach is to optimize the networking stack itself, which involves refining the implementation of QUIC and improving its ability to handle congestion. The stake-weighted quality of service (QoS) mechanism is a proposed solution, where transactions from staked connections are prioritized. By giving preference to validators with more stake, the network aims to reduce the likelihood of legitimate transactions being dropped.

  • In simple terms, it means giving priority to transactions from validators who have more skin in the game (i.e., more stake). By prioritizing transactions from reputable nodes, the network aims to reduce the chances of legitimate transactions getting dropped during times of high congestion.

  • However, this solution is not without its own challenges and potential drawbacks, as it introduces a level of centralization and may not be entirely effective in mitigating the issue.

• In addition to optimizing the networking stack, there are other avenues worth exploring.

  • Improving the fee mechanism and economic incentives could help discourage spam transactions and ensure that legitimate transactions are prioritized. By making it more costly to spam the network, attackers would have less incentive to congest the network with frivolous transactions.

  • However, this approach must be balanced against the goal of keeping transaction fees low and accessible for regular users. Since, Solana does not work with base fees, it is a tradeoff.

  • I previously wrote about how Solana's Fee Markets work.

• Furthermore, the development of parallel transaction processing techniques, such as sharding or side chains, could help alleviate the burden on the main network. By distributing the workload across multiple subnetworks or chains, the overall capacity of the network can be increased, reducing the likelihood of congestion and dropped transactions.

But here's the thing: scaling a blockchain is no easy feat. Solana's experience with failed transactions is a testament to the challenges that come with building a high-performance network. As the demand for decentralized applications grows, all blockchain networks will need to grapple with the question of how to handle increased traffic and maintain a seamless user experience.

In the end, it's all about finding the right balance. Solana's journey to address the failed transaction issue is an ongoing process of trial and error, collaboration, and innovation. The community's dedication to tackling this problem head-on is a sign of their commitment to building a robust and reliable network.

So, the next time you hear about Solana's failed transactions, remember that it's not just a simple glitch. It's a complex problem that highlights the intricacies of blockchain technology and the challenges of scaling. As Solana continues to evolve and improve, we can all learn valuable lessons from their experience.

This tweet sums up what I think about all this

• Why are Solana Transactions Dropping?

• Solana Congestion Problem

Thank you for reading through, and subscribe below for regular post updates.

I’d also appreciate it if you shared this with your friends, who would enjoy reading this.

You can contact me here: Twitter and LinkedIn.

Recently, we saw Solana bombarded with trolls about failed transactions onchain.

Before I start, it's important to understand that the issues Solana is facing are not unique to this blockchain. Every major blockchain platform has faced scalability and congestion challenges at some point in its evolution. Ethereum and its L2s experienced periods of severe network congestion and high fees during the CryptoKitties craze and the recent inscriptions rush earlier this year. Even the Bitcoin network has experienced transaction backlogs and high fees during periods of heightened activity.

At the core of the problem is the discrepancy between Solana's transaction processing capacity and the actual demand during periods of high network activity.

Unlike Ethereum, which employs a mempool to hold pending transactions before they are included in a block, Solana's design allows transactions to be sent directly to the block leader. While this approach reduces latency and improves efficiency under normal circumstances, it also makes the network more susceptible to congestion and overload.

So, Solana transactions were failing primarily due to issues with the network's networking stack. The networking stack is the underlying infrastructure responsible for handling communication between validators and propagating transactions across the network.

What's concerning in Solana's case is the fundamental nature of its issues.

1. The Networking Stack problems, and

2. the inability to effectively manage connections during high-demand periods

point to potential architectural flaws or limitations in Solana's design.

The problem arises when the demand for transactions exceeds the capacity of the block leaders (validators). In Solana's architecture, when a user submits a transaction, it is sent directly to the block leader responsible for producing the current block. This is different from other blockchains like Ethereum, where transactions first go to a mempool before being picked up by validators.

When there is a surge in transaction volume, such as during periods of high market activity or when bots are spamming the network with transactions, the block leaders can become overwhelmed. If the number of incoming transactions exceeds the block leader's capacity to process them, the networking stack starts to struggle.

Dropped transactions occur when a user's transaction fails to be included in a block and seems to disappear without any feedback. This is considered a worse user experience compared to failed transactions, which at least provide some indication of what went wrong.

From a user's perspective, a failed transaction is like sending a message into the void. You think your transaction went through, but it just disappears without a trace. No confirmation, no feedback, just a whole lot of uncertainty. It's a far cry from the seamless experience we all hope for when interacting with a blockchain.

Solana's networking stack is responsible for handling the communication between validators and the propagation of transactions. When the demand for transactions exceeds the capacity of the block leaders (validators), the networking stack struggles to cope. Solana uses QUIC protocol to manage network congestion, but it is not properly optimized. As a result, connections are dropped unintentionally, leading to transactions being dropped.

The issue of failing transactions on the Solana network is complex and multifaceted, highlighting the challenges of scaling L1s and L2s alike. Solana's unique architecture, which aims to achieve high throughput and low latency, has exposed certain vulnerabilities in its networking stack.

Solana uses "QUIC" to manage network congestion. However, the implementation of QUIC in Solana's networking stack is not optimized properly. When the block leader is overloaded with transactions, QUIC is supposed to prioritize and handle the connections efficiently. But, due to the suboptimal implementation, QUIC ends up dropping connections that it shouldn't be dropping.

But here's the kicker: the implementation of quic in Solana's networking stack isn't quite up to par. It's like having a traffic controller who's a bit too trigger-happy with the red light. Quic ends up dropping connections that it shouldn't, leading to those frustrating failed transactions.

As a result, even legitimate transactions from users get dropped. When a transaction is dropped, it means that it fails to be included in a block, and the user doesn't receive any feedback or confirmation. The transaction seems to disappear as if it never happened. This is a worse user experience compared to a failed transaction, where the user at least receives an error message indicating that something went wrong.

One of Solana's key value propositions has always been its low transaction fees and high throughput through its novel PoH mechanism and data propagation model. However, these very features, which were meant to provide scalability, seem to be causing bottlenecks and vulnerabilities when faced with high demand and network spam from malicious actors.

This issue exposes a fundamental weakness in Solana's current design. The network's ability to handle high transaction loads is limited by the performance and efficiency of its networking stack. As a result, users experience dropped transactions, which is a frustrating and unintuitive outcome. The lack of feedback or confirmation leaves users uncertain about the status of their transactions, undermining the overall user experience.

To address this problem, I could see Solana working on probable solutions:

• One approach is to optimize the networking stack itself, which involves refining the implementation of QUIC and improving its ability to handle congestion. The stake-weighted quality of service (QoS) mechanism is a proposed solution, where transactions from staked connections are prioritized. By giving preference to validators with more stake, the network aims to reduce the likelihood of legitimate transactions being dropped.

  • In simple terms, it means giving priority to transactions from validators who have more skin in the game (i.e., more stake). By prioritizing transactions from reputable nodes, the network aims to reduce the chances of legitimate transactions getting dropped during times of high congestion.

  • However, this solution is not without its own challenges and potential drawbacks, as it introduces a level of centralization and may not be entirely effective in mitigating the issue.

• In addition to optimizing the networking stack, there are other avenues worth exploring.

  • Improving the fee mechanism and economic incentives could help discourage spam transactions and ensure that legitimate transactions are prioritized. By making it more costly to spam the network, attackers would have less incentive to congest the network with frivolous transactions.

  • However, this approach must be balanced against the goal of keeping transaction fees low and accessible for regular users. Since, Solana does not work with base fees, it is a tradeoff.

  • I previously wrote about how Solana's Fee Markets work.

• Furthermore, the development of parallel transaction processing techniques, such as sharding or side chains, could help alleviate the burden on the main network. By distributing the workload across multiple subnetworks or chains, the overall capacity of the network can be increased, reducing the likelihood of congestion and dropped transactions.

But here's the thing: scaling a blockchain is no easy feat. Solana's experience with failed transactions is a testament to the challenges that come with building a high-performance network. As the demand for decentralized applications grows, all blockchain networks will need to grapple with the question of how to handle increased traffic and maintain a seamless user experience.

In the end, it's all about finding the right balance. Solana's journey to address the failed transaction issue is an ongoing process of trial and error, collaboration, and innovation. The community's dedication to tackling this problem head-on is a sign of their commitment to building a robust and reliable network.

So, the next time you hear about Solana's failed transactions, remember that it's not just a simple glitch. It's a complex problem that highlights the intricacies of blockchain technology and the challenges of scaling. As Solana continues to evolve and improve, we can all learn valuable lessons from their experience.

This tweet sums up what I think about all this

• Why are Solana Transactions Dropping?

• Solana Congestion Problem

Thank you for reading through, and subscribe below for regular post updates.

I’d also appreciate it if you shared this with your friends, who would enjoy reading this.

You can contact me here: Twitter and LinkedIn.