Original author: YBB Capital Researcher Ac-Core
Eclipse background
Source: Eclipse official website
Eclipse founder Neel Somani once worked as a software engineer at Airbnb and a quantitative researcher at Citadel. He founded Eclipse, a startup based on Solana, in 2022, and received support from Solana co-founder Anatoly Yakovenko and Polygon (for Solana and Polygon). Build a compatible Rollup blockchain). According to CoinDesks report on September 28, 2022, Eclipse successfully completed a US$6 million Pre-Seed round of financing led by Polychain and a US$9 million seed round of financing co-led by Tribe Capital and Tabiya, with a total financing amount of 1,500 Ten thousand U.S. dollars. In addition, Eclipse also received a development grant from the Solana Foundation to support Solana Virtual Machine-driven Rollup.
Somani, the founder of Eclipse, used his connections and geographical advantage close to Solanas Chicago headquarters to successfully create a unique chain using Solanas virtual machines. The vision is to enable developers to deploy Rollup powered by the Solana virtual machine, with plans to launch a public test network on the Cosmos ecosystem in early 2023, and plans to support Aptos 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 via Inter-Blockchain Communication (IBC)."
Niraj Pant, Partner at Polychain Capital, commented:"As large enterprises and governments begin to enter the blockchain space, Eclipse is an important infrastructure to facilitate their use cases, such as Web2-scale consumer and financial applications.
Eclipse architecture
According to the official explanation below, Eclipse Mainnet is Ethereum’s first general-purpose L2 built around SVM. It combines the best parts of the modular stack and aims to become the fastest and most versatile Layer 2 of Ethereum driven by SVM. The project architecture uses Ethereum as the settlement layer and is used for the official embedded verification bridge; Celestia is used as the data availability layer; RISC Zero is used to generate zero-knowledge fraud proofs; and finally Solanas SVM is implemented as a modular Layer 2 project as a whole . The following will be explained in detail based on official explanations.
Settlement Layer—Ethereum: Eclipse will settle to Ethereum (i.e. the embedded verification bridge on Ethereum) and use ETH as its gas consumption, and the fraud proof will also be submitted on Ethereum;
Execution layer—Solana Virtual Machine (SVM): Eclipse will run a high-performance SVM as its execution environment, 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 proof (no intermediate state serialization required);
Communication Protocol—IBC: Complete bridging with non-Eclipse chains through Cosmos’ inter-chain communication standard IBC;
Cross-chain protocol—Hyperlane:Eclipse and Hyperlane have partnered to bring Hyperlane’s permissionless interoperability solution to Solana Virtual Machine (SVM)-based blockchains.
Source: Eclipse official
Settlement Layer: Access Ethereum’s Security and Liquidity
Eclipse uses Ethereum as the settlement layer like other Ethereum Rollups. This process requires Eclipses verification bridge on Ethereum to be directly incorporated into Eclipse. Its nodes need to detect the correctness of the verification bridge and correct transaction ordering, so as to allow users to Get Ethereum-level security.
L2 BEAT defines Layer 2 as “a chain that derives its security, fully or partially, from the first layer of Ethereum so that users do not have to rely on the integrity of Layer 2 validators to ensure the security of funds.” The Eclipse Validation Bridge enforces ultimate validity and censorship resistance under certain failure conditions, allowing users to force completion of their transactions through the bridge and use Ethereum as transaction gas even if the sequencer goes down or censorship begins in L2 Carry out burning.
Execution Layer: Capturing Solana’s Transaction Speed and Scale
In order to improve efficiency, Eclipse Mainnet adopts Solanas execution environment, using SVM and Sealevel (Solana is used to build horizontal expansion technical solutions, and the hyper-parallel transaction processing engine is used to horizontally expand across GPUs and SSDs), which is different from the EVM single-thread Compared with running, its advantage is that it can be executed without designing overlapping state transactions, rather than executing them sequentially.
Regarding EVM compatibility issues, Eclipse Mainnet has cooperated with Neon EVM to allow developers to leverage Ethereum tools and build Web3 applications on Solana. According to official data, its throughput is greater than single-threaded EVM and can reach 140 TPS levels. EVM users use the MetaMask wallet"Snaps "Plug-ins interact with applications natively in Eclipse Mainnet.
Data Availability: Leveraging Celestia’s Bandwidth and Verifiable Nature
The Ecilpse Mainnet will leverage Celestia for data availability and long-term relationships. The reason for this is that Ethereum is currently unable to meet Ecilpses target throughput and fees, which even after the EIP-4844 upgrade can provide an average of approximately 0.375 MB per block. Blobs space (limited to approximately 0.75 MB per block).
According to official data, the ERC-20 transaction based on Rollup expansion is calculated as 154 bytes per transaction, which is equivalent to the total of all Rollups as approximately 213 TPS. For Compression Swap, calculated as approximately 400 bytes per transaction, all Rollups TPS is approximately 82 TPS. Compared to the 2 MB blocks launched by Celestia, Blobstream is expected to increase to 8 MB after the network proves stable and more DAS (relevant scaling explained below) light nodes come on and off.
Ecilpse believes that with the support of Celestias DAS light node, Celestia has become the best choice for the current Eclipse Mainnet due to the trade-off between the security of the encryption economy and highly scalable DA throughput. Even though there is currently a view that using Ethereum DA is the orthodox Layer 2, the project team will continue to pay attention to the progress of DA expansion after EIP-4844. If Ethereum can provide Eclipse with a larger-scale and high-throughput DA, The possibility of migrating to Ethereum DA will be re-evaluated.
Proof mechanism: RISC Zero fraud proof (no intermediate state serialization)
Eclipses proof method is similar to Anatolys SVM fraud proof SIMD (see GitHub extension link 2 for details), which is consistent with John Adlers insight to avoid the high cost of state serialization. Therefore, in order to avoid reintroducing the Merkle tree (hash tree) into the SVM, early project parties tried to insert the Sparse Merkle Tree into the SVM, but updating the Merkle tree every time a transaction would have a huge impact on performance. Without the use of Merkle trees for proof, existing general-purpose Rollup frameworks (such as OP stack) cannot serve as the basis for SVM Rollup, which requires a more creative failure proof architecture.
Failure proof requirements: the transactions input commitments, the transaction itself, and proof that re-executing the transaction results in a different output than specified on the chain.
Input commitments are usually implemented by providing the Merkle root of the Rollup state tree. Eclipsses executor will publish a list of inputs and outputs (including account hash values and related global state) for each transaction, as well as the transaction index that generated each input, and Publish the transaction to Celestia so that any full node can follow it, pull the input account from its own state, calculate the output account, and confirm that the commitment on Ethereum is correct.
There are also two possible critical error types here:
Incorrect output: The validator provides ZK proof on the correct output chain. Eclipse uses RISC Zero to create ZK proofs of SVM execution, continuing the projects previous work proving BPF bytecode execution (see GitHub extension link 3 for details). This allows our settlement contract to ensure correctness without having to run transactions on-chain.
Incorrect input: The validator publishes historical data on the chain indicating that the input state does not match what is claimed. Celestias Quantum Gravity Bridge is used to allow the Eclipse settlement contract to verify that there is fraud in historical data.
Eclipse connections to ETH and Celestia
Image source:@jon_charb
DA is one of the main parts of Rollup cost expenditure. Currently, there are two main methods of data availability in Ethereum L2, Calldata and DAC (Data Availability Committees).
Calldata: Layer 2 solutions such as Arbitrum or Optimism publish transaction data directly on the chain as calldata into Ethereums highly censorship-resistant blocks. Ethereum unifies the pricing of call data, calculation and storage under one unit: Gas, which is also one of the main costs of Rollups expenditure on Ethereum. To improve efficiency, the EIP-4844 upgrade introduces Blobspace to replace calldata, thereby providing a target value of 375 KB per block for all Rollups;
DAC: DAC has much higher throughput than issuing calldata directly on-chain, but users need to trust a small committee or group of validators to avoid malicious withholding of data. DACs, which also include restaking-based solutions, introduce significant trust assumptions on L2s, forcing DACs to rely on reputation, governance mechanisms, or token voting to inhibit or punish the behavior of withholding data, so to a certain extent When using an external DA, a DAC is required.
It should be added that Celestia uses the Blobstream proof-of-stake consensus network in Eclipse to allow Layer 2 to access Celestias blobspace, reaching 8 MB blobspace according to the compression scheme. This is roughly equivalent to 9,000 to 30,000 ERC-per-second. 20 Transmission. However, the use of Blobstreams Layer 2 in the process will rely on Celestia verifier certification. If the light node of the security assurance process detects the malicious behavior of 2/3 of Celestia verifiers by retaining data, they can be punished. Objectively speaking, DAC is different from the native chain. There are still deficiencies in the trust level of DA, but this deficiency is unavoidable when thinking from the perspective of innovation and market narrative.
Image source: Eclipse official - Eclipse modular interaction logic
According to the official documentation, as shown in the figure above, Eclipse passes Celestias Blobstream (as the Ethereum modular DA solution based on DAS extension is introduced above), and the Eclipse data proved to Ethereum has been tested and run, allowing the bridge to be based on Celestias Signed data root to verify data security provided for fraud proof. Its users deposit funds into Eclipse via the native Ethereum bridge, with the process outlined below:
1. The user calls the Eclipse deposit bridge contract on Ethereum (see extended link 1 for the contract address);
2. In Eclipses SVM executor (calculates SVM results and outputs them to the Ecilpse new state node), the relay (ETH and Eclipse channels) completes the cross-chain data interaction between the users sending address and receiving address;
3. The relay calls the SVM bridge program and is responsible for sending user deposits to the target address;
4. The relay verifies the deposit transaction through the zk-light client (to be implemented);
5. The final transfer transaction block containing subsequent deposits is completed and published through the Solana Geyser plug-in.
In this process, the SVM executor will publish each Eclipse slot to the message queue through Geyser, and its slot will be published to Celestia as a data block, and Celestias verifier will accept the submitted data block. Proof transactions are included in the Eclipse chain and correspond to the data root, and finally each Celestia data block is relayed via Blobstream to the Eclipse bridge contract on Ethereum.
Picture source: Eclipse official: Celestia and SVM executor interaction
At the same time, similar to other Layer 2s in Ethereum that use fraud proofs, withdrawing funds between Eclipse and Ethereum also requires a query window period so that verifiers can submit fraud proofs when the state transition is invalid.
The SVM executor will periodically release an epoch (process according to a predetermined batch number) commitment of the Eclipse slot to Ethereum and release the mortgage;
Eclipses bridge contract performs basic checks to ensure that the published data format is intact (see reference article [2] Fraud Proof Design chapter for details);
If the submitted batch passes the basic check, a predefined window will be generated. Within this window, if the batch is committed, it means that the state transition is invalid, and the verifier can issue a fraud certificate;
If a validator successfully publishes a fraud proof, they win the executors guarantee, the published batch is rejected, and Eclipse L2s specification state rolls back to the last valid batch commitment. Here Eclipse managers will have the power to elect new executors;
However, if the challenge period is passed without proof of fraud, the executor will recover its collateral and rewards;
Finally the Eclipse bridge contract completes all withdrawal transactions included in the finalized batch.
summary
Eclipse is still in the early development testnet stage and is the first SVM Layer 2 on Ethereum. The testnet is currently online and the mainnet is planned to be released in Q1 2024. Ethereum still regards Rollup as its core development route. Putting aside the topic of orthodoxy, this means to a certain extent that Ethereum has left the broad definition of Layer 2 to the market, so the overt empowerment is also hidden. with various forms of competition. Eclipse takes advantage of this and uses modular development to combine the security of Ethereum, the high performance of Solana and Celestia DA to create a strong market narrative.
Looking back at the development process of Ethereum, a very interesting point is that the last round of market conditions was driven by the hype of DeFi Summer, with a large number of innovations and additions in “DeFi Matryoshka” and “DeFi Lego”, which caused a blowout development in the entire ecosystem. In this round, a large number of staking matryoshka and staking Lego combinations have appeared under the combination of LSD and re-staking, allowing EigenLayer, Blast and Merlin of the BTC ecosystem to reach new highs in TVL in the short term. If we regard matryoshka dolls and Lego as the main theme of market sentiment, then modularity can also play its own matryoshka doll and Lego melody in the future.
The charm of modularity lies in the decoupling benefits of components, thereby realizing innovation at each layer in the stack, so that the optimization of each module can amplify the optimization of other modules. Perhaps in the future, for developers and users, modularization The development process may generate a large number of competing options.
Reference article
【 1 】https://blog.celestia.org/introducing-blobstream/Introducing Blobstream: Delivering Modular DA to Ethereum
【 2 】https://mirror.xyz/eclipsemainnet.eth/0Q9NufkOPaRfCwi0yFj-_D 4 eONgscqpr 00 HGgYCwkHA ?ref=twitterExplore Eclipse’s Canonical Ethereum bridging and verification system
Extension link
（1）https://sepolia.etherscan.io/address/0x7C9e161ebe55000a3220F972058Fb83273653a6eEcilpse deposit contract bridge address
（2）https://github.com/solana-foundation/solana-improvement-documents/pull/65SIMD: Fraud Proof of SVM
（3）https://github.com/Eclipse-Laboratories-Inc/zk-bpfDemonstrating BPF bytecode execution
