Solana
The Solana Trilemma
The Solana Trilemma

TL;DR

  • Spamming Issues: Solana faces significant spamming, with over 50% of block space filled by failed transactions. This vulnerability arises from its distinctive system that processes transactions in real-time without a mempool.
  • The Solana Trilemma: Solana network struggles to balance between among permissionless transaction transmission, real-time processing, and anti-spamming measures simultaneously. This trilemma is central to the challenges Solana is facing.
  • Proposed Solutions: Solutions under consideration include SWQoS (Stake Weighted Quality of Service), the JITO client for enabling MEV (Maximal Extractable Value), and Dynamic Base Fees. Each solution involves trade-offs, necessitating innovative approaches and continuous community involvement to address these challenges effectively.

Current State of the Solana Network

To process or not to process, that is the question

The Solana Network is currently facing a significant issue: spamming. Despite rapid growth fueled by the rise of meme coins and leading DEX volumes, Solana is encountering significant challenges due to spamming. According to the on-chain analytics, more than 50% of the block space is occupied by failed transactions, negatively impacting the user experience on the network. This issue is exacerbated by the fact that over 70% of block space is occupied by failed transactions, and the number of transactions reaching leader validators via RPC is significantly low. To understand why this is happening, we need to look at how Solana transactions are processed.

Solana Transaction Processing

Overview of Solana TX Processing

Solana employs a unique system that leader validators continuously execute incoming transactions, create blocks and propagate them. Validators then vote on these blocks, and once the votes surpass the Tower BFT threshold, the blocks are confirmed. Unlike Ethereum, Solana transactions do not have a nonce; instead validity is checked through a recent block hash, which does not influence execution order. RPC nodes relay user transactions to leader validators using UDP (QUIC) to ensure timely execution before expiration. This system allows Solana to maintain a mempool-less blockchain, achieving 0.4-second block creation times and real-time transaction processing.

The Solana Trilemma

The Solana Trilemma

However, this unique system structure has led to a new problem: spamming. Solana's efficiency and speed, combined with low fees and the absence of a mempool, make the network an attractive target for bots incentivized to send a tons of transactions for substantial economic rewards. This phenomenon can be described through the Solana trilemma: permissionless transaction transmission, real-time transaction processing, and anti-spamming. These three aspects cannot all be fully satisfied simultaneously.

Introducing a mempool would compromise Solana's high throughput and real-time processing capabilities. Implementing measures to filter spam transactions could threaten the permissionless nature of the network. Maintaining the current level of permissionless and real-time processing could lead to performance degradation due to spamming. These aspects are not binary but exist on a spectrum. An optimal balance needs to be found between user satisfaction and technical feasibility.

Options Discussed in the Solana Ecosystem


SWQoS (Stake Weighted Quality of Service)

Overview of SWQoS

Several solutions are currently discussed in the Solana ecosystem to address these issues. SWQoS (Stake Weighted Quality of Service) suggests partially compromising permissionless transaction transmission to gain advantages in real-time processing and anti-spamming. RPC and Validators form peer relationships, where RPC nodes relay transactions weighted by validator stakes. Transactions relayed through RPC nodes with higher stake validators have a higher chance of reaching leader validators and being executed. However, this could lead to a situation where only transactions from highly staked validators' peers are prioritized, creating a quasi-permissioned environment. High-frequency trading and arbitrage companies might monopolize transaction execution, disadvantaging retail users who might face higher costs. In an extreme scenario, this could potentially lead to a dystopia where a few entities monopolize network usage.

JITO

Overview of JITO MEV Client

Jito Labs, another proposed solution, focuses on enabling MEV (Maximal Extractable Value) on the Solana network through specialized clients. MEV searchers identify opportunities and generate bundles, which are then auctioned off to leader validators running the Jito client. The highest bidding bundles are included in blocks, pausing block creation for 200ms during the auction. However, only 25% of validators currently run the Jito client, and broader adoption requires it to be more cost-effective than spamming.

Additionally, increasing demand for MEV and overlapping account access for each MEV bundle could complicate the auction process, raising concerns about continuous block creation without empty slots. This situation might lead to a predictable virtual mempool environment, moving away from Solana's mempool-less nature. Such a shift could not only eliminate real-time transaction processing but also create a private mempool, increasing the economic hurdle for transaction processing.

Dynamic Base Fee

A more recent proposal is the Dynamic Base Fee, which suggests changing the current fee structure to increase the cost of spamming relative to the economic incentives. Solana currently charges 0.000005 SOL per signature in a transaction, irrespective of the block space usage. Dynamic Base Fee proposes that fees adjust dynamically based on CU usage and account access costs, increasing during network congestion. This approach aims to make spamming economically unviable by raising costs during network congestion. Local Fee Market, a related concept, suggests that write lock costs on congested accounts increase, raising transaction fees proportionally. Implementing such a system would encourage more efficient and parallel account usage in on-chain programs. However, the dynamic fee model might deter users due to unpredictable costs, affecting the network's accessibility.

Conclusion

Solana's growth highlights its success as an accessible, high-performance blockchain but also exposes its vulnerabilities to spamming. Addressing the trilemma requires innovative approaches, as seen with SWQoS, Jito, and Dynamic Base Fee. Solana's ability to balance permissionless transaction transmission, real-time processing, and anti-spamming measures will determine its long-term viability. Like Ethereum's move towards L2 solutions, Solana might need out-of-the-box thinking to evolve and remain a preferred global state machine. Continuous development and community engagement are crucial for Solana to navigate its trilemma and grow as a major blockchain infrastructure.

Go back