Written by: imajinl, Paul Timofeev, Shoal Research
Translated by: Yangz, Techub News
"The necessary puzzle pieces to achieve mainstream blockchain adoption (with complementary case studies)."
Why a multi-chain future is inevitable
A multi-chain future with hundreds of chains is inevitable. Over time, nearly every team and developer will want their own economics and users, and even though this can be achieved in a general-purpose execution environment like Solana, applications rely on the throughput of that environment, which has historically proven to be unreliable at times. If we believe that a paradigm shift to blockchain technology is imminent, then the next logical conclusion is to have hundreds of specialized execution environments for applications built on blockchain technology. This is already happening today, with applications like dYdX, Hyperliquid, Frax, and other nascent projects all becoming independent appchains and rollups. Additionally, L2 scaling solutions are likely to coexist alongside L1, as smaller groups of nodes can communicate significantly faster around the world than larger groups of nodes. This would allow L2s (like Rollups) to scale almost unlimited while inheriting the security of L1 and having a 1/N trust assumption (rather than the high quorum required to reach consensus like L1). Essentially, we envision a future with hundreds of L1s and L2s.
However, even with the current multi-chain status quo of only a few dozen L1 and L2, concerns have been raised about the user experience. Therefore, the future of multi-chain needs to overcome many problems, including fragmented liquidity, the complexity of end users using multiple cross-chain bridges, RPC terminals, different Gas tokens, and markets. So far, there is no way to completely abstract away the complexity of the user experience in the current situation. If the multi-chain ecosystem continues to develop without first solving these major user experience obstacles, it is conceivable how unusable blockchain will be for end users.
The Internet didn’t become what it is today because users understood its core protocols like HTTP, TCP/IP, UDP. Instead, it abstracted the technical details to make them accessible to laymen. Over time, so will blockchains and blockchain-native applications. In the cryptocurrency space, users need to deploy liquidity decentralized across multiple L1s and L2s to meet suboptimal user experiences and understand the technical details of these systems.
Now is the time to abstract everything - as far as the average user is concerned, they don’t need to know that they are using a blockchain, let alone how many L1s and L2s are underneath it, because this is the only way for the industry to gain mass adoption.
Why chain abstraction can solve all problems
Chain abstraction is a means to abstract the nuances and technical details of the blockchain for ordinary users, thereby providing a seamless user experience. It can be said that a breakthrough in user experience may be the missing piece for the next generation of enterprises and users to enter the blockchain and crypto-native ecosystem.
A deeper look at the components of the chain abstraction
Before introducing the infrastructure projects that are critical to realizing the future of chain abstraction, it is necessary to first understand some of the technical components of chain abstraction.
Account Abstraction
Wallets today face many limitations. In addition to various security vulnerabilities, they can only provide limited functionality unless used in conjunction with other smart contracts. Imagine what would happen if an Externally Owned Account (EOA) was turned into a Smart Contract Wallet (SCW)? Unlike an EOA, an SCW cannot initiate transactions independently (it needs a prompt from the EOA). By merging the functionality of both, we can effectively turn an EOA into a SCW, allowing it to not only initiate transactions, but also execute complex, arbitrary logic, which is the premise of smart contracts.
The merger of the two can unlock a large number of use cases, and here we will focus specifically on its relationship to chain abstraction.
When converting EOA to SCW, it effectively separates who executes the transaction from who signs it. This means that users do not need to execute transactions directly, but rather, they are executed on their behalf by sophisticated actors (called executors). It is worth noting that in this process, users do not give up custody of their wallets as they retain their own private keys. There are other benefits to having executors, such as not having to keep Gas balances on all different blockchains as transaction/Gas fees can now be abstracted away as well. In addition, users can execute bundled transactions with a single click of a button. For example, approving a token for use on a DEX, exchanging it, and then lending the proceeds to the Aave market.
With executors, there is no need to interact directly with smart contracts, while users can retain custody of their funds. Imagine how cool it would be to use any blockchain application through a Telegram bot, and account abstraction technology makes it possible.
Additionally, account abstraction allows users to self-custody their assets and open DeFi positions on many chains without the need for different wallets, RPCs, or worrying about different signature types, all without even considering which chain they are using. (More on account abstraction in this demo and article) Not only that, account abstraction also eliminates the need for users to hold private keys to protect their accounts from third-party management.
In addition to social recovery, users can also choose more traditional verification methods such as 2FA and fingerprint to ensure the security of their wallet. Social recovery can recover lost wallets through the user's family, etc. "The next billion users are not going to write 12 words on a piece of paper. The average person doesn't do that. We need to provide better usability for them; they don't need to think about encryption keys." - Yoav Weiss, EF Since wallets are the entry point to crypto and blockchain, account abstraction will eventually enable chain abstraction to flourish. For more details on the inner workings of account abstraction, see this post by Jarrod Watts.
Intent
The so-called intention refers to allowing experienced participants or "solvers" to execute transactions on behalf of users in an optimal manner. Simply put, it is to implement the on-chain operations required by users in an optimal manner outside the chain. For example, when you submit an order to CowSwap, you are actually submitting an intention to exchange the above token for another token at the best price. By submitting this intention off-chain, the public mempool can be bypassed and routed directly to the encrypted private mempool. Solvers will then compete to meet or resolve your intentions at the best possible price, whether using their own balance sheets, private order flows, or on-chain liquidity venues such as Uniswap and Curve. In this way, the solver's profit is compressed to zero, providing users with the best execution.
Now that we have defined intents, how exactly do they help us implement the chain abstraction?
The answer comes back to the line between signers and executors in the account abstraction. If all a user needs to do is click a button to sign a transaction, then they can outsource all of their on-chain needs to mature participants who are responsible for finding the best execution. These mature participants then take on the risk of interacting with all the different applications on L1 and L2, the associated gas fees for different tokens on different chains, reorganization risk, and other execution risks. By taking on these steps and risks, solvers will price the fees they charge users accordingly. In this case, users don’t have to consider the various complexities and risks associated with using on-chain products and services, but instead outsource them to mature participants who charge users accordingly. Because there is competition between solvers, the fees charged to users will be compressed to near zero because there will always be solvers ready to undercut the price of the solver who wins the order flow. This is the magic of the free market - through competition, users will enjoy better services at lower prices. For example: I have ETH on Ethereum, I want SOL on Solana, and I want to execute at the best price. Through a request for quote (RFQ) system, the intent market delivers order flow, and seconds later, users are able to hold SOL on Solana. It is worth noting that Ethereum has a block time of 12 seconds, which means that although solvers have no settlement guarantees, by running their own nodes, they can be fairly certain that the USDC deposit transaction is valid and will go through. Additionally, by using their own balance sheet, solvers can pre-fund the purchase of SOL on Solana and essentially fulfill intent before obtaining funds. Since the risk is not borne by the user, but by established participants, users can fulfill their intent with sub-second latency and the best price without knowing the cross-chain bridges, RPCs, or Gas costs used.
In this case, the user still knows which chain they are using. This example shows how intents work in the current context, rather than in a completely abstract chain. Intentions don’t stop here, there are more possibilities.
It is not difficult to imagine that in the future, intentions will meet all the needs of users. Users only need to specify what to do and it will be completed in the most efficient way. For example, a user may want to borrow DAI with ETH and deposit DAI into a liquidity pool to earn CRV rewards. In this example, the authorized solver will compare all DAI with the borrowing rate of ETH and lend at the lowest interest rate. The solver will then deposit DAI into a vault similar to Yearn, automatically convert the highest yield into CRV, and transfer it to the user's wallet.
However, it is important to note that risk is subjective and cannot be expressed in terms of intent, unlike other objective inputs such as the maximum price slippage of a trade. So which lending markets, liquidity pools, and chains can be used to fulfill this intent? After all, each market has a different risk profile and trust assumptions. This is where “authorized solvers” come in. Each authorized solver is trusted to some extent by the user to fulfill the user’s intent in accordance with the risk and trust preferences expressed in advance by the user. For example, a user can specify that deposits should not be made to “risky” contracts. However, it is likely that only advanced users will specify a large number of subjective preferences to solvers. Even more sophisticated participants than advanced users (HFT, MM, VC, etc.) may directly connect to the chain to avoid any fees charged by the solver and customize the risk and trust assumptions themselves. Users who are slightly familiar with blockchains may choose from a few presets (such as low, medium, or high risk) and solvers can act on these presets.
Utilizing a set of authorized solvers to satisfy the subjective needs of users creates competition between solvers, incentivizing them to complete user orders in the best possible way without causing any trouble to the user. In addition, users can revoke the executor rights of a solver at any time, thereby "revoking" the authorization, which creates a system of checks and balances. This way, solvers have an incentive to remain honest and follow user preferences, otherwise different solvers can prove that they have acted maliciously against the user who initiated the order flow. Of course, intents are still a work in progress, and speculation about how intents can be transformed into more complex technology is just that, speculation. However, it is not surprising to see intents develop in this way. We believe that intents will play the most important role in realizing the future of chain abstraction. CowSwap and deBridge are two projects that focus on intents.
We have already introduced CoWSwap and its intent-based architecture. Similar to CoWSwap, deBridge also adopts an intent-based architecture, but its purpose is to enable lightning-fast cross-chain transactions. Like most intent-based solutions, deBridge leverages a network of solvers consisting of MMs, HFTs, and other sophisticated players to front-end funds on the target chain through their own balance sheets before collecting users' funds on the source chain. In addition to allowing solvers to compete with each other to provide users with the best execution possible, deBridge also differentiates itself by shifting risks (such as reorganization risk) and other inconveniences (such as gas fees and different RPCs on different chains) to solvers. The figure below shows the deBridge model. In the example below, a user with a USD stablecoin on Solana wants to have a EUR stablecoin on Ethereum, then they express their intention to deBridge, which propagates it to the solver network, allowing the solver to exchange their ETH on Ethereum for the EUR stablecoin ethEUR on Ethereum. After the deBridge validator group verifies that the solver has fulfilled the user’s intent on the destination chain (in this case, providing the user with ethEUR), deBridge quickly unlocks the user’s funds on the source chain (in this case, Solana) and gives them to the solver. Importantly, the user does not need to wait for verification before receiving funds on the target chain.
To get a better understanding of deBridge and intent-based design, listen to this podcast episode.
Liquidity Aggregation
One of the manifestations of the growing multi-chain future is the extreme fragmentation of liquidity. In a world with hundreds of Rollups, validiums, L1s, etc., each hosting liquidity on their own network, the end-user experience will become increasingly poor due to the fragmentation of liquidity pools. If there was only one CEX hosting all the liquidity of the crypto market, rather than hundreds of CEXs and more on-chain DEXs (all sharing the same liquidity pool), then end-user execution would likely be optimal, aside from censorship and overall centralization issues.
However, this is only a hypothesis, as it is not feasible in the real world where competition is fierce and decentralized forces exist. The emergence of DEX aggregators was an important step forward in user experience, aggregating dispersed sources of liquidity from a single network into a unified interface. However, as the inevitable multi-chain future begins to emerge, DEX aggregators will no longer be suitable, as they can only aggregate liquidity on a single chain, not multiple chains and their liquidity. Additionally, for blockchains like Ethereum, the associated gas costs required to route liquidity across multiple source chains or between chains make the cost of using an aggregator higher than the cost of direct liquidity sources. This model can achieve greater success on low-price, low-latency networks such as Solana, although the aggregators themselves are still limited in the liquidity sources they can route transactions to.
In the future of chain abstraction, it is critical to have technology that aggregates decentralized liquidity, as the ideal user experience will be chain-free and will likely rely on third-party solvers to provide execution services. Many teams are developing solutions designed to drive multi-chain liquidity fragmentation. Below we will mainly introduce Polygon AggLayer and Optimism Superchain.
Polygon AggLayer
As stated on the Polygon website: “AggLayer will be a decentralized protocol consisting of two parts: a universal cross-chain bridge and a ZK-driven mechanism that provides cryptographically secure guarantees for seamless cross-chain interoperability. With security provided by ZK proofs, chains connected to AggLayer can remain sovereign and modular while retaining the seamless user experience of a monolithic chain.” Fundamentally, there is a typical bridge between Ethereum L2 scaling solutions and Ethereum. This means that all user funds bridged from Ethereum to L2 reside in this bridge contract. However, this undermines interoperability between different L2s and their ability to seamlessly communicate data and transfer value. This is because, for example, if you want to cross from Base to Zora (both are Ethereum Rollups), as shown in the figure below, it will take 7 days for you to withdraw funds, first from Base to Ethereum, and then from Ethereum to Zora. For an OP-type Rollup like Base, it takes time to dispute the bridge transaction using fault/fraud proofs. Not only is this a long process, but it is also costly because it requires interaction with the Ethereum main chain. Polygon AggLayer turns this process on its head. As shown in the figure below, all chains share a cross-chain contract with other chains that utilize AggLayer.
How AggLayer works
At its core, AggLayer aggregates zero-knowledge (ZK) proofs from all chains connected to it, facilitating cross-chain transactions. AggLayer is essentially an aggregation place where all supported chains publish ZK proofs to prove that certain actions have occurred. To further illustrate this, let’s consider how it works in a real-world scenario. For this example, let’s assume that all mentioned chains are connected to AggLayer. A solver detects a request or intent from a user on Base. The user has ETH and wants to purchase 3000 DAI worth of NFTs on Zora. Since the solver has no DAI, they must quickly find the best way to fulfill that intent. They discover that DAI on Optimism is cheaper than on Zora. The solver then publishes a proof to AggLayer that the user has ETH on Base and wants to receive the corresponding amount of ETH on Optimism. Since cross-chain contracts are shared, only one ZK proof is needed to transfer the same amount of fungible assets on chain “X” to chain “Y”. After publishing the ZK proof and unlocking the corresponding amount of ETH on Optimism, the solver swaps in DAI and performs the same process to obtain the same amount of DAI on Zora and then complete the NFT purchase. Behind the scenes, AggLayer also settles these ZK proofs to Ethereum, providing stronger security guarantees for end users and the chains connected to AggLayer. However, in this case, the solver/user/other actor bears inventory risk. This risk can manifest in the form of DAI on Optimism being arbitrage, NFT cost increases, ETH price drops, or any other risks between user order flow from generation to transaction, resulting in losses to the parties involved. DEX aggregators on a single chain have atomic composability, while solvers interacting with different state machines are different. Atomic composability ensures that all operations are executed in a single linear order, either all succeed or all fail. This is because there is always a delay of at least one block between different state machines due to the potential risk of reorganization (on the target chain). However, this does not mean that the above use cases cannot happen.Not only are there long-tail events, but solvers and other sophisticated participants can also take on these risks and compensate for them through pricing to users. For example, solvers can guarantee execution by covering losses (if they occur) or using their own balance sheet to satisfy user intent.
Optimism Superchain
Another example of aggregated liquidity is the Optimism Superchain. As defined in the Optimism documentation, Superchain is "a network of chains that share cross-chain, decentralized governance, upgrades, communication layers, and more, all built on the OP Stack." This project focuses on aggregated liquidity, similar to AggLayer. Superchain will allow all chains that are part of it to use shared cross-chain contracts. This is the first step in aggregating liquidity between chains in Superchain.
The difference between Superchain and AggLayer is that AggLayer relies on ZK proofs for a seamless experience, while Superchain relies on a shared sorter. This article will not go into the details of the shared sorter, but you can refer to this article to understand how the shared sorter unlocks advantages in the field of seamless interoperability across chains and, to a certain extent, atomic composability. Since Superchain stipulates that opt-in chains must use a shared sorter, the execution environment that can be used by opt-in chains may be limited. In addition, other cumbersome challenges will arise, such as chains being unable to access MEVs created by their users, as well as other challenges outlined in this article. However, teams such as Espresso are working on how to redistribute MEVs enabled by chains using a shared sorter. In addition, all chains connected to the Polygon AggLayer are also required to use the same ZK loop, which will also limit the execution environment that can be used by chains connected to the AggLayer.
Chain abstraction "cake" framework
Frontier Research has developed the CAKE (Chain Abstraction Key Elements) framework. The framework outlines the three layers required to achieve the following state (not including the user-facing application layer): “In the chain abstraction world, a user visits a dApp website, connects a wallet, signs an intent action, and then waits for final settlement. All the complexity of acquiring the required assets on the target chain and final settlement has been abstracted from the user side and occurs in the infrastructure layer of CAKE.” The framework defines the three infrastructure layers of CAKE as the permission layer, the resolution layer, and the settlement layer. We have already discussed the resolution layer and the permission layer. The permission layer includes account abstraction and policy - we call it authorization, while the settlement layer, includes underlying technology such as oracles, cross-chain bridges, pre-confirmations, and other backend functions. Therefore, the settlement layer is expected to bring huge benefits to solvers and other mature participants as well as user-facing applications, because the settlement components in the framework can work together to help solvers manage risk and provide better execution for users. This will be further extended to other components such as data availability and proof of execution. These are all requirements for blockchains to provide application developers with a secure building experience and provide security guarantees, which are ultimately passed on to end users. The CAKE framework encompasses many of the concepts mentioned in this article and provides a coherent way to look at the various components of the chain abstraction and how they relate to each other. Readers interested in the framework can read this introductory article.
Chain Abstraction Case Study
We’ve already covered a few projects that are working towards a chain-abstract future, here are a few others.
Particle Network
Particle Network is launching a modular L1 based on the Cosmos SDK that will run as a high-performance EVM-compatible execution environment. Initially, Particle debuted as an account abstraction service provider, enabling users to create smart contract wallets connected to their Web2 social accounts, which can then be used in dApp embedded interfaces. The protocol has since expanded its service offerings, aiming to promote chain abstraction across the broader blockchain space through its suite of wallet, liquidity, and gas abstraction services on L1. Similar to other chain abstraction service providers, Particle envisions a future where anyone can easily transact on multiple chains through a single account and pay gas fees in any token they wish. As such, the underlying L1 will act as an orchestrator of a multi-chain ecosystem, unifying users and liquidity across EVM and non-EVM realms.
Particle Chain Abstract Stack
Universal Accounts (UA) From an end-user perspective, Particle’s chain abstraction stack starts with first principles — creating accounts. Universal Accounts on Particle are ERC-4337 smart accounts attached to pre-existing EOAs (Externally Owned Addresses) that aggregate token balances on multiple chains into a single address by automatically routing and executing atomic cross-chain transactions. Traditional cryptocurrency wallets can be used to create and manage accounts, while Particle’s WaaS also enables users to sign up using social logins. To abstract away the various complexities of blockchain-native operations, UA functions as a unified interface built on top of existing wallets, allowing users to deposit and use tokens across multiple blockchain environments as if they were on a single chain. To keep state in sync between UAs, account settings will be stored on Particle L1 as the central source of truth for each instance. The network will then facilitate cross-chain messaging to deploy new instances or update existing ones. Thus, Particle L1 is the coordination and settlement layer that handles all cross-chain transactions via user agreements.
Universal Liquidity Another key component of the Particle chain abstraction service is the Universal Liquidity feature. While the User Agreement provides a way for users to express transaction requests through an interface, Universal Liquidity refers to the layer responsible for automatically executing these requests, which in turn enables the unification of balances across different networks. This feature is key to enabling cross-chain transfers, which are otherwise hindered by current barriers to entry (such as purchasing native Gas tokens and creating native wallets for new networks). For example, when a user wishes to purchase an asset on a blockchain that has never been used and does not have any funds, the liquidity required for the purchase is automatically obtained from the user's existing balances, which may be on a different chain and may be in a different token. This is largely achieved through Particle's decentralized messaging network (DMN), which supports specialized services (called relayer nodes) to monitor the settlement of off-chain events and state events. More precisely, relayers in the DMN monitor the status of user operations on external chains using a messaging protocol, and then settle the final execution status to Particle L1. Universal Gas The third pillar of the Particle chain abstraction stack is the implementation of the Universal Gas token. By interacting with Particle’s UA, Universal Gas allows users to pay for Gas with any token. When a user wishes to execute a transaction through Particle UA, the interface prompts the user to select a Gas token, which is then automatically paid through Particle’s native Paymaster contract. All Gas payments are settled on their respective source and target chains, while a portion of the fees are exchanged for Particle’s native PARTI tokens and settled on Particle L1.
Particle builds on its existing account abstraction infrastructure, which has reported over 17 million wallet activations and over 10 million user actions. Particle L1 is not intended to compete directly with existing blockchains; rather, it aims to provide an interoperability layer that connects them in partnership with key teams in the chain abstraction services space, including the Near and Cake R&D teams. Particle Network L1 is currently in a testnet phase, allowing early participants to try out universal gas in an experimental UA implementation.
Near Protocol
As a sharded proof-of-stake L1, Near’s core revolves around bridging the gap between blockchain-native applications and mainstream audiences. Near achieves this through Account Aggregation. Account Aggregation is a multi-layered architecture that aims to abstract away key pain points of using blockchain networks, such as switching wallets, managing gas fees, cross-chain, etc. It aggregates all operations into a single account.
Near Chain Abstract Stack
Near Accounts Near’s proprietary account model maps each account to a more readable account name, such as alice.near, in addition to the alphanumeric public key hash standard found on most blockchains today. Near accounts also use two types of access keys, which differ in nature and underlying functionality, enabling accounts to manage multiple keys on multiple blockchains, with each key responsible for various permissions and configurations unique to its domain:
Full-Authority Keys: These keys can be used to sign transactions, effectively acting on behalf of the account, and therefore should never be shared.
Function Call Keys: These keys are used to sign permissions specifically for calls to a specific contract or set of contracts.
Near’s proprietary key management system, FastAuth, lowers the barrier to entry and further enhances the abstraction of blockchain for end users. FastAuth enables users to register blockchain-native accounts with a simple email address and replaces lengthy and complex private keys and passwords with passkeys (biometrics that replace passwords). Multi-chain Signatures Multi-chain signatures are a key component of Near’s chain abstraction, allowing any NEAR account to have associated remote addresses on other chains and sign messages and perform transactions from those addresses. To achieve this, multi-chain signatures use the NEAR MPC (multi-party computation) network as signers for these remote addresses, eliminating the need for explicit private keys. This is made possible by a novel threshold signature protocol that implements a form of key sharing that allows MPC signers to maintain the same total public key even as key shares and nodes change. Making MPC signing nodes part of the NEAR network allows smart contracts to initiate the signing process for an account. Each account can create an unlimited number of remote addresses on any chain by using different combinations of chain IDs, NEAR account IDs, and specific paths. Meta Transactions Currently, another key issue that hinders the development of a seamless user experience in a universal blockchain environment is that each blockchain requires gas fees to be paid in its own native token, which requires users to acquire these tokens before using the underlying network. NEP-366 introduces meta transactions for Near, a feature that allows users to perform transactions on Near without owning any gas or tokens on the chain. This is achieved through third-party service providers, Relayers, who receive signed transactions and forward them to the network while attaching the necessary tokens to subsidize their gas fees. From a technical perspective, the end user creates and signs a SignedDelegateAction (which contains the data required to build the transaction) and then sends it to the relay service. The relay service signs the transaction with this data, sends the SignedTransaction to the network via an RPC call, and ensures that the relay service pays the gas fees when performing actions on behalf of the user.
Other noteworthy chain abstraction projects
Here are other noteworthy teams building solutions for chain abstraction services. This list is not necessarily exhaustive, but provides a foundation for those interested in further researching chain abstraction models. Connext Connext, a modular interoperability protocol, defines chain abstraction in a blog post (May 2023) as "a pattern for improving the user experience of dApps by minimizing the user's concern about the chain they are on", which accurately describes the core principles that chain abstraction service providers are currently building around. Connext provides a set of smart contract modules for application developers through its Chain Abstraction Toolkit, the core function of which is xCall, a basic function that allows smart contracts to interact with each other in different environments. The xCall function can initiate funds, calldata and/or various cross-chain transfers, which the Chain Abstraction Toolkit encapsulates as simple logic for developers to use. Socket Protocol Socket Protocol provides infrastructure for application developers to build interoperability-centric products and services to achieve secure and efficient cross-chain data and asset transfers. Socket 2.0 marks the protocol’s shift from cross-chain services to chain abstraction services, highlighted by its flagship product, the Modular Order Flow Auction (MOFA) mechanism. The mechanism is designed to provide a competitive mechanism for an efficient chain abstraction market. Traditional OFA involves a network of various participants performing specialized tasks that compete to provide the best results for end-user requests. Similarly, MOFA aims to provide an open market for execution agents, called “Transmitters,” and user intent. In MOFA, Transmitters compete to create and complete chain abstraction bundles, or an ordered sequence of user requests that require the transfer of data and value between multiple blockchains. Infinex Infinex is building a single user experience layer designed to unify decentralized applications and ecosystems. Its flagship product, Infinex Account, is a multi-layered service that serves as a platform to integrate any on-chain application into a simplified user experience for end users. At the core of the Infinex Account is a set of cross-chain smart contracts that can be controlled, protected, and recovered through standard Web2 authentication.Brahma Console Brahma Finance is building its flagship product, Console, an on-chain execution and custody environment designed to enhance the DeFi user experience, with a particular focus on the EVM blockchain ecosystem. Brahma uses batched and chained transactions to synchronize transactions on different chains, and smart accounts for on-chain interactions. The end result is seamless cross-chain interaction within a single user interface. Agoric Agoric is a native L1 of Cosmos designed as an asynchronous, multi-block execution environment, and aims to be the preferred environment for developing cross-chain applications. Agoric leverages the Cosmos IBC protocol for inter-chain communication, while leveraging Axelar’s Generalized Messaging (GMP) for interactions outside of the Cosmos ecosystem. By abstracting the complexities involved in cross-chain communication and smart contract execution, Agoric’s coordination application interface (API) simplifies the developer experience, while end users benefit from applications with inherent chain abstraction capabilities.
Summarize
Having written so much, I think the advantages that chain abstraction brings to end users should be obvious. The complexity of using blockchain-native applications will be completely abstracted into a unified interface layer, creating a global, chain-free touchpoint for any user who wants to participate. Equally important, chain abstraction can bring huge benefits to blockchain applications. Currently, Web2 developers do not need to "choose" where to deploy their applications. For example, anyone can use Airbnb as long as they have an Internet connection. However, in the Web3 environment, developers need to choose the deployment environment of their applications (for example, on Ethereum, Solana, or Cosmos). This not only limits the TAM (Technology Acceptance Model), but also means that developers need to choose the "right" chain to deploy. This choice is difficult but critical. Some applications are excellent in their own right, but they are troubled by the underlying blockchain. In addition, as the blockchain industry continues to grow and evolve, the so-called "right" chain may also continue to change. In the future of chain abstraction, application developers no longer need to choose a chain that is closely related to their success. It is clear that we are heading towards a multi-chain future, which will inevitably exacerbate user experience problems and hinder mainstream applications. We believe that chain abstraction and its various components are a viable solution to the user experience problems of today's cryptocurrency.
Author: TechubNews; from the ChainDD content open platform "DeDeHao", this article only represents the author's point of view, not the official position of ChainDD. For all "DeDeHao" articles, the originality and authenticity of the content are guaranteed by the contributors. If the article is plagiarized, falsified, etc., the legal consequences will be borne by the contributors themselves. If there are any infringements, violations, or other inappropriate remarks on the DeDeHao platform, please supervise the readers. Once confirmed, the platform will be offline immediately. If you encounter any problems with the content of the article, please contact WeChat: chaindd123
