You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $40/month you can upgrade to our FULL library of 60+ reports (including this one) and complete industry-leading analysis on the top crypto assets. 

Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:

• Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
• Early access to future CORE ratings: Being early is sometimes just as important as being right!
• Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
• CORE report Audio playback: Don’t want to read? No problem! Listen on the go.

In April 2024, the Solana network faced significant congestion, resulting in substantial delays and a high transaction failure rate. Reports indicate that over 70% of non-voting transactions failed to process successfully, highlighting critical issues within the network's architecture.

Causes of Transaction Failures

Solana transactions typically fail due to execution failures and transaction drops. Execution failures occur when the network recognizes a transaction but cannot complete it, consuming gas fees without achieving the desired outcome. Common causes include unmet preconditions, such as interacting with an already sold-out mint function or encountering excessive slippage due to rapid price fluctuations exceeding set tolerance levels. Transaction drops happen when the network fails to recognize or record a transaction. Users might notice this on tools like Solscan, where no record of the transaction appears, often indicated by a blank page. These failures usually stem from network layer issues like bandwidth limitations or data propagation problems rather than flaws in the transaction itself.

Generally, the fee market in Solana has proven to be inefficient. Notably, the base fees are not aligned with the compute units (comparable to Ethereum’s gas units), and priority fees, although based on compute units, are set by the units requested rather than those actually used. This system discourages optimizing the compute resources needed for transactions, as developers and users often request more compute units than necessary without incentives to minimize them. The v1.18 upgrade plans to address this by prioritizing transactions that request fewer compute units, potentially alleviating some congestion. There are also ongoing discussions about increasing the overall block space limits to expand capacity and implementing economic upgrades, such as SIMD-110, to introduce a market similar to Ethereum’s EIP-1559 for managing write lock fees, aiming to reduce spam further.

Network Layer Challenges

Solana's architecture aims for high throughput and speed, enabling continuous block production. Unlike traditional blockchains that rely on a mempool to queue transactions, Solana prepares transactions directly for the next block, reducing latency and enhancing efficiency. This process depends on the swift delivery of transactions to the block leader, who compiles the new block. Disruptions in the connection to the block leader can prevent transactions from being included in the next block. To mitigate this, Solana employs a networking layer that empowers block leaders to manage traffic by throttling connections, helping to prevent congestion and potential network halts.

Solana has enhanced its networking layer by integrating the QUIC protocol, developed by Google in 2012, to expedite network communications. QUIC’s flow control mechanisms, which manage data transmission rates to prevent congestion, align with Solana’s goals for high speed and throughput. This upgrade reduces connection times, lowers latency, and improves the speed and reliability of user interactions with the block leader.

However, the implementation of throttling mechanisms within QUIC has room for improvement. Ideally, throttling should be based on well-defined criteria such as transaction fees or other metrics reflecting a transaction's value or importance. Currently, connections are throttled without clear criteria, leading to random transaction drops. This undermines the network's fairness and efficiency, as even transactions willing to pay higher fees might be dropped.

Scheduler Mechanisms

Unlike Ethereum, which processes transactions sequentially and may experience delays during high network congestion, Solana has a built-in scheduler developed by Solana Labs and integrated into each validator's software. This scheduler allows for continuous and independent transaction scheduling directly within the protocol. The transaction scheduler in Solana, which is crucial for building blocks, currently suffers from a lack of deterministic transaction ordering. This means it doesn't guarantee that transactions with higher priority fees are processed earlier, nor do they have a better chance of being included in a block. This system, which relies partially on variance and operates on a first-in, first-out basis, has unfortunately encouraged spamming. In response, Andrew Fitzgerald from Anza has been pivotal in developing improvements for this scheduler.

Solana's scheduler employs a multi-threaded approach, processing multiple transactions concurrently across four default threads. This parallel processing capability, facilitated by the Proof of History mechanism, efficiently manages the locking and unlocking of accounts for transaction processing. By allowing non-overlapping transactions to proceed simultaneously, Solana significantly increases its network throughput and efficiency, theoretically reducing wait times for transaction processing and offering a more responsive network experience.

However, the scheduler in Solana exhibits non-deterministic characteristics, particularly in how it assigns and processes transactions across multiple threads. Transactions are randomly assigned to one of the four threads, each maintaining its own queue. This randomness helps avoid conflicts and optimizes processing efficiency, as the assignment is not based on predetermined rules like the current load on each thread.

Priority fees aim to influence the order of processing within the threads once transactions reach Solana's scheduler. Essentially, paying more should theoretically speed up processing after the scheduler picks up a transaction. However, a high-priority fee transaction can still be processed later than a lower-priority fee transaction if it is assigned to a busier thread. This randomness means that paying a priority fee does not guarantee faster processing if the transaction ends up in a busier thread. Therefore, while priority fees do matter within each thread, their overall effectiveness can be limited by the scheduler’s design, which can sometimes make spamming transactions more effective for ensuring faster processing.

Ethereum’s EVM can, in theory, handle up to ~2,000 TPS, as seen in Binance Smart Chain when you max out the gas limit and block times. However, even this is insufficient to service long-term block space demand. Solana made some impressive innovations to scale sequencing, taking advantage of a parallelizable execution environment and a clever consensus mechanism, which allows for far more efficient throughput. But, despite its improvements, this is neither sufficient nor scalable. As Solana increases its throughput, the hardware costs to run a node and process transactions also increase.