Eclipse Mainnet: A New L2 Paradigm Combining Solana and Ethereum Technologies, Integrating the Best of Both Worlds
TechFlow Selected TechFlow Selected
Eclipse Mainnet: A New L2 Paradigm Combining Solana and Ethereum Technologies, Integrating the Best of Both Worlds
L2 has the incredible ability to leverage Ethereum's network effects and settlement guarantees while experimenting with the best new execution environments, and Eclipse Mainnet is a natural realization of this vision.
Navigating Web3 tides with focused insightsWritten by: Eclipse
Compiled by: TechFlow
Eclipse Mainnet is a general-purpose Layer 2 that combines the best parts of modular architecture:
-
Settlement layer: Ethereum — Eclipse will settle on Ethereum (i.e., the validation bridge will be on Ethereum) and use ETH as its gas token.
-
Execution layer: Solana Virtual Machine (SVM) — Eclipse will run the high-performance SVM as its execution environment.
-
Data availability: Celestia — Eclipse will publish its data to Celestia for scalable data availability (DA).
-
Proving: RISC Zero — Eclipse will use RISC Zero for zero-knowledge fraud proofs (without intermediate state serialization!)
Much of Eclipse's focus has been around enabling projects to deploy app-specific rollups. However, it’s now clearer than ever that Ethereum needs a general-purpose Layer 2 capable of true scale. Most applications won’t benefit from the customization of app-specific chains; instead, the resulting fragmentation and complexity can actually lead to worse user and developer experiences.
There’s often a false dichotomy between the modular rollup vision and having the capabilities of a single monolithic chain with massive scalability, parallel execution, and shared state. “Modular” is frequently conflated with “app-specific,” leading to the perception that rollups mean a world of fragmented, low-throughput chains.
Execution Layer: Solana Speed and Scale
Eclipse Mainnet will adopt a Solana-class optimal execution environment. This brings significant advantages:
Optimized Parallel Execution
The SVM and its Sealevel runtime are renowned for supporting parallel transaction execution. Transactions that don’t touch overlapping state can be executed in parallel rather than sequentially.
This allows SVM to scale directly with hardware, as processors continuously add more cores at lower cost. Single-threaded runtimes (like today’s EVM) do not inherently benefit from reduced per-core costs. Over the past decade, improvements in single-thread performance have steadily diminished. Nearly all progress now comes from increasing core counts, making workload parallelization critical:
While there are some early attempts at parallelizing the EVM, adding this while maintaining compatibility introduces fundamental trade-offs, including suboptimal performance unless other bottlenecks (e.g., state growth) are also resolved. Contracts that pre-declare state dependencies (as in SVM) enable optimal parallelization.
Native Fee Markets
Most fee markets today are global, meaning one popular application increases fees for all users on the chain. An NFT mint shouldn’t render the entire chain unusable for everything else. Solana’s groundbreaking work on native fee markets solves this cross-application state contention. In its current implementation, the scheduler prioritizes non-conflicting transactions, allowing conflict-free transactions to proceed at lower fees. Long-term, native fee markets will be implemented at the protocol level, ensuring that fee spikes in one application don’t affect others on the chain.
Native fee markets benefit from Solana’s unique parallelized runtime. Attempting to implement native fee markets for state hotspots in the EVM using heuristics (i.e., without pre-declaring state access) would result in inefficiencies and potential attack vectors.
Early research is also underway to allow applications to easily internalize their own native value, which today typically requires more creative application-level design.
State Growth Management
Even before sequential execution becomes a bottleneck, state growth is a pressing constraint for the EVM.
Because state isn’t stored in Merkle trees, Solana avoids the overhead of updating Merkle trees with every state change. Instead, the entire state is archived once per epoch (every 2.5 days). This is cheaper than real-time archiving (as in the EVM).
More importantly, the EVM allows dynamic account access (i.e., transactions can access any state on demand). This dynamic lookup means state cannot be pre-loaded into memory before execution. In SVM, each transaction specifies all required state upfront.
Thus, state size does not impact SVM execution. Assuming validators upgrade storage disks every two years, the network can safely double snapshot sizes every two years without major issues.
Additionally, teams like Helius are actively improving historical data accessibility and reducing state size through compression.
EVM Compatibility
Neon EVM is an Ethereum Virtual Machine smart contract that can be deployed on any SVM chain. This brings full EVM compatibility (including EVM bytecode support and Ethereum JSON-RPC) to Eclipse Mainnet, with throughput exceeding that of a single-threaded EVM. Since each Neon EVM instance has its own native fee market, applications can simply deploy their contracts to gain benefits akin to app-chains, without compromising UX, security, or liquidity.
Additionally, the Solang compiler can compile Solidity smart contract code into SVM bytecode.
MetaMask Snaps
Onboarding EVM users to non-EVM chains has historically been a major hurdle, but the recently announced MetaMask Snaps will break this barrier. EVM users can continue using MetaMask without switching wallets. Thanks to Drift’s open-source contribution of a robust MetaMask Snaps implementation, the experience closely mirrors interacting with any EVM chain. Eclipse Mainnet users will be able to interact natively with apps within MetaMask, or use Solana-native wallets like Salmon.
Firedancer
Firedancer is Jump’s highly anticipated Solana client, designed to significantly boost network throughput, resilience, and efficiency. At launch, we’ll stay as close as possible to the Solana core client, but plan to adopt Firedancer once the code stabilizes.
Security
The Solana runtime drastically reduces the attack surface, preventing reentrancy attacks we’ve seen far too often. Specifically, the Solana runtime only allows program self-recursion, not arbitrary cross-program reentrant calls. Additionally, the separation of state and code leads to stateless code, which is generally easier to test effectively.
Simpler Proving
SVM is register-based, with a much smaller instruction set than the EVM, making SVM execution easier to prove in ZK contexts. For optimistic rollups, the register-based design enables simpler checkpointing.
Settlement Layer: Ethereum Security and Liquidity
Like today’s major rollups, Eclipse Mainnet will settle on Ethereum. Specifically, our verification bridge on Ethereum will be tightly integrated with Eclipse. Eclipse nodes will consult this bridge to determine the “canonical chain.” The bridge enforces correct ordering on Eclipse.
This allows our users to inherit certain security properties from Ethereum. The bridge validates all Eclipse transactions, preventing invalid state commitments. It also ensures final liveness and censorship resistance under certain failure conditions. Even if the L2 sequencer stops operating or begins censoring, users can force transaction inclusion via the bridge.
Due to these security properties, validiums and optimiums are often referred to as “Ethereum L2s.” L2BEAT defines an L2 as “a chain whose security is fully or partially derived from Ethereum Layer 1, so users don’t need to trust the honesty of L2 validators to keep their funds safe.”
Settling on Ethereum underscores the importance of Ethereum-native assets in Eclipse Mainnet’s DeFi and NFT economy. ETH is the most decentralized currency and the clear preference for most users, so we will also use ETH as our gas token. In the long term, fee abstraction will allow users to pay in any token of their choice (e.g., USDC). Currently, Eclipse Mainnet has no plans to issue its own token.
Data Availability: Celestia Bandwidth and Verifiability
Eclipse Mainnet will use Celestia for data availability (also known as data publishing or data posting). Celestia has been a long-term ecosystem partner of Eclipse.
Eclipse Mainnet’s target throughput and fee structure are unfortunately not supported by Ethereum’s current bandwidth limits — even after EIP-4844 (aka “Proto-danksharding”), which provides about 0.375 MB of blobspace per block (with a per-block limit of ~0.75 MB).
-
For basic-compressed ERC-20 transfers (~154 bytes per tx), this equates to roughly 213 TPS across all rollups.
-
For compressed swaps (~400 bytes per tx), this equates to roughly 82 TPS across all rollups.
In contrast, Celestia will launch with 2 MB blocks by year-end. Once sufficient Data Availability Sampling (DAS) light nodes are online and the network proves stable, blob space is expected to increase to 8 MB shortly after launch. DAS light nodes serve two key functions:
-
Enable users to personally verify that Eclipse block data is available;
-
Help securely scale the entire network, as higher DA layer throughput can be safely enabled with more DAS light nodes online.
Celestia is expected to be the first DA layer to enable DAS in production. This contrasts with traditional Data Availability Committees (DACs), which reintroduce committee honesty assumptions without user verification (similar to existing monolithic blockchains).
Users bridging funds from Ethereum mainnet to any chain using off-chain DA face inherent security assumptions. Technically, Celestia validators could reject transaction data but claim it is available on the Ethereum bridge. Practically, however, Celestia’s proof-of-stake consensus makes data withholding on Celestia itself punishable, leading us to consider this risk unrealistic.
Overall, Celestia’s Day-1 support for DAS light nodes, cryptoeconomic security properties, and highly scalable DA throughput make it the clear choice for Eclipse Mainnet today.
We also intend to monitor Ethereum’s progress on DA scaling post-EIP-4844. Exciting new research continues to emerge, potentially offering high-throughput DA earlier than previously thought (using more advanced distributed hash tables). If Ethereum can offer greater scale for our users, we will evaluate the possibility of migrating to Ethereum DA.
Proving: RISC Zero ZK Fraud Proofs (No Intermediate State Serialization!)
Our proving mechanism will resemble Anatoly’s SVM fraud proof SIMD, which itself builds on John Adler’s insight that state serialization is costly and avoidable.
Specifically, we want to avoid reintroducing Merkle trees in SVM. We experimented with inserting sparse Merkle trees after each transaction in SVM, but updating them caused noticeable performance degradation. Avoiding Merkle trees rules out existing generic rollup frameworks (like OP Stack) as a foundation for SVM rollups, necessitating a more creative fault-proof architecture.
In short, a fault proof requires:
-
A commitment to transaction inputs,
-
The transaction itself, and
-
Proof that re-executing the transaction produces a different output than the one specified on-chain.
Input commitments are usually done by providing the Merkle root of the rollup state tree. Our executor will publish a list of inputs and outputs for each transaction (including account hashes and relevant global state), along with the index of the transaction that produced each input. Transactions are published on Celestia, so any full node can independently extract accounts from its own state, compute output accounts, and verify that commitments on Ethereum are correct.
Two primary types of faults may occur:
-
Incorrect output — In this case, the verifier submits a zero-knowledge proof on-chain of the correct SVM execution output. We use RISC Zero to generate zero-knowledge proofs of SVM execution, extending our prior work proving BPF bytecode execution. This allows our settlement contract to ensure correctness without re-executing transactions on-chain.
-
Incorrect input — Here, the verifier publishes on-chain a reference pointing to historical data showing the input state doesn’t match what was claimed. Using Celestia’s Quantum Gravity Bridge, our settlement contract verifies that this historical data indeed proves fraud.
We stand on the shoulders of giants. Today’s rollups have advanced the research frontier of our entire industry and already offer Ethereum users lower fees than L1.
Yet they don’t fully leverage the latest technologies needed for massive scale. Recent breakthroughs have eliminated the necessity of the trade-offs early rollups had to make — rendering those trade-offs not just unnecessary, but disadvantageous:
-
High-performance parallel VMs (e.g., SVM);
-
DA scaling with DAS light node support (e.g., Celestia);
-
Advancements in proving infrastructure making it practical anywhere (e.g., RISC Zero);
-
Improved portability of code (e.g., Neon and Solang) and users (e.g., MetaMask Snaps) across ecosystems
We can learn from limitations faced by other chains and selectively integrate the best components for long-term scalability.
We often hear visions of a future with a million app-specific rollups.
Consensus-level customization may be valuable for certain applications (e.g., dYdX v4), and we’re excited to help teams launch app-specific rollups.
However, such cases are rare. That’s why most new rollups are still just plain EVM forks. Developer problems aren’t solved by fragmenting UX across more chains. The primary use case found today for millions of chains often seems to be launching more tokens. For the vast majority of use cases, there’s simply no need for full-stack technical customization.
Even when real demand exists, the infrastructure required to support many app-chains with competitive UX won’t be ready for years (if ever). Optimism’s Superchain (OP Stack), zkSync’s Hyperchains (ZK Stack), Arbitrum’s Orbit chains, etc., all envision multiple chains sharing infrastructure. This aims to provide smoother UX for inter-chain operations within the same ecosystem (e.g., two chains within Superchain), rather than fully isolated chains (e.g., Ethereum vs. Solana).
Yet current plans (if any) remain far from competing with a single shared-state chain. Moreover, they don’t solve cross-ecosystem interoperability (e.g., Superchain to Hyperchain). Modular construction shouldn’t mean building silos.
Managing accounts across many chains is more complex for users. Constant cross-chain navigation and concerns over required gas tokens lead to worse UX. Relying on infrastructure providers to operate and maintain so many chains is also more complex and expensive.
We’ve always appreciated the simplicity of Solana’s vision: one highly optimized shared state machine, scaled to support most valuable use cases. This is often seen as incompatible with a rollup-centric roadmap, but in reality, it isn’t. We aim to combine the best of both worlds.
This misconception stems from today’s rollups largely running the original single-threaded EVM, with minimal changes to leverage early network effects. Hence, “dedicated blockspace” is often cited as a reason to deploy app-specific rollups. You don’t want other apps on your chain to spike fees due to a viral NFT mint — but the answer isn’t to spin up your own chain. That involves painful and unnecessary trade-offs (complexity, cost, worse UX, fragmented liquidity, etc.). The optimal solution is clear: simply use a parallel VM with native fee markets for state hotspots. That’s exactly what SVM offers.
Ethereum is the intellectual, social, and economic center of crypto. Its Achilles’ heel has always been scalability. DA scaling is still ongoing, and existing L2 execution environments can’t compete with newer innovations like SVM. We worry that if things remain unchanged, the Ethereum ecosystem will be caught off guard during any surge in activity. Single-threaded EVM and constrained DA will quickly bring back high fees — this time on rollups.
We believe Eclipse Mainnet is the obvious solution: combining Solana’s performance with the security, verifiability, and network effects of a rollup-centric roadmap.
Conclusion
The beauty of Ethereum lies in its constant innovation. The rollup-centric roadmap exemplifies this, delegating execution and innovation to the free market. L2s gain incredible ability to leverage Ethereum’s network effects and settlement guarantees while experimenting with the best new execution environments. Eclipse Mainnet is a natural realization of this vision.
If someday a higher-performance execution layer emerges, we’d be thrilled to see it deployed as a competitive Ethereum L2. Until then, SVM remains the standard.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@EclipseFND
