Author: YBB Capital Researcher Ac-Core

Eclipse Background

Eclipse founder Neel Somani, who previously worked as a software engineer at Airbnb and a quantitative researcher at Citadel, founded the Solana-based startup Eclipse in 2022. The startup garnered support from Solana co-founder Anatoly Yakovenko and institutions/individuals like Polygon (building Rollup blockchains compatible with both Polygon and Solana). According to a CoinDesk report dated September 28, 2022, Eclipse successfully completed a $6 million Pre-Seed funding round led by Polychain and a $9 million Seed funding round co-led by Tribe Capital and Tabiya, totaling $15 million in funding. Additionally, Eclipse received a development grant from the Solana Foundation to support the Solana Virtual Machine-driven Rollup.

Leveraging his network and the geographical advantage of being close to the Solana headquarters in Chicago, founder Somani successfully utilized Solana’s virtual machine to create a unique blockchain. His vision is to enable developers to deploy Rollups powered by the Solana Virtual Machine and plans to launch a public testnet in the Cosmos ecosystem in early 2023, with intentions to support Aptos’s Move language in the future.

Solana co-founder and Eclipse angel investor Anatoly Yakovenko commented, “Eclipse paves the way for Solana to communicate with Cosmos through Inter-Blockchain Communication (IBC).”

Niraj Pant, a partner at Polychain Capital, stated, “As large corporations and governments begin to enter the blockchain space, Eclipse serves as crucial infrastructure facilitating their use cases, such as consumer and financial applications on a Web2 scale.”

Eclipse Architecture

The following is based on the official explanation: Eclipse Mainnet is Ethereum’s first general-purpose L2 centered around the SVM, combining the essence of a modular stack with the goal of becoming the fastest and most universal Layer2 powered by SVM. The project’s architecture involves using Ethereum as the settlement layer with an official embedded verification bridge; Celestia as the data availability layer; RISC Zero for generating zero-knowledge fraud proofs; and ultimately, Solana’s SVM as the execution environment for this modular Layer2 project. The details are explained below based on the official description.

Settlement Layer — Ethereum: Eclipse will settle on Ethereum (i.e., using an embedded verification bridge on Ethereum), use ETH for gas consumption, and submit fraud proofs on Ethereum;

Execution Layer — Solana Virtual Machine (SVM): Eclipse will run a high-performance SVM as its execution environment, specifically a fork of the Solana Labs client (v1.17);

Data Availability Layer — Celestia: Eclipse will publish data to Celestia to achieve scalable data availability (DA);

Proof Mechanism — RISC Zero: Eclipse will use RISC Zero for ZK fraud proofs (without the need for intermediate state serialization);

Communication Protocol — IBC: Eclipse will complete bridging with non-Eclipse chains through Cosmos’s Inter-Blockchain Communication standard IBC;

Cross-Chain Protocol — Hyperlane: Eclipse collaborates with Hyperlane to introduce Hyperlane’s permissionless interoperability solution into blockchains based on the Solana Virtual Machine (SVM).

Settlement Layer: Gaining Ethereum’s Security and Liquidity

Like other Ethereum Rollups, Eclipse uses Ethereum as its settlement layer. This process involves integrating Eclipse’s verification bridge directly into Eclipse, where its nodes must check the correctness of the verification bridge and the correct transaction ordering, thereby providing users with Ethereum-level security.

L2BEAT defines Layer2 as “chains that derive their security fully or partially from Ethereum’s first layer, so that users do not have to rely on the honesty of Layer2 validators to ensure the safety of their funds.” The Eclipse verification bridge can perform final validity and censorship resistance in certain failure scenarios. Even if the sequencer goes down or begins censoring on L2, users can still force through their transactions via the bridge and burn Ethereum as transaction gas.

Execution Layer: Achieving Solana’s Transaction Speed and Scale

To enhance efficiency, the Eclipse Mainnet adopts Solana’s execution environment, utilizing SVM and Sealevel (Solana’s technology solution for building horizontal scalability, a super-parallel transaction processing engine for horizontal scaling across GPUs and SSDs). Compared to the EVM’s single-threaded operation, its advantage is that it can execute transactions without designing overlapping state transactions, rather than executing them sequentially.

Regarding EVM compatibility, the Eclipse Mainnet collaborates with Neon EVM to allow developers to use Ethereum tools and build Web3 applications on Solana. According to official data, its throughput is significantly higher than that of a single-threaded EVM, reaching up to 140 TPS. EVM users can natively interact with applications on the Eclipse Mainnet through the “Snaps” plugin of the MetaMask wallet.

Data Availability: Utilizing Celestia’s Bandwidth and Verifiability

Eclipse Mainnet will utilize Celestia for data availability and establish a long-term collaboration, as Ethereum currently cannot support Eclipse’s target throughput and cost, even after the EIP-4844 upgrade, which provides an average of about 0.375 MB of Blobs space per block (with a per block limit of about 0.75 MB).

According to official data, for ERC-20 transactions based on Rollup scaling, calculated at 154 bytes per transaction, this equates to a total of approximately 213 TPS for all Rollups, while for Compression Swaps calculated at about 400 bytes per transaction, the total TPS for all Rollups is about 82 TPS. In contrast, Celestia’s 2MB blocks, with the network proof stable and more DAS (Data Availability Sampling) light nodes coming online, Blobstream is expected to increase to 8MB.

Eclipse believes that, with the support of Celestia’s DAS light nodes, considering the trade-off between cryptographic economic security and highly scalable DA throughput, Celestia becomes the prime choice for Eclipse Mainnet currently. Even though there exists a viewpoint that using Ethereum’s DA is the orthodox way for Layer2, the project will continue to monitor the progress in DA expansion after EIP-4844. If Ethereum can provide larger scale and higher throughput DA for Eclipse, the possibility of migrating to Ethereum’s DA will be reassessed.

Proof Mechanism: RISC Zero Fraud Proofs (Without Intermediate State Serialization)

Eclipse’s proof method is similar to Anatoly’s SVM fraud proof SIMD (see extended GitHub link 2), aligning with John Adler’s insight of avoiding the high costs of state serialization. To prevent reintroducing a Merkle tree (hash tree) into the SVM, early attempts were made to insert a Sparse Merkle Tree into the SVM, but updating the Merkle tree with each transaction greatly impacted performance. Without using a Merkle tree for proofs, existing general Rollup frameworks (such as the OP stack) cannot serve as the foundation for an SVM Rollup, necessitating a more creative fault proof architecture.

Fault proof requirements: the transaction’s input commitment, the transaction itself, and the proof that re-executing the transaction would result in an output different from what is specified on the chain.

Input commitments are typically achieved by providing a Merkle root of the Rollup state tree. Eclipse’s executor will publish a list of inputs and outputs for each transaction (including account hashes and related global states), the transaction index that generated each input, and publish transactions to Celestia, allowing any full node to follow up, extract input accounts from their own state, compute output accounts, and confirm the commitments on Ethereum are correct.

Two major types of errors can occur:

Incorrect Output: Validators provide a ZK proof of the correct output on the chain. Eclipse uses RISC Zero to create ZK proofs of SVM execution, continuing the project’s previous work on proving BPF bytecode execution (see extended GitHub link 3). This allows our settlement contract to ensure correctness without needing to run the transaction on-chain.

Incorrect Input: Validators publish historical data on-chain, indicating that the input state does not match what was claimed. The Quantum Gravity Bridge of Celestia is then used to allow Eclipse’s settlement contract to verify the existence of fraudulent historical data.

Eclipse’s Connection with ETH and Celestia

Data Availability (DA) is one of the main components of Rollup cost expenditure. Currently, Ethereum L2’s data availability mainly relies on two methods: Calldata and DAC (Data Availability Committees).

· Calldata: For instance, Layer2 solutions like Arbitrum or Optimism publish transaction data as calldata directly onto Ethereum’s highly censorship-resistant blocks. Ethereum prices call data along with computation and storage under one unit: Gas, which is one of the main costs Rollups incur to Ethereum. To enhance efficiency, the EIP-4844 upgrade introduced Blobspace to replace calldata, providing a target of 375 KB per block for all Rollups;

· DAC: Compared to directly publishing calldata on-chain, DAC offers much higher throughput, but users need to trust a small committee or group of validators to avoid malicious data withholding. DACs, including restaking-based solutions, introduce significant trust assumptions for L2s, thereby forcing DACs to rely on reputation, governance mechanisms, or token voting to suppress or penalize the behavior of concealing data. Thus, using external DA to some extent necessitates the use of DAC.

It should be noted that Eclipse utilizes Celestia’s Blobstream, a proof-of-stake consensus network, to allow Layer2 access to Celestia’s Blobspace. This achieves up to 8 MB of blobspace according to the compression scheme, which is roughly equivalent to 9,000 to 30,000 ERC-20 transfers per second. However, Layer2s using Blobstream will depend on proofs from Celestia validators. If light nodes detect malicious data withholding by 2/3 of Celestia validators, they can penalize them. Objectively speaking, the trustworthiness of DAC compared to native chain DA still has its shortcomings, but from the perspective of innovation and market narrative, such deficiencies are unavoidable.

As explained in the official documentation and illustrated above, Eclipse demonstrates the data proven to Ethereum through Celestia’s Blobstream (as introduced above, an Ethereum modular DA solution based on DAS expansion). This allows the bridger to verify the data safety provided for fraud proofs based on Celestia’s signed data root. Users deposit funds into Eclipse through the native Ethereum bridge, with the process outlined as follows:

1. Users call the Eclipse deposit bridge contract on Ethereum (contract address in extended link 1);

2. Eclipse’s SVM executor (computing SVM results and outputting to the new Eclipse state node) and the relayer (ETH to Eclipse channel) complete the cross-chain data interaction between the sender and receiver addresses;

3. The relayer calls the SVM bridging program, responsible for sending user deposits to the target address;

4. The relayer verifies the deposit transaction through a zk-light client (to be implemented);

5. Finally, the transaction block containing subsequent deposits is completed and published through the Solana Geyser plugin.

In this process, each Eclipse slot is published to the message queue through Geyser by the SVM executor. These slots are then published to Celestia as data blocks, and Celestia validators commit to these submitted data blocks to prove that transactions are included in the Eclipse chain and correspond to the data root. Finally, each Celestia data block is relayed to the Eclipse bridger contract on Ethereum through Blobstream.

Similar to other Ethereum Layer2 solutions that use fraud proofs, withdrawing funds from Eclipse to Ethereum also requires a challenge period, allowing validators to submit fraud proofs in case of invalid state transitions.

· The SVM executor periodically commits to an epoch of Eclipse slots on Ethereum (the process follows a pre-determined number of batches) and publishes collateral;

· Eclipse’s bridge contract performs basic checks to ensure the integrity of the published data format (see the fraud proof design section in reference article [2]);

· If the submitted batch passes the basic checks, a predefined window is generated. If within this window, the batch commitment indicates an invalid state transition, validators can publish fraud proofs;

· If validators successfully publish a fraud proof, they win the executor’s collateral, the submitted batch is rejected, and the canonical state of Eclipse L2 is rolled back to the last valid batch commitment. At this point, Eclipse’s administrators have the right to select a new executor;

· However, if the challenge period passes without any successful fraud proofs, the executor will reclaim their collateral and rewards;

· Finally, Eclipse’s bridge contract completes all withdrawal transactions contained in the finally confirmed batch.

Summary

Eclipse is currently in the early stages of development and testing, marking the first SVM Layer2 on Ethereum. Its testnet is already live, with the mainnet launch planned for Q1 2024. Ethereum still considers Rollups as a core part of its development roadmap. Setting aside the debate over orthodoxy, this somewhat means that Ethereum has left the broad definition of Layer2 to the market, hence, openly empowering while also subtly introducing various forms of competition. Eclipse leverages this by combining the security of Ethereum, the high performance of Solana, and Celestia’s DA narratives through modular development for a strong market narrative.

Looking back at Ethereum’s development, an interesting aspect was the last market cycle, which under the hype of DeFi Summer, saw a surge in “DeFi nesting” and “DeFi Legos” innovations and intensifications, leading to an explosive development in the ecosystem. This round, with the combination of LSD and Re-staking, saw a surge in “staking nesting” and “staking Legos” combinations, with EigenLayer, Blast, and the BTC ecosystem’s Merlin rapidly increasing TVL in a short period. If nesting and Legos are considered the main theme of market sentiment, then modularity can also play its unique nesting and Legos melody in the future.

The charm of modularity lies in the decoupling benefits of components, thereby achieving innovation in every layer of the stack, allowing the optimization of each module to amplify the optimization of other modules. Perhaps in the future, the modular development process may offer developers and users a plethora of competitive options.

About YBB

YBB is a web3 fund dedicating itself to identify Web3-defining projects with a vision to create a better online habitat for all internet residents. Founded by a group of blockchain believers who have been actively participated in this industry since 2013, YBB is always willing to help early-stage projects to evolve from 0 to 1.We value innovation, self-driven passion, and user-oriented products while recognizing the potential of cryptos and blockchain applications.

Website | Twi: @YBBCapital

References
[1] https://blog.celestia.org/introducing-blobstream/ — Introducing Blobstream: Bringing Modular DA to Ethereum

[2] https://mirror.xyz/eclipsemainnet.eth/0Q9NufkOPaRfCwi0yFj-_D4eONgscqpr00HGgYCwkHA?ref=twitter — Exploring Eclipse’s Canonical Ethereum Bridging and Verification System

Extended Links
(1)https://sepolia.etherscan.io/address/0x7C9e161ebe55000a3220F972058Fb83273653a6e — Eclipse Deposit Contract Bridge Address

(2) https://github.com/solana-foundation/solana-improvement-documents/pull/65 — SIMD: SVM Fraud Proofs

(3) https://github.com/Eclipse-Laboratories-Inc/zk-bpf — Proving BPF Bytecode Execution