In the increasingly crowded landscape of Ethereum rollups, the majority of development has focused on a single model. The Ethereum Virtual Machine (EVM) remains the primary execution unit, meaning parallel execution remains an ambition rather than a common feature. Eclipse builds on this standard and brings the Solana Virtual Machine (SVM) in an Ethereum-oriented environment, with the rollup structure being revised to integrate this.
The introduction of the SVM to the Ethereum rollup landscape offers deterministic parallelism, meaning applications can operate in separate "lanes" instead of competing for a shared global queue. This plays a crucial role in managing congestion, formulating rates, and maintaining system performance during periods of high activity. These separate "queue markets" ensure that congestion in a single application doesn't increase costs across the network. This is a fundamental reason why Eclipse performs better under load than traditional EVM-based rollups.
Eclipse has also consciously moved away from the hyper-modular Rollups-as-a-Service model it initially pursued. Where dozens of configurations were previously offered, Eclipse has formalized its architecture. This allows us to see how the project has evolved from experiments with Polygon SVM and Cascade to a shared network running on the SVM, settling on Ethereum, and publishing data on Celestia.
Eclipse implements ZK-accelerated fraud proofs, powered by RISC Zero. In most optimistic rollups, disputes unfold through multi-day interactive games that replicate parts of the execution on Ethereum. Eclipse, on the other hand, encapsulates the disputed computation within a single, concise proof, which can be submitted when a challenge arises. This accelerates the dispute process and eliminates the need to rebuild intermediate states on Ethereum.
The fraud tests utilize a bond mechanism that attaches clear economic consequences to the challengers. A correct challenge leads to a reward, while an incorrect challenge results in the loss of the stake. This preserves the incentive model we know from optimistic rollups, but places the challenged computation within a zk-proof environment instead of on Ethereum itself.
Eclipse aims to achieve L2BEAT's Stage 2 classification, which requires permissionless fraud testing, strict upgrade rules, and a clear exit window for users. analysis covers the gap between the current design and these technical requirements. Currently, Eclipse is classified in the "Other" category of L2BEAT, and significant steps are needed to be recognized as a full-fledged Ethereum rollup.
A recent upgrade to support this is the ZK Data Availability Challenge subsystem, which verifies Celestia commitments on Ethereum for a predictable fee. This improves the requirements for verifiable data availability by allowing Ethereum smart contracts to verify Celestia's commitments instead of implicitly trusting them. However, this alone is not yet sufficient to meet the Stage 0 requirements.
Eclipse aims to achieve what no Ethereum layer-2 has yet proven in production. It combines a high-performance SVM runtime with Ethereum's settlement guarantees and an external data availability network. Whether this combination will result in a new class of rollups or expose the limits of modular designs remains an intriguing question for the future.
What makes Eclipse different from other L2 solutions?
Eclipse implements deterministic parallelism using the SVM, which allows applications to operate independently and manage congestion more effectively.
How does Eclipse ensure the security of its system?
Eclipse uses ZK-accelerated fraud tests and a bond mechanism that provides economic incentives for proper challenges and penalties for improper ones.
What are Eclipse's future plans?
Eclipse aims to achieve Stage 2 classification of L2BEAT, with a focus on improving permissionless fraud testing and ensuring data availability.