Solana continues to be congested, does Sol need L2 and Rollup?

This article is machine translated
Show original
Solana Needs a Soulmate: Are Appchains and Rollups the Perfect Match?

Written by Yash Agarwal

Compiled by: TechFlow

A month ago, DRiP founder Vibhu sparked a much-needed debate with a statement: Solana needs to have L2 and Rollup.

He feels this way because DRiP has been leaking a lot of value (~$20k/week) to the base layer due to the SOL price increase and network congestion. The increase in activity on Solana has led to:

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

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

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

“There are diminishing returns to composability,” Vibhu noted, noting 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 business

Solana has experienced multiple congestion events over the past few months, from airdrops like JUP to ORE mining and Meme coin trading spikes. While one might say that Firedancer can solve all of these problems, let’s be realistic: the timeline is still uncertain and it cannot scale more than 10x at the moment. Nevertheless, the fact is that of all the major chains that have gone through various tests, Solana is considered the only true monolithic chain left.

Should Solana remain a monolith or become modular? Will Solana also evolve like Ethereum, adopting decentralized L2 and L3 solutions, etc.? 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 perspective and discuss various extension methods to provide an overview.

In short, we will discuss:

  • Solana and Congestion

  • Making Solana modular

  • Solana application chain and examples

  • Solana L2 and Rollup (RollApps) and Examples

  • Infrastructure supporting Rollup and application chains

Solana and Congestion

Let's address the elephant in the room first: the Solana network has been extremely congested recently (mostly resolved now) due to activity like airdrops, large amounts of Memecoin transactions, high pings, a high percentage of failed transactions, and increased network fees due to increased priority fees. Despite these issues, Solana has been able to consistently process ~1-2k TPS, more than all EVM chains combined. I'd say this is a good problem for a blockchain to have, and it puts Solana's monolithic theory to the test.

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

  • Implementing priority fees is critical to avoid delayed or lost transactions.

  • The system optimizes the usage of program compute units (CUs) by penalizing the system so that only the necessary parts are used.

  • Implement priority-weighted Quality of Service (QoS), allowing applications to prioritize user transactions.

However, all these measures can only improve transaction completion rate to a certain extent and cannot guarantee a smooth transaction user experience. One immediate solution to this problem is the much-anticipated new transaction scheduler, scheduled for release in late April in version 1.18. It will be launched alongside the current scheduler but will not be enabled by default so that validators can monitor the performance of the new scheduler and easily return to the old scheduler if any problems arise. This new scheduler is designed to fill blocks more efficiently and economically, improving on the inefficiencies of the old scheduler. Read this article for a deeper understanding of the new scheduler.

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

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

  1. Overhaul of the fee market and increase of base fee (currently set to 5,000 Lamports or 0.000005 SOL)

  2. Implement exponential write lock fees on accounts, i.e. gradually increase the fees over time to avoid spam

  3. Optimize CU (Compute Unit) budget requests through a penalty system.

  4. Strengthening the overall network architecture

Even with improvements in these vertical scaling (single chain) aspects, we cannot rule out the possibility of Solana adopting horizontal scaling (Rollup). In fact, Solana could be a hybrid of both, where it could serve as an excellent base layer for Rollup, with extremely low latency block times (~400ms), which would greatly benefit Rollup, such as enabling ultra-fast soft confirmations from sequencers. The best part is that Solana has historically been very fast at implementing changes, which could make it a more efficient Rollup layer than Ethereum.

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

Making Solana modular

Efforts to make Solana modular have already begun. As shown in the Anza DevRel post , Solana validators and SVM (the execution environment that handles 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 the SVM and easily creating 'Solana AppChains'.

For Rollups, the benefits may come from optimizing Solana’s data availability (DA)/blob layer, although this may happen at a later stage.

Anza engineer Joe C also announced plans to make SVM modular, where the transaction processing pipeline will be taken out of the validator and put into the SVM. This will enable developers to run an implementation of SVM and operate independently of any validator.

An isolated SVM would be a collection of completely independent modules. Any SVM implementation could drive these modules through well-defined interfaces, further lowering the barrier to SVM-compatible projects because the overhead required to build custom solutions is greatly reduced. Teams can implement only the modules they are interested in while leveraging modules from established implementations such as Agave or Firedancer.

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

In general, there are two directions to go: Layer-2s/Rollup and Application Chain. We will study these two directions one by one.

Solana Application Chain

Also known as SVM forks, these are essentially forks of the Solana chain dedicated to specific applications. Python was the first Solana AppChain, but the concept really gained traction when Rune, the founder of Maker, proposed developing a Maker AppChain (for governance) based on the Solana (SVM) codebase. He chose SVM because of its strong developer community and technical advantages over other virtual machines, aiming to fork the best performing chain to better meet consumer needs. Although no action has been implemented yet, the move has sparked an urgent discussion about the Solana AppChain.

Broadly speaking, it can be divided into two types:

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

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

Pyth: The ancestor of Solana application chain

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

The Pythnet Application Chain is a proof-of-authority fork of the Solana mainnet that serves as the computational base layer for processing and aggregating data provided by data publishers on the Pyth network.

Why did Pyth move?

  • It does not require composability, so it can escape mainnet congestion

  • It requires a permissive environment to publish 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 Lisks include:

  • Perp DEX: Like Hyperliquid , Perp DEX can be run as a separate L1 network. In addition, 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 that 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 marketplace through the Cosmos application chain.

  • Governance Appchains: Sovereign governance appchains may be attractive, as validated by MakerDAO’s interest in the SVM Appchain. Cryptocurrency governance is still evolving, and having dedicated chains to fork can be a useful coordination mechanism.

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

  • Game Application Chain: A casino game project on Solana is considering its application chain.

  • Modified forks of Solana: Similar to how Monad or Sei provided an 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 exploring new design architectures.

Envisioning the Solana Lisk Stack

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

It is also possible to create middleware like Cosmos-SDK to provide a one-stop solution for creating application chains with built-in support for Oracle (such as Pyth or Switchboard), RPC (such as Helius), and message connectivity (such as Wormhole).

The Polygon AggLayer is also an interesting approach where developers can connect any L1 or L2 chain to the AggLayer, which aggregates the ZK proofs of all connected chains.

Is Lisk a positive for the Solana ecosystem?

While appchains do not directly increase the value of SOL, as they do not pay SOL fees or use SOL as a gas token unless the 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 appchains will strengthen the SVM network effect. The same logic makes Eclipse (SVM L2 on Ethereum) a positive for SVM, even though it is a direct competitor to the Solana mainnet.

Solana Layer 2

Solana's Layer2, or Rollup, is a logically independent chain that publishes data to the Data Availability (DA) layer of their main chain and reuses the main chain's consensus mechanism. They can also use other DA layers, such as Celestia, but then they are no longer true Rollups. "RollApp" is a term generally used to refer to application-specific Rollups (which most Solana applications are exploring).

Is Solana’s Rollup the same as Ethereum’s?

Obviously not. For Solana, Rollup is largely abstract to end users. Ideologically, Ethereum's Rollup was top-down, with the Ethereum Foundation and leaders deciding to scale through Rollup, and they started supporting various L2s after the CryptoKitties incident. On Solana, demand is bottom-up, that is, from application developers with significant consumer adoption. Therefore, most current Rollups are marketing strategies that are more driven by narratives than consumer demand. This is a major difference that may lead to a different future for Rollup than what is seen on Ethereum.

Does Compression = Rollup?

L2 scales 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 can offload transactions from the mainnet and reduce contention for the base layer state. Notably, Grass L2 will utilize state compression for its Rollup.

Rollup on Solana

There are currently two "Rollapp-like" apps running:

GetCode

A payment app with a micropayment SDK that enables anyone to instantly make and accept payments, and also uses a pseudo-Rollup for the app. 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 a variety of future activities, not just payment transactions. Additionally, Solana as a chain can be replaced if necessary.

  • Instant and Private: Given the soft finality of the sorter, payments are instant even when Solana is congested. While transactions are visible on-chain, the exact value and intent remain obscure, ensuring user privacy.

MagicBlocks’ Ephermal Rollup

MagicBlocks is a Web3 gaming infrastructure that has developed temporary (or ad hoc) Rollups specifically for gaming. It uses the account structure of SVM, and the game state is divided into clusters. It temporarily transfers the state to an auxiliary layer or "temporary Rollup", a configurable, dedicated layer. Temporary Rollup runs as a specialized SVM runtime or Rollup to allow for transaction processing at increased throughput.

Using a Rollup-like structure can achieve:

  • The specialized runtime is customized to include gas-free transactions, faster block times, and incorporates a tick mechanism (i.e., an integrated transaction scheduling system with no fees, similar to clock work).

  • Developers can deploy programs to the base layer (such as Solana) instead of on a separate chain or Rollup. ER does not disrupt the existing ecosystem and allows for the acceleration of targeted operations without creating an isolated environment. This means that all existing Solana infrastructure can be utilized.

This approach helps build a highly scalable system that can spin up Rollups on demand and automatically scale horizontally to accommodate users performing millions of transactions without the typical tradeoffs of traditional L2. While MagicBlock focuses on gaming, this approach can also be applied to other applications, such as payments.

Upcoming Solana Rollup

Grass : The DePIN project aims to solve the AI ​​data problem through verified web crawlers. When the Grass node crawls AI training data from the network, the verifier will store the data on the chain, accurately track the source of the data and the nodes responsible for crawling the data, and reward them proportionally.

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

This development will allow Grass to become the base layer for a host of applications that are only possible on top of Grass (note that platforms and infrastructure generally have higher valuations and that Grass will soon be launching a token).

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

Perpetual exchanges have immediate PMF (product market fit) for Rollups because they significantly improve the user experience. Just ask anyone who has traded between Hyperliquid or Aevo and the Solana Perpetual Options Exchange, and you'll find that on 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 synchronous execution and are highly composable with other assets in other aspects of DeFi (especially trade matching).

Interestingly, Armani, the co-founder of Backpack, also tweeted that they are now leaning towards L2.

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

Sovereign SDK is another node.js-like framework 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. The Rust code can be your specific application logic or any virtual machine.

Some arguments about Rollup

1.Rollup = Align with SOL :

The term “ETH alignment” or better yet “ETH asset package preference” has become a popular meme. Why do you think Layer 2 and Restaking/EigenLayer have become the hottest narratives? It’s because they increase the “monetary properties of ETH” and ETH is used as a 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 important. Remember, most Rollups are “marketing gimmicks” and they provide better token value accumulation as the market still values ​​infrastructure more than applications.

2. Rollups will feel like an extension of Solana

In addition to the benefits of security (i.e., inherited from the base layer), ease of access to Solana users and assets will be a significant advantage. As Jon Charbonneau points out, Ethereum Rollups, such as Base, Optimism, and Arbitrum, feel more like extensions of Ethereum. Users keep the same wallets and addresses, the native Gas token is a single canonical version of ETH, ETH dominates DeFi, all trading pairs are priced in ETH, social apps 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, most Solana Rollapps will not make users feel like they are using a separate chain (e.g., Getcode).

3. Solana will see more “RollApps” instead of “Rollups”

Solana does not have the same scaling issues as Mainnet is unusable due to high gas fees, it is already highly optimized. However, some applications that require dedicated block space will create their own Rollup. While a general-purpose Rollup on Solana does not make sense to me, it makes sense for the project economically. For example, Base users generated $2 million in revenue for Coinbase in just one day! For builders, the incentives are heavily biased towards L2. However, as observed, every EVM Rollup seems to be a normal Rollup like Lvm, Scroll or zkSync, which has become a ghost chain with only small token airdrop transactions by airdroppers.

Additionally, I feel like a generalized L2 on Solana could lead to the same problems Ethereum had previously, namely centralized Rollups, congestion, and liquidity fragmentation.

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

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

  • Value Capture: Internalizing value on a shared Solana layer that is not designed with just one application in mind is more challenging. MEV capture could be another lucrative option for DEXs.

  • Dedicated block space

  • Customizability for use cases such as:

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

    • Fee Market Experiment

    • Encrypted mempool to minimize MEV

    • Customized order book

However, not all applications will want to launch their own Rollup, especially those that have not yet reached a certain escape velocity (e.g., sufficient TVL, users, transaction volume). Launching your own chain today involves painful and unnecessary trade-offs (complexity, cost, worse user experience, liquidity fragmentation, etc.), and most applications, especially those in the early stages, cannot justify the incremental benefits. Solana remains the heart and soul of SVM development, and many new applications will likely be deployed as a result.

Application Builder: Solana Mainnet or Appchain or Rollup

For application builders: Solana Mainnet vs Appchain vs Rollup is entirely situational. If there is no strong need to combine with all other applications, it makes total sense to move some different components off-chain (whether Appchain or Rollup). Users don’t even need to know they are using a Rollup or Appchain. Grass, Zeta, and Getcode all abstract away any Rollup type infrastructure they use 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 is used on Solana:

  • User creates a wallet (can be on L2/Appchain)

  • Distribute compressed NFTs (can be on L2/Appchain)

  • Compress NFT transactions (can be on L2/Appchain, but funds need to be bridged)

We can clearly see that there is no strong demand for anything other than what L2/Appchain can offer on Solana L1. Since DRiP’s primary target is always web2 users, it can bootstrap them directly onto their chain, which gives it higher control in the long run since it doesn’t leak all value to the base chain (Solana). Additionally, DRiP has already reached escape velocity (largest consumer application on Solana) and can now move to their own chain. A pseudo-Rollup structure like Getcode makes total sense for DRiP.

Infrastructure that drives Rollup and Appchain:

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

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

  • Shared sorters, like Rome Protocol , and the need for lightweight clients like Tinydancer . Shared sorters can be interesting for Rollups because they enable activities like atomic arbitrage, MEV, and seamless bridging, reducing liquidity fragmentation.

  • Wallets like Phantom, Backpack, and Solflare. Multi-signature and smart contract wallet infrastructure like Squads . Squads has been positioned as “the definitive smart contract wallet infrastructure layer for Solana and SVM.”

  • SOL Restaking: The modular view also advocates restaking, because these Rollups/Appchains may need SOL to share security and be more aligned with Solana. This leads to:

Summary: Can Solana cope with global demand?

Absolutely not. Let’s be realistic: even taking into account Moore’s Law (hardware performance will continue to improve, and Solana is already optimized for such hardware advances), this is impractical. I believe that all the less important transactions (like DRiP sending NFTs) will eventually move to their own chains, while the most valuable transactions will stay on the main chain, where true composability is critical (such as spot DEXs).

And, this doesn’t mean Solana loses the monolithic vs. composability race; it will manage use cases that rely on composability and low latency better than other chains. No, Sui/Aptos/Sei/Monad etc. are not better at this time, because we don’t know if they’ve been battle-tested with high user activity.

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

Solana Needs a Soulmate: Are Appchains and Rollups the Perfect Match?

Source
Disclaimer: The content above is only the author's opinion which does not represent any position of Followin, and is not intended as, and shall not be understood or construed as, investment advice from Followin.
Like
1
Add to Favorites
Comments