Cross-chain Trilemma and Modular Solutions

Author: Arjun Bhuptani, ConnextNetwork

Compiled by: The Way of the Metaverse

In this article, Arjun Bhuptani summarizes the current issues with the Connext cross-chain protocol (such as high fees, slow speeds, etc.), and he explains how Connext addresses these challenges through an upgrade called Amarok, which combines the cross-chain mechanisms of Connext and Nomad.

In the author's view, similar to the blockchain itself, there is no single architecture that can provide all the ideal properties needed for cross-chain functionality, but we can approach the optimal cross-chain solution through a modular protocol stack.

Motivation for the Upgrade

The motivation for this upgrade is to address key issues faced by different types of participants in the network.

Problems Faced by End Users

1. Gas Costs: The current cross-chain process relies on a two-stage preparation/fulfillment process to complete cross-chain interactions, which is not easy to batch process.
2. Signature Claims: Completing transactions requires users to sign messages to claim funds. This allows Connext to achieve trust minimization, but the process is painful as it requires users to remain online to sign.
3. Risk of Fund Lockup: The relationship between user transactions and routers is 1:1. If a router goes offline or loses connection to the chain midway through the process, the user's funds may be stuck for up to 72 hours.
4. Speed: Because users must bind their transactions to a given router, any delays experienced by that specific router are passed on to the users.
5. Liquidity Fragmentation: The liquidity provided by routers depends on paths, meaning it is only available between a given pair of chains. As the number of cross-chain transactions increases, it becomes more difficult for users to make large trades.

Problems Faced by Developers

1. Off-chain Dependencies: Most integrations in this field are only for contracts, but Connext currently requires running a client SDK to find routers for a given transaction.
2. Signature Claims: The need for claims requires developers to track ongoing transactions and prompt users to sign at the right time. This adds a lot of overhead and complexity compared to simple on-chain transactions.
3. No Universal Messaging: Connext currently supports cross-chain contract calls, but this can only be done safely in certain situations. It is a significant barrier to require developers to know when this functionality can and cannot be used.

Problems Faced by Routers

1. Rebalancing: Routers send funds on the target chain and receive funds on the source chain. This means their liquidity moves between chains or rollup layer networks and may get stuck, reducing capital efficiency.
2. Unclear ROI: It is well-known that tracking the return on investment for routers is difficult because the two-stage process means that the data needed to track returns is scattered across various chains.
3. Liveness Issues: As mentioned above, if a router is unavailable during a transaction, user funds can be locked for up to 72 hours. This liveness issue increases the difficulty for routers.
4. Gas Malicious Attacks: Users or routers can collude to cancel transactions. However, when this happens, there is no clear mechanism to compensate for the pre-paid gas costs.

What Was the Initial Solution?

Connext initially planned to address these issues through the following combinations:

1. Incentives—For example, using vAMM pricing to incentivize rebalancing and using a penalty mechanism to enhance system liveness.
2. Wallet Integration—By porting the Connext SDK code into wallets, the "signature claim" process can be abstracted away from developers and users.

Connext has always focused on ensuring that transactions minimize trust as much as possible, and the aforementioned obstacles are trade-offs made to achieve this security.

In the past few months, Connext has developed a better architecture that can avoid the above issues without introducing trust.

Modular Cross-Chain Solution

This breakthrough in thinking comes from the close collaboration between Connext and Nomad. Nomad is an optimistic cross-chain bridge protocol that provides fully expressive and trust-minimized communication on any chain, but the trade-off is a 30-minute delay.

Similar to the blockchain itself, there is no single architecture that can provide all the ideal properties needed for cross-chain functionality, but we can approach the optimal cross-chain solution through a modular protocol stack.

Modular Cross-Chain Stack

New Process

The new design process heavily utilizes the Nomad protocol, which does not require signatures but simply allows any router to provide funds for user transactions and execute calls, claiming funds through Nomad.

Since routers are not pre-specified, there is a risk that routers can compete with each other in the mempool to complete a given transaction. This is a suboptimal outcome because losing this race still incurs gas costs for the routers. To address this issue, the developers introduced a sequencer (conceptually similar to a rollup sequencer) that is responsible for collecting bids (attempted transactions) from routers and batch publishing them to the chain.

Note that the role of the sequencer in Connext does not affect the security of the system's funds in any way. Instead, it is merely a mechanism designed to fairly distribute fee revenue/work among routers. If the data availability of all routers bidding for a given (a) user transaction is available, and a deterministic process for selecting a winner (b) is in place, this can be completed without trust. Connext is currently exploring ways to solve this issue, including allowing the sequencer to publish data to its own rollup or achieving Tendermint consensus between routers and the sequencer.

Related Changes

The Amarok upgrade will implement a better cross-chain process and feature set that can address some of the issues mentioned earlier:

1. Simplified Process: No longer a two-stage process with signatures; all transactions now occur in a single transaction on the sending chain, simplifying the user and developer experience. Connext also no longer requires cancellations, eliminating the gas malicious attack costs for routers.
2. 1-of-N Routing: Any router can complete a user's transaction, eliminating the possibility of user funds being locked and significantly reducing the liveness requirements for routers. This also completely removes the need for developers to rely on off-chain code.
3. Simpler Liquidity: Routers receive liquidity on the target chain of the transaction, where they provide liquidity. Liquidity is no longer path-dependent, eliminating the rebalancing and fragmentation issues, greatly improving capital efficiency and availability.
4. Cheaper and Faster Transactions: The new process reduces the number of on-chain calls from 4 to 2, making transactions not only cheaper but also faster.
5. Arbitrary Messaging: The most exciting improvement brought by the Amarok upgrade is that developers can now build various cross-chain dapps, unlocking powerful features such as JS-style asynchronous development (including support for Solidity callbacks).

What’s Next?

Connext is currently running a dedicated testnet with the Amarok upgrade, and in the coming weeks, a fully functional public testnet will be available for anyone to use.

In May, Connext plans to complete the upgrade audit and conduct the mainnet upgrade in June.

Once the Amarok upgrade is completed, it will open the door for builders, allowing them to create any type of cross-chain application they can imagine on top of Connext. Here are some early use cases that developers have already discussed:

1. Cross-chain connection of DEX liquidity in a single transaction;
2. Cross-chain treasury strategy management;
3. Key protocol operations, such as cross-chain replication/synchronization of global constants (like PCV);
4. Introducing UniV3 TWAP to each chain without introducing oracles;
5. Chain-agnostic veToken governance;
6. Cross-chain interoperability between metaverses.