Solana needs to have application chains and/or rollups to alleviate network congestion. Can they become a good way for Solana to expand?
Author: YASH AGARWAL
Translated by: Blockchain in Plain English
A month ago, a statement made by Vibhu, the founder of DRiP, sparked intense discussions. DRiP is the top consumer application on Solana, distributing free NFTs from top artists. Vibhu's point of view is that Solana needs to have a second-layer network and/or rollups. He holds this view due to the rise in SOL price and network congestion, causing DRiP to lose approximately $20,000 in value per week.
The increase in activity on Solana has led to:
Advantages – increased liquidity, capital, and trading volume (benefiting from composability)
Disadvantages – rising infrastructure costs, poor user experience, network congestion
However, DRiP primarily utilizes Solana as infrastructure, distributing millions of artist NFTs to tens of thousands of wallets weekly, without benefiting from high composability. The growth in total staking and capital inflow on Solana has little impact on DRiP, as it is mainly troubled by high infrastructure costs and other disadvantages.
Vibhu pointed out, "Composability has diminishing marginal returns." He also mentioned that Solana application developers are privately discussing their need for rollups because:
Increasing transaction throughput, reducing block space competition, and lowering fees.
Better control over the economic value generated by their business.
In the past few months, Solana has experienced multiple congestion events, from the JUP airdrop to ORE mining and peak meme coin trading. While some believe Firedancer can solve all these issues, let's be realistic: the timeline remains uncertain, and currently, it cannot scale to more than 10x. Nevertheless, Solana remains the last truly monolithic structure among all battle-tested major chains.
Should Solana remain monolithic or become modular? Will Solana evolve to have decentralized second-layer and third-layer solutions like Ethereum? What is the current status of Solana's application chains and rollups?
To answer these questions and summarize the entire discussion, 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 discuss various expansion methods from a market-oriented and practical perspective to provide an overview. All insights, no nonsense—plus a lot of exclusive information. In short, we will discuss:
Solana and congestion issues
Making Solana modular
Solana application chains—with examples
Solana's second-layer and Rollups (RollApps)—with examples
Infrastructure supporting Rollups and application chains
1. Solana and congestion issues
Let's first talk about the current issues: recent high congestion on the Solana network (largely resolved now), mainly due to airdrops, a large volume of meme coin trading activities, leading to high latency, a higher transaction failure rate, and increased network fees due to rising priority fees. Nevertheless, Solana has consistently been able to handle approximately 1-2k TPS (transactions per second), exceeding the total of all EVM chains. I believe this is a good problem for a blockchain to have and also tests the theory of Solana's monolithic structure.
The Solana Foundation recently released a blog urging projects to take immediate action to improve network performance, including:
Implementing priority fees—crucial for avoiding transaction delays or losses.
Optimizing program compute unit (CU) usage—using only the necessary parts.
Implementing quality of service (QoS) based on staked weight—allowing applications to prioritize processing their users' transactions.
However, all these measures can only improve transaction completion rates to a certain extent and cannot guarantee a smooth user experience. An immediate solution to this problem is the highly anticipated new transaction scheduler, planned to be introduced in version 1.18, expected to be released in late April. It will be introduced 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 aims to more efficiently and economically fill blocks, addressing the inefficiencies of the old scheduler. Read this article for more detailed information about the new scheduler.
Anza (a derivative entity of Solana Labs) has been working to address network congestion issues, which are believed to be related to QUIC implementation and the behavior of Agave (Solana Labs) validation clients when handling a large number of requests.
While proponents of modularity strongly advocate for a "modular roadmap" for Solana, Solana Labs/Anza (core maintainers of the Solana protocol) are still focused on optimizing the throughput and latency of the base layer. Some potential improvements include:
Reforming the fee market and increasing the base fee (currently set at 5000 Lamports or 0.000005 SOL).
Implementing exponential write lock fees for accounts, gradually increasing fees over time to prevent spam transactions.
Optimizing CU budget requests through a penalty system.
Enhancing the overall network architecture.
Even with these improvements in vertical scaling (single chain), we cannot overlook the possibility of Solana adopting horizontal scaling (rollups). In fact, Solana can be a hybrid of both—it can serve as an excellent base layer for rollups, with ultra-low block times (approximately 400 milliseconds), which would significantly benefit rollups, such as making it possible to obtain super-fast soft confirmations from sequencers. Most importantly, Solana has historically implemented changes rapidly and may become a base layer for rollups more efficiently than Ethereum.
Update: Anza has now released some patches to alleviate some ongoing network congestion issues and will make further improvements in v1.18.
- Making Solana modular
Efforts to modularize Solana have begun. As pointed out in a post by Anza DevRel, Solana validators and SVM (the execution environment for processing transactions and smart contracts/programs) are closely coupled and maintained by Anza (a derivative entity of Solana Labs). However, in the coming months, the validator client and SVM runtime will be separated. This separation will aid in forking SVM and easily creating "Solana application chains."
For rollups, optimizing Solana's data availability (DA)/blob layer may bring benefits, although this may occur at a later stage.
Anza engineer Joe C has also announced plans to modularize SVM, separating the transaction processing pipeline from the validator and placing it into SVM. This will enable developers to run their own implementations of SVM and operate independently of any validator.
The isolated SVM will consist of fully independent modules. Any SVM implementation can drive these modules through defined interfaces, significantly reducing the overhead required to build custom solutions and lowering barriers for SVM-compatible projects. Teams can implement only the modules they are interested in while leveraging existing implementations to complete other parts, such as implementations from Agave or Firedancer.
In short, Solana will become more plug-and-play, making it easier to implement Solana application chains and rollups.
Overall, this can evolve in two directions: Layer-2s/Rollups and application chains. We will discuss each one by one.
3. Solana Application Chains
Also known as SVM forks, these are essentially forks of Solana chains specifically tailored for particular applications. Pyth was the first Solana application chain, but the concept gained attention when Maker's founder Rune proposed developing a Maker application chain (for governance) based on the Solana (SVM) codebase. He chose SVM due to its strong developer community and technical superiority, aiming to fork the best-performing chain to better meet consumer needs. While not yet implemented, this move sparked widespread discussions about Solana application chains.
In general, Solana application chains can be divided into two types:
Permissionless chains: Anyone can join the network, similar to the current Solana mainnet.
Permissioned chains: Built for institutions by the Solana Foundation, known as "Solana Permissioned Environments (SPEs)," allowing entities to build and maintain their own chain instances, supported by SVM.
Pyth – Solana Native Application Chain: Once accounted for 10-20% of all transactions on the Solana mainnet. However, it does not require high composability, so they simply forked the Solana codebase. This allowed them to leverage Solana's fast 400ms block time for high-frequency price updates. Pythnet is the first network to build an application chain using SVM.
Pythnet application chain is an authoritative proof fork of the Solana mainnet, serving as a computational base layer for handling and aggregating data provided by the Pyth data publishers network.
Why did Pyth choose to migrate?
It does not require high composability (especially for non-Solana applications), thus unaffected by mainnet congestion.
It needs a permissioned environment for data publishing.
It reduces the leakage of costs from the base layer (Solana) by internalizing fees.
Cube Exchange is another example, a hybrid centralized exchange platform 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 may include:
Perpetual Contract DEXs: Perpetual contract trading platforms, such as Hyperliquid, can operate as independent L1 networks. Additionally, for trading use cases, the number of transactions per block can be customized, or conditional logic can be implemented, such as integrating the execution of stop-loss orders directly into L1, ensuring their execution as state transitions, or introducing application-specific atomic logic.
AI and DePIN: These can have a range of controlled service providers similar to Pyth. For example, Akash operates as a computing marketplace through a Cosmos application chain.
Governance Application Chains: MakerDAO's interest in SVM application chains validates the appeal of a sovereign governance application chain. Cryptocurrency governance is still evolving, and having a dedicated chain for forking may be a useful coordination mechanism.
Future Enterprise Application Chains: Potential applications include funds (such as BlackRock) or payment systems (such as Visa or CBDC).
Gaming Application Chains: A casino gaming project on Solana is considering establishing its own application chain.
Modified Solana Forks: Similar to Monad or Sei providing optimized EVMs (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.
4. 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. Inspired by Avalanche subnets (connected through native Avalanche Warp Messaging) and Cosmos application chains (connected through IBC), Solana can also create a native messaging framework to connect these application chains. ```
Creating middleware similar to Cosmos-SDK is also a viable approach, providing an all-in-one solution for creating application chains with built-in support, including oracles (such as Pyth or Switchboard), RPC (such as Helius), and message connectivity (such as Wormhole), and more.
Polygon AggLayer is also an interesting approach, where developers can connect any L1 or L2 chain to AggLayer, which aggregates ZK proofs from all connected chains.
Are application chains positive for the Solana ecosystem?
While application chains will not directly accrue value to SOL, as they do not pay fees in SOL or use SOL as GasToken—unless re-staked SOL is used for economic security—they do greatly benefit the SVM ecosystem. Just as there is an 'Ethereum EVM network effect,' more SVM forks and application chains will strengthen the SVM network effect. Even though Eclipse (an SVM L2 on Ethereum) is a direct competitor to the Solana mainnet, the same logic applies to Solana, making SVM bullish.
5. Solana Layer-2s
Solana Layer-2s, or Rollups, are logically independent chains that publish data to the host chain's data availability (DA) layer and reuse the host chain's consensus mechanism. They can also use other DA layers, such as Celestia, but doing so would no longer be a true Rollup. "RollApp" is commonly used to refer to application-specific Rollups (the approach most Solana applications are exploring).
1) Are Solana Rollups the same as Ethereum's Rollups?
Clearly not. For Solana, Rollups mostly abstract away from end-users. Ideologically, Ethereum's Rollups are top-down, with the Ethereum Foundation and leaders deciding that scaling through Rollups is the best approach and supporting various L2s after the CryptoKitties incident. On Solana, the demand is bottom-up, coming from application developers with significant user adoption. Therefore, most Rollup strategies currently are marketing strategies, more driven by narrative than consumer demand. This is a significant difference that may lead to a different future for Rollups compared to what we see on Ethereum.
2) Is compression equivalent to Rollups?
L2s scale the base 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 Rollup) or validity proofs (zk Rollup). This proof process is called "settlement." Similarly, compression unloads transactions from the mainnet, reducing contention for the base layer's state. It's worth noting that Grass L2 will utilize state compression to achieve its Rollup.
3) Rollups Landscape on Solana
Currently, there are two "Rollup-like" applications in operation:
a. GetCode:
This is a payment application with a micro-payment SDK that enables anyone to make and receive instant payments, and it also uses a pseudo-Rollup as part of its application. It creates intentions for all transactions and uses a Rollup-like sequencer to settle on Solana after N intervals.
Adopting a Rollup-like structure brings the following benefits:
Flexibility: Intentions can represent various future activities, not limited to payment transactions. Additionally, if necessary, Solana as a chain can be replaced.
Instant and Private: Due to the soft finality of the sequencer, payments are instant even during Solana congestion. While transactions are visible on the chain, the exact value and intentions remain ambiguous, ensuring user privacy.
b. MagicBlocks' Ephermal Rollups
MagicBlocks is a Web3 game infrastructure that has developed Ephermal (or temporary) Rollups, specifically for gaming. It uses SVM's account structure, and the game state is divided into clusters. It temporarily moves the state to an auxiliary layer or "ephemeral Rollup," a configurable dedicated layer. The ephemeral Rollup, as a dedicated SVM runtime or Rollup, can provide higher throughput to facilitate transaction processing.
Adopting a Rollup-like structure brings the following benefits:
Customizable dedicated runtimes, including gasless transactions, faster block times, and integrated tick mechanisms (e.g., clock-like integrated transaction scheduling system, operating without fees).
Developers can deploy programs to the base layer (e.g., Solana) rather than a separate chain or Rollup. ER (Ephemeral Rollups) do not erode the existing ecosystem and allow for accelerated target operations without creating isolated environments. This means that all existing Solana infrastructure can be leveraged.
This approach facilitates building a highly scalable system, capable of launching Rollups on demand and automatically scaling to accommodate millions of transactions from users, without sacrificing the typical trade-offs of traditional L2s. While MagicBlock's focus is on gaming, this approach can also be applied to other applications, such as payments.
4) Upcoming Solana Rollups:
a. Grass
This is a DePIN project aimed at solving AI data issues through verified web scraping. When Grass nodes scrape web pages for AI training data, the validation nodes store the data on-chain, accurately tracking the data's source and which node is responsible for scraping it, and rewarding them accordingly.
Grass requires 1 million network requests per second, which is not feasible on the Solana mainnet. Therefore, they plan to ZK-proof all raw data sets and batch settle them to Solana L1. They are considering using state compression from another cluster and settling the root on mainnet-beta.
This development will make Grass the base layer for various applications that are only possible on top of Grass (note that platforms and infrastructure typically receive higher valuations, and Grass is about to launch its Token :P).
b. Zeta
One of the oldest perpetual DEXs on Solana, which used to rely entirely on on-chain perpetual order books, also plans to move its matching off-chain through Solana Rollup.
Perpetual DEXs have an immediate PMF for Rollups, as they greatly improve the user experience. Just ask those who have traded between Hyperliquid or Aevo and Solana perpetual DEX, the latter requires signing for each transaction, wallet pop-ups, and waiting for about 10-20 seconds. Additionally, perpetual contracts do not require synchronous execution and have high composability with other protocols in other aspects of DeFi, especially in trade matching.
Interestingly, Armani, co-founder of Backpack, also tweeted that they are now leaning towards L2.
Sonic is also building a modular SVM chain (Hypergrid) that allows games to deploy their own chains on Solana. There are also some Ethereum Rollups based on SVM, such as Eclipse and NitroVM, which use SVM as the execution engine. Neon acts as an EVM-compatible L2 on Solana. Additionally, there are some conceptual projects, such as Molecule (an SVM Bitcoin Layer 2).
Sovereign SDK is another framework similar to Node.js for building Rollups. Users provide their Rust code, and we convert it into an Optimistic or ZK Rollup deployable on any blockchain. The Rust code can be your specific application logic or any virtual machine.
5) Rollups = Aligned with SOL
"ETH alignment" or more appropriately "ETH backpack bias" has become a popular meme. Why do Layer 2 and Restaking/EigenLayer become the hottest narratives? Because they increase the "monetization of ETH," with ETH being used as the core asset everywhere.
The same principle applies to Solana. The Solana community will rally around any solution that increases their SOL holdings—simple as that. As the Solana ecosystem expands, the once overlooked "monetization of SOL" will become important. Remember, most Rollups are essentially "market positioning," as the market still values infrastructure more than applications.
6) Rollups will feel like an extension of Solana
In addition to the security benefits (i.e., inheriting security from the base layer), easy access for Solana users and assets will be a significant advantage. As Jon Charbonneau pointed out, Ethereum Rollups (such as Base, Optimism, and Arbitrum) are more like extensions of Ethereum. Users retain the same wallet and address, the native gas Token is a single canonical version of ETH, ETH dominates all trading pairs in DeFi, social apps price NFTs in ETH and pay creators in ETH (e.g., friend.tech), and deposits on L2 are instant, and so on.
Similarly, this will also happen on Solana. Learning from Ethereum, most Solana Rollapps will not make users feel like they are using a separate chain (e.g., Getcode).
7) Solana will see more "RollApps" rather than "Rollups"
Solana does not have the scaling issues like Ethereum, as the mainnet is highly optimized and cannot be used due to high gas fees. However, some applications that require dedicated block space will create their own Rollups. While I believe general Rollups on Solana don't make sense, economically, they make sense for projects. For example, Base users generated $2 million in revenue for Coinbase in one day! The incentives for builders are very much inclined towards L2. However, as observed, every EVM Rollup looks like a regular Rollup, and many projects, such as Linea, Scroll, or zkSync, have become virtual chains for token airdrops with only a few users conducting small transactions.
Additionally, I think general L2 on Solana may lead to the same Ethereum problems as before, i.e., concentrated Rollups, congestion, and fragmented liquidity.
8) Why do some applications want to move to Rollapps/appchain?
Every application will initially launch on the Solana mainnet, as hosting more applications on a shared Solana layer significantly reduces complexity for developers and users. However, as these applications grow, they may seek:
Value capture: Internalizing value on a shared Solana layer designed for an application becomes more challenging. For DEXs, MEV capture may be another profitable option.
Dedicated block space:
Customizability in usage, such as: Privacy: for example, Getcode uses a sequencer to provide private payments for its users.
Fee market experiments
Encrypted memory pools to minimize MEV
Custom order books
However, not all applications will want to launch their own Rollup, especially those that have not yet reached a certain escape velocity (e.g., enough TVL, users, transaction volume). Launching your own chain today involves painful and unnecessary trade-offs (complexity, cost, poor user experience, fragmented liquidity, etc.), and most applications, especially early-stage ones, cannot justify it for incremental gains. Solana remains the core and soul of SVM development, and many new applications may deploy because of it.
6. For application builders: Choosing Solana mainnet or Appchain or Rollup
Specific situations call for specific analysis. If there is no strong need for composability with all other applications, then it makes complete sense to move some different components off-chain (whether it's appchain or rollup). Users don't even need to know whether they are using a Rollup or Appchain. Grass, Zeta, and Getcode all abstract out the infrastructure of any type of Rollup they are using for their users.
For permissioned and customized use cases, Token Extension also meets most needs, such as KYC/transfer logic, while maintaining composability.
So, will DRiP be an L2/appchain?
Currently, DRiP is used on Solana for:
- User wallet creation (can be on L2/appchain)
- Distribution of compressed NFTs (can be on L2/appchain)
- Transactions of compressed NFTs (can be on L2/appchain, but requires bridging of funds)
We can clearly see that, apart from the technology that L2/appchains can provide, DRiP does not have a strong need to stay on Solana Layer 1. Since DRiP's primary target has always been web2 users, it can completely guide them to its own chain, which will give it more control in the long term, as it won't leak all the value to the base chain (Solana). Additionally, DRiP has reached escape velocity (the largest consumer application on Solana) and can now move to its own chain. Pseudo Rollup structures like Getcode make complete sense for DRiP.
Infrastructure supporting Rollups and Appchains:
If the proposition for Rollapp/Appchain expands, existing infrastructure providers will benefit greatly, as they will enter new markets: existing Rollup service providers like Caldera can easily enter the SVM market when demand arises. SVM Ethereum Rollups, such as Eclipse and NitroVM, are also closely watching this opportunity. Additionally, Sovereign Labs provides a Sovereign SDK Solana adapter that can enable Rollups on Solana (not yet in production). Helius is another company that is very suitable to provide infrastructure for Solana L2, as Mert has hinted at this multiple times.
Demand for shared Sequencers like Rome Protocol and lightweight clients like Tinydancer. Shared Sequencers may be interesting for Rollups, as they can enable activities such as atomic arbitrage, MEV, and seamless bridging, reducing liquidity fragmentation.
Wallets like Phantom, Backpack, and Solflare. Multi-signature and smart contract wallet infrastructure, such as Squads. Squads has always positioned itself as "explicit smart contract wallet infrastructure layer for Solana and SVM."
SOL restaking: Modular propositions also promote restaking, as these Rollups/Appchains may need shared security of SOL and be more aligned with Solana. This will lead to early participants, such as Cambrian, Picaso, and Solayer, through LST like Stakenet and Sanctum's Jito, and validators—increased income.
7. Summary thoughts: Can Solana meet global demand?
Absolutely not. Let's be practical: even considering Moore's Law (i.e., hardware performance will continue to improve, and Solana has already optimized for this hardware progress), it's not realistic. I believe all non-critical transactions (such as DRiP sending NFTs) will eventually move to their own chains, while the most valuable transactions will continue to stay on the main chain, where true composability is crucial (e.g., spot DEX).
This does not mean that Solana has failed in the monolith vs. composability battle; it will handle cases dependent on composability and low latency better than other chains. No, Sui/Aptos/Sei/Monad, etc., are not better at this currently, as we don't know if they have been tested with high real user activity.
Unlike Ethereum, the goal of the Solana mainnet is not to become a "B2B chain"; it is and will be a consumer chain in the past and future. There are significant challenges in building distributed systems at scale, and Solana has the greatest potential to become the shared ledger for the most valuable transactions globally.
Solana needs a soulmate: the question is whether Appchain and Rollup are its perfect match?
Source: https://blog.superteam.fun/p/solana-need-l2s-and-appchains
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
