Why LI.FI is Excited about Eclipse & The Modular Future
Ethereum has long grappled with high fees and network congestion. Rollups hoped to alleviate these problems. However, as we have realized, simply shifting to rollups does not inherently solve the issue of gas fee spikes in times of high network activity.
For instance, the average transaction fee to perform a token swap on Arbitrum spiked to nearly $5 during Arbitrum Odyssey. This underscores that while rollups mark a positive step towards scaling Ethereum, they may not represent the endgame for blockchain design in their existing form. Perhaps the launch of various rollup frameworks indicates a consensus about this limitation. However, even if we continue building thousands of rollups, it won’t be possible to offer low transaction fees as long as all of them use Ethereum for data availability (i.e., for publishing their data) due to the throughput limitations of Ethereum.
This context sets the stage for a modular rollup like Eclipse, which presents a modular approach to constructing a scalable rollup by combining Ethereum with Solana's Virtual Machine for execution and Celestia for data availability.
This article breaks down Eclipse and explains why LI.FI is excited about a modular future.
Let’s dive in!
Eclipse: The Flag Bearer of the Modular Blockchain Thesis
At LI.FI, we believe that building more specialized blockchains could be the key to scaling crypto (transacting with increasing speed at decreasing gas cost). And this belief is not solely ours. It is actually an emerging idea in blockchain design that’s gaining traction, called the Modular Blockchain Thesis.
Eclipse was born out of the Modular Blockchain Thesis.
The Modular Blockchain Thesis suggests that separating the three layers of blockchains (execution, settlement, and data availability) into unique chains is more efficient than having one chain handle everything. By doing so, the goal is to make blockchains cheaper and more scalable through specialization.
Let’s dive into Eclipse’s architecture to highlight how Eclipse separates duties across multiple blockchains in order to achieve high throughput and low cost while maintaining security.
Eclipse Is a Rollup w/ Solana’s Speed + Low Fees, Ethereum’s Security, and Celestia’s Data Availability
Modular rollups like Eclipse benefit from optimizing at each layer.
Here’s how Eclipse aims to incorporate the best elements from various blockchain solutions for long-term scalability:
Eclipse will use the Solana Virtual Machine (SVM) as the Execution Layer
Eclipse is deeply inspired by the simplicity of Solana's vision – of a highly optimized, shared state machine capable of supporting global adoption for a majority of the most valuable use cases. Eclipse isn’t alone, as the network effects of the SVM codebase seem to be on the rise across the crypto developer ecosystem. For example, Maker DAO announced that they’ll be forking the SVM for its native chain dubbed “NewChain”.
While it’s certainly en vogue to be bullish SVM right now, Eclipse has made a deliberate choice to harness the power of modularity and use the SVM as its execution layer (the environment where transactions are processed and the new state of the blockchain is computed), and not the Ethereum Virtual Machine (EVM).
SVM stands out by enabling chains like Solana to optimize performance for high throughput at low cost. This is primarily achieved through optimized parallel execution of transactions and the implementation of localized fee markets. These features are major reasons why Eclipse chose SVM over EVM, as they allow for higher throughput and low fees, which is why we will dive deeper into these topics right now.
Single Threaded (EVM) vs. Parallel Execution (SVM)
While the EVM operates in a single-threaded manner, the SVM allows multiple transactions to be executed in parallel, significantly increasing throughput and efficiency.
Single-threaded execution in the EVM means that transactions are grouped into blocks, and these blocks are processed sequentially. This helps Ethereum maintain the consistency of its state across different nodes worldwide, as every node processes transactions in the same order. As a result, it’s easier to achieve consensus about the state of Ethereum.
However, even though single-threaded execution is simple in design and helps Ethereum’s nodes to maintain consistency of its state, it limits how many transactions Ethereum can handle at once. All nodes process only the transactions within the same block at a time. So, when many people try to make transactions at the same time, the fees shoot up, and people have to pay a premium (aka priority fee) to get their transactions processed on priority and get it executed in the next block (this also happens in single-threaded VMs other than the EVM but the dollar value of priority fees are much lower).
This is different from systems like the SVM, which can process many transactions at the same time. The SVM does this with features called Sealevel and Proof of History. It takes advantage of new hardware with many processors that can execute different transactions, enabling a single node to handle many transactions simultaneously. This is why Solana can execute >4.1K transactions per second on average.
Local Fee Markets
Another major benefit of SVM's parallelized execution capabilities is localized fee markets, a system where transaction fees are determined based on application-specific demand for block space.
This model differs from global fee markets, where every application must pay the same fees irrespective of the block space they’re using. As a result, this method prevents any single application from monopolizing the fee market, ensuring sufficient block space is available for every application to offer low-cost transactions to its users.
Eclipse will use Ethereum as the Settlement Layer
Eclipse will leverage the security of Ethereum to verify the execution of its transactions, similar to traditional rollups like Optimism and Arbitrum. It will do so via a native bridge with Ethereum, which will play a pivotal role in Eclipse’s functioning. This is important, as Eclipse’s native bridge with Ethereum allows it to be enshrined in the rollup ecosystem.
Using Ethereum for security and liveness
Ethereum grants security properties to Eclipse because the proof of all Eclipse transactions is ultimately settled on Ethereum via the native bridge.
Each Eclipse node also runs a full Ethereum node and all Eclipse’s transactions are verified on the native bridge (that is connected to Ethereum) via a proof, allowing the bridge to maintain the current state of the Eclipse chain at all times. The bridge acts as the source of truth for Eclipse nodes to determine the canonical chain. Thus, like other L2s like Arbitrum and Optimism, the native bridge with Ethereum enforces the correct ordering for Eclipse transactions.
Consequently, in the event of a disruption in the Eclipse Sequencer, users can publish proofs for verification via the native bridge. This feature enhances the network's liveness and censorship resistance, bolstering the overall reliability of Eclipse.
Moreover, Ethereum currently holds 70% of the total value locked in DeFi. By establishing connectivity with Ethereum via the native bridge, Eclipse will hope to onboard some of the existing liquidity from Ethereum to its ecosystem.
Using Ethereum as a Hub for bridging between Rollups
By choosing Ethereum as the settlement layer, Eclipse can share a common layer with other prominent rollups in the EVM ecosystem, like Arbitrum, Optimism, Base, and zkSync.
As all these rollups maintain a native bridge with Ethereum, it serves as a central Hub, linking all these chains together. This removes the need for each rollup to form individual bridges with each other, allowing for inter-rollup bridging via Ethereum.
For instance, sending a message from Eclipse to Arbitrum using Ethereum as the Hub would look something like this: Eclipse -> Ethereum -> Arbitrum.
However, this system is limited in the number of tokens it can support and the speed at which it can enable users to bridge assets across rollups. Thus, third-party liquidity bridges like Across and Catalyst are still necessary to offer users a fast bridging experience.
Eclipse will use Celestia as the Data Availability (DA) Layer
Eclipse will publish the data related to its transactions on Celestia, using it as a data availability (DA) layer. With Celestia, all the data required to verify transactions and reconstruct the final state of the blockchain is available to download for all the nodes. According to Eclipse, Celestia currently stands as the sole DA solution capable of providing the required block space to achieve the targeted high throughput and attain Solana-like low fees.
The team's assessment suggests that even with EIP-4844, also known as "Proto-danksharding", Ethereum's DA infrastructure will fall short of meeting Eclipse's demands. Furthermore, alternative DA solutions like EigenDA and Polygon Avail are still in the early stages of development and are not near a Mainnet launch.
It's worth noting that Eclipse remains open to the possibility of transitioning to Ethereum DA or any other suitable DA solution if it can offer greater scalability to Eclipse in the future.
Eclipse Leverages Other Crypto Superpowers Too
Eclipse is a modular rollup and it is not limited to just borrowing from other blockchains in building a scalable and low-cost experience. Eclipse will also use a few other crypto primitives as well, such as:
Eclipse will use RISC Zero for ZK Fraud Proofs
In Rollups, sequencers order the transactions, which are then fed to full nodes of the blockchain. From there, the selected nodes process (or execute) the transactions, compute the resulting state of the blockchain, and publish it on the data availability layer in the form of blocks.
This posted state, however, is optimistically verified (it's assumed optimistically that the transactions are valid) and thus, untrusted in its current form and needs to be verified directly on Ethereum in the case of rollups. This verification process is called the settlement process, where rollups use the concept of fraud proofs. Here, there are two approaches:
Optimistic fraud proofs – all transactions are considered valid unless verifiers (typically full nodes) challenge them using fraud proofs and prove otherwise.
Zero knowledge fraud proofs – transactions are verified by generating a zk proof. It is "a method by which one party (the prover) can prove to another party (the verifier) that a given statement is true [without] conveying any additional information".
However, there’s now a hybrid settlement process that’s being adopted by modular rollups like Eclipse called optimistic zk proofs, where all transactions are considered valid, and in the case the transactions are challenged, a zk proof is created to verify correctness.
Eclipse integrates zk fraud proofs through RISC Zero's zkVM. This integration enables Eclipse to create zk proofs of SVM execution and validate the correctness of outputs derived from Rust code.
Let’s see how this mechanism works by diving into the lifecycle of an Eclipse transaction:
Users create transactions by interacting with applications on Eclipse Mainnet.
Transactions are received by Eclipse full nodes via wallets (through RPC nodes).
The Eclipse Sequencer orders transactions in a block.
A commitment is made by the Executor (full nodes of Eclipse) to the order of transactions within the block.
The commitment of the block is posted on Ethereum via the native bridge.
The Executor constructs and executes the block and computes the resulting state (untrusted) of the Eclipse blockchain.
The Executor posts this block to the Celestia (the data availability layer).
To verify the correctness of executed transactions, the settlement process is conducted on the smart contract on Ethereum.
So here’s what Eclipse’s settlement process will look like, where all 4 superpowers of Eclipse work in tandem – SVM produces the block and computes the resulting state, block data is posted on Celestia, zk fraud proofs created by RISC Zero, and the settlement contract eventually verifies the correctness of the transactions in the block on Ethereum.
Eclipse’s will use a Dynamic Interop Framework
Eclipse has established its native bridge with Ethereum and uses Hyperlane, along with Cosmos IBC, to ensure connectivity with other blockchains. Here's a breakdown of Eclipse's connectivity options:
With Ethereum – Eclipse employs its native bridge, referred to as the 'enshrined validating bridge,' directly deployed on the Ethereum network. This bridge facilitates the transfer of assets to Eclipse from Ethereum.
With Solana and Other EVM and Non-EVM Chains – Eclipse's connection to non-Ethereum chains is achieved through Hyperlane. Hyperlane’s Permissionless Interoperability solution is specifically designed to enable fast and final bridging between Eclipse and non-Ethereum chains, including those based on the SVM like Solana.
With Cosmos Chains – Eclipse is actively working on an integration with the Cosmos Inter-Blockchain Communication (IBC) protocol. While this integration is still in development, it promises to establish trust-minimized bridging between Eclipse and Cosmos chains.
Eclipse Challenges the ‘a Chain for Every App’ Thesis with Composability
Eclipse acknowledges that specific sectors like gaming and successful DeFi projects like dYdX will undoubtedly benefit from building application-specific chains tailored to their needs. However, Eclipse fundamentally questions the need for every application to have its own blockchain.
Eclipse believes that the idea of a future characterized by thousands of application-specific chains, while being pushed by many smart teams, is characterized by several unanswered questions…
How will these chains be made searchable and easily accessible for wallets? Are we fragmenting users and liquidity across isolated rollup clusters? What does UX look like in a rollup-centric future? Is it truly the ideal UX if users have to sift through lists of chains in dApps and wallets to find the one they want to use? How do bridges connect to all these new chains? Is it smart to create a rollup-centric roadmap when nobody has figured out how to run a decentralized sequencer?
On the contrary, Eclipses believes that most applications will benefit from the composability with other applications on a shared state more than they would from customized features on their own chain.
Eclipse advocates for building a highly scalable blockchain with the power of modularity – building a specialized blockchain that offers high throughput and low gas fees for users by leveraging the benefits of different blockchain ecosystems for different things. Ethereum for settlement, Solana for execution, Celestia for data availability.
Why LI.FI is Excited About Eclipse, SVM Chains & the Modular Future
While Eclipse certainly isn’t guaranteed to win the L2 war, there’s no denying that it has the potential to be a game-changer in the blockchain world.
By leveraging the SVM for execution and Celestia for data availability, Eclipse provides developers with a powerful tool to create high-performance, low-cost blockchain applications that share the same state. These applications can operate without being hampered by the typical issues associated with high transaction costs and limited throughput on traditional blockchains.
Moreover, as Eclipse bootstraps its ecosystem, several liquidity bridges will enable cross-chain swaps to/from Eclipse and other SVM and EVM-compatible chains (Eclipse can support programs built for the EVM using Neon EVM).
LI.FI will Power Eclipse & SVM Chains w/ Essential Cross-Chain Tools
Over the past six months, LI.FI has built a solution that not only enables us to support Solana but also opens the door to supporting any chains compatible with SVM in the future. This includes Eclipse and potential application-specific blockchains developed on Eclipse, or even chains like Maker DAO's newChain, which is likely to fork the SVM down the line.
We plan to aggregate the most in-demand liquidity bridges that support the Eclipse Mainnet. This aggregation will be combined with DEXs on the chain, enabling us to support cross-chain swaps to and from any of the 18+ chains supported by LI.FI to Eclipse.
As a result, applications on Eclipse will gain access to liquidity from any chain, simplifying the onboarding of users to Eclipse by integrating LI.FI’s API, SDK, and Widget. They can also choose to build more customized cross-chain strategies on Eclipse using our developer tools. Furthermore, users can swap and bridge to Eclipse via Jumper.exchange directly.
We’re incredibly excited about the progress and expansion of the modular ecosystem.
Props to Eclipse and teams like Celestia for their forward-thinking approach towards blockchain development. We’re excited to witness and support their growth in the near future.
Acknowledgements: Thanks to Mark Murdock (LI.FI) for the edits and Neel Somani (Eclipse), Jim Chang (Catalyst), Heechang Kang (Four Pillars), and Dominik Hell (LI.FI) for feedback on the article.
FAQ: Why LI.FI is Excited about Eclipse & The Modular Future
Get Started With LI.FI Today
Enjoyed reading our research? To learn more about us:
- Head to our link portal at link3.to
- Read our SDK ‘quick start’ at docs.li.fi
- Join the official Discord Server
- Subscribe to our newsletter on Substack
- Follow our Telegram Newsletter
- Follow us on Twitter & LinkedIn
Disclaimer: This article is only meant for informational purposes. The projects mentioned in the article are our partners, but we encourage you to do your due diligence before using or buying tokens of any protocol mentioned. This is not financial advice.