In the dynamic archipelago of blockchains, each island (or blockchain network) is self-sufficient, boasting its own protocols and tokens. These islands are formidable in isolation, but their true potential is untapped due to a glaring absence: sturdy & safe bridges to connect them.

As many of us know, interoperability is extremely important in the coming multi-chain world. But the current state of security & reliability around bridges presents a multi-faceted problem:

• Security Shortfalls in Existing Bridges: Attempts to construct bridges have been made, but these are often complex and fraught with risk. Like precarious rope bridges swaying over a chasm, they present vulnerabilities that could lead to catastrophic security breaches, leaving users and developers wary of crossing.

• Operational Inefficiencies: The absence of seamless interaction forces users to navigate a labyrinth of convoluted processes. This inefficiency is reminiscent of having to take a roundabout maritime route, cumbersome and time-consuming, just to trade simple goods.

• Trust Issues: In the current bridge landscape, trust is a scarce commodity. Sending valuable assets across these rudimentary bridges carries the risk of loss or tampering, much like sending a treasure without a convoy.

The Solution

In early 2023, a team at Gnosis introduced Hashi. Hashi emerges as a sophisticated and principled approach to bridging. It serves as a protocol that not only connects blockchain networks but also increases the sanctity and security of cross-chain communication through redundancy.

Hashi is akin to an international airport built on blockchain territory. Just as airports enable people from different countries, speaking different languages, to traverse borders safely and efficiently, Hashi facilitates a similar function for blockchain networks. Here are the key solutions Hashi provides:

• Interoperability with Integrity: Hashi creates a framework where messages and transactions are not just passed along but are assured for integrity. This is comparable to having a multi-layered security check at an airport, ensuring every individual crossing borders is authenticated.

• Streamlined Cross-Chain Communication: Hashi offers a streamlined approach to cross-chain transactions, removing the need for complex and often convoluted bridging solutions that were once the norm. It's like replacing connecting flights with a direct route, reducing the time and points of failure in a journey.

• Scalable and Secure Architecture: Hashi's architecture is designed to be both scalable and secure, addressing the needs of growing blockchain ecosystems without compromising on security. This is akin to an airport expanding its capacity while maintaining rigorous safety protocols.

• Enhanced User Experience: For the blockchain-savvy user, Hashi provides a transparent and intuitive experience for cross-chain interactions. It's similar to having a clear and concise airport sign system, guiding passengers through a seamless transit process.

• Trust Ensured by Design: With Hashi, trust is engineered into the protocol. Users and developers can have confidence that the assets and data transmitted across chains are preserved without alteration, akin to a bank's guarantee during a wire transfer.

Hashi stands not as a makeshift bridge but as a comprehensive transport system that brings robustness, efficiency, and confidence to the cross-chain communication space.

The Different Components To The Hashi Protocol

Hashi (橋)

• Custom Oracle Adapters: Users have the flexibility to construct custom oracle adapters. These adapters serve as specialized contracts that connect to external data sources, or oracles, to retrieve verifiable data, such as block hashes, which are crucial for ensuring the integrity and origin of blockchain data.

• Domain-Specific Hash Queries: Hashi allows querying an oracle for the hash of a particular ID within a given domain (e.g., the block hash from a specific chain ID). A block hash is a unique identifier that represents the state of a blockchain at a particular point in time, akin to a fingerprint for a set of transactions.

• Consensus Mechanism: It enables users to seek consensus from a set of oracles for a given ID in a domain. This is similar to getting multiple expert opinions to reach a high-confidence conclusion.

• Unanimous Agreement: Users can also query for a block hash that has been unanimously agreed upon by a set of oracles. This feature strengthens security by ensuring that only when all oracles are in absolute agreement is the hash accepted, reducing the risk of false or tampered data.

ShoyuBashi (所有橋)

• Owner Controls: The owner account has the power to set and modify the instance of Hashi to query, define oracle sets for each domain, and set thresholds for oracle consensus. This is akin to an administrator setting rules for data validation.

• Public Queries: Any user can query for an agreed-upon hash by a threshold of oracles. This threshold mechanism acts as a layer of democratic validation to determine the authenticity of a block hash.

GiriGiriBashi (ギリギリ橋)

• Initial Setup: An owner can initialize oracle sets and thresholds, similar to setting up initial security parameters.

• Adaptation and Security: Owners can replace underperforming or compromised oracles, ensuring the bridge's integrity is maintained.

• Dispute Resolution: Users have the ability to challenge an oracle’s report. Challenges can lead to the oracle being quarantined if found at fault, ensuring only reliable oracles participate.

• Re-establishing Trust: In case of widespread issues, a no-confidence state can be declared, prompting a reset in the domain by the owner, much like a system reboot after a critical error.

Yaho (ヤッホー)

• Message Dispatching: Users can dispatch messages across chains via Hashi. Yaho records these messages and emits their hashes as events, essentially announcing the successful send-off of a message.

• Message Relaying: It also provides functionality to relay stored messages to different message adapters, broadening communication capabilities.

• Combined Operations: For efficiency, Yaho can dispatch messages and relay them in a single transaction, streamlining cross-chain communication.

Yaru (やる)

• Message Execution: Yaru acts on the receiving end of the bridge, executing messages that come from Yaho, similar to a recipient acting on a received letter.

Hashi Zodiac Module

• Control Across Chains: Users can control an avatar (like a multi-signature wallet, or 'Safe') on one chain from an address on another, enabling cross-chain command and control of assets or contracts.

• Message Passing: It defines instances for Yaho to pass messages and specifies chain IDs and foreign controller addresses, creating a comprehensive cross-chain command structure.

By incorporating redundancy and a high threshold for oracle consensus, Hashi prioritizes security, even at the expense of higher gas costs and potentially slower operations. This trade-off is deemed necessary to mitigate the risks that have plagued previous bridge protocols, providing a robust solution in a landscape where security incidents can be incredibly costly.

A quick note before we proceed on about Hashi: Understanding Arbitrary Message Bridges (AMB)

Before we delve into the specifics of how Hashi operates across chains, it's essential to understand the concept of Arbitrary Message Bridges (AMB). An AMB is a protocol that enables the transmission of messages between two distinct blockchain networks. These messages can carry various types of information, such as function calls, transaction requests, or simple data transfers. In essence, an AMB acts like a courier service that connects two separate communities, allowing them to communicate and interact securely and reliably.

AMBs are pivotal in decentralized applications that require cross-chain interactions because they expand the functionality of smart contracts beyond the confines of their native blockchain. For instance, a smart contract on the Ethereum network can trigger an action on the Gnosis Chain, or vice versa, through messages passed by the AMB. It's a bridge that not only links two separate ecosystems but also enables them to work together harmoniously.

How Message Dispatching on Hashi Works ✉️

Message Transmission from Goerli to Gnosis Chain

Using the Hashi protocol to send a message from the Goerli testnet to the Gnosis Chain involves a sequence of carefully orchestrated steps that ensure the message is not only delivered but also verified and executed. Here's how the process unfolds:

1. Initiation by the User:

   • A user starts by interacting with the Yaho contract on the Goerli network. They call the dispatchMessagesToAdapters function on Yaho to initiate the message sending process.

2. Message Processing by Yaho:

   • Yaho takes the user's message and communicates with the AMB Message Relay. The role of the AMB Message Relay is to take the message from Yaho and prepare it for cross-chain delivery.

3. Relaying via AMB Message Relay:

   • The AMB Message Relay, after receiving the message from Yaho, calls its relayMessages function. This function includes an operation to storeHashes, which is executed on an adapter on the Gnosis Chain. This action essentially packages the message for its cross-chain journey.

4. Cross-Chain Handover:

   • The AMB Message Relay on Goerli then interacts with the AMB contract through the requireToPassMessage function. This is where the AMB takes the relayed message and securely sends it to the AMB contract on the Gnosis Chain.

5. Receipt and Verification on Gnosis Chain:

   • Once the message arrives on the Gnosis Chain, the AMB Adapter contract calls its storeHashes function. This crucial step logs the message, ensuring that it's safely received and ready for the next phase. A MessageDispatched event is emitted, providing a messageId that is vital for tracking and executing the message.

6. Execution of the Message:

   • The final step involves the user calling the executeMessages function on the Yaru contract on the Gnosis Chain. The user provides the messageId (obtained from the MessageDispatched event) and the original message as parameters.

   • Yaru then performs the execution of the message, completing its cross-chain journey and allowing the intended actions to be carried out on the Gnosis Chain.

Message Transmission from Gnosis Chain to Goerli

The process of sending a message from the Gnosis Chain to the Goerli network through Hashi involves several components that work together to ensure the message is not only transmitted across chains but also validated and executed securely.

Step-by-Step Process from Gnosis Chain to Goerli

1. User Interaction on Gnosis Chain:

   • It begins with the user calling Yaho.dispatchMessagesToAdapters on the Gnosis Chain. This function is responsible for initiating the message relay process, much like dropping a mail into the postbox.

2. Message Handling by Yaho:

   • Yaho processes the message and forwards it to the AMB Message Relay. Here, relayMessages (which involves storeHashes) is called, packaging the message and its metadata for the journey ahead.

3. Message Relay to AMB:

   • The AMB Message Relay invokes requireToPassMessage on the AMB contract. This step is akin to handing over the message to the courier service, which will carry it across the bridge to the Goerli network. During this process, the UserRequestsForSignature event is emitted.

4. Signature Retrieval by User:

   • On the Gnosis side, the user now interacts with the AMB Helper contract. By calling getSignature and providing the encodedData from step 3, the user receives a signature, a cryptographic proof that the message is valid and ready to be accepted on the Goerli chain.

5. Message Passing to Goerli's AMB:

   • With the signature in hand, the user then calls executeSignature on the AMB contract deployed on the Goerli network. The signature and encodedData are provided as parameters. This step is crucial as it's where the message is verified and accepted by the Goerli network's AMB, which in turn calls storeHashes from the AMB Adapter. The MessageDispatched event is emitted, granting the user the messageId needed for the final step.

6. Execution on Ethereum via Yaru:

   • The last phase of the journey takes place on the Ethereum network. The user calls Yaru.executeMessages with the obtained messageId and the original message as parameters. Yaru then executes the message, thereby completing the cross-chain communication loop.

This process exemplifies the robustness of Hashi in handling cross-chain messages, incorporating cryptographic verification at each step to maintain security and integrity. From the user's perspective on the Gnosis Chain, the journey of the message is transparent and results in a series of actions being triggered on the Goerli network, all orchestrated by the Hashi protocol.

Ok, so what’s next?

To delve deeper into the Hashi protocol and explore its full potential, a comprehensive suite of resources is available. These materials include technical documentation, tutorials, and community discussions, all designed to provide a thorough understanding of the protocol and its applications. Whether you're looking to integrate Hashi into your project or simply curious about the mechanics of cross-chain bridges, these resources serve as a gateway to a wealth of knowledge.

Chainlink’s VRF Service doesn’t exist on Goerli/Chiado. So with Hashi, we’re able to request a random number from Chainlink’s VRF on Goerli and have it listened for on our dapp deployed on Chiado. This is less documentation and more so of a technical implementation.

Hashi Protocol Documentation

Hashi Protocol Github & Contract Deployments here 👉 Deployments

This forum post is a more in depth explanation of Hashi and the problem it solves.