Eclipse Mainnet: A new L2 paradigm that combines the strengths of Solana and Ethereum technologies

Original Author: Eclipse

Original Title: 《Introducing Eclipse Mainnet: The Ethereum SVM L2》

Compilation: Deep Tide TechFlow

Eclipse Mainnet is a general Layer 2 that combines the best parts of modular architecture:

• Settlement Layer: Ethereum - Eclipse will settle on Ethereum (i.e., the verification bridge will be on Ethereum) and use ETH as its gas token.

• Execution Layer: Solana Virtual Machine (SVM) - Eclipse will run a high-performance SVM as its execution environment.

• Data Availability: Celestia - Eclipse will publish its data to Celestia for scalable data availability (DA).

• Proof: RISC Zero - Eclipse will use RISC Zero for fraud zero-knowledge proofs (without requiring intermediate state serialization!)

Most of Eclipse's highlights have revolved around deploying application-specific rollups for various projects, but it is now clearer than ever that Ethereum needs a truly scalable general Layer 2. Most applications will not benefit from the customizations of application-specific chains, and the resulting isolation and complexity can actually lead to worse user and developer experiences.

The vision of modular rollups often faces a false dichotomy between having large-scale scalability, parallel execution, and shared state single-chain capabilities. "Modular" is often confused with "application-specific," leading to the misconception that rollups imply a world of many fragmented and low-throughput chains.

Execution Layer: Solana's Speed and Scale

Eclipse Mainnet will adopt a Solana-class execution environment. This brings significant advantages:

Optimized Parallel Execution

The SVM and its Sealevel runtime are known for supporting parallel transaction execution. Transactions that do not touch overlapping states can be executed in parallel rather than serially.

This allows the SVM to scale directly with hardware as processors continuously add more cores at lower costs. Single-threaded runtimes (like today's EVM) inherently do not benefit from reduced costs per core. Over the past decade, improvements in single-threaded performance have been steadily diminishing. Almost all improvements still come from increasing the number of cores, so leveraging this trend for workload parallelization is crucial:

Despite some very early attempts to parallelize the EVM, adding it while maintaining compatibility comes with fundamental trade-offs, including suboptimal performance without addressing other bottlenecks (like state growth). Contracts that pre-declare state dependencies (as in the SVM) enable optimal parallelization.

Native Fee Market

Today, most fee markets are global, meaning a popular application raises fees for all chain users. Minting an NFT should not render the entire chain unusable for everything else. Solana's incredible work on native fee markets addresses this cross-application state contention issue. In its current implementation, the scheduler prioritizes non-conflicting transactions, allowing them to be processed at lower fees. In the long run, native fee markets will be realized at the protocol level. This ensures that fee spikes for a single application do not affect other parts of the chain.

Native fee markets benefit from Solana's unique parallel execution runtime. Attempting to implement a native fee market for state hotspots in the EVM using heuristic methods (i.e., without pre-declaring state access) would lead to inefficiencies and potential attack vectors.

Some early research is also underway to allow applications to easily internalize their own native value, which today often requires more creativity in application-level design.

State Growth Management

Before the EVM even encounters sequential execution as a bottleneck, state growth is its more pressing bottleneck.

Because state does not have a Merkle tree, Solana does not incur the overhead of updating the Merkle tree for each state update. Instead, the entire state is archived after each epoch (2.5 days). This is cheaper than real-time archiving (as in the EVM).

More importantly, the EVM has dynamic account access (i.e., transactions can touch any state on demand). This dynamic state lookup means that state cannot be loaded into memory before execution. In the SVM, each transaction specifies all the state needed for execution.

Thus, the size of the state does not affect SVM execution. Assuming validators upgrade their storage disks every two years, the network can safely double the snapshot size every two years without encountering significant issues.

Additionally, teams like Helius are actively improving the accessibility of historical data 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 greater than single-threaded EVM. Since each Neon EVM instance has its own native fee market, applications can simply deploy their own contracts to benefit from application 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 significant barrier, but the recently announced MetaMask Snaps will break this barrier. EVM users can continue to use MetaMask without switching wallets. Thanks to Drift's open-source contributions, a great MetaMask Snaps implementation has been built, providing an experience similar to interacting with any EVM chain. Eclipse Mainnet users will be able to natively interact with applications in MetaMask or use Solana-native wallets like Salmon.

Firedancer

Firedancer is the highly anticipated Solana client being developed by Jump, aimed at significantly increasing the network's throughput, resilience, and efficiency. At launch, we will stay as close to the Solana core client as possible, but we plan to adopt Firedancer once the code stabilizes in real-time.

Security

The attack surface of the Solana runtime is greatly reduced, preventing the reentrancy attacks we have seen too many times. Specifically, the Solana runtime only allows self-recursion in programs and does not permit arbitrary reentrant cross-program calls. Additionally, the separation of state and code leads to stateless code, which is generally easier to test effectively.

Simpler Proofs

SVM is register-based, and its instruction set is much smaller than that of the EVM, making SVM execution easier to prove in ZK. For optimistic rollups, a register-based design allows for simpler checkpoints.

Settlement Layer: Ethereum's Security and Liquidity

Like today's major rollups, Eclipse Mainnet will settle on Ethereum. Specifically, this means our verification bridge on Ethereum will be directly integrated into Eclipse. Eclipse nodes will look to this bridge to determine the "canonical chain." The bridge enforces the correct ordering of Eclipse.

This allows our users to gain certain security properties from Ethereum. The bridge will validate all Eclipse transactions, preventing the submission of invalid states. Furthermore, it will enforce finality and anti-censorship in certain failure scenarios. Even if the L2 sequencer stops operating or begins to censor, users will be able to force the inclusion of their transactions through the bridge.

Due to these security properties, effective and optimal libraries are often referred to as "Ethereum L2." L2BEAT defines L2 as "a chain that derives its security fully or partially from Ethereum Layer 1, so that users do not need to rely on the honesty of L2 validators to ensure the safety of their funds."

Ethereum settlement embodies the importance of Ethereum-native assets in the DeFi and NFT economy of Eclipse Mainnet. ETH is the clearly preferred decentralized currency for most users, so we will also use ETH as our gas token. In the long run, fee abstraction will allow users to pay with any token of their choice (e.g., USDC). Currently, there are no plans for Eclipse Mainnet to issue its own token.

Data Availability: Celestia's Bandwidth and Verifiability

Eclipse Mainnet will use Celestia for data availability (also known as data publishing). Celestia has been a long-term ecosystem partner of Eclipse.

Unfortunately, the target throughput and fees of Eclipse Mainnet are not supported by Ethereum's current bandwidth limitations. Even after EIP-4844 (also known as "Proto-danksharding"), which provides about 0.375 MB of blobspace per block (with a block limit of about 0.75 MB).

• For ERC-20 transfers with basic compression (about 154 bytes per transaction), this translates to about 213 TPS for all rollups.

• For compressed swaps (about 400 bytes per transaction), this translates to about 82 TPS for all rollups.

In contrast, Celestia will launch with 2 MB blocks by the end of this year. Once enough 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:

• Allow users to verify the availability of Eclipse block data themselves;

• Help securely scale the entire network, as the DA layer can safely increase its throughput with more DAS light nodes coming 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 the assumption of committee honesty without user verification (similar to existing monolithic blockchains).

There are inherent security assumptions for users bridging funds from the Ethereum mainnet to any chain using off-chain DA. Specifically, technically, Celestia validators can refuse transaction data while claiming that this data is available on the Ethereum bridge. In practice, Celestia's proof-of-stake consensus means that data withholding by Celestia itself is punishable, leading us to believe that this risk is unrealistic.

Overall, Celestia's DAS light node support from day one, cryptoeconomic security properties, and highly scalable DA throughput make it the clear choice for Eclipse Mainnet.

We also intend to monitor Ethereum's progress in DA scaling after EIP-4844. Exciting new research is emerging that may provide high-throughput DA sooner than previous ideas (which used more advanced distributed hash tables). If Ethereum offers greater scale for our users, we will evaluate the possibility of migrating to Ethereum DA.

Proof: RISC Zero ZK Fraud Proofs (No Intermediate State Serialization Required!)

Our proof will be similar to Anatoly's SVM fraud proof SIMD, which itself is akin to John Adler's insight that the cost of state serialization is high and can be avoided.

Specifically, we want to avoid reintroducing Merkle trees in the SVM. We attempted to insert sparse Merkle trees after each transaction in the SVM, but updating the Merkle tree resulted in significant performance loss. Not using Merkle trees excludes existing general rollup frameworks (like the OP stack) as a basis for SVM rollups, which also requires a more creative fraud proof architecture.

In short, fraud proofs require:

• A commitment to transaction inputs,

• The transaction itself, and

• Proof that re-executing the transaction leads to different outputs than those specified on-chain.

Input commitments are typically accomplished by providing the Merkle root of the rollup state tree. Our execution engine will publish input and output lists for each transaction (including account hashes and relevant global states), along with the index of the transaction that produced each input. Transactions are published on Celestia, so any full node can extract accounts from its own state, compute output accounts, and verify that the commitment on Ethereum is correct.

There are two main types of failures that may occur:

• Incorrect Output ------ In this case, the validator provides a zero-knowledge proof of the correct output of the SVM execution on-chain. We use RISC Zero to create zero-knowledge proofs of SVM execution, which is a continuation of our previous proofs of BPF bytecode execution. This allows our settlement contracts to ensure correctness without running these transactions on-chain themselves.

• Incorrect Input ------ In this case, the validator posts a reference to historical data on-chain, showing that the input state does not match the claim. Using Celestia's quantum gravity bridge, our settlement contracts ensure that this historical data indeed proves fraud.

We stand on the shoulders of giants. Today's rollups have advanced the research state of our entire industry and provided Ethereum users with lower fees than L1.

However, they have not fully leveraged the latest technologies that require scalability. Recent incredible advancements have eliminated the need for early rollups to make these trade-offs, effectively putting them at a disadvantage:

• High-performance parallel VMs (like SVM);

• DA scaling with DAS light node support (like Celestia);

• Advances in proof infrastructure that make it practical anywhere (like RISC Zero);

• Increased portability of cross-ecosystem code (like Neon and Solang) and users (like MetaMask Snaps).

We can learn from the limitations faced by other chains and then pick the best parts for long-term scaling.

We often hear about a future with a million application-specific rollups.

Consensus-level customization may be very valuable for certain applications (like dYdX v4), and we are excited to help teams launch application-specific rollups.

However, these cases are very rare. This is why most new rollups are still just ordinary EVM forks. Developer issues will not be solved by fragmenting UX across more chains. The main use cases found for millions of chains today often seem to just be launching more tokens. For the vast majority of use cases, there is currently no demand for a fully customized tech stack.

Even if real demand exists, the infrastructure needed to support many competitive UX application chains will take years to be in place (if it can reach a comparable level). Optimism's Superchain (OP stack), zkSync's Hyperchains (ZK stack), Arbitrum's Orbit chains, etc., all have visions of many chains with shared infrastructure. This aims to provide a smoother UX for inter-chain operations within the same ecosystem (e.g., between two chains in the Superchain) rather than completely isolated chains (e.g., between Ethereum and Solana).

However, the current plans (if any) are far from being able to compete with a single shared state. Furthermore, they do not address the interoperability issues across ecosystems (e.g., from Superchain to Hyperchain). Building modularity should not mean creating islands.

Maintaining accounts across many chains will be more complex for users. Constant cross-chain interactions and concerns about the required gas tokens lead to a worse user experience. Relying on infrastructure providers to operate and maintain so many chains is also more complex and costly.

We have always appreciated the simplicity of Solana's vision. A highly optimized shared state machine that scales to support most valuable use cases. This is often seen as incompatible with a rollup-centric roadmap, but it is not. We want to combine the best of both worlds.

This misunderstanding arises because today's rollups largely run the original single-threaded EVM, which has changed little to leverage early network effects. Thus, we often see "dedicated block space" cited as a reason to deploy application-specific rollups. Other applications on your chain should not become more expensive due to some crazy NFT minting, but the answer is not to create your own chain. You are making painful and unnecessary trade-offs (complexity, cost, worse user experience, fragmented liquidity, etc.). The best solution is very clear—just use a parallel VM with a native fee market for state hotspots. That is exactly what SVM brings.

Ethereum is the center of knowledge, society, and economy in crypto. Its Achilles' heel has always been scalability. The scaling of data availability is still ongoing, while existing L2 execution environments cannot compete with newer innovations like SVM. We are concerned that if the current state persists, the Ethereum ecosystem will be caught off guard in the event of any sharp increase in activity. The single-threaded EVM and constrained data availability will soon lead to a resurgence of high fees, only this time on rollups.

We believe that 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 is a prime example of this, delegating execution and innovation to the free market. L2 has the 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 a higher-performance execution layer emerges one day, we would be very excited to see it deployed as a competitive Ethereum L2. Until then, SVM remains the standard.