Dialogue Eclipse Co-founder: How does Solana SVM become Ethereum's L2?
Organized & Compiled by: Deep Tide TechFlow
Currently, Layer 2 solutions and cross-chain interoperability have become hot topics. The recently popular Eclipse offers an SVM based on Solana and can be used as an L2 for Ethereum.
Is this a positive development for Solana? Two different types of public chains have been combined to some extent through Eclipse; how should they develop in the future?
In this episode of the podcast, Neel shares with us the design philosophy of Eclipse, its relationship with other technologies like Solana and Ethereum, and the trade-offs between centralization and decentralization in Eclipse.
Hosts: David & Ryan, Bankless
Speaker: Neel Somani, CEO and Co-founder of Eclipse
Podcast Source: Bankless
Program: Link
Release Date: September 20
Motivations and Challenges of Eclipse
The Eclipse mainnet is a new L2 solution characterized by its integration of Solana's SVM (Solana Virtual Machine). Neel explains that the original intention of Eclipse was to bring Solana to Ethereum, leveraging Solana's execution capabilities while utilizing Ethereum's settlement and liquidity, but they encountered many limitations and constraints.
One of the main challenges is related to data availability. Neel mentions that according to their predictions, if they operate at the expected transaction volume, Ethereum's data availability will become very expensive. To address this issue and ensure that transaction fees remain competitive, the Eclipse team decided to introduce Celestia and Risk Zero, with Celestia being used for data availability and Risk Zero for fraud proofs.
Neel also notes that the lack of certain fundamental technical components in Solana, such as a global Merkle tree, makes the task of bringing it to Ethereum more challenging. Therefore, they had to take additional measures, such as introducing Celestia and Risk Zero, to ensure that Eclipse could successfully achieve its goals.
Deep Tide Note: Merkle Tree is a data structure used to verify the integrity and content of data 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 is single-threaded, meaning all transactions are executed sequentially, which makes the network susceptible to congestion from a large number of transactions (such as NFT launches).
SVM: In contrast to EVM, the main advantage of SVM is its ability to execute transactions in parallel. As long as these transactions do not involve the same state, they can be executed simultaneously, significantly improving processing speed and efficiency.
Design Purpose and Network Effects
EVM: Although EVM may not be optimal in execution, it is favored due to its network effects. A large number of applications have been built for EVM, making it easier to migrate these applications to other platforms.
SVM: The network effects of SVM are also growing. Neel predicts that SVM will continue to evolve in the future and bring new applications that would not exist in a non-parallel execution environment.
Underlying Technology and History
EVM: Designed for Ethereum, primarily considering Ethereum's specific needs and functionalities.
SVM: Neel mentions that SVM is actually based on the BPF (Berkeley Packet Filter) virtual machine. This virtual machine has existed in the Linux kernel for decades, making SVM more stable and reliable.
Data Availability Choices of Celestia and Ethereum
Neel explains that when Celestia goes live, it will be the most advanced scalable block space currently available for making transactions available.
Neel points out that Ethereum's bandwidth limitations result in only a limited number of transactions being published. Celestia, as an advanced scalable block space, aims to address this issue. Celestia is about to launch and has a time advantage over other technologies still in development.
Eclipse chooses Ethereum as its source of settlement and liquidity, using ETH as gas. Neel believes that while Celestia may capture some value from Ethereum, the "monetary" and "value flow" aspects of ETH are key differentiators between the two.
Most of the costs associated with transactions are typically not for data availability but for execution. During network congestion, execution fees increase.
Eclipse relies on the security provided by Ethereum. By regularly publishing state routes or commitments to Ethereum, Eclipse gains this security.
Neel emphasizes that this relationship between Eclipse and Ethereum brings value flow to Ethereum.
Modular Design and Risk Zero
Neel explains that Risk Zero is a very ambitious ZK UVM (Zero-Knowledge Proof Virtual Machine) primarily designed to generate zero-knowledge proofs for program execution.
Most ZK UVMs are designed to prove specific, customized programs. These programs are often very limited and can only be used for specific tasks or computations. Risk Zero takes a different approach, based on a general virtual machine called Risk Five. Risk Five is an open instruction set architecture that has been around for a long time and is widely used for 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 already written for Risk Five, whether in Rust, C++, or other languages, can run on Risk Zero and generate a proof that the program has executed correctly without revealing the specific content or other details of the program.
This capability provides Risk Zero with tremendous flexibility and a wide range of applications. For example, in Eclipse, when a transaction is submitted and executed internally, Risk Zero is used to generate zero-knowledge proofs for these transactions. These proofs ensure the correctness and integrity of the transactions.
To verify the correctness of a transaction, the traditional method requires the transaction to be re-executed on Ethereum. This not only takes time but can also incur high costs when executing transactions on Ethereum, especially complex smart contract transactions.
By using Risk Zero, Eclipse can avoid this re-execution requirement. Once a zero-knowledge proof is generated, it can be submitted to Ethereum to prove that the transaction has been executed correctly on Eclipse without needing to execute it again on Ethereum.
By avoiding the need to re-execute transactions on Ethereum, this significantly reduces the costs associated with transaction verification. This is a huge advantage for applications and users who want to leverage Ethereum's security but do not want to pay high fees.
Neel emphasizes that Eclipse is not just a traditional Layer 2 solution; it also provides a framework that offers developers a set of tools and structures with greater flexibility, allowing them to customize their chains according to their needs and goals.
Because Eclipse provides such a framework, multiple Eclipse chains can exist. These chains can be completely independent or communicate with the main Eclipse chain or other Eclipse chains. This multi-chain structure offers higher parallelism and scalability, allowing different applications and projects to run on their own chains without affecting the performance of other chains.
Trade-offs Between Centralization and Decentralization
The hosts mention that Solana has a broader set of validators, while Eclipse outsources its decentralization aspect to Ethereum. Neel believes that decentralization is not always the best choice, especially when weighing security and efficiency.
Neel points out that, unlike Solana, Eclipse may not be as strong in decentralization. Solana has thousands of validators, while Eclipse's costs are 4,000 times lower in fixed aspects because it only requires one validator.
When considering the design and implementation of Roll-Ups, Neel believes that the most critical factor is to consider their security attributes, focusing on whether Roll-Ups can provide the necessary security guarantees rather than simply whether they are decentralized.
If Roll-Ups can provide the same security attributes as a fully decentralized system, then some components' centralization is acceptable. For example, the sequencers of Roll-Ups may be centralized, but as long as they do not threaten the overall security of the system, such centralization is acceptable.
Neel emphasizes that even if a sequencer refuses to process a transaction, users can still submit the transaction directly to Ethereum, providing users with a decentralized alternative.
Future Outlook for Eclipse
Neel believes that existing terminology may not accurately describe the characteristics and functionalities of Eclipse. He prefers to view Eclipse as a Layer 2 Validium closely integrated with Ethereum, where EVM serves as its execution environment. For the future, Neel hopes to see new applications and true innovations on Eclipse, especially projects related to energy.
Neel mentions that the Eclipse mainnet currently has no token. Due to the low operating costs of Eclipse (primarily paying for block space on Celestia and Ethereum), there is no need for a token issuance to pay validators. Unlike Layer 1, Roll-Ups (like Eclipse) have been profitable from day one, as each transaction pays for its own fees.
The hosts mention that Solana might be better off as a Layer 2 for Ethereum. Neel believes that although Solana has not taken this path currently, Eclipse is attempting this approach by building from scratch and observing how this experiment develops.