What Exactly is Chain Abstraction?

Account abstraction, gas abstraction, and now chain abstraction—Web3 continues to introduce new layers of abstraction. But what exactly does chain abstraction add to this growing list?

First, let’s break chain fragmentation down.

What is Chain Fragmentation?

Imagine being unable to move your digital assets across chains seamlessly— this is the claustrophobic reality for many Web3 users facing chain fragmentation. If you don’t need a different credit card for every shop that you are stepping into, why should you have to sign up for a different wallet to transact on every chain you are using? This is the reality of Web3 today.

Web3’s maze of over 300 blockchain networks, result in  the ecosystem experiencing significant chain fragmentation. This fragmentation, driven by the need to scale and improve transaction throughput, has created isolated ecosystems where assets are often trapped within their native chains. To move assets across different networks, users must rely on bridges—an essential part of Web3, with monthly bridge volumes surpassing $8 billion. 

Unfortunately, these bridges have become attractive targets for hackers, contributing to nearly 50% of all DeFi exploits and over $2.5 billion in stolen assets. Additionally, many chains require native gas tokens for transaction fees, which often leaves users unable to execute transactions after bridging funds due to a lack of the required token. All these culminates in chain fragmentation-induced complexities and frustrations for both Web3 users and developers building decentralized applications (dApps).

The Problems of Chain Fragmentation

Chain fragmentation creates silos, where wallets, transactions and liquidity are isolated within their respective ecosystems, resulting in multiple issues affecting Web3 users and dApps developers. 

Incompatible Wallets

Chain fragmentation-induced silos result in each blockchain having its own wallet infrastructure, private key management systems, and transaction protocols. Users have to use different wallets for each chain, resulting in friction, complexity, and difficulty in managing their assets across multiple wallets for different chains. This cumbersome process makes onboarding new users into Web3 more challenging for developers.

Wallet incompatibility causes developers who are looking to equip their dApps with cross-chain wallet functions to face increased development complexity. This is because, to address these complexities, developers have to go through the cumbersome process of testing and adapting their dApps to the unique APIs of each wallet provider to ensure their dApps work across multiple wallets. 

Transaction Asynchrony

Silos caused by fragmented chains result in delays and inconsistencies due to lack of synchronization when executing cross-chain transactions. For example, a user trying to bridge assets from Ethereum to Solana may experience delays or inconsistency in transaction finality because Ethereum and Solana operate with different block times and transaction processing speeds. This transaction asynchrony is exacerbated by reliance on third-party validators, relayers, or smart contracts to ensure the validity of cross-chain transactions.

Delays caused by reliance on third parties may result in developers having to implement optimistic updates, where the front-end UI behaves as though a cross-chain transaction was successfully completed before receiving confirmation of this from the back-end UI. In times of high traffic volume, network congestion could result in delayed cross-chain transactions becoming failed transactions. To prepare for the contingency of failed cross-chain transactions, developers need to expend resources to store the pre-transaction state locally to revert the change in the dApp’s state to reconcile this with the state of the blockchain in the event of a need to reverse an optimistic update due to failed cross-chain transactions. 

Dispersed Liquidity

Chain fragmentation results in liquidity providers having to manage separate pools on different chains resulting in capital inefficiencies due to low liquidity concentrations in the pools of each chain. As a result, liquidity providers are unable to optimize their returns, and users face higher costs due to two primary reasons. Firstly, users have to move their digital assets across different chains to access the liquidity pools of these chains. Secondly, users face higher slippages due to low liquidity levels especially in times of high market volatility.

For decentralized finance (DeFi) developers, dispersed liquidity can severely impact key dApp features like swaps, lending, or yield farming. When liquidity is spread across multiple blockchains, developers must either integrate with several isolated liquidity pools or rely on cross-chain bridges to access liquidity on other networks.

If chain fragmentation is the problem, chain abstraction may be the solution. 

The Perspectives of Chain Abstraction

Let’s take a look at the Chain Abstraction Key Elements (CAKE) framework to present our case on how chain abstraction offers a solution to the chain fragmentation silos-induced issues of incompatible wallets, transaction asynchrony and dispersed liquidity.

Permission Layer: Enabling Compatible Wallets

Chain abstraction’s permission layer supports wallets with multi-chain compatibility by supporting the cryptographic key standards and transaction protocols used by different blockchains such as ECDSA for Ethereum and Ed25519 for Solana to facilitate the signing and processing of cross-chain transactions. Better yet, the permission layer can automate some of these processes such as the signing of sub-transactions and the management of gas fees payments across multiple chains to provide an improved user experience (UX) where the user only needs to approve the transaction once, despite its cross-chain nature. However, as Nairolf, pointed out, chain abstraction is a game-changer that goes beyond improving the UX of dApps.

Solver Layer: Streamlining Transaction Synchrony

Chain abstraction’s solver layer aggregates user intents and prioritizes transactions based on factors such as fees, urgency, and extractable value. For blockchains with a single consensus mechanism, the solver layer synchronizes transactions by streamlining the workload for validators through the pre-selection of high-priority transactions. For blockchains with multiple consensus mechanisms i.e. those that operate within multi-chain ecosystems (like Cosmos or Polkadot), the solver layer synchronizes transaction processing across different consensus mechanisms by coordinating the timing and prioritization of transactions for parallel cross-chain processing. 

Settlement Layer: Aggregating Concentrated Liquidity 

Chain abstraction’s settlement layer provides a foundation for gathering, managing, and distributing liquidity across decentralized exchanges (DEXs) and financial protocols operating on different chains by acting as a central point where liquidity is pooled from these sources. The settlement layer’s liquidity aggregation functions enable assets to be pooled in a single, cohesive source that can be tapped into by liquidity providers, allowing users, particularly those with high-frequency and high-volume trades, to benefit from lower transaction costs due to the dispensation of the need for multiple transactions to access the liquidity pools of different chains and more predictable transactions due to lower slippages thanks to the higher liquidity levels of cross-chain aggregated pools.

While CAKE is a good starting point for understanding chain abstraction, it's just one way to look at it. The CAKE framework is often used by developers creating standards. On the other hand, developers working on account systems view chain abstraction as an account system that can be extended and controlled by a single key. However, this view has its limitations. Account extensibility alone doesn’t guarantee chain abstraction. Developers already have access to systems like EOAs (Externally Owned Accounts), which are controlled by a single key and use the same address across chains with the same virtual machine. But EOAs don't offer true chain abstraction within the Ethereum Virtual Machine (EVM), showing that account extensibility doesn’t automatically lead to chain abstraction. Moreover, just because an account is extensible doesn't mean users can access or use their account seamlessly across all applications and chains.

Another alternative point of view is adopted by developers building cross-chain communication projects, such as messaging protocols, shared sequencers, aggregator layers, and composable bridges who tend to view chain abstraction as an interoperable protocol. Cross-chain application calls have been around for several years, yet most users would agree that we have not achieved full chain abstraction. Secondly, the ability to call an application on a different chain does not mean that a user can leverage their entire account, or all its stored assets when interacting with a specific dApp.

The Benefits of Chain Abstraction

While developers may have different perspectives on chain abstraction, they are all on the same page when it comes to the advantages of chain abstraction that would abstract away the existing need for multiple steps of cross-chain transactions to allow for improved UX and other benefits such as cost-savings, lower security risks and better liquidity management.

Stay tuned for our next article in which we will be taking a deep dive into how chain abstraction is paving the way to better user experience for both crypto natives and crypto newbies through the lens of chain abstraction projects making waves in Web3.