The Messaging Bridge Stack

Understanding Connext

In the past couple of years, this space has seen some of its worst hacks due to the failures of bridging protocols. This, coupled with the lack of best practices for bridge architecture and the ever-growing number of externally verified bridge projects, has left most developers asking:

Is secure crosschain development even possible?

Answering this question was our core focus when designing Connext’s Amarok upgrade last year. What we realized was that we needed to rethink bridging from first principles to specifically identify:

• What are the different components of a messaging bridge?
• Which of those components contribute most to trust & security risk?
• In what ways can we offset or offload the risk of those components?

Our goal with this series of posts is to unpack the above and, by doing so, explain how we believe we (and the broader community) can work together to fix bridging.

What is a Bridge?

Let’s start with the basics, what even is a bridge? The term bridge is quite overloaded and has come to mean any of:

1. An application UI that lets you transfer tokens between chains.
2. An underlying protocol for sending tokens between chains.
3. A mechanism for sending (arbitrary) messages one chain to another.

To make matters more confusing, (3) above is also often referred to as a crosschain messaging protocol, generalized message passing system, or interoperability protocol. Some even argue that (3) is explicitly not a bridge or is “beyond bridging”, though this is typically just a semantic effort by projects to disassociate themselves from the term.

For the purposes of this blog post, we will adopt the term messaging bridge as the definition for (3) above (as this is the primitive that underlies any kind of application-specific bridge). We will also qualify application-specific bridges by their usecase — for example: an NFT bridge, or token bridge.

Messaging Bridge Flow

There are a LOT of different messaging bridge constructions out there today. Despite this, all messaging bridges have the same core structure, implementing the following three components (best visualized as layers):

• Transport: Posting message data from one chain to another.
• Verification: Proving correctness of the above data.
• Execution: Doing something with the bridged data.

Let’s dive into how each layer works.

Transport

Transport is how a payload of data gets read from one domain and relayed to another, making no assumptions about the correctness of the data.

Transport is typically done by one or many offchain actors that watch an “outbox” on the origin chain bridge contract, and then post the corresponding data to an “inbox” on the destination chain bridge contract. It’s fairly straightforward to build this using off-the-shelf components for reading from and writing to blockchains.

The risk of hacks or other failures at the transport layer are quite minimal. At worst, they lead to downtime of the bridge as messages are no longer able to be sent across chains. Using more decentralized/fault-tolerant dependencies such as subgraphs and relayer networks (Gelato, Keep3r, etc.) can reduce transport downtime risk.

Verification

Verification is how crosschain communication is secured. After a payload of some data is transported across chains, the verification layer uses some mechanism to ensure that the data posted to the destination chain is the same as the data originally posted on origin.

How do you verify a message that goes across chains? There are a handful of methods, each with their own trust, latency, and complexity tradeoffs.

We cover some of these methods in our Interoperability Trilemma and Optimistic Bridging blog posts. We will also dive deeper into the nuances of bridge message verification in the next blog post in this series.

For the purposes of this post, what’s most important to understand is that message verification is the hard part of building bridges.

Verification layers secure arbitrary and unknowable data coming from an untrusted source on another chain, requiring either complex cryptographic or external dependencies. Even if the implementation of a verification layer is secure, message verification is also at risk of economic attacks if it is not trust-minimized, such as for example a 51% attack of a m-of-n verification layer.

These challenges make verification layers highly challenging to audit.

Every major bridge hack has involved a failure of message verification in some capacity. When verification layers get hacked, attackers get “privileged” access to everything controlled by the messaging bridge such as, for example, any locked tokens that were bridged across chains. For this reason, we (and many others) strongly recommend that application developers do not roll their own message verification. The consequences of making a mistake at this layer can be devastating.

Execution

The execution layer is a set of offchain actors responsible for ensuring that, once some data is transported across chains and verified to be correct, it can then be executed against a target contract, triggering one or many interactions on the destination chain. The bridge execution layer is what developers build against, by paying fees/sending calldata to the messaging bridge interface on origin, in order to call a contract on destination.

In many cases, execution layers will either pack data into merkle roots on the origin (and then unpack that data using merkle proofs on the destination) or relay block headers themselves (and perform storage proofs at the destination). This is because transport and verification are typically quite expensive (particularly trust-minimized methods such as light client header verification), and so per-transaction costs need to be brought down by batching.

Execution layers entirely inherit the risk of message verification, but have a low trust and security risk profile themselves. The execution layer will handle messages as part of batching them and passing them to/from lower layers, but these interactions are typically quite minimal and straightforward to audit. As execution layer contracts are primary responsible for distributing fees and paying liquidity to offchain actors, a hack at this layer typically only involves theft of fee revenue or the loss of funds of the offchain actors actively operating the network — all of which have significantly lower impact than verification layer hacks.

Special Case: Fast Execution

An interesting and under-appreciated aspect of execution is that it is entirely possible to (securely and trustlessly) execute some types of crosschain interactions before the message containing that interaction has been transported and verified.

This concept is perhaps best illustrated by considering how “fast-liquidity” systems on optimistic rollup bridges work. If Alice sends 100 USDC from Optimism to Ethereum, she typically needs to wait a full 7 days to receive her funds. To shorten this wait time, Alice can pay Bob (who already has 100 USDC on Ethereum) a fee to send her the funds immediately instead, and Bob can claim the 100 USDC coming over the Optimism bridge. In this example, Bob has basically “fronted” the funds to Alice, knowing it is safe for him to do so because there is an onchain guarantee that he will be repaid after the 7 day window.

The core principle behind fast liquidity can be generalized to do fast execution. Instead of simply transferring 100 USDC across chains, Alice can ask Bob to call a contract function on her behalf, fronting his own funds. So long as Bob can see that Alice has initiated the “slow path” call across chains, he has an onchain guarantee that he will be repaid in the future.

This mechanism can be applied to any case where Alice wants to call an unauthenticated (public) function — i.e. a function that does not restrict who the caller is. If, for example, Alice was a DAO and the target function had an onlyDAO modifier, then it would not be possible for Bob to fast execute Alice’s transaction in the first place.

Wrapping Up

It should be clear from the above discussion that, if we want to build safer messaging bridges, we should prioritize focus on improving both the security and trust-minimization of verification layers first.

In our next post, we’ll dive into why exactly it is so hard to build a single, secure crosschain message verification layer in the first place. Then, we’ll establish what the best possible outcome is for message verification, and how we can optimize on security while we get there.

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 looking to build secure bridges and other natively cross-chain applications. To date, over $1.5b in transactions have securely crossed the network.

Website | Build xApps | Twitter | Discord | Crosschain Bridge