Exploring Eclipse’s Canonical Ethereum Bridge and Its Advanced Proving System

*Forward the Original Title：Exploring Eclipse’s Canonical Ethereum Bridge and Proving System

An Overview of Our Canonical Bridge

Eclipse’s architecture is built upon three fundamental layers that work in harmony to create a robust blockchain ecosystem. At the execution layer, we’ve implemented a modified version of the Solana Labs client (v1.17) to handle SVM transaction processing. The settlement layer operates through our canonical bridge on Ethereum, which not only determines Eclipse’s fork-choice rule but also serves as the submission point for fraud proofs. Completing this triad is the data availability layer, where Eclipse publishes essential verification data as blobs on Celestia’s decentralized network.

The diagram below illustrates how these modules interact:

This article will focus primarily on Eclipse’s Ethereum bridge component. Through Blobstream, Celestia’s validator set relays signed attestations to Ethereum, verifying the proper publication of Eclipse’s slot data batches. This mechanism enables Eclipse’s bridge to cross-check fraud proof data against Celestia’s signed data roots. We’ll explore the complete workflow covering fund deposits through our bridge, the posting of Eclipse block batches as data blobs on Celestia, withdrawal processing, and fraud proof generation in exceptional circumstances.

Depositing via Eclipse’s Native Ethereum Bridge

When users initiate deposits through Eclipse’s native Ethereum bridge, the process unfolds through several coordinated steps. The journey begins when a user interacts with Eclipse’s Deposit Bridge contract on the Ethereum network. Eclipse’s SVM executor then detects this deposit through its relayer system, which monitors both the deposited amount and destination address. The relayer subsequently engages with the SVM bridge program to facilitate the transfer of funds to the intended recipient address.

As an additional security measure, the relayer verifies the deposit transaction using a zk-light client (currently in development). The final step involves the block containing the post-deposit transfer transaction being finalized and published through Solana’s Geyser Plugin mechanism.

The diagram below shows the interactions between Ethereum, Celestia, and the SVM Executor during the deposit flow described above:

Publishing Eclipse’s Slots to Celestia as Data Blobs

The process of publishing Eclipse’s slot batches to Celestia begins with the SVM executor transmitting each Eclipse slot to the message queue via the Geyser interface. These slot batches are then formatted and posted to Celestia as data blobs, creating a verifiable record of Eclipse’s blockchain activity. Celestia’s validator set generates cryptographic commitments for these data blobs, enabling transaction inclusion proofs against the published data root. These critical data roots, embedded in every Celestia block header, are then relayed to Eclipse’s bridge contract on Ethereum through Blobstream’s secure channel.

The diagram below from Celestia explains how the commitment of the data within a given Celestia block is stored in the block header:

Withdrawing and Submitting Fraud Proofs to Eclipse’s Ethereum Bridge

Similar to other L2 solutions employing fraud proofs (such as Arbitrum and Fuel), Eclipse implements a challenge period for withdrawals to allow for potential fraud proof submissions. The process begins with the SVM executor regularly posting commitments to Eclipse’s slot epochs (comprising predetermined batch quantities) to Ethereum, accompanied by collateral deposits. Eclipse’s bridge contract performs preliminary validation checks on the submitted batch data structure (detailed in the Fraud Proof Design section).

If the batch passes these initial checks, a predefined challenge window opens during which network verifiers can submit fraud proofs if they detect invalid state transitions. Successful fraud proofs result in the verifier claiming the executor’s collateral, rejection of the disputed batch, and reversion of Eclipse’s canonical state to the last valid batch commitment. In such cases, Eclipse’s governance mechanism would initiate the selection of a new executor.

Conversely, if the challenge period concludes without any successful fraud proofs, the executor reclaims its collateral along with a reward. The Eclipse bridge contract then processes all withdrawal transactions included in the now-finalized batch, completing the withdrawal cycle.

Fraud Proof Design

Our fraud proof system draws inspiration from the work of Anatoly Yakovenko and John Adler. The fraud proof mechanism requires verifiers to identify transactions containing invalid state transitions, provide the relevant transaction inputs, and demonstrate how re-executing the transaction with these inputs produces outputs that diverge from the on-chain commitment.

Eclipse’s approach leverages Celestia’s merklization of block batch blobs for transaction inclusion proofs via Merkle witnesses. Unlike EVM-based L2s that maintain a global state tree, Eclipse prioritizes performance by avoiding transaction-by-transaction state tree updates. For output verification, Eclipse’s system generates zk-proofs rather than employing the interactive verification games common in EVM-based solutions.

All Eclipse transactions follow a consistent pattern of consuming input accounts, executing transactions, and producing output accounts:

Our fraud proof design hinges on the observation that every input account must originate as an output account from a previous transaction. This allows our system to reference prior transactions rather than requiring Merkle witnesses to a global state tree. This innovative approach introduces new fraud accusation types, including invalid previous transaction references or already-spent input accounts.

Transaction Inputs Posted to Celestia

The data posted to Celestia includes both the original transaction data from the sequencer and execution data from the SVM executor. The execution data contains crucial information such as transaction counts, Celestia namespace locations, account hashes with their originating transaction counts, relevant sysvars with their values and originating transactions, and transaction outcomes (successful outputs or failure indicators).

Batch Commitments Posted to The Ethereum Bridge

Alongside the Celestia data, batch commitments are relayed to the Ethereum contract, including namespace locations for transaction and execution data, plus lists of deposits, withdrawals, and overrides with their associated Eclipse transaction counts.

Criteria for an Invalid Batch

Our system identifies several potential batch invalidity scenarios, ranging from malformed namespace locations to missing execution data or incorrect transaction outputs. The verification process may involve submitting Celestia namespace locations, transaction sequences, or zk-proofs of correct execution (potentially generated through RISC Zero’s Bonsai). The bridge contract automatically detects certain invalid conditions, while others require verifier intervention. When invalid batches are identified, the bridge contract rolls back to the last provably correct commitment while preserving all transaction records.

Parting Thoughts

This overview has provided insights into Eclipse’s trust-minimized Ethereum bridge and our innovative fraud proof design. As our modular L2 solution continues to evolve, we’ll be sharing more technical documentation and articles about various aspects of the Eclipse ecosystem in the coming weeks.

For those interested in participating in the Eclipse Testnet, detailed instructions are available here. We welcome questions and feedback through our Twitter or Discord channels.

Footnotes

[1]: The node which computes the results of SVM transactions and applies the eventual output to Eclipse’s new state

[2]: An operator which passes on-chain events between Ethereum and Eclipse

[3]: Note that the executor, not the sequencer, posts this. If it were included in the data posted by the sequencer, it would add the complication that the sequencer could skip over a count, making it impossible for the executor to do their job correctly. This could be compensated for in the fraud proof design, but it would add extra complexity. A second advantage of having only the executor post the count is that it makes it easy to allow transaction overrides to be posted to Celestia, if desired.

[4]: SVM accounts can be represented with a unique hash. The only way this hash is modified is via a transaction.

[5]: To do this without an excessive amount of hashing, we will run a trace on each executed program to see which parts of each used sysvar are actually accessed. This is possible, but will require modifying Solana’s BPF interpreter.

[6]: This includes data for attempted transactions that failed to execute.

Disclaimer：

1. This article is reprinted from [[mirror], All copyrights belong to the original author [Eclipse]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.