Amarok Hardfork: Overview

[ArjunBhuptani]

🐺 Amarok

Amarok is the first network upgrade/hardfork for Connext. It involves extensive changes to the core protocol flow for nxtp, and will massively improve both developer experience as well as the process of running a router.

This discussion will describe our motivation for these proposed changes, walk through the new flow of a transaction or crosschain message, and then explain how the network upgrade will affect the different stakeholders in our network.

Why Amarok? We've chosen to name hardforks alphabetically after mythical creatures. Amarok is a giant wolf in inuit mythology. 😃

Motivation

The impetus for this upgrade is to solve the following key problems that currently exist for the different types of stakeholders in the network.

Problems for End Users

1. Gas Costs: The current construction of nxtp utilizes a two-phase prepare/fulfill pattern to execute crosschain transactions. This means that a total of 4 onchain transactions must occur (two on the origin and two on the destination) for each given user tx, where only 1 of these 4 onchain transactions can be reasonably batched. In comparison, the majority of other approaches require only two onchain transactions (one from the user on origin and one from the network on destination), where in some cases the second transaction can be batched.
2. Liveness & Signature Dependency: The current construction requires users to sign to unlock funds on the receiving chain after validating that their transactions have been prepared correctly by a router. This means that users must remain online to manually "claim" a transaction if they want the flow to be noncustodial. This also means that contract-initiated transfers of funds (e.g. from a Gnosis Safe or DAO) are not able to be easily supported.
3. Fund Lockup Risk: Users and routers have a 1:1 relationship onchain after a user gets a route through the auction process. In the event that a router goes offline or fails after winning a user's auction, the user's funds are locked onchain for up to the transaction expiry window (72 hours). We initially thought that having a bonding/slashing mechanism to discourage this would be enough to stop this from occurring, but even a 0.00001% failure rate results in several user transactions being locked up each with which is terrible UX.

Problems for Developers

1. Offchain Auction Dependency: Prior to initiating a transfer, users need to get a route through an offchain auction process. This adds an additional dependency for application developers who are accustomed to a largely contract-only development process. The problem is greatly magnified in cases where the application is running natively and cannot use our typescript SDK.
2. Two Phase Flow (Signature Dependency): Because users must sign to claim funds, developers are forced to build code to monitor the status of in-flight transactions after dispatching them to Connext. This increases the lift for integration.
3. Lack of Support for Expressive Crosschain Communication: Connext currently supports calling contracts across chains, but can only do so in the cases where the receiving chain call is not permissioned (the call can be made by any EOA on behalf of the transaction initiator). This excludes usecases such as token migrations, NFT mint operations, crosschain DAO interactions, and other more expressive communication where there is no logical "owner" that can sign to complete a transaction.

Problems for Routers

1. Rebalancing Liquidity: When executing a transfer, a router receives liquidity on an origin chain in return for sending liquidity on a destination chain. This means that a router's capital will move around between chains and require manual rebalancing to become available again, resulting in added cost, complexity, and lower capital efficiency. We previously planned to fix this via vAMMs (offchain AMM-style pricing on liquidity to incentivize external actors to rebalance the network). However, because AMM pricing would be specific to each router's (fragmented) capital rather than the network liquidity as a whole, we observed through extensive modeling that this resulted in higher user slippage + centralizing effects around large/institutional routers.
2. Unclear ROI: Due to the intrinsic asynchrony of trying to get data across chains and the current two-phase transaction process, router ROI is notoriously difficult to track accurately.
3. Strict Liveness: Routers currently have strict liveness once they participate in auctions. This means that if routers run out of gas or crash unexpectedly, users experience lockups.
4. Large Transactions: Router returns are currently skewed in favor of larger routers because of the lack of optionality around larger transactions (where only 1-2 routers may have enough liquidity to complete them at any given time).
5. Gas Griefing: In the current model, transactions may be cancelled either by the router or by a user after transaction expiry. Unfortunately, there is no clear way for routers to be reimbursed for their costs when transaction cancelling occurs. This opens up a gas griefing vector where users can spam routers with transactions on a cheaper chain to get them to spend lots of gas on a more expensive chain, where their cost to attack is only a 72 hour lockup of funds.

Out of Scope

The following problems are explicitly out of scope for this upgrade:

1. Fully Passive LPing: Allowing users to provide 100% of router liquidity passively is not within the scope of this upgrade. Passive LPing of this style introduces trust assumptions for LPs - it is possible that this risk is acceptable for some investors, and one can imagine building a Lido-style passive LP derivative system to enable it, but we have chosen to externalize this to other teams building on Connext rather than make it a part of the core nxtp protocol.
2. Custody and Key Management: Routers currently must maintain a "hot wallet" which is their signer key utilized to make transactions in the network using their own capital in the TransactionManager.sol contract. This is a core part of the locally verified security mechanism, and so will not be able to be changed.

Proposed Solution

Modular Interoperability

We want Connext to become the interchain communication network that developers use to build fully expressive crosschain applications. Our thesis on how to do this is to move towards modularizing the specific functionalities that make up crosschain communication such that there is now a protocol stack rather than a monolithic system.

We believe this stack will something like the following:

Layer	Protocol/Stakeholders
Application Layer	Crosschain Applications (Xapps)
Liquidity Layer	Nxtp
Gateway/Routing Layer	Interchain Gateway Protocol (routes to the correct messaging protocol!)
Messaging Layer	Nomad, IBC, XCMP, Rollup AMBs
Transport Layer	Connext Routers

Note that we are explicitly splitting out the existing functionality of Nxtp as the liquidity layer and routers who will continue to provide liquidity but eventually will also be responsible for transporting data correctly between chains.

Nomad: Generalized Crosschain Messaging

While we fully expect that Connext will plug into other trustless messaging systems within a given sovereign zone (e.g. IBC), we are tightly focusing on Nomad as the messaging back bone of the network.

Nomad is a crosschain communication protocol that uses ORU-style fraud proofs for security. Nomad is easy to deploy to new chains, cheap to use, and expressive. However, because of the fraud proof model, it introduces higher latency (30-60 minutes) for message passing. After extensive research, we believe Nomad offers the best possible set of tradeoffs for the lower level communication layer, particularly as Nxtp (liquidity layer) can still be used in many cases to execute crosschain transfers instantly. We'll explain the mechanism for this below.

To learn more about Nomad, check out their docs!

Removing Signatures

Locally verified systems require the use of some "proof" to unlock an LP's inbound funds after they have successfully fronted capital to a user. The current model uses a signature from the user to verify that a transaction was completed correctly, and the route for a given transaction (which router is used) is determined upfront and recorded onchain such that the router can claim their funds on the origin chain with the user's signature.

If there is an existing trust-minimized generalized messaging layer, like Nomad, then an external proof mechanism is no longer needed. Instead, a router can simply front capital on the destination chain, and then wait for data from the origin chain to be ported over the messaging layer to destination, where both the user and router transactions can be compared for validity (and the router can replenish their capital). This was a model explored initially in the constructions of projects like Nova and Hop.

Importantly, in this case there is no more need for a user to specify upfront which router they would be working with at all. Instead, only 1 of N routers must be willing/able to provide capital for the transaction to be completed quickly.

Consenus Routing

If no router is explicitly specified, it stands to reason that routers would race each other in the mempool to complete any given transaction. This is a suboptimal outcome for everyone as all but one router transaction would be reverted onchain and cost gas.

To fix this, routers can achieve offchain consensus on the best router to complete a given tx. It is important to note that this does not affect the security model in any way. The security of consensus affects only the fee revenue and fairness of work given to routers, not the custody of funds or safety of the system.

Our current expectation here is to use tendermint consensus for this, given the maturity of the Cosmos SDK and experience of existing routers with validating tendermint chains. We can require onchain that router operators bond value to participate in the network, and have tendermint validators slash routers that try to circumvent consensus.

In the short term, we will ship a centralized auctioneer service (similar to a rollup sequencer) to get the network live faster + maintain a whitelist of routers.

Core Flow

Now we get into the meat of the new system.

A transaction flowing through Connext will now have the following lifecycle: note: interfaces still in flux here!

1. User will initiate the transaction by calling a xcall function on our contracts, passing in funds, gas details, arbitrary data, and a target address object (includes chain info). Note that xcall is meant to mimic solidity's lower level call as best as possible.
2. Our contracts will:
   • If needed, swap the passed in token to the Nomad version of the same asset.
   • Call the Nomad contracts with a hash of the tx details to initiate the 30-60m message across chains.
   • Emit an event with the tx details.
3. Routers observing the origin chain with funds on the destination chain will:
   • Simulate the transaction (if this fails, the assumption is that this is a more "expressive" crosschain message that requires permissioning and so must go through the slow Nomad process only).
   • Prepare a signed transaction object using funds on the receiving chain.
   • Post this object (a "bid") to the auctioneer.
   • Note: if the router does not have enough funds for the transfer, they may also provide only part of the transfer's value.
4. The auctioneer will be observing all of the underlying chains. Every X blocks, the auctioneer will collect bids for transactions. The auctioneer will be responsible for selecting the correct router (or routers!) for a given tx (can be random). The auctioneer will post batches of these bids to a relayer network to submit them to chain.
5. When a given bid is submitted to chain, the contracts will do the following:
   • Check that there are enough funds available for the transaction.
   • Swap the router's Nomad-flavored funds for the canonical asset of the chain if needed.
   • Send the swapped funds to the correct target (if it is a contract, this will also execute calldata against the target).
   • Hash the router's params and store a mapping of this hash to the router's address in the contract.
     --> At this point, the user's tx has already been completed!
6. Later, when the Nomad message arrives, a heavily batched tx can be submitted to take all pending hashes received over Nomad and look up whether they have corresponding router addresses in the hash -> router address mapping. If they do, then Nomad assets are minted and given to the router.
   • Note: if the router gives the incorrect amount of funds to a user or if they execute the wrong calldata, then the router's param hash will not match the hash coming over Nomad and the router will not get reimbursed. This is the core security mechanism that ensures that routers behave correctly.
   • Note 2: Routers will take a 30-60 minute lockup on their funds when relaying transactions. While this theoretically reduces capital efficiency compared to the existing system, in practice the lack of need to rebalance will mean that routers have more capital available more often regardless.

Stakeholder Changes

Users

1. Transactions are now "fire and forget". User no longer sign anything. DAOs, contract wallets, or and other contracts are treated the same as EOAs.
2. There is now zero risk of lockup. Even in the case where there are no funds available at all in the network (highly unlikely), the transaction will take a max time of 30-60 mins (nomad latency).
3. Transactions should generally be much cheaper. While there are additional txs introduced by Nomad, these can be heavily batched. The core nxtp flow itself will only require two transactions.
4. In general, getting liquidity for a transaction will be much simpler and easier. Liquidity is currently path-dependent, meaning that a user cannot make a transaction from A->C if there is no liquidity for it, even if there is liquidity from A->B and B->C.

Developers

1. No more offchain auction or signature dependency. All development is now contract-only.
2. Fully expressive crosschain communication is now possible (though in some cases will require some added latency). Developers do not need to explicitly consider whether they are using Connext, Nomad, or any other protocol in the stack. There is a single simple interface for all of it.
3. The above unlocks much more expressive and interesting contract development patterns. For example, JS-style async callbacks -> origin chain contract calls foo() on destination chain contract, which then calls the callback bar() on origin with returned data. 👀

Routers

1. No more rebalancing needed from routers. Liquidity is no longer path-dependent in general. Now there is only entry liquidity for a given chain. For example, you can now provide only liquidity on Arbitrum - in this case you may get routed over for any txs going to Arbitrum, and you will receive capital from the user on Arbitrum.
2. No more cancellations/gas griefing.
3. A single transaction may now be completed by many routers. This means larger transactions can be split up and executed by several routers in parallel in the same tx.
4. Easy metrics - now that all liquidity is only on the chain that you want to support, fees are also calculated and collected there. This means it's much more simple to track ROI metrics using a simple subgraph.
5. Passive liveness. Routers participating as auctioneers (block producers) in Tendermint consensus on routes must be live. However, it will now be entirely possible to run "light" routers that only participate in auctions if/when they are available. In combination with (3) above, this means users will be able to do things like running a router on a cellphone. 🙀

Some trade-offs/considerations:
6. The scope of the router increases somewhat - in addition to providing liquidity for fund transfers, routers will also need to execute transactions that may have little to no value included as part of them. Our long term vision is that routers become the base crosschain transport layer described in Modular Interoperability above.
7. To mitigate liquidity fragmentation and simplify router operations, routers must hold their liquidity in Nomad-minted assets. This can and will be largely abstracted from the router experience, however.
8. Routers may need to have RPC connections to a larger number of chains - we need to think through this a little more.

Other Considerations

1. To swap from canonical assets to Nomad-flavored assets and back, we will need to have stableswap AMMs on each chain baked into the contracts. This will require an additional step to bootstrap liquidity. As this is fully passive capital, we are not too concerned about this.
2. Having all of the liquidity only on a single chain with no rebalancing requirements means that we can utilize existing liquidity systems to improve pricing/capital efficiency. E.g. Aave V3 Portals, Goldfinch uncollateralized loans, Tokemak, etc.

Open Questions (WIP)

1. Fees and gas funds. We are still working on the best way to account for fees as part of this flow. In the pessimistic case where a transaction takes 30 minutes, it is impossible to generate an accurate estimate of fees when sending the tx. We are looking into allowing for the explicit specification of gas limit + bumping gas on the origin chain as a solution, though in general handling gas costs in an async environment is going to be quite challenging.

[jakekidd]

Wanted to add some of our discussion points from today as a reminder. MVP may or may not include stuff from these topics, but we may want to circle back soon:

• Native meta txs.
• Reading cross-chain state.
• Update and read back: ping-pong over nomad with a return value to the og caller).
• Watchtower griefing: need to discuss this with nomad, as staking can alleviate the problem / effectively solve it.
• Internal batching operations for claiming all owed funds from the nomad BridgeRouter on a receiving chain. This could save a significant amount of money in gas (as opposed to batching the transactions externally).
• Handling permissioned calldata that is non-signed (so coming from a contract, e.g. for crosschain DAO governance). For this, we'll need to make it clear that developers can whitelist the nomad contract and rely on the nomad network (if an alternative solution isn't available) to do their transactions.

[deuszx]

Do I understand correctly, that (long-term) you're considering having a specialized "app chain" running Cosmos SDK to auction routers' bids?