Data availability guide, Part 3: the rise of L2’s on Solana
L2 on Solana and the data availability problem | Main L2 projects - Lumio on Solana, Eclipse, Zeta ZX, ephemeral rollups by MagicBlock | How Lumio L2 ensures DA on Solana
The upcoming Lumio on Solana will use a very interesting mechanism for ensuring data availability. But before we delve into it, we have to explore why Solana needs rollups in the first place and which projects are making the most headway in this area, including Lumio, Eclipse, and Zeta X.
Intro: how Pontem’s guide to DA is structured
In Part 1 of our epic guide to data availability, we discussed what data availability (DA) means for different types of blockchain users, from full nodes to rollup sequencers and end users.
In Part 2, we looked at the biggest DA solutions in the market, including Celestia, EigenDA, NEAR, and Polygon Avail. They are mostly geared at Ethereum rollups, as the EVM L2 ecosystem is dominant at the moment, though technically these DA solutions should be able to serve non-EVM chains, too.
In Part 3 and 4, we are turning to a different and very interesting topic: data availability for rollups on Solana. There are few such projects at the moment - the most prominent being Pontem’s Lumio - but the L2 ecosystem on Solana is likely to keep growing, and any such chain will need a DA solution.
However, before we turn to the technical complexities of enabling data availability on Solana, we need to examine the whole spectrum of L2s that are currently being built on Solana or that use SVM for execution. This is what we’ll do in this article, while in the final part of the guide, Part 4, we’ll talk about advanced stuff like KZG commitments and data storage costs.
The rise of L2s on Solana
Why does Solana need rollups?
Solana is a fast blockchain with low transaction fees, so why would it need Layer-2 chains? There are a few potential reasons.
Connecting Solana to other ecosystems
Right now Solana’s ecosystem is isolated from the rest of the blockchain space due to the fundamental differences in its architecture: there is no way to port an EVM dApp to Solana. Lumio L2 solves this issue: as the first VM abstraction framework, Lumio allows developers to deploy on different VMs without rewriting their dApp code.
Imagine taking an Ethereum app and deploying it on Lumio to settle on Solana, for example. It would support both ETH and SOL as native assets, as well as bridging from both chains. Apps on Lumio can also benefit from the security advantages of different VMs.
Lumio on Solana is already SVM-equivalent, meaning that you can deploy any Solana dApp on it with no code changes. In the future, it will also support EVM and Move VM, providing the first-ever link between the ecosystems of Aptos and Sui and that of Solana.
Congestion
Solana tends to have episodes of congestion when transactions grind down almost to a halt or fail altogether. Well-known examples include the surge of memecoin launches on Pump.fun and the JUP airdrop. At certain points in Q2 2024, over 70% of transactions on Solana ended in failure.
The current infrastructure of Solana’s mainnet doesn’t provide a good solution, but the problem can be resolved through L2s, because a rollup can batch thousands of L2 transactions into a single transaction settled on Solana. All dApps hosted on a rollup will keep working normally even during congestion episodes on the mainnet.
Competition for blockspace
This problem is related to the issue of congestion, but it’s not the same. When a single app or memecoin that goes viral starts hogging up a lot of the blockspace, other apps like DEXes and games face a sudden bottleneck and rising fees as mainnet blockspace suddenly becomes more expensive. The solution is to host high-volume apps (for example, a memecoin DEX or a game) on separate application-specific chains to make sure that the apps on the mainnet are not affected.
High infra fees for dApps
As pointed out by @vibhu, creator of the NFT platform DRiP, Solana dApps can end up spending thousands of dollars a week in L1 usage costs - more than it earns in app fees. In other words, Solana may be cheap for end users, but at the same time very expensive for dApps. An L2 like Lumio solves this problem for the most part: apps will still need to pay L2 usage fees related to the use of the mainnet storage space by the rollup, but it will be very little compared to the present L1 costs.
However, upon further analysis, only the first reason - linking Solana to other ecosystems and VMs - may be really important in the long term. Why? Solana Labs Anatoly Yakovenko explains it well: normal fees on Solana are already very low, and it will be difficult for any rollup on Solana to be cheaper, since it still needs to use the L1’s storage space to write its block data (as we will see). Plus, Solana devs are working on fixes for the issues like outages and fee spikes.
Here at Pontem, we’ve thought long and hard about this - and a multi-VM or VM-agnostic L2 framework like Lumio is the only one that makes sense. Solana’s ecosystem is isolated, and no internal L1 fix can change this. Only a solution like Lumio can help Integrating it into the EVM ecosystem, which would open up huge advantages for everyone - from trading Ethereum-based memes with Solana’s low fees to Solana-native protocols like Raydium and Marinade being able to support ETH assets.
Leading L2 projects supporting Solana and SVM
Lumio
Part of the Lumio L2 federation of rollups, Lumio on Solana is currently in the public devnet stage. The devnet actually supports three VMs: SVM, EMV, and Move VM. It follows SuperLumio, a mainnet EVM implementation based on Optimism’s OP Stack, and the current Lumio testnet that settles on Ethereum. Once the devnet is properly battle-tested and stable, we will replace the current testnet with it, so that Lumio testnet will settle on Solana.
You can sign up to test Lumio on Solana in devnet here.
Eclipse
The concept of Eclipse is to connect Solana’s speed and performance with Ethereum’s unparalleled liquidity. It executes on SVM but settles on Ethereum, the idea being that SVM is the only environment that can provide true scaling but Ethereum offers better security than any other settlement layer. In other words, it’s an Ethereum L2 based on SVM, rather than an L2 for Solana.
Note the differences between Eclipse and Lumio: the current version of “Lumio on Solana” both executes on SVM and settles on Solana (and not Ethereum), but in the near future it will also support EVM and MoveVM. In other words, Eclipse and Lumio use the same VM for execution but different settlement layers.
Also, unlike Lumio, Eclipse is designed to support only EVM and SVM and no additional virtual machines. By contrast, Lumio is VM-agnostic: you can whip up a version of it that uses any combination of a virtual machine and settlement layer.
Eclipse uses Celestia as its DA layer (see Part 2 of our DA guide for more on Celestia). The project launched on mainnet in November 2024.
Zeta X
Zeta X, or simply ZX, is an upcoming L2 solution for DeFi on Solana, developed by Zeta Markets. It should deliver a fast and efficient trading experience above all, with latency comparable to Binance.
ZX will use Solana L1 for settlement and data availability - same as Lumio. The big difference is execution: according to the documents, ZX uses an off-chain order matching engine that is compatible with zkVM (zero-knowledge VM), though it doesn’t say which (as there are quite a few zkVMs on the market now). Settlement will work as in a rollup, with batches of transactions sent to the L1 optimistically (but without using ZK proofs).
Credit: Zeta Docs
ZX is an application-specific L2, designed for trading, rather than a general-purpose rollup. Most of its transactions are expected to be trading orders. This makes Zeta X different from Lumio on Solana, which can host all types of dApps, from decentralized perp trading to games.
Ephemeral rollups by MagicBlock
This solution by MagicBlock, primarily geared at gaming projects, allows developers to offload part of their transactions to SVM instances created on-demand and powered by so-called ephemeral validators. This enables much lower latency than on Solana mainnet, which can be crucial for real-time games with hundreds of players.
Security is guaranteed through a fraud proof system, as well as a special set of light clients that make sure that an ephemeral validator follows the rules. Once an ephemeral rollup isn’t needed anymore, the validator commits the blockchain state back to the mainnet, subject to a prior check by the security committee.
The data availability problem on Solana
We have already discussed the basics of the so-called DA problem in Part 1 of this guide. Here we'll talk about how the issue of rollup data availability on Solana differs from the similar issue on Ethereum - in particular, the limitations that Solana specifically imposes on L2s that make DA implementation a bit more complex.
Why Lumio on Solana needs DA
Lumio is a rollup on Solana: it rolls up L2 transactions into batches and commits them to the Solana mainnet. Validators on Solana need to have access to rollup block data in order to make sure that each new block submitted by Lumio contains only valid transactions. However, publishing all of Lumio’s block data on the L1 would be too expensive. Therefore, we have to post a compressed version of the data while at the same time making sure that validators can always access it and verify it - this is the data availability problem in a nutshell.
Limitations posed by Solana architecture on L2s
Rollups based on Solana have to contend with a few limitations - nothing severe compared to Ethereum, but still important when building an L1.
100 MB block size limit
One of the advantages of rollups is that they can stuff lots of transactions into a single block - but the summarized version submitted to the L1 must be within the limits imposed by the L1. In other words, a rollup block needs to be way smaller than the maximum L1 block size.
On Solana, the maximum block size is 100 MB - very generous compared to the roughly 7 MB that you can fit into a block on Ethereum (where the limit is actually 30 million gas rather than a set number of megabytes). With Lumio on SVM, we decided to go with 10 MB, which is more than enough.
1 Kb transaction limit
A single transaction on Solana cannot be larger than 1,232 bytes, which is a problem for rollups that need to send chunky batches of transactions. For comparison: in Ethereum, the maximum size of a blob transaction (which is what most rollups use now) is 128 Kb, which is more than enough for a compressed rollup block. By contrast, a Solana-based rollup like Lumio can fit only about 10 transactions into a single transaction that it sends to the L1.
Luckily, there is a different way to write rollup transaction data to Solana: PDAs, or program-derived accounts. They can store up to 10 MB of data (see the “Intro to PDAs” section of this article).
This is as far as we’ll go in this article, however. In Part 4, we will delve not only into PDAs but also into another pretty advanced technological concept: commitment schemes. All that technological groundwork will finally allow us to understand how Lumio L2 ensures data availability on Solana.
Want to be among the first to test Lumio on Solana? Then apply to get whitelisted for public devnet access here. And of course, keep following us on X and in Telegram so that you don’t miss any Lumio news!