Amarok AMB Update

Earlier this year, we announced the development & testnet of Connext’s Amarok network upgrade. This upgrade aims to fix many of the key issues that exist with Connext today and introduces support for arbitrary message passing, enabling developers to integrate easily into our network to build fully expressive xchain (cross-chain) applications (xapps).

Refresher on the Amarok Upgrade

The Amarok upgrade accomplishes the above by modularizing the bridging stack. Instead of having a single system to power all of the functionalities needed to build xapps, developers instead call into a single function (xcall) that splits actions between a Liquidity Layer (Connext) and a Messaging Layer.

After intensive research into the tradeoffs of bridge security models, the team chose to partner closely with Nomad, the team that invented the Optimistic Bridge model — a messaging system that relays data across chains using fraud proofs similar to optimistic rollups.

Nomad Exploit

As many of you know, Nomad was recently exploited due to an implementation bug (unrelated to their optimistic model).

The Connext team still strongly believes that Nomad is one of the best teams in the bridge space and expects they will emerge even stronger as a result of this event. We also continue to have a high conviction that optimistic bridges will be the dominant style of bridge construction in the future, given the strength of their security model.

Realistically, however, it will take time for Nomad to recover funds and restart its system. The Connext team cannot afford to wait for this to happen as we have ~150 routers, over a dozen dApp teams, and tens of thousands of users waiting for the Amarok upgrade to go live.

A New Messaging System

Fortunately, we were able to come up with an alternative approach that minimizes delays to our original timeline.

Instead of building more of our own infrastructure, the system will use existing AMBs for rollups and sidechains to relay messages and a system of Connectors to plug those into one another. Note that this entire messaging system will exist underneath the existing Amarok liquidity layer that enables sending & receiving tokens across chains.

💡 AMBs, Arbitrary Message Systems, are the canonical bridges used by other chains (L2s and L1s) to connect with a main network, typically Ethereum. Examples are the Arbitrum-Ethereum roll-up bridge or the Polygon-Ethereum PoS bridge

Hub and spoke model: transactions created on any chain will be added to a Merkle root. These roots will periodically be dispatched back to Ethereum L1. Upon reaching L1, a Gelato bot will aggregate the roots (i.e., a new root will be generated by combining each chain-specific root) and propagated (sent over AMBs back to each chain).

In the event of an emergency, a chain can be disconnected by the system on L1 — this will halt all new messages going to/from the chain without affecting the rest of the network.

What does this mean for users?

Our key design goal was to ensure that protocol, user, router, and developer patterns are as unaffected by this change as much as possible. This to reduce both the time needed to implement the system and the impact on our community:

1. No changes to the protocol: The system uses the same interface for dispatching and processing messages as Nomad. This ensures that no additional changes are needed to our existing Amarok infrastructure — this means our on-chain contracts and off-chain agents will work with the new messaging system with 0 changes.
2. No changes for builders: The interfaces and functionality that developers are integrating will remain exactly the same.
3. No changes for liquidity providers: the experience of providing liquidity either as a router (active liquidity) or user (passive LP into AMMs on each chain) will remain exactly the same.

Nonetheless, there are some tradeoffs to the new system against using an optimistic bridge directly:

1. Cost: There will be a small cost increase as state roots now need to be propagated through Ethereum L1. For now, this cost will be subsidized by Connext — we expect this to be ok for the short-medium term as gas costs on Ethereum are quite low.
2. Latency: The time taken for user transactions & xchain contract calls will still be the same — ~2 minutes. However, authenticated “slow path” xchain contract calls (i.e., those that require some permissioned access to a function call) will take longer. Previously, the latency of this was ~30 minutes. Now, we estimate it may be ~2–3 hours.
3. Trust-minimization: The beauty of this system is that it utilizes the existing AMBs of each chain — this minimizes additional trust assumptions as these AMBs are already the source of trust for all assets on a given chain/rollup. However, specifically for the Optimistic Rollups, we will need to significantly reduce the latency of “slow path” exits down from 1 week (similar to how Across works). We expect this to be an acceptable trust tradeoff for now as rollups are still heavily relying on a guarded approach to security + the system will be able to disconnect a rollup if fraud is detected to occur by the rollup’s sequencer.
4. Chain Support: As we’re using the AMBs of existing systems, we will only be able to support a handful of chains as part of the initial rollout. We have some ideas on how to expand to other chains after we go live, but on day 1 the system will support only the following chains: Optimism, Arbitrum, Gnosischain, Polygon, BNB Chain, and Ethereum.

The consequence of the above tradeoffs is that this messaging system is specifically designed to be a temporary solution that can be rolled out quickly and with minimal changes.

💡 As soon as possible, we will look to either upgrade the system to become a full optimistic bridge that we build ourselves OR plug in Nomad’s optimistic bridge messaging layer (if/when they are able to recover) underneath.

Updated Timeline

Because the system utilizes existing, battle-tested infrastructure (AMBs) and there are absolutely 0 changes to the rest of Connext, the changes required will only be:

1. A set of contracts to create and validate Merkle roots/proofs. Robust out-of-the-box versions of this are already available everywhere in the ecosystem.
2. Connectors to each chain.
3. A Gelato bot on each chain to periodically push roots through AMBs. A gelato bot on Ethereum L1 to mix & propagate roots.

We have already deployed on Goerli (Ethereum) and Optimism Goerli (Optimism), and we aim to have a working testnet back up within the next week. We have also completed the development of a connector for Sokol (Gnosischain testnet) with other testnet chains (Polygon, Arbitrum, and BNB chain) coming shortly after.

We are in the process of scheduling two audits for the new system as soon as possible.

At Connext, our philosophy is to partner closely with users to improve our user experience, security, and testing and to overall provide the most value with each release. We encourage any feedback or questions as we continue building together.

About Connext

Connext is a network for fast, trustless communication between chains and rollups. It is the only interoperability system of its type that does this cheaply and quickly without introducing any new trust assumptions. Connext is aimed at developers who are looking to build bridges and other natively cross-chain applications.

Website | Bridge | Build xApps| Twitter | Discord