# Modular Components of Eclipse {% @mermaid/diagram content="graph TD A\[Ethereum Settlement Layer] B\[GSVM Execution Layer] C\[Celestia Data Availability Layer] D\[RISC Zero Fraud Proofs] E\[Eclipse] ``` A --> E B --> E C --> E D --> E ``` " %} ## Settlement: Ethereum Ethereum serves as the trust anchor for Eclipse. All finalized state transitions on Eclipse are rooted to Ethereum, ensuring: * Economic finality based on Ethereum's validator set. * Robust fraud proofs and escape hatches to protect users. * Censorship resistance independent of Eclipse validators. By outsourcing security to Ethereum, Eclipse validators can focus entirely on maximizing throughput, latency, and computational efficiency. ## Execution: GSVM: Eclipse's Next Generation SVM Client Eclipse extends the Solana Virtual Machine (SVM) with GSVM, a high-performance, hardware-aware implementation. GSVM leverages SmartNICs and FPGAs to offload cryptographic verification, transaction filtering, and pre-processing. Combined with NVMe-backed, state-optimized storage formats, this minimizes latency and maximizes compute efficiency. The compute pipeline is optimized for multi-core CPUs and GPU-accelerated tasks, integrating tightly with a storage engine that aligns with modern I/O patterns. Execution, storage, and networking operate in a tightly optimized loop. Sequencers can hint storage to prefetch state before execution, reducing I/O stalls and increasing pipeline utilization. GSVM introduces the concept of **Hotspot Islands,** isolated execution zones for high-traffic workloads like AMMs or games. Each island has local fee markets and dedicated compute threads, ensuring that congestion is contained and global throughput isn't compromised. {% @mermaid/diagram content="graph TD A\[GSVM Execution Environment] B\[Hotspot Island - AMM Workload] C\[Hotspot Island - Gaming Application] D\[General State Space] ``` A --> B A --> C A --> D B -->|Isolated Cores| B C -->|Isolated Cores| C ``` " %} > The diagram above illustrates how the GSVM client isolates applications into dedicated execution zones, minimizing interference and maximizing throughput. Concurrency control is hybrid: optimistic paths reduce unnecessary serialization, while pessimistic fallback ensures correctness for contentious interactions. Over time, GSVM becomes smarter, profile-guided and reinforcement-learned optimizations adapt to application behavior, improving resource scheduling and hotspot management. {% @mermaid/diagram content="graph TD A\[GSVM Validator Client] B\[SmartNICs and FPGAs] C\[NVMe-Aligned Database] D\[Hotspot Islands] E\[Self-Improving Runtime] F\[Cross-Layer Optimizations] ``` A --> B A --> C A --> D A --> E A --> F" %} ``` ## Data Availability: Celestia Eclipse uses Celestia as its modular DA layer. The **Eclipse Celestia Publisher** system ensures scalable, fault-tolerant publishing of transaction data through three coordinated stages. The publisher retrieves finalized Eclipse blocks, batches and compresses them, and submits them to Celestia as data blobs. These blobs are then erasure-coded and included in a Merkle root by Celestia validators. A separate gateway module aggregates published batches, computes their commitment root, and anchors that root to Ethereum for verifiability. {% @mermaid/diagram content="graph TD A\[Eclipse Blocks] B\[Batching and Compression] C\[Celestia DA Layer] D\[Merkle Aggregation] E\[Ethereum Anchoring] ``` A --> B --> C --> D --> E" %} ``` > The diagram above gives a high-level view of how data flows through the publishing pipeline, from Eclipse block production to Ethereum anchoring. {% @mermaid/diagram content="graph TD A\[Eclipse Node - Solana-okay necompatible blocks] B\[Solana Retriever] C\[Celestia Publisher] D\[Celestia Network] E\[Gateway Publisher] F\[Ethereum - Gateway Contract] ``` A --> B B --> C C --> D C --> E E --> F" %} ``` > Above is a more detailed view of the interactions between system components and actors involved in this process: #### **How Celestia Data Availability Works** When Eclipse blocks are submitted to Celestia, the Celestia DA layer erasure-codes the data and embeds it into namespaced Merkle trees. Light clients perform data availability sampling by randomly selecting shares of each blob to verify availability. If enough of these shares are present, clients can probabilistically assume that the entire dataset is retrievable. This provides scalable assurance without requiring full node replication. #### **Data Flow of the Publisher** The publishing process is split across three stages: 1. **Block Indexing**: Eclipse blocks are continuously fetched and indexed with metadata. 2. **Publishing to Celestia:** Indexed blocks are batched and compressed into Celestia blobs. Commitments and block heights are stored. 3. **Ethereum Anchoring:** The Gateway aggregates commitments, computes a Merkle root, and submits it to an Ethereum smart contract. {% @mermaid/diagram content="sequenceDiagram participant EclipseNode as Eclipse Node participant Retriever as Solana Retriever participant Publisher as Celestia Publisher participant Celestia as Celestia Network participant Gateway as Gateway Publisher participant Ethereum as Ethereum ``` EclipseNode->>Retriever: Fetch Blocks Retriever->>Publisher: Index Blocks Publisher->>Celestia: Submit Compressed Batches Celestia-->>Publisher: Commitments and Heights Publisher->>Gateway: Aggregate Batches and Build Merkle Root Gateway->>Ethereum: Submit Batch Header" fullWidth="false" %} ``` This system allows Eclipse to offload massive data throughput while maintaining verifiability and settlement integrity. ## Proving: RISC Zero Eclipse employs RISC Zero for fraud proof generation, providing: * Succinct, verifiable fraud proofs using zero-knowledge techniques. * Protection against invalid state transitions. * Minimal performance overhead during normal operation. As an optimistic rollup, Eclipse assumes honest execution but enforces verifiability and accountability through RISC Zero's zkVM. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.eclipse.xyz/architecture/eclipse-architecture/modular-components-of-eclipse.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.