Hyperlane and Eclipse Collaborate to Expand Interoperability in the Blockchain Ecosystem

The TLDR:

• Hyperlane is expanding its permissionless interoperability protocol to Solana Virtual Machine (SVM) in collaboration with Eclipse, a customizable rollup provider.
• The integration allows Eclipse to offer users fast-finality interoperability, a mechanism for a token bridge, and the ability to connect with non-IBC-enabled chains.
• Hyperlane's protocol enables permissionless communication between different blockchains through a decentralized infrastructure of validators, relayers, and watchtowers.
• The collaboration is a significant step forward in promoting interoperability, modularity, and customization within the Solana Virtual Machine (SVM) ecosystem.

Introduction

In the blockchain world, the ability for different blockchains to communicate and interact with each other is crucial. It opens up new possibilities and use cases for the entire ecosystem. In this blog post, we will discuss how the Eclipse chain is integrating with the Hyperlane inter-blockchain interoperability protocol and what this means for the blockchain community.

So, how exactly will Eclipse chains interact with other blockchains? Eclipse engineers have been working hard to build support for Hyperlane's interoperability stack on Eclipse and Solana Virtual Machine (SVM) based blockchains over the past few months. This integration brings numerous benefits to Eclipse users, including:

• Empowering Eclipse rollups to connect with other rollups and ecosystems permissionlessly
• Offering a complement to IBC (Inter-Blockchain Communication) protocol by enabling communication with non-IBC-enabled chains
• Providing a fast-finality interoperability protocol for Eclipse rollups
• Establishing a mechanism for a token bridge
• Expanding the potential user base and use cases in the SVM blockchain ecosystem

Hyperlane Overview

Hyperlane is a permissionless interoperability layer that allows anyone to enable communication between chains without the approval of an authority or significant modification to the protocol. This ability is particularly useful for Eclipse's high throughput SVM-based rollups as it allows for an effectively unlimited number of rollup chains to be instantiated. Hyperlane's generic message passing protocol enables features such as asset bridging in addition to raw message passing.

How It Works

The Hyperlane protocol enables communication between different blockchains through a set of decentralized entities:mailbox contracts, validators, relayers, and watchtowers.

1. Mailbox contracts reside on both the origin and destination chains and provide an inbox and an outbox for Hyperlane messages.
2. Validators read messages from the outbox, bundle them into "checkpoints," sign them using cryptographic methods to ensure authenticity and integrity, and then store them in a highly available data store like an AWS S3 bucket.
3. Relayers read the signed checkpoints, identify the transaction's payer on the destination chain, and forward the message to the destination's inbox contract.
4. The inbox contract verifies the message's content through a customizable security policy known as an Interchain Security Module (ISM) and passes it to the recipient smart contract listed in the message.
5. Watchtowers are responsible for identifying malicious or misbehaving validators and making it economically infeasible for them to continue operating by slashing their staked tokens.

Hyperlane's protocol is designed to be inherently permissionless, meaning any chain can participate without approval from a governing authority. Anyone can run one of the Hyperlane agents, such as a validator, relayer, or watchtower. This contrasts with existing bridging solutions like Wormhole, where a central authority composed of "guardian" nodes must approve a chain's use of the bridge, which can be costly and require huge token incentives.

One of Hyperlane’s important features is that its ISMs allow for customizable security models depending on the requirements put forth by the developer and/or transaction. For example, multiple validator signatures may be required to ensure relayed messages are valid via a Multisig ISM. Or, perhaps for a very niche chain, only one validator/relayer will be run so only one known signer is required. One could even implement an ISM that leverages the consensus of Wormhole’s guardians to approve messages.

Hyperlane leverages verifiable fraud proofs, and in the future zero-knowledge (ZK) proofs, to enforce economic incentives for the protocol via watchtower slashing of validator stake. In the Hyperlane protocol, validators stake tokens on the origin chain as collateral for fraudulent or rogue behavior, e.g., modifying a message prior to signing it to insert malicious content. Because a validator’s stake lives on the origin chain, a circular dependency on the Hyperlane protocol is avoided and slashing can be achieved in a trustless manner. At the time of writing, slashing is not yet implemented in the mainline Hyperlane codebase.

Hyperlane vs. IBC

While Hyperlane and IBC both allow for inter-blockchain communication, there are a few key differences to note. In Hyperlane, trust is placed in the customizable ISM contracts that ensure a message is in fact authentic and valid. Economic incentives discourage malicious behavior such as validators and relayers sending invalid messages. Finality may be reached quickly in this case as it depends on the origin and destination chains time to finality and the polling period of the Hyperlane agents.

In IBC, trust is placed in the security models of the origin and destination chains with light clients on each chain relying on the other chain’s consensus. For Eclipse chains, there is a (potentially long) challenge period which needs to pass prior to reaching finality for cross chain messaging.

Eclipse Support in Hyperlane

Prior to Eclipse’s involvement, Hyperlane did not support SVM-based blockchains. Eclipse’s SVM rollups are among the first non-EVM execution layers that Hyperlane supports. Additions and some small refactors to the Hyperlane codebase were necessary to integrate with Eclipse as well as some dependency tweaks to Eclipse’s Solana fork.

Implementation

The additions to Hyperlane required to support Eclipse are namely the SVM Rust implementation of the mailbox, ISM, and interchain gas payment smart contracts; implementation of the interfaces used by the Hyperlane agents – validator, relayer, watchtower – to allow for interaction with Eclipse chains; and the supporting configuration and test infrastructure. The overall operation of the smart contracts and the agents largely remain the same between SVM and EVM implementations, however there are a number of quirks and differences related to the account model, transaction size limit, and other execution layer details that require small workarounds in the codebase as they violate original assumptions in the Hyperlane protocol architecture.

One such difference is the separation of data accounts and program accounts in SVM vs EVM smart contracts. In order to enable greater parallelism and execution throughput, the SVM programming model requires all accounts that a transaction will use to be listed prior to execution. This just means that some extra information is required at the call site when relayers are sending a message to the destination chain - a solvable problem.

Another difference is that Eclipse supports account data change notifications via pub/sub rather than only supporting polling. This may be leveraged in future work to streamline Hyperlane agent interaction with Eclipse chains.

The collaboration between Hyperlane and Eclipse is a significant step forward in promoting interoperability, modularity, and customization across the industry, especially within the SVM ecosystem.

About Eclipse:

Eclipse is a customizable rollup provider designed for developers building some of blockchain's most unique use cases. Eclipse features a novel architecture that allows for decentralized applications to act as their own sovereign chain. This enables developers to deploy customizable chains without the hassle of managing infrastructure and security.

Join our community: https://linktr.ee/eclipsefnd

‍