Introduction.

The blockchain industry has experienced exponential growth in recent years, with the emergence of thousands of new chains, protocols and dApps. However, despite the innovation brought, certain barriers persist, including the complexity of interacting with and from different chains, managing addresses, and achieving seamless connectivity between networks. When it comes to crosschain infrastructure, this is where chain abstraction comes into play.
In this comprehensive high-level article, we will deep dive into these concepts, exploring their intricate details and highlighting the potential use cases for the web3 ecosystem.

Crosschain Infrastructure.

Today, bridges are mostly described as a way to transfer tokens X from chain A to chain B. Reducing the usefulness of bridges to this kind of limited use case is, without doubt, only scratching the surface, and fails to fully appreciate the potential of such tools.

There are different levels of bridges that could be detailed as follows:

• Arbitrary messaging bridges (AMB). They are designed to relay any data between two EVM-based chains. The originating contract encodes data in the form of an arbitrary method call, which can also include or exclude parameters. This information, along with the target contract address, is passed to the AMB contracts
  Example: LayerZero, xCall by Connext, AnyCall by Multichain

• Liquidity Network Bridges. The mechanism for Liquidity Bridge is similar to Uniswap’s pair liquidity provider, the Liquidity Bridge has liquidity providers on each side of the bridge. The depth of liquidity on each chain for each asset represents the quota for cross chain on destination chain. Liquidity providers are needed and stake their token on one side of the bridge.
  Example: Stargate, Connext, Multichain

But we need to think bigger, think further. Being able to interact with contracts on a chain B from a chain A opens up possibilities. Just imagine the possibility of buying an NFT on chain A with tokens from chain B or crosschain governance votes, or even crosschain money markets.

Today, a multitude of projects are competing to provide the best solution for "arbitrary messaging bridges" (AMBs). This term, introduced by LiFi in this article published in 2022, implies that bridges can transfer all types of data from one chain to another.

Arbitrary Messaging Bridges.

The Interoperability Trilemma.

Trilemmas are legion in blockchain technology, and it's no surprise that a new trilemma has emerged concerning interoperability.
The interoperability trilemma , as defined by Connext in 2021, defines the impossibility of satisfying more than 2 characteristics simultaneously on the following three properties: 

• Trustlessness. have equivalent security to the underlying chain.

• Extensibility. be able to be supported on any chain.

• Generalizability. have the ability of handling arbitrary crosschain data.

Bridge Verification Mechanisms.

Based on the properties of the interop trilemma, developers have produced roughly four bridge verification mechanisms for transferring data across chains: 

• Externally verified: multi-party custody (MPC) systems. These systems rely on a third-party group of validators to confirm transactions between blockchains.
  Mostly outsourced,  verified bridges are faster and cheaper to transact, but less secure due to reliance on third-parties to confirm blockchain transactions.
  Example: Multichain 

• Locally verified: atomic locks. These systems use self-executing smart contracts to exchange assets on the source chain for assets on the destination chain.
  Here, the smart contracts replace third-party validators, which makes this mechanism trust-minimize (though expensive and slow).
  Example: Thorchain, Connext, Hop

• Hybrid verification: conditional transfers. These systems offer the speed of atomic swaps and the security of optimistically verified protocols.
  Here, users receive funds on the destination chain almost instantly via LPs who front liquidity to users in exchange for a fee. The LPs receive a user’s funds on the source chain and rebalance their assets using the bridge. As a result, on the condition that an LP is available and able to front liquidity to the user, transactions are executed; if this condition fails, a slow route is activated where the messaging bridge is utilized to bridge user funds.
  Example: Hop – users get their desired assets immediately, while liquidity providers (Hop Bonders) obtain assets within a day through the Hop optimistic messaging system.

• Natively verified: light client relays. These systems verify the state of one blockchain on other blockchains to confirm cross-chain transactions. Here, actors monitor events on the source chain, generate proof of work, and forward those proofs to light clients on the destination chain. Then, the validity of proofs for specific transactions on the destination chain is checked against the records kept by the light clients on the source chain.
  Natively verified bridges are considered the most secure way to move data across chains, but are notorious for lacking extensibility and for being very expensive to build with.
  Example: Cosmos IBC, Near Rainbow Bridge.

Token Bridges.

Built on top of Arbitrary Messaging Bridges, Token Bridges are third-party bridges built to facilitate token transfers. There different existing types of tokens bridges:

• Liquidity networks. enables the exchange of assets on source chain for the desired asset on the destination chain using liquidity pools. For example, Bob has ETH on Ethereum and wants to bridge it to Arbitrum. The liquidity network matches Alice with Bob, an LP who is willing to swap ETH on Arbitrum for ETH on Ethereum for a fee. Examples: Hop, Across, Connext Amarok.

• Wrap and Mint bridges. enables tokens to be minted on new chains by securing tokens on the source chain via a third party multisig setup. Examples: Portal, Multichain.

There Is No Perfect Bridge.

No bridge is a perfect solution in terms of security, speed, or connectivity across every blockchain. As a result, the bridge ecosystem has a wide range of designs and flavors. 

5 major problems:

• Liquidity fragmentation. Despite bridges originally being introduced to unify liquidity across chains, we see that liquidity is now fragmented across various token standards, wrapped assets, and bridge specific liquidity pools on different chains.

• Developer overhead. Developers have an abundance syndrome – there’s a problem of plenty when it comes to choosing a bridge to build on and deciding which one to use is simply a headache.

• Single point of failure. When a dApp or business decides to build on a single bridge, there is a single point of failure for future business logic to be corrupted (if the bridge were to ever be successfully attacked). 

• Bad user experience. Bridges are clunky and specialized, offering varying degrees of UX depending on the token/chain combination a user requests. No bridge offers the best experience from a liquidity perspective on EVERY chain, forcing users to manually hunt for the best bridge given unique priorities. 

• Bridge discovery problem. Users find it challenging to identify the most suitable bridge for their specific transaction requirements.

Abstracting By Aggregating.

Various solutions, such as LiFi or Socket, have emerged to solve these problems:

• No Bridge-Type Rules Them All. Each bridge type has made trade-offs, thus has strengths and weaknesses.

• Reduced Fragmentation. Reduce Fragmentation by integrating and offering all the different sources of liquidity.

• Availability of Liquidity. Offer a better user experience as even if an individual source of liquidity might get drained, an aggregator can facilitate transactions by sourcing liquidity from the other available alternatives.

• Connectivity with the multichain ecosystem. By leveraging the expandability of different bridges in their stack, aggregators are able to offer routes to a widespread network of blockchains.

• Reduced Complexity. Help users find the best route for their crosschain swap based on their requirements and preferences.

• Failsafes are Necessary in Crypto. Offer fall-back options for users and dApps.

Note: We invite you to read the excellent series of articles published by the LiFi team:

• Crypto Aggregation Theory (ft. Bridges) – Pt1. The Evolution of Aggregation Theory

• Crypto Aggregation Theory (ft. Bridges) – Pt.2 Bridge Aggregation in a Multi-Chain World

However, there are still limits to cross-chain aggregation:

• Multi-Message Aggregation. Crosschain DEX aggregators, such as LiFi, already perform basic aggregation of arbitrary messaging bridges. Depending on the user's request, LiFi automatically forwards the request to the bridge. The crosschain contract call is then subject to the bridge's security, which can represent a single point of failure. To mitigate this risk, Uniswap (via the work of deBridge and Celer) has introduced Multi-Message Aggregation (MMA). A message with multiple copies are sent through different bridges to the destination chains, and will only be executed at the destination chain when the same message has been delivered by a quorum of different bridges.The current solution are designed for messages being sent from one source chain to multiple destination chains. It also requires that there is only one permitted sender on the source chain. This would be the use case for Uniswap governance contracts on Ethereum calling remote functions of contracts on other EVM chains. This solution is currently applicable only for Uniswap, However it seems that LiFi is currently working on a generalizable solution.

• Multiple Contracts Calls. Bearing in mind the above diagram of "Multi-Message Aggregation", one possible development could be the use of several AMBs in a single transaction. In this way, it would be possible to call several different contracts from the same starting chain to a different destination chain. In terms of liquidity, this development could enable the emergence of crosschain swaps splitting transfer orders between different AMBs, thus combining optimum security with the best possible price for the user in a crosschain swap.

• Crosschain Multipath. Single-chain DEX aggregators enable swaps via indirect routes (2+ swaps) to be carried out in a single transaction, transparently for the user. Let's consider in this example that we have 3 different tokens named X, Y and Z and that all 3 are available on a chain A and a chain B. 

  We also know that token X only has liquidity on chain B, token Y only on chain A and token Z on both chains A and B. 

  Alice would like to swap token X for token Y on chain A, but X has no liquidity available at the time of the swap. However, there is plenty of liquidity on chain B, and token X is bridgeable to chain B. So we'd like to be able to carry out this swap by bridging token X from chain A to chain B, then exchanging X for Z, and finally bridging token Z to chain A and exchanging it for token Y. 

  This is a huge advantage for protocols with tokens deployed and bridgeable on several chains, particularly stablecoins (e.g.: USDO, MAI, USDC...).

  Crosschain multipath would enable liquidity to be concentrated on a single chain, limiting fragmentation and providing greater liquidity depth, while reducing slippage.

Chain Abstraction, The Final Goal.

A New Paradigm.

Bridges, as arbitrary messaging bridges and token bridges, are a way of implementing Chain Abstraction, the final goal. We can separate Chain Abstraction into 2 distinct subjects:

• RPC Unification. Today, when interacting with a chain other than the one to which the user is connected, it is always necessary to change the chain via the wallet's RPC. This is a further complication for users. To overcome this problem, Gelato has introduced Relay, a solution that abstracts the need to change RPCs. As requests are submitted to Gelato Relay, a network of decentralized Gelato Executors will execute and get the transactions validated as soon as possible. EIP-712 signatures enforce the integrity of data, while gas fee payments can be handled in any of our supported payment methods.Users can now execute transactions from any chain to any chain by only signing a message.

• Token Balance Unification. Why did we talk at length about Crosschain Infrastructure in the first part of this article? For this specific solution. Let's imagine that a user currently has USDC on 3 separate chains (Polygon, Avalanche, Gnosis). He wishes to provide liquidity in USDC on Balancer Polygon; he must therefore manually bridge the USDC from Avalanche and Gnosis to Polygon and then provide the liquidity. This creates a significant opportunity cost, both for the user and the bridges, but above all for the dApp (in this case Balancer). The solution would be to unify token balances, using crosschain infrastructure (e.g. LiFi) to bridge tokens between any chain.

Simplifying The UX.

Today, the leitmotiv of many projects is to onboard the next billion users with DeFi. They all focus on having low transaction costs, a simple interface, etc., but forget one thing: DeFi. The next billion users don't want to know that they're using crypto to send money to their family, to save, receive their salaries or to make a loan. When Apple launched its new savings product paying 4.15% APY (USD), attracting nearly $1 billion in deposits in 4 days, users didn't wonder who the banking partner behind the offer was, in this case Goldman Sachs, which was using customer deposits to buy US-T Bills. Users simply, with one click, deposited their USD into Apple's saving vault, and that was that. To onboard the next billion users, we need to disregard DeFi and use it as an infrastructure, a backend. Users shouldn't know they're using DeFi, just as today's Apple saving vault depositors don't know they're actually buying US-T Bills.

However, we shouldn't shy away from the decentralized, permissionless and open-source nature and philosophy that DeFi offers compared to web2 products, justifying it by the fact that web3 can't offer an excellent user experience. 99% of dApps on the market today have a UX that is at best passable, in most cases execrable, requiring you to sign messages to access them, to change RPCs when you want to change chain, to deposit in vaults with only a single token from a defined chain, requiring you to interact with an external dApp to obtain the desired token if you hold another token, or even the same token but on a different chain. This creates both a barrier to entry and a poor user experience. Many projects today skimp on UX, thinking that design must be at the service of tech, not thinking their product from the user's point of view but purely technical. This leads to many projects that are technically innovative but will never be recognized as such, partly due to poor UX (but not only). At Murphy Labs we believe that tech should be at the service of design, we think first and foremost in terms of user experience. What problems do they currently have? In our today’s research, the constant need to switch between different chains, with ever-increasing numbers of tokens, requiring interaction with third-party protocols. Chain Abstraction is the solution: users no longer need to worry about which chain they're connected to, or which token they're using to deposit in a vault. By unifying balance tokens and RPCs, users are now faced with an experience that no longer requires them to use third-party applications to swap and bridge their tokens, or to spend 5 seconds switching chains.

This opens endless possibilities.

Conclusion.

Bringing Chain Abstraction with its RPC and token balances unification, thanks to the Crosschain infrastructure, is just one part of the puzzle that will eventually enable the space to offer the same experience as web2, adjusted to the level of web3 with its permissionless and decentralized nature. 

In conjunction with account abstraction (Safe), gas abstraction (Gelato), crypto abstraction (Monerium) and yield abstraction (Strateg), chain abstraction will enable us to onboard the next billion users, without them knowing they're using DeFi.

Abstract Everything.

Murphy Labs Research — Anything that can happen, will happen.

• Website: https://murphylabs.io/

• Twitter: https://twitter.com/murphy_labs

• Lenster: https://lenster.xyz/u/murphy_labs