Does Solana need L2 and application chain?

24-06-18 15:32
Read this article in 43 Minutes
总结 AI summary
View the summary 收起
Original title: "Solana Need L2s And Appchains?"
Original author: Yash Agarwal
Translation: Ladyfinger, BlockBeats
Editor's note:

As a high-performance public chain platform, Solana is facing unprecedented development opportunities and challenges. In this article, Yash Agarwal takes a panoramic and in-depth look at the key issues in the Solana ecosystem - modularization, application chains, Rollups, and how they work together to drive Solana towards a broader future.


Introduction


A month ago, Vibhu, the founder of DRiP, the top free NFT distribution application on Solana, made a statement that sparked widespread discussion:


Solana will and needs Layer 2 and Rollup.


He expressed this view because DRiP loses about $20,000 in value every week as SOL prices and network congestion rise. The increase in Solana network activity has brought two effects:


Advantages: Enhanced liquidity, increased capital and transaction volume (thanks to composability)

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


However, DRiP mainly distributes millions of NFTs from artists to thousands of wallets every week through Solana as infrastructure, and there is not much demand for high composability. Solana’s TVL growth and capital inflows have had little impact on DRiP, which is instead primarily plagued by high infrastructure costs.


Vibhu noted that “composability has diminishing returns.” He also mentioned that Solana application developers have privately discussed their need for Rollups because these Rollups can increase transaction throughput, reduce block space competition, and reduce fees. In addition, they can better control the economic value generated by the business.


Post Link


Solana has experienced multiple congestion events over the past few months, from JUP airdrops to ORE mining and peak meme coin trading. While some believe that Firedancer can solve these problems, the reality is that the timeline is unclear and it is currently unable to scale more than 10x. Despite this, Solana is the only one of all the battle-tested major chains to remain a monolithic chain.


Should Solana remain a monolithic chain or become modular?


Will Solana also evolve into a sharded Layer 2 and Layer 3 solution like Ethereum?


What is the current situation of Solana's application chain and Rollup?


To answer these questions and put together a summary, this article will explore various possibilities and discuss the pros and cons of each project. This article will not go into technical details, but discuss various expansion methods from a market-oriented and practical application perspective to provide an overview. All insights, no nonsense, just a lot of exclusive information.


In short, we will discuss the following issues:


· Solana and the problem of network congestion


· Making Solana modular


· Solana application chain - with examples


· Solana Layer2 and Rollup - with examples


· Infrastructure to support Rollup and application chain



Solana’s problems and the need for modularity


First, let’s discuss the current problems: Due to airdrops and a surge in memecoin transactions, the Solana network has been very congested recently (most of which have been resolved at present), resulting in high ping times, high transaction failure rates, and increased network fees. Despite this, Solana has maintained a transaction processing capacity of 1-2 thousand times per second, which exceeds the sum of all EVM chains. It can be said that this is a good problem for blockchains, and it also tests Solana’s monolithic chain theory.


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


· Implementing priority fees: It is critical to avoid delayed or lost transactions.

· Making optimal use of program compute units (CUs): using only necessary resources.

· Implementing stake-weighted quality of service (QoS): allowing applications to prioritize users’ transactions.


However, these measures can only improve transaction completion rates to a certain extent and do not guarantee a smooth transaction experience. One solution to this problem is the much-anticipated New Transaction Scheduler, which is scheduled to be introduced in version 1.18 in late April. The new scheduler will exist alongside the current scheduler, but will not be enabled by default, allowing validators to monitor the performance of the new scheduler and easily switch back to the old scheduler if problems arise. The new scheduler is designed to fill blocks more efficiently and affordably, improving upon inefficiencies of the old scheduler.


Read this article for a deeper dive into the new scheduler.


Anza, a spinoff entity of Solana Labs, has been working to resolve network congestion issues identified as being related to the QUIC implementation and Agave’s (Solana Labs) validator client’s behavior in handling large numbers of requests.


Post link


While modularity supporters strongly advocate Solana's "modularity roadmap", Solana Labs/Anza, the core maintainer of the Solana protocol, is still focused on optimizing the throughput and latency of the base layer. Potential improvements include:


· Improve the fee market and increase the base fee (currently set to 5000 Lamports or 0.000005 SOL).

· Implement exponential growth of account write lock fees, i.e. gradually increase fees to curb spam.

· Optimize CU budget requests through a penalty mechanism.

· Improve overall network architecture.


Even if these vertical scaling, single-chain, improvements work, we cannot rule out the possibility of Solana adopting horizontal scaling, Rollup. The reality is that Solana can combine these two features - it can serve as an excellent Rollup base layer, with ultra-low latency block times (~400ms) and significant performance improvements for Rollups, such as implementing fast sequencer soft confirmations. On top of that, Solana has a history of implementing changes quickly, which may make it more efficient as a Rollup base layer than Ethereum.


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



Making Solana Modular


Solana’s modular development plan has begun. As shown in the Anza DevRel's 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 help create the "Solana Application Chain".


For Rollups, optimizing Solana's data availability (DA) or blob layer may come at a later stage.


Source: Anza DevRel


Anza engineer Joe C also revealed plans to modularize the SVM, where the transaction processing pipeline will be stripped out of the validator and placed into the SVM. This will enable developers to run an implementation of the SVM independently of any validator.


The standalone SVM will be a collection of completely independent modules. Any SVM implementation can drive these modules through well-defined interfaces, further reducing the barrier for SVM-compatible projects and significantly reducing the overhead required to build custom solutions. Teams can implement only the modules they are interested in while leveraging established implementations, such as those from Agave or Firedancer.


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



Overall, this can go in two directions: Layer2 (or Rollup) and application chains. We will introduce each one below.



Solana Application Chain


Also known as SVM forks, these are essentially forks of the Solana chain designed specifically for specific applications. Pyth was the first Solana application chain, but the concept really attracted attention when Rune, the founder of Maker, proposed developing a Maker application chain based on the Solana (SVM) codebase for governance. Rune chose SVM because of its strong developer community and technical advantages over other VMs, aiming to fork the most performant chain to better meet consumer needs. Although it has not yet been implemented, this move has sparked widespread discussion about Solana application chains.


In general, they can be divided into two categories:


· Permissionless - anyone can join the network, similar to the current Solana mainnet.

· Permissioned - "Solana Permissioned Environments (SPEs)" packaged by the Solana Foundation for institutions, allowing entities to build and maintain their own chain instances, powered by SVM.



Pyth - OG Solana Application Chain:


Pyth once accounted for 10-20% of all transactions on the Solana mainnet. However, it did not require any composability, so they simply forked Solana's 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 a computational base layer for processing and aggregating data provided by the Pyth data publishing network.


Why is Pyth migrating?


· It does not require high composability, especially for non-Solana applications, and is therefore immune to mainnet congestion.

· It requires a permissioned environment to publish data.

· Reduce infrastructure costs by internalizing fees that would previously leak to the base layer, i.e. Solana.


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



Solana Application Chain Examples


· Perp DEXs: Perp DEXs like Hyperliquid can run as independent Layer1 networks. 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 Layer1, ensuring that it is enforced as a state transition, or introducing application-specific atomic logic.


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

· Governance AppChains: As validated by MakerDAO’s interest in the SVM AppChain, sovereign governance AppChains can be very attractive. Crypto governance is still evolving and having dedicated chain forks can be a useful coordination mechanism.

· Future Enterprise AppChains: Potential applications include funds like BlackRock or payment systems like Visa or CBDCs.

· Gaming AppChains: A casino gaming project running on Solana is considering its AppChain.

· Forking Solana for modifications: Similar to the optimized EVM (parallelization) provided by Monad or Sei, someone could build a more optimized version of Solana. This trend may become more common in the coming years as the Solana mainnet begins to explore new design architectures.


Envisioning the Solana Application Chain Stack


While building an application chain may be relatively simple, ensuring connectivity between all application chains is critical for interoperability. Taking inspiration from Avalanche Subnets, which connect via native Avalanche Warp Messaging, and Cosmos application chains, which connect via IBC, Solana could also create a native messaging framework to connect these application chains.


Post link


A middleware platform similar to Cosmos-SDK can be built to provide a one-stop service to create application chains with built-in support for oracles such as Pyth or Switchboard, remote procedure calls, RPCs such as Helius, and messaging connections such as Wormhole.


Polygon's AggLayer provides an innovative solution that allows developers to link different Layer1 or Layer2 into AggLayer to achieve cross-chain ZK proof aggregation.


What is the positive impact of Lipchain on the Solana ecosystem?


Lipchains do not pay fees in SOL or use SOL as a transaction fee token, so they do not directly contribute value to SOL unless SOL is re-staked for economic security purposes, but their benefits to the SVM ecosystem are obvious. Just like the network effect of EVM, more SVM forks and Lipchains will strengthen the network effect of SVM. This logic also applies even if Eclipse, as a Layer2 extension of SVM on Ethereum, competes with Solana mainnet.


Solana Layer2


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


Will Solana's Rollup be like Ethereum?


Obviously not. For Solana, Rollup will be mostly abstracted from end users. From an ideological point of view, Ethereum's Rollup was top-down, that is, the Ethereum Foundation and leaders decided that the best way to scale was through Rollup, and then started supporting various Layer2s after the CryptoKitties incident. In Solana, the demand is bottom-up, that is, from application developers with significant user adoption. Therefore, most current roll-up plays are marketing plays that are more narrative-driven than user demand-driven. This is a significant difference that may lead to a different Rollup future than Ethereum.


Is compression equivalent to Rollup?


Layer2 extends the base layer blockchain (Layer1) by executing transactions on Layer2, batching transaction data, and compressing them. The compressed data is then sent to Layer1 and used for fraud proofs (optimistic rollup) or validity proofs (zk rollup). This proof process is called "settlement". Similarly, compression offloads transactions from the mainnet, reducing contention for the base layer state. It is worth noting that Grass Layer2 will leverage state compression for its rollup.


Rollup Landscape on Solana:


There are currently two Rollapps-like projects running:


GetCode


This is a payment app with a micropayment SDK that allows anyone to instantly pay and accept payments and uses a rollup-like structure for its application. It creates intents for all transactions and uses a rollup-like sorter to settle on Solana every N intervals.



Using a rollup-like structure allows for:


· Flexibility: Intents can represent a variety of future activities, not just payment transactions. In addition, Solana as a chain can be replaced if the need arises.

· Instant and Private: Due to the soft finality of the sorter, payments are instant even during Solana congestion. While transactions are visible on-chain, the exact amounts and intents remain obscure, ensuring user privacy.


MagicBlocks’ Ephemeral Rollup


MagicBlocks is a web3 gaming infrastructure that has developed Ephermal Rollup, specifically for gaming. It uses the account structure of SVM to split the game state into clusters. The state is then temporarily transferred to an auxiliary layer or "ephermal rollup", a configurable dedicated layer. The ephemeral rollup runs as a dedicated SVM runtime or rollup to process transactions at a higher throughput.



Using a rollup-like structure enables:


· Customization of dedicated runtimes, including gas-free transactions, faster block times, and integrated timing mechanisms, for example, an integrated transaction scheduling system like Clockwork, which runs without fees.

· Developers can deploy programs to a base layer, such as Solana, instead of on a separate chain or rollup. Ephemeral Rollups do not fragment the existing ecosystem, allowing for the acceleration of targeted operations without creating isolated environments. This means that all existing Solana infrastructure can be leveraged.


This approach helps create a highly scalable system that is able to spin up rollups on demand and auto-scale horizontally to accommodate users performing millions of transactions without the typical trade-offs of traditional Layer2s. While MagicBlock focuses on gaming, this approach can also be applied to other areas, such as payments.


Solana Rollup Coming Soon:


· Grass: Grass is a DePIN project that focuses on solving the data needs of artificial intelligence through verification crawling technology. The project crawls AI training data through Grass nodes on the network, and the data is stored on the blockchain by the validator, while accurately recording the source of the data and the node that performs the crawling, and rewards accordingly.


Given that Grass needs to process up to 1 million network requests per second, this is unrealistic for the Solana mainnet. Therefore, the project plans to use zero-knowledge proof technology to verify the data set and settle in batches on Solana's Layer1.


The Grass team is also considering introducing state compression technology from other clusters and anchoring data on the beta version of the Solana mainnet. This innovation will make Grass a foundational platform that supports a wide range of applications that can only be built on it


*Note that projects that build platforms and infrastructure usually have higher market valuations, and Grass is also about to launch its token.


· Zeta: One of the earliest perpetual contract exchanges on Solana, it has a perpetual order book that is completely on-chain and is currently planning to use Solana's Rollup technology to migrate its trade matching process off-chain.


Perpetual contract exchanges have obvious advantages using Rollup technology because it greatly improves the user trading experience. You can ask those who have traded with perpetual contract exchanges on Solana on platforms such as Hyperliquid or Aevo, which require users to sign each transaction, wallet pop-up windows, and wait about 10 to 20 seconds. In addition, perpetual contract transactions do not need to be executed synchronously and can be highly integrated with other parts of the DeFi ecosystem, especially in terms of trade matching.



Interestingly, Armani, the co-founder of Backpack, also said on Twitter that they are now focusing on Layer2 solutions.



Sonic is developing a modular SVM chain called Hypergrid that allows game developers to deploy their own chains on the Solana platform. At the same time, there are Ethereum Rollup projects based on SVM technology, such as Eclipse and NitroVM, which use SVM as their execution engine. In the Solana ecosystem, Neon is a Layer 2 solution compatible with EVM. In addition, some innovative projects such as Molecule, an SVM Layer 2 for Bitcoin, is still in the early conceptual stage.


Sovereign SDK provides a node.js-like framework specifically for building Rollups. Users can submit their Rust code, and the platform is able to convert it into Optimistic Rollup or ZK Rollup that supports deployment on any blockchain. These Rust codes can be customized application logic or implementations of any virtual machine.


Some arguments about Rollup


Rollup = consistency with SOL


"ETH-Aligned", Ethereum consistency, or "ETH Bag Biases", Ethereum bag bias, has become a popular network meme.


Why are Layer 2 and Restaking/EigenLayer the hottest topics?


This is because they increase the “moneyness” of ETH, which is used as a core asset everywhere.


The same principle applies to Solana. The Solana community will support any solution that can increase their SOL holdings - it's that simple. As the Solana ecosystem expands, the once-overlooked “moneyness” of SOL will become important. Remember, most Rollups are “marketing gimmicks” anyway, and since the market still values infrastructure more than applications, they provide better token value accumulation.


Rollups will feel like an extension of Solana


In addition to the benefits of security, that is, inheriting security from the base layer, easy access to Solana users and assets will be a major advantage. As Jon Charbonneau points out, Ethereum Rollups like Base, Optimism, and Arbitrum feel more like an extension of Ethereum. Users keep the same wallets and addresses, the native gas token is a single, standard version of ETH, ETH dominates DeFi, all trading pairs are ETH, social apps price NFTs in ETH and pay creators (e.g., friend.tech), and deposits on Layer2 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.


Solana will see more “RollApps” than “Rollups”


Solana does not have scaling issues like Ethereum, the mainnet is difficult to use due to high gas fees, it is highly optimized. However, some applications that need dedicated block space will create their Rollups. While general purpose Rollups on Solana do not make sense to me, economically it does make sense for projects. For example, Base users generated $2 million in revenue for Coinbase in just one day! The incentives for builders are heavily tilted towards Layer2. However, as observed, every EVM Rollup seems to be a regular Rollup, and many projects like Linea, Scroll, or zkSync have become ghost chains with only farmers doing a few transactions for token airdrops.


Moreover, I feel like a general-purpose Layer2 on Solana could lead to the same old problems as Ethereum, namely centralized Rollups, congestion, and liquidity fragmentation.


Why do some applications want to migrate to Rollapps/AppChains?


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


· Value capture. It is more challenging to internalize value on a shared Solana layer that is not designed for just one application. MEV capture could be another lucrative option for DEXs.

· Dedicated blockspace.

· Customizability in use cases. For example, in terms of privacy, Getcode uses sequencers to provide private payments to its users, market fee experiments, encrypted memory pools to minimize MEV, and customized order books.


However, not all applications will want to launch their own Rollup, especially those that have not reached a certain escape velocity, e.g., sufficient TVL, users, transaction volume. Launching your own chain today involves painful and unnecessary tradeoffs of complexity, cost, worse UX, liquidity fragmentation, etc., and most applications, especially early-stage ones, cannot justify these tradeoffs for incremental gains. Solana remains the heart and soul of SVM development, so many new applications are likely to be deployed.


For Application Builders


Whether Solana is mainnet or Lipchain or Rollup depends entirely on the different situations. If there is no strong need for composability with other applications, it is completely reasonable to put some different components off-chain, whether it is Lipchain or Rollup. Users don’t even need to know that they are using a Rollup or Lipchain. Grass, Zeta, and Getcode all abstract away any Rollup-type infrastructure they use for their users.


For use cases that require authorization and customization, Token Extensions can also meet most needs, such as KYC or transfer logic, while maintaining composability.


Infrastructure that drives Rollup and Application Chain


If the Rollapp/Application Chain theory is expanded, existing infrastructure providers will be able to benefit greatly because they will enter new markets:


· Existing Rollup as a Service (RaaS) providers, such as Caldera, can easily enter the SVM market as demand emerges. SVM Ethereum Rollups like Eclipse and NitroVM are also paying close attention to this opportunity. Additionally, Sovereign Labs provides a Sovereign SDK Solana Adapter that is able to support Rollups on Solana (not yet production ready). Helius is another company that is well suited to build infrastructure for Solana Layer2, as Mert has hinted at several times.


· Shared sequencers like Rome Protocol and the need for light clients like Tinydancer. Shared sequencers could be interesting for Rollups as they enable activities like atomic arbitrage, MEV, and seamless bridging, reducing liquidity fragmentation.


· Wallets like Phantom, Backpack, and Solflare. Multisig and smart contract wallet infrastructure like Squads. Squads has been positioned as the “ultimate smart contract wallet infrastructure layer for Solana and SVM.”


· Re-staking SOL: Modularity theory also promotes re-staking, as these Rollups/appchains may need SOL to share security and be more aligned with Solana. This will bring early participants like Cambrian, Picaso and Solayer, Jito through Stakenet, LST like Sanctum, and increased income for validators.


Finally, can Solana cope with global demand?


Of course not. Realistically, even given Moore’s Law, even if hardware continues to improve in performance, and Solana is optimized for this hardware progress, this is impractical. I believe that all of the less critical 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, like spot DEXes.


This does not mean that Solana has lost the battle between monolithic and composability; it will manage better than other chains in situations where it relies on composability and low latency. And Sui, Aptos, Sei, Monad, etc. are no better because we don’t know yet if they can withstand high levels of real user activity.


Unlike Ethereum, the Solana mainnet is not intended to be a “B2B chain”; it has always been and will always be 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 soul mate: Will application chains and Rollups be its perfect match?


Original link


欢迎加入律动 BlockBeats 官方社群:

Telegram 订阅群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方账号:https://twitter.com/BlockBeatsAsia

举报 Correction/Report
PleaseLogin Farcaster Submit a comment afterwards
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit