Continuous congestion, does Solana need Layer 2 and Rollup?

Original Title: “Solana Need L2s And Appchains”

Author: Yash Agarwal

Translated by: Shenchao TechFlow

A month ago, Vibhu, the founder of DRiP, sparked an urgent debate in a statement: Solana needs L2s and Rollups.

He feels this way because, due to the rise in SOL prices and network congestion, DRiP has been leaking a significant amount of value (about $20,000/week) to the base layer. The increase in activity on Solana has led to:

• Advantages: Enhanced liquidity, capital, and trading volume (attributed to composability)

• Disadvantages: Rising infrastructure costs, poor user experience, congestion

However, DRiP primarily uses Solana merely as infrastructure, distributing millions of NFTs weekly to thousands of wallets, and thus does not benefit from high composability. The growth of Solana's TVL and capital inflows has had little impact on DRiP, which is mainly troubled by disadvantages such as high infrastructure costs.

Vibhu pointed out: "The diminishing returns of composability." He also noted that Solana application developers are privately discussing their desire for Rollups, for reasons including:

• Increased transaction throughput, reduced block space competition, and lower fees

• Better control over the economic value generated by their businesses

In recent months, Solana has experienced multiple congestion events, from airdrops like JUP to peaks in ORE mining and meme coin trading. While some may argue that Firedancer can solve all these issues, let's be realistic: the timeline remains uncertain, and it cannot scale more than tenfold at present. Nevertheless, the fact is that among all major chains that have undergone various trials, Solana is considered the only true monolithic chain that remains.

Should Solana remain monolithic or become modular? Will Solana evolve like Ethereum, adopting decentralized L2 and L3 solutions? What is the current landscape of application chains and Rollups on Solana?

To answer these questions and summarize the entire debate, this article will explore all possibilities, discuss various projects, and evaluate their pros and cons.

This article will not delve into technical details but will take a more market-oriented and practical approach to discuss various scaling methods to provide an overview.

In short, we will discuss:

• Solana and congestion

• Making Solana modular

• Solana application chains and examples

• Solana L2 and Rollups (RollApps) and examples

• Infrastructure supporting Rollups and application chains

Solana and Congestion

Let's first address the elephant in the room: the Solana network has been very congested recently (most of which has now been resolved), due to activities like airdrops and a large number of meme coin trades, leading to high ping times, a high proportion of failed transactions, and increased network fees due to priority fees. Despite these issues, Solana has maintained a processing speed of about 1-2k TPS, which is more than all EVM chains combined. I would say this is a good problem for a blockchain, and it has also tested Solana's monolithic thesis.

The Solana Foundation recently published a blog post, urging projects to take immediate action to enhance network performance, including:

• Implementing priority fees, which are crucial for avoiding delays or lost transactions.

• Optimizing the use of compute units (CUs) through a penalty system, only using the necessary parts.

• Implementing priority-weighted Quality of Service (QoS), allowing applications to prioritize user transaction processing.

However, all these measures can only improve transaction completion rates to a certain extent and do not guarantee a smooth user experience for transactions. An immediate solution to this problem is the highly anticipated new transaction scheduler, which is planned for release in version 1.18 at the end of April. It will be launched alongside the current scheduler but will not be enabled by default, allowing validators to monitor the performance of the new scheduler and easily revert to the old scheduler if any issues arise. This new scheduler is designed to fill blocks more efficiently and economically, improving the inefficiencies of the old scheduler. Read this article for a deeper understanding of the new scheduler.

Anza (a derivative entity of Solana Labs) has been continuously attempting to address the network congestion issues, which have been identified as related to QUIC implementation issues, as well as the behavior of the Agave (Solana Labs) validator client when asked to handle a large number of requests.

While proponents of modularity strongly advocate for Solana to adopt a "modular roadmap," Solana Labs/Anza (the core maintainers of the Solana protocol) remain focused on optimizing throughput and latency at the base layer. Some potential improvements include:

1. A comprehensive reform of the fee market and an increase in base fees (currently set at 5,000 Lamports or 0.000005 SOL)

2. Implementing exponential write lock fees for accounts, gradually increasing fees over time to avoid spam

3. Optimizing CU (compute unit) budget requests through a penalty system.

4. Strengthening the overall network architecture

Even with these vertical scaling (single-chain) improvements, we cannot rule out the possibility of Solana adopting horizontal scaling (Rollups). In fact, Solana can be a hybrid of both, serving as an excellent base layer for Rollups with extremely low latency block times (around 400 milliseconds), which would greatly benefit Rollups, such as achieving ultra-fast soft confirmations from sequencers. The best part is that Solana has historically implemented changes quickly, which may make it a more efficient Rollup layer than Ethereum.

Update: Anza has now released some patches to help alleviate ongoing network congestion and will follow up with further enhancements in v1.18.

Making Solana Modular

Efforts to make Solana modular have already begun. As shown in a post by Anza DevRel, Solana validators and SVM (the execution environment for processing transactions and smart contracts/programs) are tightly coupled and maintained by Anza. However, the validator client and SVM runtime will be separated in the coming months. This separation will facilitate forking SVM and easily creating 'Solana application chains.'

For Rollups, the benefits may come from optimizing Solana's data availability (DA)/blob layer, although this may occur in later stages.

Anza engineer Joe C has also announced plans to modularize SVM, where the transaction processing pipeline will be extracted from the validators and placed into SVM. This will allow developers to run implementations of SVM independently of any validator operations.

An isolated SVM will be a collection of completely independent modules. Any SVM implementation can drive these modules through clearly defined interfaces, further lowering the barriers for SVM-compatible projects, as it greatly reduces the overhead required to establish custom solutions. Teams can implement only the modules they are interested in while leveraging modules from established implementations like Agave or Firedancer.

In short, Solana will become more plug-and-play, making Solana application chains and Rollups easier to create.

Overall, there are two directions to go: Layer-2s/Rollups and application chains. We will examine these two directions one by one.

Solana Application Chains

Also known as SVM forks, these are essentially forks of Solana chains dedicated to specific applications. Pyth was the first Solana application chain, but the concept gained real attention when Rune, the founder of Maker, proposed developing a Maker application chain (for governance) based on the Solana (SVM) codebase. He chose SVM because it has a strong developer community and technical advantages that surpass other virtual machines, aiming to fork the best-performing chains to better meet consumer needs. Although no actions have been implemented yet, this move has sparked urgent discussions about Solana application chains.

Broadly speaking, they can be divided into two types:

• Permissionless: Anyone can join the network, similar to the current Solana mainnet

• Permissioned: Packaged by the Solana Foundation as "Solana Permissioned Environments (SPEs)" for institutional use, allowing entities to build and maintain their own chain instances, supported by SVM.

Pyth: The Progenitor of Solana Application Chains

At one point, Pyth accounted for 10-20% of all transactions on the Solana mainnet. However, it does not require any composability, so they simply forked the Solana codebase. This allowed them to leverage Solana's 400-millisecond fast block time for high-frequency price updates. Pythnet is the first network to adopt SVM as its application chain.

The Pythnet application chain is an authorized proof-of-stake fork of the Solana mainnet, serving as the computational base layer for processing and aggregating data provided by data publishers from the Pyth network.

Why did Pyth migrate?

• It does not require composability, allowing it to escape mainnet congestion

• It needs a permissioned environment for publishing data

++Cube Exchange++ is another example, a hybrid CEX deployed as a sovereign SVM application chain (with a fully off-chain order book and settlement on its SVM application chain).

Some examples of Solana application chains include:

• Perp DEX: Like ++Hyperliquid++, Perp DEX can operate as a standalone L1 network. Additionally, for trading use cases, the number of trades per block can be customized, or conditional logic can be implemented, such as integrating the execution of stop-loss orders directly into L1, ensuring it is executed as a state transition, or introducing application-specific atomic logic.

• AI and DePIN: These can have a list of controlled service providers like Pyth. For example, Akash operates as a computing market through a Cosmos application chain.

• Governance application chains: The interest from MakerDAO in SVM application chains validates the potential attractiveness of sovereign governance application chains. Governance in cryptocurrency is still evolving, and having dedicated chains for forking can serve as a useful coordination mechanism.

• Future enterprise application chains: Potential applications include funds (like BlackRock) or payment systems (like Visa or CBDC).

• Gaming application chains: A casino gaming project on Solana is considering its application chain.

• Modified forks of Solana: Similar to Monad or Sei, which offer optimized EVM (parallelization), someone could build a more optimized version of Solana. This trend may become more common in the coming years, especially as the Solana mainnet begins to explore new design architectures.

Envisioning the Solana Application Chain Stack

While building an application chain may be relatively straightforward, ensuring connectivity between all application chains is crucial for interoperability. Drawing inspiration from Avalanche subnets (connected via native Avalanche Warp Messaging) and Cosmos application chains (connected via IBC), Solana could also create a native messaging framework to connect these application chains.

Middleware similar to Cosmos-SDK can also be created to provide a one-stop solution for building application chains with built-in support for Oracles (like Pyth or Switchboard), RPC (like Helius), and messaging connectivity (like Wormhole).

++Polygon AggLayer++ is also an interesting approach, allowing developers to connect any L1 or L2 chain to AggLayer, which aggregates ZK proofs from all connected chains.

Are Application Chains a Positive for the Solana Ecosystem?

Although application chains do not directly increase the value of SOL, as they do not pay fees in SOL or use SOL as a gas token unless re-staked SOL is used for economic security, they do greatly benefit the SVM ecosystem. Just as there is an "EVM network effect," more SVM forks and application chains will strengthen the SVM network effect. The same logic makes Eclipse (an SVM L2 on Ethereum) favorable for SVM, even though it is a direct competitor to the Solana mainnet.

Solana Layer 2

Solana's Layer 2, or Rollup, is a logically independent chain that publishes data to its main chain's data availability (DA) layer and reuses the consensus mechanism of the main chain. They can also use other DA layers, such as Celestia, but then it would no longer be a true Rollup. "RollApp" is a term commonly used to refer to application-specific Rollups (most Solana applications are exploring).

Are Solana's Rollups the Same as Ethereum's?

Clearly not. For Solana, Rollups are essentially abstracted from the end user. Ideologically, Ethereum's Rollups are top-down, with the Ethereum Foundation and leaders deciding to scale through Rollups, which they began supporting after the CryptoKitties incident. In contrast, on Solana, the demand is bottom-up, coming from application developers with significant consumer adoption. Therefore, most current Rollups are marketing strategies, driven more by narrative than by consumer demand. This is a significant difference that may lead to a future for Rollups that differs from what is seen on Ethereum.

Compression = Rollup?

L2s scale the underlying layer blockchain (L1s) by executing transactions on L2, batching transaction data, and compressing it. The compressed data is then sent to L1 and used in fraud proofs (optimistic Rollups) or validity proofs (zk Rollups). This proof process is referred to as "settlement." Similarly, compression can offload transactions from the mainnet, reducing contention for the underlying layer's state. Notably, Grass L2 will utilize state compression for its Rollup.

The State of Rollups on Solana

Currently, there are two "somewhat like Rollapps" applications running:

GetCode

A payment application with a micropayment SDK that enables anyone to pay and receive payments instantly, also utilizing a pseudo-Rollup for the application. It creates intents for all transactions and uses a Rollup-like sequencer to settle on Solana after N intervals.

Using a Rollup-like structure can achieve:

• Flexibility: Intents can represent various future activities, not just payment transactions. Additionally, if necessary, Solana as a chain can also be replaced.

• Instant and private: Given the soft finality of the sequencer, payments are instant even during Solana congestion. While transactions are visible on-chain, the exact value and intent remain obscured, ensuring user privacy.

MagicBlocks' Ephermal Rollup

MagicBlocks is a Web3 gaming infrastructure that has specifically developed ephemeral (or temporary) Rollups for gaming. It uses SVM's account structure, with game states divided into clusters. It temporarily transfers state to a secondary layer or "temporary Rollup," a configurable dedicated layer. The temporary Rollup runs as a specialized SVM runtime or Rollup runtime to facilitate transaction processing under increased throughput.

Using a Rollup-like structure can achieve:

• Customization of dedicated runtimes, including gasless transactions, faster block times, and integration of a ticking mechanism (e.g., an integrated transaction scheduling system without fees, similar to a clockwork).

• Developers can deploy programs to the base layer (e.g., Solana) instead of on a separate chain or Rollup. ER will not disrupt the existing ecosystem and allows for accelerated target operations without creating isolated environments. This means that all existing Solana infrastructure can be utilized.

This approach helps build a highly scalable system that can launch Rollups on demand and automatically scale horizontally to accommodate millions of transactions without the typical trade-offs of traditional L2s. While MagicBlock focuses on gaming, this approach can also be applied to other applications, such as payments.

Upcoming Solana Rollups

++Grass++: A DePIN project aimed at solving AI data issues through verified web crawlers. When Grass nodes crawl AI training data from the web, validators will store the data on-chain, accurately tracking the data's source and the nodes responsible for crawling the data, rewarding them proportionally.

Grass requires one million network requests per second, which is not feasible on the Solana mainnet. Therefore, they plan to ZK-proof the raw data of all datasets and batch settle on Solana L1. They are considering using state compression from another cluster and settling the root on the mainnet-beta.

This development will make Grass the foundational layer for a series of applications that can only be possible on top of Grass (note that platforms and infrastructure typically have higher valuations, and Grass is about to launch a token).

++Zeta++: One of the oldest perpetual exchanges on Solana, which once relied entirely on an on-chain perpetual options order book, is now also planning to move its matching off-chain through Solana Rollup.

Perpetual exchanges have an immediate PMF (product-market fit) for Rollups, as they significantly improve user experience. Just ask those trading between Hyperliquid or Aevo and the Solana perpetual options exchange, and you'll find that in the Solana perpetual exchange, you have to sign for each trade, a wallet pops up, and you have to wait about 10-20 seconds. Additionally, perpetual exchanges do not require synchronized execution and have high composability with other assets in other aspects of DeFi (especially in trading matching).

Interestingly, Armani, co-founder of Backpack, also stated on Twitter that they are now more inclined towards L2.

Sonic is also building a modular SVM chain (Hypergrid), which will allow games to deploy their own chains on Solana. There are also SVM-based Ethereum Rollups, such as Eclipse and NitroVM, which use SVM as the execution engine. Neon operates as an EVM-compatible L2 on Solana. Additionally, there are some projects in the conceptual stage, such as Molecule (an SVM Bitcoin Layer 2).

Sovereign SDK is another framework similar to node.js for building Rollups. Users bring their Rust code, and we convert it into an optimistic or ZK Rollup that can be deployed on any blockchain. Rust code can be your specific application logic or any virtual machine.

A Few Arguments About Rollups

1. Rollup = Alignment with SOL:

The term "ETH alignment" or better "ETH asset bundle preference" has become a popular meme. Do you think that's why Layer 2 and Restaking/EigenLayer have become the hottest narratives? It's because they enhance the "monetary properties of ETH," with ETH being used as the core asset. The same principle applies to Solana. The Solana community will rally around any solution that can enhance their SOL holdings; it's that simple. As the Solana ecosystem expands, the once-overlooked "monetary properties of SOL" will become significant. Remember, most Rollups are "marketing gimmicks," and since the market still values infrastructure more than applications, they offer better token value accumulation.

2. Rollups will feel like an extension of Solana

In addition to the security benefits (i.e., inheriting security from the base layer), easy access to Solana users and assets will be a significant advantage. As Jon Charbonneau pointed out, Ethereum Rollups like Base, Optimism, and Arbitrum feel more like extensions of Ethereum. Users keep the same wallet and address, the native gas token is a single standardized version of ETH, ETH dominates DeFi, all trading pairs are priced in ETH, social applications price NFTs in ETH and pay creators in ETH (e.g., friend.tech), and deposits into L2 are instant, etc. Similarly, this will happen on Solana. Learning from Ethereum's experience, most Solana Rollapps will not make users feel like they are using a separate chain (e.g., Getcode).

3. Solana will see more "RollApps" than "Rollups"

Solana does not face the same scaling issue as Ethereum, where the mainnet is unusable due to high gas fees; it has been highly optimized. However, some applications that require dedicated block space will create their own Rollups. While a general Rollup on Solana does not make sense to me, it is economically sensible for projects. For example, Base users generated $2 million in revenue for Coinbase in just one day! The incentives for builders are heavily skewed towards L2. However, as observed, each EVM Rollup seems to be an ordinary Rollup, like Lvm, Scroll, or zkSync, which have become ghost chains with only a few token airdrop trades conducted by those seeking airdrops.

Moreover, I feel that a general L2 on Solana may lead to the same issues previously seen on Ethereum, namely centralized Rollups, congestion, and liquidity fragmentation.

4. Why do some applications want to migrate to Rollapps/appchains?

Each application will initially launch on the Solana mainnet because hosting more applications on shared infrastructure can significantly reduce complexity for developers and users. However, as these applications grow, they may seek:

• Value capture: Internally internalizing value on a shared Solana layer designed for a single application is more challenging. MEV capture may be another profitable option for DEXs.

• Dedicated block space

• Customizability of use cases, such as:

• Privacy: For example, Getcode uses a sequencer to provide private payments for its users.

• Fee market experimentation

• Encrypted memory pools to minimize MEV

• Customized order books

However, not all applications wish to launch their own Rollup, especially those that have not yet reached a certain escape velocity (e.g., sufficient TVL, users, trading volume). Launching one's own chain today involves painful and unnecessary trade-offs (complexity, cost, worse user experience, liquidity fragmentation, etc.), and most applications, especially those in early stages, cannot justify the incremental benefits. Solana remains the core and soul of SVM development, and many new applications are likely to deploy because of this.

Application Builders: Solana Mainnet or Appchain or Rollup

For application builders: whether to choose Solana mainnet, Appchain, or Rollup entirely depends on the situation. If there is no strong need for composability with all other applications, moving some different components off-chain (whether Appchain or Rollup) makes complete sense. Users do not even need to know they are using a Rollup or Appchain. Grass, Zeta, and Getcode all abstract away any type of Rollup infrastructure they are using for their users.

For use cases that require permissions and customization, token extensions can also meet most needs, such as KYC/transfer logic, while retaining composability.

Will DRiP become an L2/Appchain?

Currently, DRiP uses on Solana:

• Users create wallets (which can be on L2/Appchain)

• Distributing compressed NFTs (which can be on L2/Appchain)

• Trading compressed NFTs (which can be on L2/Appchain, but requires bridging funds)

We can clearly see that there is no strong demand on Solana L1, aside from the technology that L2/Appchain can provide. Since DRiP's primary goal has always been web2 users, it can directly guide them to their chain, which can give it greater control in the long run, as it will not leak all value to the base chain (Solana). Additionally, DRiP has already achieved escape velocity (the largest consumer application on Solana) and can now transition to its own chain. For DRiP, a pseudo-Rollup structure like Getcode makes complete sense.

Infrastructure Driving Rollups and Appchains:

If the theory of Rollapp/Appchain is expanded, existing infrastructure providers will benefit greatly as they enter new markets:

• Existing Rollup-as-a-Service (RaaS) providers, such as ++Caldera, can easily enter the SVM market as demand arises. SVM Ethereum Rollups like ++Eclipse++ and ++NitroVM++ are also closely watching this opportunity. Additionally, Sovereign Labs offers a Sovereign SDK Solana adapter that can enable Rollups on Solana (not yet in production). Helius is another company very well-suited to build infrastructure for Solana L2, as Mert has hinted multiple times.

• Shared sequencers, such as ++Rome Protocol++, and demand for lightweight clients like ++Tinydancer. Shared sequencers could be interesting for Rollups as they enable activities like atomic arbitrage, MEV, and seamless bridging, thereby reducing liquidity fragmentation.

• Wallets like Phantom, Backpack, and Solflare. Multi-signature and smart contract wallet infrastructure, such as ++Squads. Squads has been positioned as "the clear smart contract wallet infrastructure layer for Solana and SVM."

• SOL Restaking: The modular perspective also advocates for re-staking, as these Rollups/Appchains may require SOL shared security and align more closely with Solana. This leads to:

• Early participants like ++Cambrian++, ++Picaso++, and ++Solayer++

• Jito's LSTs like ++Stakenet++ and ++Sanctum++

• Increased revenue for validators

Summary Thoughts: Can Solana Meet Global Demand?

Absolutely not. Let's be realistic: even considering Moore's Law (hardware performance will continue to improve, and Solana has already been optimized for such hardware advancements), this is unrealistic. I believe that all less critical transactions (like DRiP sending NFTs) will eventually migrate to their own chains, while the most valuable transactions will remain on the main chain, where true composability is crucial (e.g., spot DEX).

Moreover, this does not mean that Solana has failed in the competition of monolithic versus composability; it will manage cases that rely on composability and low latency better than other chains. No, Sui/Aptos/Sei/Monad, etc., currently do not have better options, as we do not know if they have undergone real-world testing with high user activity.

Unlike Ethereum, the Solana mainnet is not designed to be a "B2B chain"; it has always been a consumer chain. Building distributed systems at scale is very challenging, and Solana has the best potential to become the shared ledger for the world's most valuable transactions.

Does Solana need soulmates: will Appchains and Rollups be its perfect choice?