🌉 Why Modularity is an End-game for Bridge Design

Everyone is now creating their own Rollups. Frax has Fraxchain, Coinbase is launching Base, Consensys is developing Linea, and so on. The narrative for hyperchains, rollups, rollapps, and superchains is now real, and more chains will keep launching as new scaling solutions. Not to mention those new alternative L1s such as SUI, Aptos, Fantom, Avalanche, and so forth. With more chains arising, secure cross-chain communication becomes more important.

But do we really need an interoperability protocol to facilitate cross-chain communication? Or can we achieve cross-chain communication without any generalized interoperability protocol? The answer is: we can.

For example, if I were to communicate between Ethereum Mainnet and L2 like Optimism, we can rely on the most secure trust-minimized path, which is its Arbitrary Message Bridging (AMB). But the problem arises when we try to communicate between L2s. When we try to send calldata from Optimism to Arbitrum, we can’t send calldata from Optimism to Arbitrum directly since there’s no direct path connecting these two chains. The most secure method to ensure calldata is passed in the highest security possible is to send calldata from Optimism to Mainnet, then from Mainnet to Arbitrum.

With more chains being developed, the number of most secured paths will also increase correspondingly. For example, zkSync<>Polygon, Base<>OP, Fraxchain<>Arbitrum, etc. For each unique path, there will be more and more “most-secured path” available for each communication channel.

To solve this multiple path problem, most bridges try to connect all chains using their self-designed shared verification method (although some don’t and let dApps decide their security method like LayerZero or Router Protocol). For example, Axelar uses a Proof-of-Stake Network (PoS) to validate information between two connected chains, Wormhole uses a Proof-of-Authority Network (PoA) to relay the message between chains, etc.

Now we can see the big picture and the problem with the bridging space. To pass bridge data (or token) from one chain to another, you must choose between:

1. Use a trust-minimized path possible such as AMBs, IBC, XCMP, but you are limited to communication between a specified ecosystem only (AMBs allow only ETH<>L2 communication, IBC for Cosmos Ecosystem, and XCMP for Polkadot).
2. Trust a verification method from the 3rd party bridge provider, assuming that PoS, PoA, or other verification method is economically secured

Connext solves this issue by utilizing both the most secure path and a battle-tested optimistic verification on top. This is possible because of a modular architecture design, which allows Connext to use the most secure communication path between two connected chains, ensuring maximum security.

In this article, we’ll discuss why Connext chooses a shared security with a modular architecture and why we think this design is an end-game for bridge design.

🗿 Monolith Bridge vs Modular

What is a Modular Bridge? And what is even a Monolith Bridge? Simply put, a Monolith Bridge is a type of bridge design that builds the whole bridging infrastructure in a single protocol. A Modular bridge, on the other hand, decomposes bridge functionalities into different parts and builds only on specific functionalities, outsourcing different functionalities to other protocols.

But why modular over monolith?

⌛ Monolith Bridge Limitation

Interoperability is a HARD problem. It’s so hard that there’s no one-size-fits-all solution. Yet, most bridges are built in a monolithic architecture. For example, Axelar, Wormhole, Multichain, etc. These bridges are all monolith and bounded by their verification design. For example, Axelar will be forced to use only their PoS Network for verifying cross-chain transactions, and Wormhole is also forced to use only their PoA Network. Although this can be changed, the cost of changing their verification stack will be huge because it is rooted in their bridge architecture design.

🤨 Monolith Bridge always brings in trust assumptions

When we talk about the most secure cross-chain communication, it’s either AMBs (for ETH<>L2) or a default messaging protocol that deeply ties with blockchain consensus like IBC (for Cosmos), or XCMP (for Polkadot). We can safely say to some extent that these bridges are the closest to trustless as possible. If there’s ANY bridge that can communicate without using this most secured path, we now have additional trust assumptions to the bridge.

For Wormhole, we’re trusting that their PoA network will not collude to communicate a fraud transaction. Any additional trust to the cross-chain communication also introduces additional risks. Any bridge that add too many trust assumptions often fail to secure their users’ funds successfully (Multichain/Ronin hacks really emphasize how important trust is).

🏃 Reducing trust assumptions, towards trust-minimized bridges

Bridging verification is not a one-size-fits-all solution. It never was. Anyone attempting to provide a one-size-fits-all solution will introduce an additional trust assumption.

Connext tackled this problem by introducing a modular bridge design, allowing a customized shared verification layer across different cross-chain communication paths (Read more about Connext modularity design here). With this design, Connext uses the battle-tested and the most secure communication channel for each connected path, achieving a lower trust assumption compared to monolith bridges.

With Connext Modular design, all cross-chain communication that was executed using Connext’s xcall will use an optimistic verification on top of the most-secured verification channel (e.g., AMBs for L2<>L2 communication)

📡 Future-Proof with Modularity

One significant concern with monolith bridges is their lack of guaranteed future-proof security. When Monolith commits to their bridge design, their infrastructure deeply depends on how the verification method was used. What if one day a more secure and cheaper verification method was developed? Monolith bridges will have a hard time upgrading their verification stack because it’s deeply tied to their monolithic architecture, losing a future-proof trait.

In contrast, Connext modularity is future-proof because Connext only builds an execution layer for bridges, outsourcing transport and verification to others. For example, Connext can use Gelato, IBC to transport data across chains; Succinct’s zk-light client or AMBs for the verification layer. If there’s no default path between two domains (e.g., ETH<>BNB), Connext can always fallback to a fraud-proof optimistic verification system that was battle-tested on many L2s. Optimistic verification can build on any existing transport layer while maintaining high economical security (read more here).

With this modular design, we can ensure that the cross-chain transaction done via Connext is safe and trust-minimized. If a new verification method for bridging emerged in the future, Connext will be able to shift the most secure communication path to a newer version easily thanks to its modularity.

🧩 Modular Bridge: isolated vs shared security setting

The idea of modularity is not new in bridging. For example, LayerZero also proposed a modular set up for bridging, allowing dApps to choose their security mechanism. However, this approach to security measurement is totally different.

Unlike other trust-minimized bridges (Connext, Hop, Across), LayerZero uses a mechanism called isolated security where each dApp integrated with LayerZero must choose its security stack. This is totally different from what Connext as well as most bridges employ. Most bridges use a shared security model where the bridge design their best security practices for dApps.

🚫 Why Not Isolated Security?

There are a few reasons why the isolated security model is not ideal. First, isolated security assumes developers have full knowledge of what maximum security for bridging is. Obviously, this is not always the case because there’s no one-size-fits-all bridging solution that is secured for all connected chains as mentioned previously.

Second, isolated security doesn’t solve the interoperability problem at all.

The core problem for interoperability is to figure out how to verify a cross-chain transaction. Isolated security delegates this burden to dApps instead of solving this problem directly (read more here). dApps need to resort to multisig or external validator sets in order to operate — or worse, rely on LayerZero as the trusted, custodial party (this is the case for 99% of the projects deployed so far).

Third, the isolated security model introduces more risks toward end-users. This is because each dApp will have its own security configuration and users can’t be sure that every dApp they’re interacted with is configured securely. Not to mention that isolated security also allows dApps to adjust their bridge security, which introduces additional risks to end-users as demonstrated by L2Beat.

🔐 Isolated Verification is not Isolated Security, but Shared Security

Connext employs a modular design that allows for cross-chain communication through shared security, using the most secure verification method for all connected paths.

Although this is not an isolated security model, it veers more towards an isolated verification approach, ensuring the highest level of security for all paths, if feasible.

This approach by Connext essentially takes the responsibility away from developers integrating the platform, as they do not have to make decisions about their bridge security. This is because they are using the most secure communication path possible for each cross-chain transaction to different chains. In this sense, while the bridge security model for Connext is still shared, it focuses on offering the most secure cross-chain transaction paths.

On the other hand, LayerZero features a modular design as well, but with isolated security. It allows cross-chain communication to use different verification methods as judged by dApp developers. The two concepts have similarities but diverge significantly in terms of trust assumptions. Despite some overlap, the fundamental difference between Connext and LayerZero is the shift in trust assumptions and the role of developers in ensuring secure transactions.

✍️ Conclusion

In this article, we discuss the limitation of the monolith bridges and show why modular bridge is an end-game for bridging solution. Monolith bridges are bounded with their initial design and introduce additional trust assumptions for doing cross-chain communication. Modular Bridges, on the other hand, adapt their security for any connected domain while being able to upgrade their security model resulting in a future-proof design. In addition, we also show that modularity itself is not enough, but a shared security is also necessary to make sure that end-users are exposed to minimal risks and trust as much as possible.

References

• An Exploration of Connext’s Architecture Pt.1: High Security and Censorship Resistance
• The Messaging Bridge Stack
• Optimistic Bridges
• Circumventing Layer Zero: Why Isolated Security is No Security

About Connext

Connext is a trust-minimized interoperability protocol aiming to be a HTTP of Web3, abstracting the concept of chains away from users

• Website
• Blog
• Discord
• Documentation
• Bridge