Lifecycle of an Eclipse Transaction

This section illustrates the full path of a transaction within Eclipse—from user submission to final settlement. The system modularly separates responsibilities across five actors: the user, the Eclipse Node, GSVM for execution, Celestia for data availability, Ethereum for final settlement, and RISC Zero for provable security.

1. User Submission: A transaction is initiated by a user and submitted to an Eclipse Node.

2. Preprocessing: SmartNICs and FPGAs kick in to filter, deduplicate, and locally pre-confirm transactions. Relevant state is prefetched into memory to minimizse latency during execution.

3. Sequencing: Transactions are ordered using a mix of performance-based and application-specific logic. When traffic spikes occur in particular applications, like AMMs or games, Eclipse creates Hotspot Islands to isolate those workloads on dedicated threads.

4. Execution: GSVM executes the transaction using a hybrid concurrency model. It combines optimistic and pessimistic paths to ensure both speed and safety. The runtime also learns and improves over time based on real workloads.

5. DA Publishing: Executed transaction data is batched and published to Celestia through the Celestia Publisher. Celestia handles erasure-coding and inclusion into a Merkle tree, which is later referenced on Ethereum.

6. Settlement: Once data is available, the state commitment is finalized and posted to Ethereum, ensuring long-term finality.

7. Fraud Window: If any fraudulent activity is suspected, RISC Zero can generate a fraud proof. This proof is submitted to Ethereum to challenge and revert invalid state transitions.