Compilation & Translation: TechFlow

Currently, Layer 2 solutions and cross-chain interoperability have become hot topics. Recently popular Eclipse offers an SVM based on Solana and can also function as an Ethereum L2.

Is this beneficial for Solana? Two different types of public chains are in some way combined through Eclipse—how should this evolve moving forward?

In this podcast, Neel shares with us Eclipse’s design philosophy, its relationship with other technologies such as Solana and Ethereum, and the trade-offs between centralization and decentralization within Eclipse.

Hosts: David & Ryan, Bankless

Guest: Neel Somani, CEO and Co-founder of Eclipse

Source: Bankless

Episode: Link 

Release Date: September 20

Motivations and Challenges Behind Eclipse

• Eclipse Mainnet is a new L2 solution featuring an embedded Solana SVM (Solana Virtual Machine). Neel explains that Eclipse’s original goal was to bring Solana to Ethereum—leveraging Solana’s execution capabilities while benefiting from Ethereum’s settlement layer and liquidity—but they encountered many limitations and constraints.

• One major challenge relates to data availability. Neel mentioned that according to their projections, if operating at the transaction volume they anticipate, data availability on Ethereum would become prohibitively expensive. To address this and keep transaction fees competitive, the Eclipse team decided to integrate Celestia and Risk Zero—Celestia for data availability and Risk Zero for fraud proofs.

• Neel also noted that due to Solana lacking certain fundamental technical components like global Merkle trees, porting it onto Ethereum became significantly more difficult. As a result, additional measures—such as integrating Celestia and Risk Zero—were necessary to ensure Eclipse could successfully achieve its goals.

TechFlow Note: Merkle Tree is a data structure used to verify data integrity and content without revealing all the data; primitives refer to basic, core functions or components.

Solana Virtual Machine (SVM) vs Ethereum Virtual Machine (EVM)

• Differences in Execution

  • EVM: Neel points out that the main issue with EVM is that it's single-threaded—all transactions execute sequentially, making the network prone to congestion during high-traffic events like NFT mints.

  • SVM: Unlike EVM, SVM’s key advantage lies in its ability to execute transactions in parallel. As long as transactions don’t involve the same state, they can be processed simultaneously—greatly improving processing speed and efficiency.

• Design Purpose and Network Effects

  • EVM: While EVM may not be optimal in execution performance, it benefits greatly from strong network effects. A vast number of applications have already been built for EVM, making migration easier.

  • SVM: The network effect around SVM is also growing. Neel predicts SVM will continue evolving and enable entirely new applications that wouldn't exist in non-parallel execution environments.

• Underlying Technology and History

  • EVM: Designed specifically for Ethereum, taking into account Ethereum’s unique requirements and features.

  • SVM: Neel mentions that SVM is actually based on the BPF (Berkeley Packet Filter) virtual machine—a VM that has existed within the Linux kernel for decades, lending greater stability and reliability to SVM.

Choosing Between Celestia and Ethereum for Data Availability

• Neel explains that when Celestia launches, it will represent the most advanced scalable blockspace currently available for making transactions accessible.

• Neel notes that Ethereum’s bandwidth limitations restrict the number of transactions that can be published. Celestia, as an advanced scalable blockspace, aims to solve this problem. With Celestia launching soon, it holds a time-to-market advantage over other technologies still under development.

• Eclipse chooses Ethereum as its settlement and liquidity source and uses ETH as gas. Neel believes that although Celestia might capture part of Ethereum’s value, the “monetary” nature and “value flow” of ETH remain key differentiators.

• Most transaction costs typically come not from data availability but from execution. During network congestion, execution fees increase significantly.

• Eclipse relies on Ethereum for security. By periodically publishing state roots or commitments to Ethereum, Eclipse inherits Ethereum’s security.

• Neel emphasizes that this relationship between Eclipse and Ethereum brings valuable activity and usage to Ethereum.

Modular Design and Risk Zero

• Neel explains that Risk Zero is an ambitious ZK UVM (Zero-Knowledge Universal Virtual Machine), whose primary function is generating zero-knowledge proofs for program execution.

• Most ZK UVMs are designed to prove specific, customized programs—often highly restricted and only suitable for particular tasks or computations. Risk Zero takes a different approach by being based on Risk Five, a general-purpose virtual machine. Risk Five is an open instruction set architecture that has existed for a long time and is widely used across various computing tasks.

• A key feature of Risk Zero is its ability to generate zero-knowledge proofs for any Risk Five program. Almost any program written for Risk Five—whether in Rust, C++, or another language—can run on Risk Zero and produce a proof verifying correct execution without revealing the program’s content or other details.

• This capability gives Risk Zero tremendous flexibility and broad applicability. For example, in Eclipse, when transactions are submitted and executed internally, Risk Zero generates zero-knowledge proofs for these transactions, ensuring correctness and integrity.

• Traditionally, verifying transaction correctness requires re-executing them on Ethereum—an approach that is both time-consuming and costly, especially for complex smart contract transactions.

• By using Risk Zero, Eclipse avoids the need for re-execution. Once a zero-knowledge proof is generated, it can be submitted to Ethereum to prove that the transaction was correctly executed on Eclipse, without needing to replay it on Ethereum.

• Avoiding re-execution on Ethereum dramatically reduces verification-related costs. This is a significant advantage for applications and users who want to leverage Ethereum’s security without paying high fees.

• Neel emphasizes that Eclipse is not just a traditional Layer 2 solution—it also provides a framework offering developers tools, structure, and greater flexibility to customize their own chains according to their needs and goals.

• Because Eclipse provides such a framework, multiple Eclipse chains can exist. These chains can be fully independent or interoperate with the main Eclipse chain or other Eclipse chains. This multi-chain architecture enables higher parallelism and scalability, allowing different applications and projects to operate on their own chains without affecting others’ performance.

Balancing Centralization and Decentralization

• The host observes that Solana has a broader validator set, whereas Eclipse outsources its decentralization aspect to Ethereum. Neel counters that decentralization isn't always optimal, especially when weighed against security and efficiency.

• Neel notes that unlike Solana, Eclipse may appear less decentralized. While Solana has thousands of validators, Eclipse’s fixed costs are about 4,000 times lower than Solana’s because it only requires one validator.

• When considering Roll-Up design and implementation, Neel argues the most critical factor is its security properties—focus should be on whether the Roll-Up provides adequate security guarantees rather than simply how decentralized it is.

• If a Roll-Up can offer the same security properties as a fully decentralized system, then partial centralization of certain components is acceptable. For instance, a Roll-Up’s sequencer might be centralized, but as long as it doesn’t compromise overall system security, this is tolerable.

• Neel emphasizes that even if a sequencer refuses to process a transaction, users can still directly submit the transaction to Ethereum, providing a decentralized fallback option.

Future Outlook for Eclipse

• Neel believes current terminology may not fully capture Eclipse’s characteristics and functionality. He prefers viewing Eclipse as a Layer 2 Validium tightly integrated with Ethereum, using EVM as its execution environment. Looking ahead, Neel hopes to see novel applications and genuine innovation emerge on Eclipse, particularly projects related to energy.

• Neel mentions that Eclipse Mainnet currently has no token. Since Eclipse’s operational costs are low—mainly covering blockspace fees on Celestia and Ethereum—there’s no need to issue tokens to pay validators. Unlike Layer 1s, Roll-Ups like Eclipse are profitable from day one, as each transaction pays for itself.

• The host suggests Solana itself might benefit from becoming an Ethereum Layer 2. Neel agrees that while Solana hasn’t taken this path yet, Eclipse is experimenting with exactly this model—building from scratch and observing how the experiment unfolds.