This article introduces the Chain Abstraction Key Elements (CAKE) framework.

Author: Favorite Mirror Reads Archive

Compiled by: Deep Tide TechFlow

Key Points Summary

• The current default encrypted user experience is to let users always know which network they are interacting with. However, internet users do not need to know which cloud provider they are interacting with. Introducing this approach to blockchain is what we call Chain Abstraction.

• This article introduces the Chain Abstraction Key Elements (CAKE) framework. The framework consists of application layer, permission layer, solver layer, and settlement layer, aiming to provide users with a seamless cross-chain operation experience.

• Implementing chain abstraction requires a set of complex technologies to ensure reliability, cost-effectiveness, security, speed, and privacy of the execution process.

• We define the cross-chain trade-offs in chain abstraction as a trilemma and propose six design schemes, each with its unique advantages.

• In order to successfully make a leap towards the future of chain abstraction, as an industry, we must define and adopt a common standard for information transmission between the layers of CAKE. A good standard is the icing on the cake.

Introduction

In 2020, the Ethereum network transitioned to a rollup-centric expansion roadmap. Four years later, there are over 50 rollup layers (L2) in use. While the rollup layer provides the necessary horizontal expansion, it completely disrupts the user experience.

Users should not care or know which rollup they are interacting with. Encrypted users know which rollup they are using (Optimism or Base), similar to Web2 users knowing which cloud provider they are using (AWS or GCP). The vision of Chain Abstraction is to abstract chain information from the user's perspective. Users only need to connect their wallets to the dApp and sign the expected operation, ensuring that the details of having the correct balance on the target chain and executing the expected operation are handled behind the scenes.

In this article, we will explore that chain abstraction is a truly interdisciplinary problem, involving the interaction of the application layer, permission layer, solver layer, and settlement layer. We introduce the Chain Abstraction Key Elements (CAKE) framework and delve into the design trade-offs of the chain abstraction system.

Introducing the CAKE Framework

In the world of chain abstraction, users access dApp websites, connect wallets, sign operations, and wait for final settlement. All complex operations are completed in the infrastructure layer of CAKE. The three infrastructure layers of CAKE include:

1. Permission Layer: Users connect their wallets to dApps and request quotes for user intent. Intent refers to the result the user expects at the end of the transaction, rather than the transaction path. For example, transferring USDT to a Tron address or depositing USDC into a yield-generating strategy on Arbitrum. Wallets should be able to read user assets (i.e., read state) and execute transactions on the target chain (i.e., update state).

2. Solver Layer: The solver layer estimates costs and execution speed based on the user's initial balance and intent. In cross-chain settings, this process is called solving and is crucial because transactions are asynchronous, and sub-transactions may fail during execution. Asynchrony introduces a cross-chain trilemma involving cost, execution speed, and execution guarantee.

3. Settlement Layer: After the user approves the transaction with their private key, the settlement layer ensures its execution. This includes two steps: bridging the user's assets to the target chain and then executing the transaction. If a protocol uses a complex solver for certain operations, they can provide their own liquidity and execute operations on behalf of the user without bridging.

Implementing chain abstraction means merging the three infrastructure layers into a unified product. A key insight in merging these layers is the distinction between information transmission and value transmission. Inter-chain information transmission should be lossless, thus relying on the most secure path. For example, when a user votes "in favor" in a governance vote on one chain to another, they do not want their vote to become "maybe." On the other hand, value transmission may have some loss based on user preferences. A mature third party can be used to provide faster, cheaper, or guaranteed value transmission for users. It is important to note that, measured by fees paid to validators, 95% of Ethereum block space is used for value transmission.

Key Design Decisions

The three layers mentioned above introduce key design decisions that CAKE needs to make. These decisions involve who controls the power to execute intent, what information is disclosed to the solver, and what settlement paths are available for the solver to use. The following is a detailed analysis of each layer.

Permission Layer

The permission layer holds the user's private key and signs messages on behalf of the user, which are then executed on the chain as transactions. CAKE needs to support signature schemes and transaction payloads for all target chains. For example, a wallet supporting the ECDSA signature scheme and EVM transaction standard will be limited to Ethereum, its L2, and sidechains (such as the Metamask wallet). On the other hand, a wallet supporting EVM and SVM (Solana VM) will be able to support both ecosystems (such as the Phantom wallet). It is important to note that the same mnemonic can be used to generate wallets on both EVM and SVM chains.

A multi-chain transaction consists of multiple sub-transactions that need to be executed in the correct order. These sub-transactions must be executed on multiple chains, each with its own time-varying costs and random numbers. Coordinating and settling these sub-transactions is a key design decision for the permission layer.

1. EOA wallets are wallet software running on the user's machine and holding their private key. They can be browser-based extensions (such as Metamask and Phantom), mobile applications (such as Coinbase Wallet), or dedicated hardware (such as Ledger). EOA wallets require users to individually sign each sub-transaction, currently requiring multiple clicks. They also require users to hold fee balances on the target chain, introducing significant friction in this process. However, by allowing users to sign multiple sub-transactions with a single click, the friction of multiple clicks can be abstracted from the user.

2. In Account Abstraction (AA) wallets, users still have access to their private keys, but they separate the signer of the transaction payload from the executor of the transaction. This allows complex parties to bundle and execute user transactions atomically (Avocado, Pimlico). AA wallets still require users to individually sign each sub-transaction (currently through multiple clicks), but do not require holding fee balances on each chain.

3. Policy-based proxies store the user's private key in a separate execution environment and generate signed messages on behalf of the user based on user policies. Telegram bots, near-account aggregators, or SUAVE TEE are policy-based wallets, while Entropy or Capsule are policy-based wallet extensions. Users only need to sign an approval, and subsequent sub-transaction and fee management signatures can be handled by these proxies during the operation.

Solver Layer

After the user submits their intent, the solver layer involves returning fees and confirmation time to the user. This issue is closely related to the design of order flow auctions, which is discussed in detail here. CAF can execute user intent using paths within the protocol, or compromise on certain security guarantees by using a complex third party (i.e., solver) to provide an improved user experience. Introducing a solver to the CAF framework will lead to the next two design decisions, which are closely related to information sharing.

Intent consists of two types of extractable values (EV): EV_ordering values and EV_signal.

• EV_ordering is a value specific to the blockchain, typically extracted by the entity executing user orders (such as block builders or validators).

• EV_signal represents the value that any entity complying with the order before it is formally recorded on the blockchain can access.

Different user intents have different distributions between EV_ordering and EV_signal. For example, intents to swap coins on a DEX typically have a higher EV_ordering value but a lower EV_signal value. Conversely, the EV_signal component of front-running transactions will be higher, as front-running can capture more value than executing the transaction. It is worth noting that EV_signal can sometimes be negative, for example in the case of market maker trades, where the entity executing these orders may suffer losses due to having a better understanding of future market conditions.

When someone can observe a user's intent in advance, they can front-run, leading to value leakage. Additionally, the possibility of EV_signal being negative can create a competitive environment among solvers, leading them to submit lower bids, causing further value leakage (also known as adverse selection). Ultimately, leakage affects users by increasing fees or offering more favorable prices. It is important to note that low fees or higher prices are two sides of the same coin, and will be used interchangeably in the rest of this article.

Information Sharing

There are three ways to share information with solvers:

1. Public Mempool: User intent is publicly broadcast to a public mempool or data availability layer, and the first solver that can fulfill the request executes the order and becomes the winner. This system extracts a high amount of user information, as users publicly disclose their EV_ordering and EV_signal. Examples include Ethereum's public mempool and various blockchain bridges. In the case of bridges, users must place their assets in custody before transferring them to the target chain to prevent malicious attacks, inadvertently disclosing their intent in the process.

2. Partial Sharing: CAF can reduce the amount of value revealed to bidders by limiting the disclosed information. However, this approach directly leads to the loss of price optimality and may lead to issues such as bid spam.

3. Private Mempool: The latest developments in MPC and TEE make it possible to have a completely private mempool. No information is leaked outside the execution environment, and solvers encode their preferences and match them with each intent. While a private mempool captures EV_ordering, it cannot fully capture EV_signal. For example, if a front-running transaction is sent to the mempool, the first person to see the order can front-run and capture EV_signal. In a private mempool, information is only released after block confirmation, so anyone who sees the transaction can capture EV_signal. It can be imagined that solvers will establish authentication nodes to capture EV_signal from TEE-forged blocks, turning EV_signal capture into a delayed competition.

Solver List

CAF also needs to decide how many and which bidders to allow to participate in the auction. The main options are as follows:

1. Open Access: The barrier to entry for participation is kept as low as possible. This is similar to a public mempool, leaking EV_signal and EV_ordering.

2. Restricted Access: Control over the ability to execute orders is achieved through whitelists, reputation systems, fees, or seat auctions. The control mechanism needs to ensure that solvers in the system do not capture EV_signal. Examples include 1inch Auction, Cowswap Auctions, and Uniswap X Auctions. The competition for winning orders captures EV_ordering for users, while the control mechanism can capture EV_signal for order generators (wallets, dApps).

3. Exclusive Access: Exclusive access is a special form of auction where only one solver is chosen at a time. Since no information is leaked to other solvers, there is no adverse selection or front-running. The order initiator captures the expected values of EV_signal and EV_ordering, as there is no competition, and users can only get execution without price improvement. Examples of such auctions include Robinhood and DFlow auctions.

Settlement Layer

Once a wallet signs a set of transactions, they need to be executed on the blockchain. Cross-chain transactions transform the settlement process from atomic to asynchronous operations. During initial transaction execution and confirmation, the state on the target chain may change, potentially leading to transaction failures. This section will explore the trade-offs between security costs, confirmation time, and execution guarantees.

It is important to note that the execution of expected transactions on the target chain depends on the target chain's transaction inclusion mechanism, including the ability to review transactions and the fee mechanism of the target chain, among other factors. We believe the choice of the target chain is a decision for the dApp, beyond the scope of this article.

Cross-Chain Oracle

Two blockchains with different states and consensus mechanisms require an intermediary, such as an oracle, to facilitate the transfer of information between them. Oracles act as relays for inter-chain information transfer, including verifying locked funds in custody accounts on the original chain and minting tokens for users on the target chain, or confirming token balances on the original chain for participation in governance votes on the target chain.

Oracles transmit information at the speed of the slowest chain, which is to manage reorganization risk, as oracles need to wait for consensus on the original chain. For example, if a user wants to bridge USDC from the original chain to the target chain, they lock their funds in custody for this purpose. However, if the oracle does not wait for sufficient confirmations and continues to mint tokens for the user on the target chain, problems may arise. If a reorganization occurs, the user's custody transaction is overwritten, leading to double spending.

There are two types of oracles:

1. Off-Chain Oracles: These need to be separate from third-party validators running consensus to transfer information between chains. Additional validators increase the cost of running the oracle. Examples of off-chain oracles include LayerZero, Wormhole, ChainLink, and the Axelar network.

2. On-Chain Oracles: Deeply integrated into the ecosystem's consensus algorithm and use a set of validators running consensus to transfer information. Cosmos's IBC is used for chains running the Cosmos SDK, the Polygon ecosystem is developing AggLayer, and Optimism is developing Superchain. Each oracle uses dedicated block space to transfer information between chains within the same ecosystem.

3. Shared Sorters as Off-Chain Entities have transaction sorting rights within the protocol and can bundle transactions across chains. While still in development, shared sorters do not need to wait for specific block confirmations to reduce reorganization risk. To truly achieve cross-chain atomicity, shared sorters need to be able to execute subsequent transactions, conditioned on the success of early transactions, turning them into chain chains.

Token Bridging

In the multi-chain world, users' token and fee balances are dispersed across all networks. Before each cross-chain operation, users need to bridge their funds from the original chain to the target chain. Currently, there are 34 active cross-chain bridges, with a total TVL of $7.7 billion and a bridging volume of $8.6 billion in the past 30 days.

Token bridging is a case of value transfer. This creates an opportunity for professional third parties skilled in capital management and willing to take on reorganization risk, reducing the costs and time required for user transactions.

There are two types of cross-chain bridges:

1. Lock and Mint Bridges: These bridges verify token deposits on the original chain and mint tokens on the target chain. While the capital required to launch these bridges is relatively small, a significant investment is needed for secure transfer of locking information. Security vulnerabilities in these bridges have led to losses of billions of dollars for token holders (source).

2. Liquidity Bridges: Liquidity bridges utilize liquidity pools on the original and target chains and use algorithms to determine the conversion rate between tokens on the original and target chains. While the initial cost of these bridges is higher, they require lower security guarantees. If a security vulnerability occurs, only the funds in the liquidity pool are at risk.

In both types of cross-chain bridges, users need to pay liquidity costs. In lock and mint bridges, liquidity costs occur when swapping wrapped tokens for the desired tokens (e.g., from USDC.e to USDC) on the target chain, while in liquidity bridges, liquidity costs occur when swapping tokens from the original chain for tokens on the target chain.

The Cross-Chain Trilemma

The five design decisions mentioned above lead to the cross-chain trilemma. CAF must choose two attributes between execution guarantees, low fees, and execution speed.

1. In-Protocol Paths: These are specified cross-chain information transfer paths. These systems sacrifice execution speed in consideration of reorganization risk, but reduce costs by eliminating additional validator sets or liquidity costs.

2. Solver Aggregation: Collecting quotes from multiple solvers to identify the cheapest and fastest path to execute user intent. However, due to adverse selection and front-running, solvers may sometimes fail to fulfill the intent, leading to reduced execution.

3. Execution Competition: Selecting the winning solver by arranging solver races to execute intent or choosing a single solver. Both approaches result in high user fees, as solvers compete for execution rather than price improvement.

Six Components of CAKE

To write this article, we researched over 20 teams directly and indirectly committed to chain abstraction design. In this section, we discuss six independent CA implementations that we believe have inherent efficiency and product-market fit. If built correctly, these designs have the potential to complement each other.

A key conclusion is that we need a unified standard for expressing cross-chain intent. Each team is researching its own methods and protocols to encode user intent. A unified standard will improve user understanding of their signed messages, making it easier for solvers and oracles to understand these intents and simplify integration with wallets.

| Name | Purpose | Example | Wallet | Information Sharing | Solver List | Oracle | Token Bridging | | ---- | ------- | ------- | ------ | ------------------- | ----------- | ------ | --------------- | | Token Specified Bridge | Cheap cross-chain transfers | CCTP, CCIP, xERC20 | Any | Public | Depends on implementation | In-protocol | Lock and Mint | | Ecosystem Coordinated Bridge | Cross-chain message calls | AggLayer, Superchain, IBC | Any | Public | Depends on implementation | In-protocol | Lock and Mint | | Solver Price Competition | Cheap cross-chain swaps | Bungee, Jumper, Uniswap X | Depends on implementation | Depends on implementation | Controlled access | Off-chain | Liquidity | | Wallet Coordinated Messages | Cross-chain message calls | Alfred, Avocado, Near Account | AA or strategy-based | Depends on implementation | Depends on implementation | Off-chain | Depends on implementation | | Solver Speed Competition | Fast cross-chain transfers | Across, Orbiter | Any | All or none | Depends on implementation | Off-chain | Liquidity | | Exclusive Batch Auction | Cross-chain message calls | NA | Any | None | Exclusive | Off-chain | Liquidity |

Token Specified Bridge

There is a special case of lock and mint bridges that do not incur liquidity costs, also known as the lock and mint bridge (e.g., USDC CCTP). Token teams specify a canonical token address on each chain, and the bridge is authorized to mint tokens, i.e., the tokens needed by users.

Upon closer observation, you will find that the lock and mint bridge is similar to cross-chain transfers conducted with sufficient block confirmation speed. xERC20 is such a standard used to specify canonical tokens and authorize bridges on the target chain. The token specified bridge is an example of an in-protocol path, sacrificing speed for execution guarantees and low fees, for example, CCTP takes 20 minutes to complete a transfer.

Ecosystem Coordinated Bridge

The ecosystem coordinated bridge allows arbitrary messages to be transferred between chains within the same ecosystem. These bridges are in-protocol paths prioritizing execution guarantees and low fees over speed. Examples include Cosmos IBC, Polygon AggLayer, and Optimism Superchain.

Three years ago, the Cosmos ecosystem faced challenges similar to what Ethereum faces today. Liquidity was dispersed across chains, each chain had its own fee token, and managing multi-chain accounts was very cumbersome. The Cosmos ecosystem solved these issues by implementing the IBC in-protocol message transfer bridge, achieving seamless multi-chain account management and cross-chain transfers.

The Cosmos ecosystem consists of sovereign chains with strong security and fast finality, making in-protocol cross-chain message transfer very fast. In contrast, the rollup ecosystem relies on challenge period endings (Optimistic Rollups) or submission of zk-proofs (Validium Rollups) to achieve finality. Due to these finality constraints, the speed of cross-ecosystem message transfer is slower.

Solver Price Competition

Solver price competition involves sharing order information with all solvers. Solvers aim to aggregate the expected value (EV) generated by order intent and offer it to users. The selection of the winning solver in the system is based on maximizing user price improvement. However, this design carries the risk of non-execution, requiring additional mechanisms to ensure the reliability of orders. Examples of such mechanisms include Uniswap X, Bungee, and Jumper.

Wallet Coordinated Messages

Wallet coordinated messages utilize the functionality provided by AA or strategy-based wallets to offer a cross-chain experience compatible with any intent type. It serves as the ultimate CA aggregator, redirecting user intent across various CA designs to address specific intents. Examples include Avocado wallet, Near Account Aggregator, and Metamask Portfolio.

It is worth noting that over the past decade, the crypto ecosystem has realized that the relationship between users and their wallets is very sticky. Every time I think about migrating my mnemonic from Metamask to another wallet, I feel extremely fearful. This is also why, even with the support of Vitalik Buterin himself, EIP-4337 still has a low adoption rate after 2.5 years. While newer wallet protocol versions may offer better pricing (account abstraction) or improved usability (strategy-based wallets) for users, migrating users from their current wallets is a daunting task.

Solver Speed Competition

Solver speed competition allows users to express intent for specific cross-chain conversions to obtain high execution guarantees. It does not help users minimize costs, but provides a reliable channel to include complex transactions. The first solver to execute the intent based on block builder fees or inclusion speed will win.

The design aims to achieve high inclusion rates by maximizing the EV captured by solvers. However, this comes with a centralized cost as it relies on complex capital management on the Ethereum mainnet or low-latency execution on Layer 2.

Exclusive Batch Auction

The exclusive batch auction holds an auction for the exclusive right to execute all order flows within a time window. Since other solvers cannot see the orders, they bid based on predicted market fluctuations and average execution quality. The exclusive batch auction relies on a reserve price to ensure good user pricing and therefore cannot be used for price improvement. Sending all order flows to a single bidder eliminates information leakage and improves execution guarantees.

Conclusion

The Chain Abstraction Framework (CAF) is committed to providing seamless cross-chain interactions for users. In this article, we have studied several designs that are in production or development, from teams explicitly or implicitly attempting to address the chain abstraction problem. We believe this year will be the year of CAF, and significant competition is expected between different designs and their implementations in the next 6-12 months.

Cross-chain value transfer will be achieved through token-authorized bridging for low fees, and fast execution will be achieved through solver speed or price competition. Information transfer will be routed through message bridging matched with the ecosystem, aiming to minimize user costs, and maximized speed through wallet-controlled platforms. Ultimately, these six different design approaches will form a cluster as they each cater to different needs and leverage efficiency in different areas of the trade-off matrix.

An important conclusion we have drawn from this process is the need for a universal standard to express cross-chain intent. Currently, multiple teams are independently researching protocols for encoding user intent, leading to duplicated work. A unified standard will help improve user understanding of their signed messages, facilitate solvers and oracles in handling intent, and simplify integration with wallets.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。