[Xangle Digest]

※ This article contains content originally published by a third party. Please refer to the bottom of the article for the copyright notice regarding this content. 

Table of Contents

Multichain’s anyCall
Hyperlane
deBridge
Comparative Analysis: Which AMB to Build on?
Closing Thoughts 

 

Multichain's anyCall

Overview

anyCall is a generic cross-chain messaging protocol built by Multichain leveraging its Secure Multi-Party Computation (SMPC) network to sign transactions to send messages and contract calls from one chain to another. The team believes that anyCall will be the backbone of the next phase in the evolution of dApp design.

In January 2022, two critical vulnerabilities with the Multichain liquidity pool contract and router contract were exploited, resulting in the loss of $3M in users’ funds. The team worked closely with whitehat hackers and recovered nearly 50% of the total stolen funds.

anyCall expands the brand name and experience of the Multichain team into cross-chain messaging. Some of anyCall’s best features include:

• Ease of deployment — Integrating anyCall is consistent and hassle-free for developers. The quick and easy integration enables developers to add the business logic of cross-chain transfers to their dApps without spending many resources.
• Ability to transfer arbitrary data across chains — anyCall enables the transfer of arbitrary data like smart contracts, messages, tokens, NFTs, and data from one blockchain to another in just one transaction.
• Improved UX — anyCall allows multiple functions (like bridging and swapping) to be performed with a single contract call. As a result, users have to go through fewer steps, improving a dApp’s UX significantly.
• Cross-chain contract calls — This feature enables calling a contract on the destination chain directly from the source chain. anyCall can be used for any type of cross-chain communication, such as sharing information like state, data, and messages across chains.

Additionally, anyCall enjoys the following network effects:

• Connectivity with the Multichain ecosystem — Multichain is one of the most widely used bridging solutions. It has tremendous connectivity and enables users to bridge over 1600+ tokens across 60+ blockchains, including EVM and non-EVM chains.
• Mutlichain’s bridged volume and TVL — Multichain has over $86B in total bridged volume to date and boasted a TVL of over $10B at peak. It constantly does over $50M in daily bridged volume from 3,000+ daily active users.
• Network connectivity — As of September 2022, anyCall supports arbitrary message passing and cross-chain contract calls across 11 chains: BNB Chain, Polygon, Ethereum, Optimism, Gnosis Chain, Fantom, Moonriver, IoTeX, Arbitrum, Avalanche, Harmony.
• Protocol level integrations — anyCall has been integrated by dApps like Curve to support multi-chain gauges, Hundred Finance to offer uniform reward distribution, Fiver for gas to acquire gas tokens by paying in stables, and Fantom Animals to offer omni-chain NFTs.
• MULTI token holders — MULTI is a top 300 token with a market capitalization of roughly $100 million.

How It Works — Transaction Lifecycle

anyCall’s architecture can be divided into two layers — the lower layer and the upper layer. The lower layer consists of an off-chain trust mechanism, whereas the upper layer consists of an on-chain call/trigger API.

The off-chain trust mechanism is responsible for validating messages from the source chain. It triggers the required operations after performing destination chain addressing as per the logic specified by dApps. The upper layer consists of a trigger API on the source chain and a call API on the destination chain. When the API on the source chain is triggered, the off-chain trust mechanism initiates the validation for consensus, and afterward, the call API on the destination chain completes the contract call as specified by the dApp.

anyCall relays messages across chains through the following contracts and functions:

• Step 1, anyCall Function — This function is present on the source chain and plays a key role in storing data to be transferred to the destination chain. The anyCall contract validates and relays messages to the destination chain.
• Step 2, Multichain’s MPC network — The MPC network consists of 24 nodes and is responsible for performing validity checks on messages sent to the anyCall contract by the anyCall Function. The anyCall contract is present in a common MPC address across all supported blockchains. When a message is sent by the anyCall function, MPC nodes ensure the security of the messages before sending them to the destination chain.
• Step 3, anyExec Function — The anyExec Function receives messages from the anyCall contract and executes the request on the destination chain. 

 

Security

anyCall offers the following security features –

• Multichain’s MPC network — anyCall depends on Multichain’s Multi-Party Computation nodes to verify the information across chains. The MPC network adopts a method where a single private key is subdivided and encrypted among several nodes to ensure the security of the system. It is a distributed mechanism that consists of nodes executing a predetermined amount of signatures per transaction to approve cross-chain movements of assets.
• Audits from external security companies — Multichain conducts detailed security audits from security companies. For anyCall, the team has conducted 2 audits, both by BlockSec — one for the older version and one for the new version of anyCall (both versions are currently live).
• Open bug bounties — Multichain has one of the biggest bug bounties running on Immunefi, with rewards up to $2M for finding vulnerabilities in the system. Moreover, Multichain is also active on other bug bounty platforms to attract whitehat hackers to find potential vulnerabilities.
• Transaction limits — To ensure the security of funds, Multichain has adopted the rule of delayed withdrawals, the length of which is proportional to the amount of the transaction. This ensures that Multichain gets adequate time to validate that transactions are genuine and safe.
• Total volume limits on new chains — For new chains with relatively lower security, Multichain limits the total volume that can be bridged to/from that chain within a certain period. This strategy helps avoid bad asset spillovers to other chains when a particular chain is hacked (ex: Harmony’s $100M hack).
• Security fund — Multichain has an insurance fund where 10% of all transaction fees are stored. These funds can be used to compensate users if any assets are lost under special conditions.

Trust Assumptions

anyCall makes the following trust assumptions:

• Externally verified by the MPC network — anyCall transfers are verified by the MPC network, a group of 24 validator nodes. Thus, users need to trust the nodes to act honestly and also validate correct messages/transfers. ½ or 13 nodes can collude to steal user funds.
• Nodes care about reputation — anyCall’s security relies on the reputational security of the nodes in the MPC network. It assumes that the potential benefits of acting maliciously and colluding to steal user funds are lesser than the reputational costs for the nodes.
• Censorship risk — If 12 MPC nodes collude, they can censor a message through anyCall.

Community & Resources

You can learn more about Multichain’s anyCall and stay updated about its community through the following:

• Official Website
• Docs
• Whitepaper
• Github
• Analytics Dashboard
• Medium
• Twitter
• Telegram

 

 

 

Hyperlane

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:

• Official Website
• Docs
• Github
• Twitter
• Discord

 

 

 

deBridge

Overview

deBridge is a generic cross-chain messaging and interoperability protocol. It aims to expand the concept of traditional bridges by allowing users and developers to transfer both simple messages and complex data (such as arbitrary messages or call data) from one chain to another.

deBridge’s main selling point is the wide range of developer-friendly tooling it offers, which opens up opportunities for composability and enables developers to build complex cross-chain applications. As an infrastructure platform, deBridge enables developers to leverage its cross-chain messaging functionality by seamlessly integrating any of its tools, such as SDK, API, or widget, depending on their requirements, and build different cross-chain use cases, such as token bridges, NFT bridges, cross-chain staking, lending, payments, credentialing, etc.

Some of deBridge’s best features include:

• Limitless value transfers through deSwap Liquidity Network (DLN) — DLN is a protocol built on top of deBridge introducing a new design that utilizes liquidity across chains on demand instead of locking it in liquidity pools, enabling unlimited asset transfers across chains with 0 TVL.
• Hardhat plugin — deBridge’s hardhat plugin offers a secure environment for dApps building on it to test different features before going live.
• Cross-chain transaction bundling — deBridge lets dApps bundle different transactions into a single transaction, allowing them to offer swaps + interactions in one maneuver (ex: staking).
• Full functionality (even if some blockchains experience downtime) — deBridge’s architecture consists of an off-chain transaction validation mechanism. As a result, if certain blockchains experience downtime, deBridge protocol can continue processing transactions for all other supported chains. Moreover, given the off-chain validation mechanism, deBridge’s validators don’t need to relay any transactions and thus have unlimited throughput. Additionally, since the validators don’t need to communicate with each other, their IP addresses are never exposed, increasing the overall security of the infrastructure.
• Verifiable and open transactions — Details of any cross-chain transfer through deBridge’s infrastructure can be accessed by anyone on deBridge’s Explorer.

Additionally, deBridge enjoys the following network effects:

• deBridge applications — The team behind deBridge has built several deApps that showcase its capabilities. Examples — 1) deSwap: a solution for cross-chain swaps, 2) dePort: a bridge that enables applications to mint synthetic representations of their tokens, 3) deNFT (not launched yet): a solution to build cross-chain native NFTs.
• dApps building on it — deBridge’s infrastructure is being used by several applications. For instance, Thunder Lands recently integrated dePort to scale the Thunder token (TNDR) across chains. Since dePort is built on deBridge protocol, it can be said that Thunder Lands is built on deBridge infrastructure. Similarly, deBridge’s applications are being used by Frontier Wallet, Wirex Wallet, Plato, and Minimax, among others.

 

 

• Winner of Chainlink Global Hackathon — deBridge began as a hackathon project in April 2021 at the Chainlink Global Hackathon where it was awarded the Grand Prize.
• Funding — deBridge raised $5.5M in a funding round led by ParaFi. The round also saw participation from Huobi Ventures, Crypto.Com Capital, and Animoca Brands, among others.
• Network connectivity — As of November 2022, deBridge supports 7 blockchains: Ethereum, BNB Chain, Polygon, Arbitrum, Heco, Fantom, and Avalanche. The team plans to add support for non-EVM chains such as Solana (and more) soon.

 

How It Works — Transaction Lifecycle

A transaction through deBridge’s architecture passes through two key layers:

• Protocol Layer (on-chain) — a set of on-chain smart contracts deployed on all deBridge-supported chains. The parameters of the smart contracts, such as fees, chains, and validators, are managed by deBridge governance.
• Infrastructure Layer (off-chain) — nodes run by validators elected via deBridge’s governance. These validators also run full nodes on all the blockchains supported by deBridge.

 

 

Here’s how deBridge works at a high level:

• Step 1: A transaction is assigned a Submission ID (unique hash) when it passes through the smart contract on the source chain (aka deBridgeGate) — this ID is the identifier of each transaction and ensures the uniqueness of the message within the deBridge protocol.
• Step 2: deBridge validators (12) track events emitted by deBridgeGate smart contracts on all supported blockchains. They wait for a specific amount of block confirmations (depending on the chain) until the transaction achieves finality before validating. If the details of the submission are correct, each validator signs the Submission with their own Private Key and publishes it to the deBridge API.
• Step 3: Validator signatures are saved to IPFS (the team plans to add Arweave soon) where they can be retrieved by anyone (user or keeper) to be passed through the deBridgeGate smart contract on the destination chain (aka target chain).
• Step 4: At least ⅔ (8 out of 12) validators must sign a message for it to be confirmed and claimed on the destination chain. If the required number of signatures is met, the transaction is executed by the deBridgeGate smart contract, and the call data is transferred to the target chain.