TL;DR: We’re excited to finally announce the architecture for Eclipse Mainnet: Ethereum’s fastest L2, powered by the SVM.

Eclipse Mainnet is a general-purpose L2 that combines the best pieces of the modular stack:

• Settlement: Ethereum - Eclipse will settle to Ethereum (i.e., the enshrined validating bridge will be on Ethereum) and use ETH as its gas token.
• Execution: Solana Virtual Machine (SVM) - Eclipse will run the highly performant SVM as its execution environment.
• Data Availability: Celestia - Eclipse will post its data to Celestia for scalable data availability (DA).
• Proving: RISC Zero - Eclipse will use RISC Zero for ZK proofs of fraud (without intermediate state serialization!)

Most of Eclipse’s headlines have been around our work to deploy app-specific rollups for a range of projects, but it’s now clearer than ever that Ethereum needs a general-purpose L2 capable of truly massive scale. Most applications don’t benefit from app-specific chain customizations, and the resulting isolation and complexity can actually result in worse UX and developer experience.

There’s often a false dichotomy presented between the modular rollup vision vs. the ability to have a single chain with massive scale, parallelized execution, and shared state. “Modular” is often conflated with “app-specific”, which would lead you to believe that rollups mean a world of many fragmented and low-throughput chains. We challenge that idea.

Execution: Solana’s Speed & Scale

Eclipse Mainnet will adopt Solana’s best-in-class execution environment. This brings tremendous advantages:

Optimized Parallel Execution

The SVM and its Sealevel runtime famously enable parallel transaction execution. Transactions which don’t touch overlapping state can be executed in parallel rather than sequentially.

This allows the SVM to directly scale with hardware as processors continue to add more cores at lower cost. Single-threaded runtimes (such as today’s EVM) fundamentally do not benefit from reducing the cost per core. For over a decade now, single-threaded performance speedups have been continually diminishing. Nearly all improvements continue to come from increasing the number of cores, so it’s critical to take advantage of this trend by parallelizing workloads:

There are some very early unproven attempts to parallelize the EVM, but adding this on while maintaining compatibility brings fundamental tradeoffs including suboptimal performance without addressing other bottlenecks (e.g., state growth). Contracts declaring state dependencies upfront (as in the SVM) allows for optimal parallelization.

Local Fee Markets

Most fee markets today are global, meaning that one hot application increases fees for all users of the chain. One NFT mint shouldn’t render the chain useless for everything else. Solana’s amazing work on local fee markets solves this cross-app state contention. In its current implementation, the scheduler prioritizes transactions without conflicts, allowing conflict-free transactions to go through with lower fees. Longer term, local fee markets will be implemented at a protocol level. This ensures that fee spikes for a single app don't impact the rest of the chain.

Local fee markets are possible thanks to Solana’s uniquely parallelized runtime. Trying to implement local fee markets for state hotspots in the EVM using heuristics (i.e., without declaring state access upfront) would present inefficiencies and likely attack vectors.

There’s also early research underway that would allow applications to easily internalize the local value attributable to them, which today generally requires more creative app-level design.

State Growth Management

Before the EVM even bumps up against sequential execution as a bottleneck, state growth is its far more pressing bottleneck.

Because there is no Merkle tree for state, Solana doesn't incur the overhead of updating a Merkle tree for each state update. Instead, after each epoch (~2.5 days), the entire state is merklized. This is much cheaper than real-time merklization (as in the EVM).

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

As a result, state size doesn't impact SVM execution. The network could safely double the snapshot size every 2 years without running into major issues assuming validators upgrade their storage disks every 2 years.

Furthermore, teams like Helius are actively improving the accessibility of historical data and reducing state size with compression.

EVM Compatibility

Neon EVM is an EVM operating as a smart contract that can be deployed on any SVM chain. This brings full EVM compatibility to Eclipse Mainnet (including EVM bytecode support and the Ethereum JSON-RPC) with greater throughput than single-threaded EVMs. Because each Neon EVM instance has its own local fee market, apps can just deploy their own contract to attain the benefits of an app chain without fragmenting UX, security, or liquidity.

Separately, the Solang compiler enables compilation of Solidity smart contracts code into SVM bytecode.

MetaMask Snaps

Onboarding EVM users to non-EVM chains has historically been a major hurdle, but the recently unveiled Metamask Snaps are set to break down that barrier. EVM users can continue to use MetaMask without needing to switch wallets. The UX is comparable to interacting with any EVM chain, thanks to Drift’s open-source contributions building out a great MetaMask Snap implementation. Eclipse Mainnet users will be able to interact with apps natively in MetaMask or use a Solana-native wallet like Salmon.

Here’s a sneak peek of the UX from Drift:

Firedancer

Firedancer is the highly anticipated Solana client being developed by Jump to drastically increase the network’s throughput, resilience, and efficiency. At launch we will stick as closely as possible to the Solana core client, but we plan to adopt Firedancer once the code is live and stable.

Safety

Solana’s runtime has a greatly reduced attack surface area which prevents the infamous reentrancy exploits we’ve seen far too often. Specifically, the Solana runtime only allows programs to self-recurse, rather than allowing arbitrary reentrant cross program invocations. Moreover, separating state and code results in stateless code, which is typically easier to test effectively.

Easier Proving

The SVM is register-based and has a much smaller instruction set vs. the EVM, making SVM execution easier to prove in ZK. For optimistic rollups, the register-based design allows for easier checkpointing.

Settlement: Ethereum’s Security & Liquidity

As with today’s major rollups, Eclipse Mainnet will settle to Ethereum. Concretely, this means that our validating bridge on Ethereum will be directly enshrined into Eclipse. Eclipse nodes will look to this bridge to determine the “canonical chain”. The bridge enforces the correct ordering for Eclipse.

This allows our users to gain certain security properties from Ethereum. The bridge will validate all Eclipse transactions, preventing submission of invalid states. Additionally, it will enforce eventual liveness and censorship resistance under certain failure cases. Even if the sequencer were to go down or start censoring at the L2, users would be able to force inclusion of their transactions via the bridge.

Because of these security properties, validiums and optimiums are often referred to as “Ethereum L2s.” L2BEAT defines an L2 as “a chain that fully or partially derives its security from layer one Ethereum so that users do not have to rely on the honesty of L2 validators for the security of their funds.”

Ethereum settlement recognizes the importance that Ethereum-native assets will likely play in Eclipse Mainnet’s DeFi and NFT economies. ETH is the best decentralized money that most users clearly prefer, so we will also use ETH as our gas token. Longer term, fee abstraction will enable users to pay in any token of their choosing (e.g., USDC). There are no plans for Eclipse Mainnet to have its own token at this time.

Data Availability: Celestia’s Bandwidth & Verifiability

Eclipse Mainnet will utilize Celestia for data availability (a.k.a. data publishing or data publication). Celestia has been a long-standing ecosystem partner of Eclipse.

Eclipse Mainnet’s target throughput and fees are unfortunately not supported by Ethereum’s current bandwidth. This will remain so even after EIP-4844 (a.k.a. “Proto-danksharding”), which provides an average of ~0.375 MB blobspace per block (with a limit of ~0.75 MB per block).

• For ERC-20 transfers with basic compression (~154 bytes per transaction), this translates to ~213 TPS across all rollups combined.
• For swaps with compression (~400 bytes per transaction), this translates to ~82 TPS across all rollups combined.

In comparison, Celestia will launch with 2 MB blocks later this year. Blobspace is expected to increase to 8 MB shortly after launch, once enough data availability sampling (DAS) light nodes come online and the network proves stable. DAS light nodes serve two critical functions:

• Enable users to verify for themselves that Eclipse block data has been made available
• Contribute to securely scaling the entire network, as DA layers can safely increase their throughput as more DAS light nodes come online

Celestia is expected to be the first DA layer to launch with DAS in production. This contrasts with traditional Data Availability Committees (DACs), which reintroduce committee honesty assumptions without user verification (akin to existing monolithic blockchains).

There’s an inherent security assumption for users who bridge their funds from Ethereum Mainnet to any chain that uses offchain DA. In particular, it is technically possible for Celestia validators to withhold transaction data but claim to the Ethereum bridge that the data is available. In practice, Celestia’s proof-of-stake consensus means data withholding on Celestia itself is slashable, making this risk unrealistic in our view.

Overall, Celestia’s DAS light node support from day one, crypto-economic security properties, and highly scalable DA throughput make it the clear choice for Eclipse Mainnet today.

Note that some view onchain Ethereum DA as a requirement to be a true "L2" here for the reasons described above. We’re going by the more common L2 terminology cited earlier, and we want to be clear on the security considerations.

We also intend to monitor Ethereum’s progress on DA scaling after EIP-4844. Exciting new research continues to come out, potentially offering high throughput DA sooner than previous ideas (which use more advanced distributed hash tables). If Ethereum offers greater scale for Eclipse to the benefit of our users, we would assess the possibility of migrating to Ethereum DA.

Proving: RISC Zero ZK Proofs of Fraud (Without Intermediate State Serialization!)

Our proving will look similar to Anatoly’s SVM fraud proofs SIMD, which is itself similar to John Adler's insight that state serialization is expensive, and it is possible to avoid it.

Specifically, we want to avoid reintroducing a Merkle tree into the SVM. We experimented with inserting a Sparse Merkle Tree into the SVM early on, but updating the Merkle tree after each transaction results in substantial performance hits. Proving without a Merkle tree rules out existing generalist rollup frameworks like the OP Stack as a basis for SVM rollups, and it also requires a more creative fault proof architecture.

At a high level, a fault proof requires:

1. A commitment to inputs for a transaction,
2. The transaction itself, and
3. Proof that re-executing the transaction leads to a different output than what was specified onchain.

The input commitment is typically made by providing the Merkle root for the rollup’s state tree. Our executor will instead post a list of inputs and outputs (including account hashes and relevant global state) for each transaction, along with an index of the transaction which produced each input. The transactions are published to Celestia, so any full node can follow along to pull input accounts from its own state, compute the output accounts, and confirm that the commitment on Ethereum is correct.

There are two possible types of major faults:

1. Incorrect outputs - In this case, the verifier provides a ZK proof onchain of the correct outputs. We’re using RISC Zero to create ZK proofs of SVM execution, continuing our previous work proving BPF bytecode execution. This allows our settlement contract to ensure correctness without having to run the transactions themselves onchain.
2. Incorrect inputs - In this case, the verifier posts onchain a reference to the historical data showing that the input state is not as claimed. Using Celestia’s Quantum Gravity Bridge, our settlement contract ensures that this historical data does indeed prove fraud.

Why Eclipse, Why Ethereum, Why Now

We stand on the shoulders of giants. Today’s rollups have advanced the state of research for our entire industry, and they’ve provided Ethereum users with cheaper fees compared to the L1.

However, they don’t take full advantage of the latest technology that’s needed to scale to the masses. Early rollups largely prioritized EVM-compatibility and/or optimizations for more efficient ZK-proving. More recently though, we’ve seen unbelievable progress which obviates the need to make those tradeoffs that early rollups chose, and indeed puts them at a disadvantage:

• Highly performant parallelized VMs (e.g., SVM)
• DA scaling with DAS light node support (e.g., Celestia)
• Advances in proof infrastructure to make it practical anywhere (e.g., RISC Zero)
• Increased portability of code (e.g., Neon and Solang) and users (e.g., MetaMask Snaps) across ecosystems

Eclipse has the massive benefit of hindsight. We get to learn from the limitations that other chains have faced then cherry-pick the best pieces to scale for the long-term.

‍

‍

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

Consensus-level customizations can be incredibly valuable for certain applications (e.g., dYdX v4), and we’re excited to help teams launch app-specific rollups.

However, these cases are few and far between. That’s why most new rollups are still just vanilla EVM forks. Developers’ problems aren’t solved by fragmenting UX across more chains. The main use case for a million chains today often appears to be launching a million more tokens. The demand for full-stack customization simply doesn’t exist today for the vast majority of use cases.

Even if the real demand was there, the infrastructure required to support many app-chains with competitive UX is years away (if it ever gets to par). Optimism’s Superchain (OP Stack), zkSync’s Hyperchains (ZK Stack), Arbitrum’s Orbit chains, and so on all have many-chain visions with shared infrastructure. This is intended to provide smoother UX operating between chains in the same ecosystem (e.g., between two chains within the Superchain) vs. completely isolated chains (e.g., between Ethereum and Solana).

However, the current plans (where they exist) are still a far cry from ever being competitive with a single shared state. Furthermore, they don’t address interoperability across ecosystems (e.g., Superchain to a Hyperchain). Building modular shouldn’t mean building islands.

It’s more complicated for users to maintain accounts across many chains. It’s worse UX to keep bridging and worrying about what gas token you need. It’s more complicated and expensive to be reliant upon infrastructure providers for operating and maintaining so many chains.

We've always appreciated the simplicity of Solana’s vision. One highly optimized shared state machine with the scale to support the majority of valuable use cases. This is often viewed as incompatible with a rollup-centric roadmap, but that is simply not the case. We want to combine the best of both worlds.

This misconception arises due to the fact that today’s rollups are largely running the vanilla single-threaded EVM effectively unchanged in order to piggyback on early network effects. As a result, we often see “dedicated blockspace” cited as the reason to deploy an app-specific rollup. Those crazy NFT mints shouldn’t jack up the prices for all the other apps on your chain, but the answer isn’t to go make your own chain. This is like using a sledgehammer to crack a peanut. You make painful and unnecessary tradeoffs (complexity, cost, worse UX, fragmented liquidity, etc.). The optimal solution is incredibly clear - just use a parallelized VM with local fee markets for state hotspots. That’s exactly what the SVM brings.

Ethereum is the intellectual, social, and economic center of crypto. Its Achilles’ heel has been scaling. DA scaling is still in the works, and the existing L2 execution environments can’t compete with newer innovations like the SVM. We fear that the Ethereum ecosystem would be caught flat-footed by any sharp increase in activity as it stands today. Single-threaded EVMs and constrained DA would quickly lead to a resurgence of high fees, except this time on rollups.

We believe Eclipse Mainnet is the obvious solution: uniting Solana’s performance with the security, verifiability, and network effects of the rollup-centric roadmap.

Parting Thoughts

The beauty of Ethereum is that it eats innovation. The rollup-centric roadmap is the epitome of this, delegating execution and innovation to the free market. L2s have the incredible ability to leverage Ethereum’s network effects and settlement assurances while experimenting with the best new execution environments. Eclipse Mainnet is the natural fulfillment of this vision.

If a more performant execution layer comes along some day, we’ll be incredibly excited to see it deployed as a competitive Ethereum L2. Until then, the SVM remains the standard.

To get involved, reach out to us at team@eclipse.builders for testnet instructions.

‍