Fixing Cross-Chain Composability

TLDR; Why build on Wormhole Batch VAAs?

⭐ Trust is isolated -> Composing protocols only trust the bridge

⭐ Composability is the default → Any set of protocols integrating Wormhole is composable by default

⭐ Integrations are simple → Protocols only integrate with Wormhole directly

⭐ Costs are low → A batch can be verified at almost constant cost compared to many individual messages

Introduction

The last years cemented DeFi as an emerging space for technological and financial innovation. One main driver for the rapid pace of innovation has been composability: the ability for different protocols to seamlessly interact and integrate with each other and for each to focus on its own primitive.

With Ethereum’s capacity being maxed out by the amount of its users, the space for alternative generalized settlement layers has grown and with it, so has the need for users to interact with applications on different chains.

We saw first instances of bridging value between these different ecosystems happening through centralized exchanges. Relying on trusted middlemen to move assets across permission-less settlement layers was/is, of course, not ideal.

Over the last year, we saw the emergence of the first decentralized bridges and generalized cross-chain interoperability protocols.

Most of them implement a very basic primitive: cross-chain messaging.

While cross-chain messaging solves for generalized use cases, it is very bad at one thing — making different protocols compose with one another.

But, why is cross-chain composability important?

Meaningful cross-chain interactions mostly require multiple dApps to function together for the user to perform an action. The main driver for this is the need to send value with interactions (app and asset bridge composing).

Examining the status quo: cross-chain composability is HARD

To understand what makes cross-chain composability hard, we first need to understand how cross-protocol interactions work today — specifically how cross-chain interactions are working under the hood and why its hard to make them composable.

Programs that are deployed on the same blockchain can synchronously invoke each other. If they live on different chains, however (also instances of the same dApp on different chains), they cannot directly call into each other. Instead they emit a message on the source chain that can be relayed, verified, and interpreted on the target chain to carry on with the desired action. This message contains all instructions required to perform the desired actions on the target chain.

This messaging primitive hinders composability. This is because for synchronous actions to happen different programs need to embed all of their instructions into the same message.

In current practice, this is leading to design patterns where dApps are nesting their different actions into each other to be embedded in one common message:

e.g.: User -calls> dApp -calls> Token Bridge -calls> Messaging Protocol

This is bad for multiple reasons:

• Trust: The nested approach requires the protocols to trust each prior protocol in the chain of calls. In our example, the call stack would be unpacked on the target chain in reverse order, meaning the dApp is trusting the Token Bridge to deliver its instructions.
  → If the weakest protocol in the chain fails they all fail.
• Integration Effort: It requires every dApp in the chain to integrate with both the dApp prior and after in the chain of nested calls. Due to the previously mentioned security implications, the bar for this is high.
  → Actual composability is limited
• Complexity: The given example is a simple one. Having 3+ protocols compose with each other in this fashion is very complex to implement and prone to errors.
• Security: In the past, we have seen an entire class of DeFi exploits based on protocols forwarding calls from users.

The challenge:

Build a new primitive for cross-chain composability while:

• Enabling open plug-and-play integrations without integration efforts on the integrated side
• Enabling atomic interactions across protocols among multiple chains
• Eliminating the necessity of chaining / nesting composing dApps
• Preventing composing dApps from inheriting each others’ security assumptions

The Solution: 🌈 Atomic Batch VAAs

Atomic Batch VAAs are a novel approach to cross-chain composability solving the challenges defined above.

The general idea behind Batch VAAs is simple: allow different protocols to independently send messages within the same atomic transaction. Each of the individual actions is owned by the respected protocol, but can only be executed in the aggregate, maintaining atomicity (optional).

This allows an integrator to atomically compose with different protocols without having to inherit their trust assumptions or even work together for an integration.

Protocols can build core-primitives and expose them as open endpoints for everyone to build on top.

Lets look at an example:

Here we see 6 protocols composing with each other in a permission-less fashion:

• A consumer xApp
• Two different token bridges
• An open relaying network
• A dApp on the target chain
• …and of course Wormhole.

The xApp is leveraging a diverse set of different protocols to perform its desired action with ease: interact with another protocol on another chain while transferring some value (e.g. depositing into a lending pool or trading on a dex).

The relaying network is using another token bridge in the backend to transfer relayer payments. This interaction seamlessly goes into the same Wormhole batch and can be atomically executed on the target chain.

For the first time complex interactions like this are possible in a permission-less manner, where each of these protocols just implicitly integrates with Wormhole.

Next up? We’ll cover how Wormhole Batch VAAs allow trust-less, swappable open relaying systems to be developed.