Using a cake candle diagram, I will show you the key to chain abstraction

Original title: Introducing the CAKE framework

Original author: Ankit Chiplunkar, Stephane Gosselin, Frontier Research
Original translation: Deep Tide TechFlow

Key points

· The current default crypto user experience is for users to 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 paper introduces the Chain Abstraction Key Elements (CAKE) framework. The framework consists of four parts: application layer, permission layer, solver layer, and settlement layer, and is designed to provide users with a seamless cross-chain operation experience.

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

· We define the cross-chain tradeoff in chain abstraction as a trilemma and propose six design solutions, each with its own unique advantages.

· To successfully make the leap to a chain-abstract future, as an industry we must define and adopt a common standard for information passing between CAKE layers. A good standard is icing on the cake.

Introduction

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

Users should not care or understand which rollup they are interacting with. Crypto users know which rollup they are using (Optimism or Base) in the same way that Web2 users know which cloud provider they are using (AWS or GCP). The vision of Chain Abstraction is to abstract chain information from the user's view. Users only need to connect their wallet to the dApp and sign the intended action, and the details of ensuring that the user has the correct balance on the target chain and performs the intended action are all handled behind the scenes.

In this article, we will explore that chain abstraction is a truly multidisciplinary 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 chain abstraction systems.

Introduction to CAKE Framework

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

1. Permission layer:Users connect their wallets to the dApp and request quotes for user intents. Intent refers to the result that users expect to get at the end of the transaction, not the transaction path. For example, transferring USDT to a Tron address or depositing USDC into a yield-generating strategy on Arbitrum. The wallet 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 fees and execution speed based on the user's initial balance and intent. In a cross-chain setting, this process, called solving, is crucial because transactions are asynchronous and sub-transactions may fail during execution. Asynchronicity introduces the cross-chain trilemma, which involves fees, execution speed, and execution guarantees.

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

Achieving chain abstraction means merging the three infrastructure layers mentioned above into a unified product.A key insight in merging these layers is the difference between information transfer and value transfer. Information transfer between chains should be lossless, so it needs to rely on the safest path. For example, users vote "yes" from one chain to a governance vote on another chain, and they don't want their vote to become "maybe". On the other hand, value transfer may be lost depending on user preferences. An established third party can be leveraged to provide users with faster, cheaper, or guaranteed value transfer. It is important to note that 95% of Ethereum block space is used for value transfer, measured in fees paid to validators.

Key Design Decisions

The above three levels introduce key design decisions that CAF needs to make. These decisions involve who controls the power to execute intent, what information is disclosed to solvers, and what settlement paths are available to solvers. Below is a detailed analysis of each level.

Permission Layer

The permission layer holds the user's private keys and signs messages on their behalf, which are then executed as transactions on-chain. CAF needs to support signature schemes and transaction payloads for all target chains. For example, wallets that support 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, wallets that support 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 the 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 fees and random numbers. How these sub-transactions are coordinated and settled is a key design decision for the permission layer.

1.EOA wallets are wallet software that runs on the user's machine and holds their private keys. 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 sign each sub-transaction individually, which currently requires multiple clicks. They also require users to hold a fee balance on the target chain, which introduces significant friction in the process. However, by allowing users to sign multiple sub-transactions with a single click, the friction of multiple clicks can be abstracted away 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. Enable complex parties to bundle and execute user transactions in an atomic manner (Avocado, Pimlico). AA wallets still require users to sign each sub-transaction individually (currently through multiple clicks), but do not require holding a fee balance on each chain.

3.Policy-based agents hold the user's private key in a separate execution environment and generate signed messages on behalf of the user based on the user's policy. Telegram bots, near account aggregators or SUAVE TEE are policy-based wallets, while Entropy or Capsule are policy-based wallet extensions. The user only needs to sign an approval letter, and the subsequent signing of sub-transactions and fee management can be completed by these agents during the operation.

Solver Layer

After a user posts an intent, the solver layer involves returning fees and confirmation times to the user. This problem is closely related to designing order flow auctions, which is discussed in detail here. CAF can leverage an in-protocol path to enforce user intent, or leverage a complex third party (i.e., solver) to compromise on certain security guarantees and provide an improved user experience to users. Introducing solvers into the CAF framework leads to the next two design decisions, which are closely related to information.

Intents consist of two types of extractable values (EVs): EV_ordering values and EV_signal.

· EV_ordering is a blockchain-specific value that is typically extracted by entities that execute user orders, such as block builders or validators.

· EV_signal represents the value that is accessible to any entity that complies with an order before it is formally recorded on the blockchain.

Different user intentions have different distributions between EV_ordering and EV_signal. For example, the intention to swap coins on a DEX typically has a high EV_ordering value, but a low EV_signal value. Conversely, hacker trades will have a higher EV_signal component because front-running will gain more value than executing the trade. It is worth noting that EV_signal can sometimes be negative, such as in the case of market maker trades, where entities that execute these orders may suffer losses because market makers have a better understanding of future market conditions.

When someone is able to observe a user's intention in advance, they can front-run, resulting in value leakage. Additionally, the possibility of a negative EV_signal creates a competitive environment among solvers, causing them to submit lower bids, creating further value leakage (aka adverse selection). Ultimately, leakage affects users by increasing fees or offering better prices. Note that low fees or increasing 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 Memory Pool:User intent is publicly broadcast to a public mempool or data availability layer, and the first solver that can satisfy the request executes the order and becomes the winner. This system highly extracts user information because users disclose their EV_ordering and EV_signal. For example, Ethereum's public mempool and various blockchain bridges. In the case of bridges, users must place their assets in escrow before transferring them to the target chain to prevent malicious attacks, but this process inadvertently discloses their intent.

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

3. Private Memory Pool:Recent developments in MPC and TEE make fully private mempools possible. No information is leaked outside the execution environment, and solvers encode their preferences and match each intent. Although private mempools capture EV_ordering, they cannot fully capture EV_signal. For example, if a hacker transaction is sent to the mempool, the first person to see the order can preemptively trade and capture the EV_signal. In a private mempool, information is not released until the block is confirmed, so anyone who sees the transaction can capture the EV_signal. It is conceivable that solvers will set up certification nodes to capture EV_signal from newly minted blocks from the TEE, turning EV_signal capture into a delayed competition.

List of Solvers

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 the ability to participate is as low as possible. This is similar to a public mempool, leaking EV_signal and EV_ordering.

2. Restricted Access:Gating of order execution capabilities through whitelists, reputation systems, fees, or seat auctions. The gating mechanism needs to ensure that solvers in the system do not capture EV_signal. Examples include 1inch Auction, Cowswap Auctions, and Uniswap X Auctions. Competition for order winning captures EV_ordering for users, while gating mechanisms 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 selected per time slot. Since no information is leaked to other solvers, there is no adverse selection and no front-running discounts. The order flow initiator captures the expected value of EV_signal and EV_ordering, and since there is no competition, users only get execution but no price improvement. Examples of this type of auction are Robinhood and DFlow auctions.

Settlement Layer

Once a wallet has signed a set of transactions, they need to be executed on the blockchain. Cross-chain transactions transform the settlement process from an atomic operation to an asynchronous operation. During the initial transaction execution and confirmation, the state on the target chain may change, which may cause the transaction to fail. This subsection explores the trade-offs between security cost, confirmation time, and execution guarantees.

It is important to note that the execution of the intended transaction on the target chain depends on the transaction inclusion mechanism of the target chain, including factors such as being able to review transactions and the fee mechanism of the target chain. We believe that the choice of target chain is a dApp decision and 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. The oracle acts as a relay for information transfer between chains, including verifying that users have locked funds in escrow accounts in the locking and minting bridge, or confirming users' token balances on the original chain to participate in governance voting on the target chain.

Oracles relay information at the speed of the slowest chain, this is to manage the risk of reorganization, as the oracle needs to wait for consensus on the source chain. Let’s say a user wants to bridge USDC from the source chain to the target chain, and to do this the user locks their funds in escrow. However, problems can arise if the oracle does not wait for enough confirmations and continues to mint tokens for the user on the target chain. If a reorganization occurs, the user overwrites their escrow transaction and the oracle causes a double spend.

There are two types of oracles:

1. Out-of-protocol oracles:Need to be separate from the third-party validators running consensus to relay information between chains. Additional validators increase the cost of running an oracle. LayerZero, Wormhole, ChainLink, and Axelar Network are examples of out-of-protocol oracles.

2. In-protocol oracles:Deeply integrated into the consensus algorithm of the ecosystem and use the set of validators running consensus to relay information. Cosmos’ IBC is used on chains running the Cosmos SDK, the Polygon ecosystem is developing AggLayer, and Optimism is developing Superchain. Each oracle uses dedicated block space to pass information between chains in the same ecosystem.

3. Shared sorters are extra-protocol entities that have transaction sorting rights within the protocol, i.e. they can bundle transactions across chains. Although still under development, shared sorters do not have 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 conditional on the success of earlier transactions, thereby turning them into inter-chain atomicity.

Bridge Tokens

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

Bridge tokens are a case of value transfer. This creates an opportunity to leverage professional third parties who are good at capital management and willing to bear the risk of restructuring, reducing the cost and time required for users to trade.

There are two types of cross-chain bridges:

1. Lock and Mint Bridges: Lock and Mint Bridges verify token deposits on the source chain and mint tokens on the target chain. The capital required to launch such bridges is small, but the secure transfer of lock information requires a large investment. Security vulnerabilities in these bridges have led to billions of dollars in losses for token holders.

2. Liquidity Bridge: Liquidity bridges utilize liquidity pools on the source and target chains and use an algorithm to determine the conversion rate between the source and target tokens. While these bridges have a higher initial cost, they require lower security guarantees. In the event of a security breach, only the funds in the liquidity pool are at risk.

In both types of cross-chain bridges, users pay liquidity costs. In the locking and minting bridges, the liquidity cost is incurred when swapping from the wrapped token to the desired token (USDC.e to USDC) on the target chain, while in the liquidity bridges, the liquidity cost is incurred when swapping from the token on the source chain to the token on the target chain.

Cross-Chain Trilemma

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

1. In-protocol path: is a designated path for cross-chain information transmission. These systems take into account the risk of reorganization, sacrificing execution speed, but reducing costs by eliminating additional validator sets or liquidity costs.

2. Solver aggregation:Collect quotes from multiple solvers to identify the cheapest and fastest path to execute user intent. However, due to adverse selection and front-running, sometimes a solver may not be able to meet the intent, resulting in reduced execution.

3. Execution competition:Selecting the winning solver by arranging solvers to race to execute the intent or selecting a single solver. Both methods result in high user fees as solvers compete for execution rather than price improvement.

Six Components of CAKE

To write this article, we looked at over 20 designs from teams working directly and indirectly on chain abstraction. In this section, we discuss six independent CA implementations that we believe have inherent efficiency and product-market fit. These designs have the potential to be combined with each other if built correctly.

A key conclusion is that we need a unified standard for expressing intent across chains. Each team is working on their own methods and protocols to encode user intent. A unified standard would improve users’ understanding of their signed messages, make it easier for solvers and oracles to understand these intents, and simplify integration with wallets.

Token Designated Bridges

There is a special case of a lock and mint bridge that does not pay liquidity costs, also known as a burn and mint bridge (e.g. USDC CCTP). The token team specifies a canonical token address on each chain, and the bridge has the authority to mint tokens, i.e., the tokens that users need.

If you look closely, you will find that burning and minting bridges is similar to cross-chain transfers that are made with sufficient block confirmation speed. xERC20 is such a standard for specifying canonical tokens and their authorized bridges on the target chain. Token-specified bridges are an example of an intra-protocol path, i.e., it sacrifices speed for guaranteed execution and low fees, e.g., CCTP takes 20 minutes to complete a transfer.

Ecosystem Coordination Bridges

Ecosystem Coordination Bridgescan transfer arbitrary messages between chains within the same ecosystem. This type of bridge is an intra-protocol path that prioritizes 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 is scattered across chains, each with its own fee token, and managing multi-chain accounts is cumbersome. The Cosmos ecosystem solves these problems by implementing an IBC in-protocol messaging bridge, enabling seamless multi-chain account management and cross-chain transfers.

The Cosmos ecosystem consists of independent chains that have sovereign security and fast finality, making cross-chain messaging within the protocol very fast. The rollup ecosystem relies on the end of the challenge period (optimistic Rollups) or the submission of zk proofs (validity Rollups) to achieve finality. Due to these finality restrictions, messaging across the ecosystem will be slower.

Solver Price Competition

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

Wallet Reconciliation Messages

Wallet Reconciliation Messages leverages the capabilities provided by AA or policy-based wallets to provide a cross-chain experience compatible with any intent type. It acts as the ultimate CA aggregator, redirecting user intent between various CA designs to solve specific intents. Examples include Avocado Wallet, Near Account Aggregator, and Metamask Portfolio.

It is important to note that over the past decade, the crypto ecosystem has learned that the relationship between users and their wallets is extremely sticky. I feel extreme fear every time I think about migrating my mnemonic from Metamask to another wallet. This is also why EIP-4337 has low adoption after 2.5 years, even with the support of Vitalik Buterin himself. Although newer wallet protocol versions may provide users with better prices (account abstraction) or improved ease of use (policy-based wallets), migrating users from current wallets is a difficult 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 fees, but provides a reliable channel to include complex transactions. The first Solver to execute intent based on block builder fees or include speed will win that intent.

The design aims to achieve high inclusion rates by maximizing the EV captured by the Solver. However, this comes at the cost of centralization as it relies on either complex capital management on the Ethereum mainnet or low-latency execution on L2.

Exclusive Batch Auctions

Exclusive Batch Auctionshold auctions for the exclusive right to execute all order flow within a time window. Since other solvers cannot see the orders, they bid based on predicted market volatility and average execution quality. Exclusive Batch Auctions rely on a fallback price to ensure a good user price and therefore cannot be used for price improvement. Sending all order flow to a single bidder eliminates information leakage and improves execution guarantees.

Conclusion

The Chain Abstraction Framework (CAF) promises to provide users with seamless cross-chain interactions. In this article, we looked at several designs in production and development by teams that are explicitly or implicitly trying to solve the chain abstraction problem. We believe this will be the year of the CAF and expect significant competition between different designs and their implementations over the next 6-12 months.

Cross-chain value transfers will be achieved through token-authorized bridges for low fees and solver speed or price competition for fast execution. Information transfers will be routed through ecosystem-matched message bridges designed to minimize user costs and wallet-controlled platforms to maximize speed. Ultimately, these six different design proposals will form a cluster because they each address different needs and exploit efficiencies in different areas of the trade-off matrix.

An important conclusion we draw from this process is that we need a common standard for expressing cross-chain intent. Currently, multiple teams are working on their own protocols for encoding user intent, resulting in duplication of work. Unifying standards will help improve users’ understanding of signed messages, make it easier for solvers and oracles to handle intent, and simplify integration with wallets.

Original link