Hyperlane — A Deep Dive
Everything you need to know about the Interchain Highway
Introduction
We recently published a 10,000-word document comparing seven of the most well-known arbitrary messaging bridges (AMBs).
To make the doc a bit more digestible, we are breaking it up into a series of “Deep Dives” on Substack every Friday, which will also include a link to a Twitter Spaces with the AMB being covered.
First up is Hyperlane! You can find the deep dive below and our Twitter Spaces here.
Overview
Hyperlane, previously known as Abacus, is a generalized interchain messaging protocol offering an on-chain API that sends and receives messages across chains. It is primarily a tool built to empower developers to send data between chains and create natively cross-chain applications. Its key differentiators are Hyperlane’s explicit focus on data passing via APIs and the flexibility it offers to dApps to set up application-specific validators.
Some of Hyperlane’s best features include:
Easy to integrate API — Hyperlane offers an on-chain API that can be integrated into dApps to send and receive interchain messages. According to Hyperlane, developers can send a simple interchain message to a predeployed smart contract in less than five minutes.
Local security provided by application-specific validators — Applications can add their own validator sets for security purposes (in addition to Hyperlane’s proof of stake protocol).
Message observability — Applications can track interchain messages and perform an action when the message is processed on the destination chain. The team plans to add an interchain message explorer to enable complete message observability in the near future.
Network Connectivity — As of September 2022, Hyperlane supports arbitrary message passing and cross-chain contract calls across seven chains: Arbitrum, Avalanche, BNB Chain, Celo, Ethereum, Optimism, and Polygon.
Natively interchain DAO governance — Hyperlane is governed by a DAO, and ABC token holders have the power to propose and implement changes to the Hyperlane protocol by voting from any Hyperlane-supported chain.
How It Works — Transaction Lifecycle
Hyperlane uses “Inbox” and “Outbox” smart contracts to send and receive interchain messages. Every chain Hyperlane supports has one Outbox and n-1 Inboxes (one for every other chain). Sending and receiving messages with Hyperlane is a three-step process:
Step 1 — An application calls Outbox.dispatch() on the source chain. Each message gets inserted as a leaf into an incremental Merkle tree (for gas efficiency) of the Outbox.
Note: The Outbox.dispatch() function consists of all information related to the transaction (such as message content, destination chain ID, and recipient address).
Step 2 — The latest Outbox Merkle root is signed by the validator set of the source chain. This Merkle root is also signed by application-specific validators (local security) if they exist.
Step 3 — A Relayer delivers the message to recipients by calling InboxValidatorManager.process(). Doing so provides the message’s Merkle proof, the message, and the signed root mentioned in step 2. The InboxValidatorManager verifies that the root was signed by validators and then calls Inbox.process to verify the Merkle proof. After verification, the Inbox contract calls the recipient.handle() function, and the messages are delivered to the application.
Security
Hyperlane offers the following security features:
Economic security by the PoS Validator set — Hyperlane security relies on a delegated proof-of-stake protocol. Each Hyperlane-supported chain has its own validator set, and the PoS protocol ensures that there is an economic cost for malicious actions.
Users select validators — Users can stake ABC tokens and delegate them to Hyperlane validators. The validators with the most tokens delegated to them are chosen to be part of the validator set. There is also a transition window where users can propose to change members of the validator set.
Application-specific security through sovereign consensus — Hyperlane introduces a new flavor to the world of AMBs. It takes a page out of Cosmos’ application-specific development concept and offers developers the flexibility to enhance the security of their dApp. On top of securing the API with a delegated proof-of-stake protocol that validates messages for all the dApps building on Hyperlane, applications are allowed to specify their own validator set. This gives developers the ability to design their own validator set with application-specific security guarantees.
Censorship resistance — Unlike most AMBs, Hyperlane validators don’t sign individual messages. Instead, they sign the Merkle root of the Outbox with all the messages bundled together, thereby improving Hyperlane’s censorship resistance, as validators cannot censor specific messages.
Watchtowers for supervision — Hyperlane’s design consists “watchtowers” that observe an Outbox and the related Inboxes to detect malicious validator activity such as censorship or fraudulent messages. If a watchtower detects malicious activity, it can submit the evidence to the source chain and earn a reward. In such cases, validators are penalized with their stake getting slashed.
Trust Assumptions
Hyperlane makes the following trust assumptions:
External verification by a validator set — Hyperlane uses a chain-specific validator set to sign messages going from one chain to another. As a result, there’s an inherent trust in the design as users trust that validators verify transactions honestly and do not collude to steal the funds.
Note: Specific details about Hyperlane’s validator set, such as the number of validators, staked capital, etc., are not publicly available.
Each chain’s security is not the same — Each Hyperlane-supported chain has its own validator set. This means Hyperlane does not require validators to be present on all supported chains. As a result, some chains may be less secure than others if there’s low economic security due to fewer validators. However, Hyperlane offers applications the flexibility to choose the chains they want to send/receive messages across. As a result, if a dApp concludes that a specific chain’s security is insufficient, it can choose not to integrate that chain.
Slashed stake penalty will always de-incentivize validators from colluding — The stake of Hyperlane validators are bonded, i.e., their stake will be slashed if they act maliciously (collude or censor messages). While users are protected by a slashing mechanism, there is an assumption that it provides economic security in all scenarios. However, in cases where the cost of attack (slashing penalty and reputation) is lower than the amount of capital that can be stolen by colluding, there is more incentive for validators to collude and steal funds rather than acting honestly.
Community & Resources
You can learn more about Hyperlane and stay updated about its community through the following:
Conclusion
Arbitrary messaging bridges are critical pieces of web3 infrastructure. It is absolutely paramount that users and developers can securely (and easily) engage with data across chains — else, the dream of buzzwords like interoperability, modularity, or composability is dead. In its current state, the AMB space is still in a “nascent” phase, with lots of different design choices being tested in live action (and, hence, lot’s of hacks).
We are super excited by what Hyperlane is building and can’t wait to see what the AMB structure unlocks for the crypto space.
And, of course, LI.FI is thankful for all the feedback and cooperation from the Hyperlane team for the doc/Twitter spaces.
Get Started with LI.FI Today
Enjoyed reading our research? Please subscribe and show us your support!
To learn more about us:
Head to our link portal at links.li.fi
Read our SDK ‘quick start’ at docs.li.fi
Join the official Discord server
Subscribe to our newsletter on Substack
Follow our Telegram Newsletter
or try our any-2-any swaps NOW at transferto.xyz