Original author: Favorite Mirror Reads Archive
Original translation: TechFlow
Summary of key points
The default crypto user experience today 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. Bringing this approach to blockchain is what we call Chain Abstraction.
This article introduces the Chain Abstraction Key Elements (CAKE) framework. The framework consists of four parts: application layer, permission layer, solver layer, and settlement layer, and aims to provide users with a seamless cross-chain operation experience.
Achieving 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 chained abstract future, we as an industry must define and adopt a common standard for messaging 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 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 away from the user's view. Users simply 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 explore how chain abstraction is a truly multidisciplinary problem involving the interactions of the application layer, the permission layer, the solver layer, and the settlement layer. We introduce the Chain Abstraction Key Elements (CAKE) framework and delve into the design tradeoffs of chain abstraction systems.
Introducing the 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. CAKE's three infrastructure layers include:
Permission layer: Users connect their wallet to the dApp and request a quote for the user’s intent. The intent refers to the outcome the user expects 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).
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 is called solving and is critical because transactions are asynchronous and sub-transactions may fail during execution. Asynchrony introduces the cross-chain trilemma involving fees, execution speed, and execution guarantees.
Settlement layer: After the user approves the transaction with a private key, the settlement layer ensures its execution. It includes two steps: bridging the user's assets to the target chain and then executing the transaction. If the protocol uses complex solvers for certain operations, they can provide their own liquidity and execute operations on behalf of users without the need for bridging.
Achieving chain abstraction means merging the three infrastructure layers 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 and therefore rely on the most secure path. For example, a user voting "yes" from one chain to a governance vote on another chain would not want their vote to become a "maybe". On the other hand, value transfer may be lossy depending on user preferences. A sophisticated 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 three layers above introduce key design decisions that CAF 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 to the solver. Below is a detailed analysis of each layer.
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 the EVM transaction standard will be limited to Ethereum, its L2, and sidechains (such as the Metamask wallet). On the other hand, wallets that support the 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 to coordinate and settle these sub-transactions is a key design decision of the permission layer.
EOA wallets are wallet software that runs on the user's machine and holds their private keys. They can be browser-based extensions (like Metamask and Phantom), mobile applications (like Coinbase Wallet), or dedicated hardware (like 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.
In Account Abstraction (AA) wallets, users still have access to their private keys, but they separate the signers of transaction payloads from the executors of transactions. Enables complex parties to bundle and execute user transactions atomically (Avocado, Pimlico). AA wallets still require users to sign each sub-transaction individually (currently via multiple clicks), but do not require holding a fee balance on each chain.
Policy-based proxies hold the user's private keys 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 TEEs 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 proxies during the operation.
Solver Layer
After a user posts an intent, the solver layer is concerned with returning fees and confirmation times to the user. This issue is closely related to designing order flow auctions, which are discussed in detail here. CAF can leverage in-protocol paths to enforce user intent, or leverage a complex third party (i.e., solver) to compromise on certain security guarantees and provide users with an improved user experience. 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 a value that is accessible to any entity that complies with the 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 usually 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 the entity executing these orders may suffer losses due to the market maker having a better understanding of future market conditions.
When someone is able to observe the 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 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 the solver:
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 is highly information-extractive because users publicly disclose their EV_ordering and EV_signal. Examples include Ethereum's public mempool and various blockchain bridges. In the case of a bridge, 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.
Partial sharing: CAF can reduce the amount of value revealed to bidders by limiting the amount of information disclosed. However, this approach will directly lead to a loss of price optimality and may cause problems such as bidding spam.
Private mempools: Recent developments in MPC and TEEs have made fully private mempools possible. No information is leaked outside the execution environment, and solvers encode their preferences and match each intent. While 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 preempt the transaction 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 authentication nodes to capture the EV_signal from newly minted blocks in the TEE, turning EV_signal capture into a latency race.
Solver List
The CAF also needs to decide how many and which bidders to allow in the auction. The main options are:
Open Access: The barrier to entry to participate is as low as possible. This is similar to exposing the mempool, leaking EV_signal and EV_ordering.
Restricted Access: Gating of order execution capabilities through whitelists, reputation systems, fees, or seat auctions. Gating mechanisms need to ensure that solvers in the system do not capture EV_signal. Examples include 1inch Auction, Cowswap Auctions, and Uniswap X Auctions. Competition to win orders captures EV_ordering for users, while gating mechanisms can capture EV_signal for order generators (wallets, dApps).
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 signs 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, potentially causing the transaction to fail. This subsection explores the trade-offs between security cost, confirmation time, and execution guarantees.
It is important to note that executing a desired transaction on a target chain depends on the target chain’s transaction inclusion mechanism, including factors such as being able to censor transactions and the target chain’s fee mechanism. We consider the choice of target chain to be 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 inter-chain information transfer, including verifying that users have locked funds in escrow accounts in the locking and minting bridge, or confirming the user's token balance on the original chain to participate in the governance vote 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. Suppose 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 may 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:
Extra-protocol oracles: Need to be separate from third-party validators running consensus to pass information between chains. Additional validators increase the cost of running an oracle. LayerZero, Wormhole, ChainLink, and Axelar Network are examples of extra-protocol oracles.
In-protocol Oracles: Deeply integrated into the consensus algorithm of the ecosystem and use the set of validators running the consensus to pass information. Cosmos’ IBC is used for chains running the Cosmos SDK, the Polygon ecosystem is developing AggLayer, and Optimism is developing Superchain. Each oracle uses dedicated blockspace to pass information between chains in the same ecosystem.
Shared sorters are extra-protocol entities that have transaction ordering 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 blocks to be confirmed 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, thus making them inter-chain.
Bridge Token
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 use case for value transfer. This creates an opportunity to leverage professional third parties that 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:
Locking and Minting Bridges: Locking and Minting Bridges validate token deposits on the source chain and mint tokens on the target chain. The capital required to launch such bridges is small, but secure transfer of locking information requires significant investment. Security breaches in these bridges have resulted in billions of dollars in losses for token holders.
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 cross-chain bridges, users are required to pay liquidity costs. In the locking and minting bridge, the liquidity cost is incurred when swapping from the wrapped token to the desired token on the target chain (USDC.e to USDC), while in the liquidity bridge, the liquidity cost is incurred when swapping from the token on the source chain to the token on the target chain.
The cross-chain trilemma
The five design decisions above raise the cross-chain trilemma. CAF must choose two properties between execution guarantees, low fees, and execution speed.
In-protocol paths: are designated paths 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.
Solver aggregation: Collects quotes from multiple solvers to identify the cheapest and fastest path to execute the user's intent. However, due to adverse selection and front-running, sometimes a solver may not be able to satisfy the intent, resulting in reduced execution.
Execution competition: Selecting a winning solver by scheduling solvers to race to execute intent or selecting a single solver. Both approaches result in high user fees as solvers compete for execution rather than price improvement.
The six components of CAKE
To write this article, we researched over 20 designs by 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 its own methods and protocols to encode user intent. A unified standard will 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 Bridge
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 right to mint tokens, i.e. the tokens that users need.
If you look closely, you will see that burning and minting bridges are similar to cross-chain transfers that are fast enough for block confirmations. xERC 20 is a standard for specifying canonical tokens and their authorized bridges on a target chain. Token-specified bridges are an example of an intra-protocol path that sacrifices speed for guaranteed execution and low fees, e.g. CCTP takes 20 minutes to complete a transfer.
Ecosystem coordination bridge
Ecosystem coordination bridges can transfer arbitrary messages between chains within the same ecosystem. These bridges are intra-protocol and prioritize 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 fragmented across chains, each chain had its own fee token, and managing multi-chain accounts was cumbersome. The Cosmos ecosystem solved these problems by implementing the 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, on the other hand, 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 is 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 users. 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 coordination message
Wallet coordination messages leverage 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 phrase from Metamask to another wallet. This is also the reason 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 their current wallets is a difficult task.
Solver speed competition
The Solver Speed Competition allows users to express intent for specific cross-chain transformations to receive high execution guarantees. It does not help users minimize fees, but rather provides a reliable channel to include complex transactions. The first Solver to execute an intent based on either block builder fees or inclusion 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 Bulk Auction
Exclusive batch auctions hold an auction 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.
in conclusion
The Chain Abstraction Framework (CAF) promises to provide users with seamless cross-chain interactions. In this paper, we examine designs in production and development by several teams that are explicitly or implicitly trying to solve the chain abstraction problem. We believe this will be the year of CAF and expect significant competition between different designs and their implementations to occur 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 message bridges that match the ecosystem, aiming to minimize user costs and maximize speed through wallet-controlled platforms. Ultimately, these six different designs will form a cluster because they each meet different needs and exploit efficiencies in different areas of the trade-off matrix.
One important conclusion we learned 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. A unified standard will help improve user understanding of signed messages, facilitate solvers and oracles to process intent, and simplify integration with wallets.
Original link
