原文作者：Nick Pai，Archetype
Original source: X
编译:深潮TechFlow
This article is divided into two parts. First, I elaborated on what I believe is critical to the consumer adoption of cryptocurrencies by chain abstraction infrastructure, and that intent-based architecture is the best way to design it. Second, I described the main obstacle to the intention of widespread adoption: the liveliness of the solution network.
At the end of the article, I propose a solution and introduce a standard developed in collaboration between Across and Uniswap, which is based on feedback from the CAKE Working Group. This standard is designed to optimize the solution user experience, lower the barrier to entry into a common solution network, enable most intents to be routed to this network, and ultimately enable a larger, more competitive solution network to thrive.
agenda
Issue:
- Define the end state: What makes a crypto app "usable"?
- Why is "chain abstraction" the solution to the user experience problems that arise from the basic topology of modular blockchains?
- Why do available crypto applications have to be built on top of the chain abstraction infrastructure?
Solution Space:
- How intent-based architecture produces chain abstraction
- Understand that the intent market performs best when the solution network is large and competitive
- Launching an Intent Solution Network requires the introduction of more apps that will generate intent
Suggest:
- Why we need a cross-chain intent standard that prioritizes "solution user experience" to scale the solution and intent market to scale large enough to enable network effects
Without chain abstraction, it is impossible to build a usable cryptographic application
Are our best and brightest people building redundant infrastructure?
Many complain that the best cryptographic engineers are overly focused on providing more block space to end users. This criticism is justified, as there are too many L2 solutions for the end user relative to the demand.
However, I refuse to accept the idea that no useful crypto apps exist.
Decentralized finance provides individuals with the ability to self-custody their digital assets, allowing them to bypass demanding service providers and use their digital assets to buy things that are valuable in the real world. The commitment to self-custody of data also offers a utopian alternative for individuals who are increasingly concerned about trusting the FAANG (an acronym for the five most popular and best-performing tech stocks in the U.S. market) monopoly to keep their data safe.
I think the real problem is not the lack of useful cryptographic apps, but the friction when end users try to access them. End users should experience the following when interacting with an encrypted application:
- Speed: The app should feel as fast as a web2 app
- Cost: Unlike Web2, all Web3 interactions have to incur some cost, but the cost of "per click" should be negligible
- Censorship resistance ("permissionless required"): Anyone with a wallet should be able to interact with the app as long as they can afford the fees
- Security: Clicks should complete the user's desired action and should not be reversed, and all web3 updates should be permanent
These are the properties of the "available" cryptographic app.
We've been trying to build usable encryption for a long time
Today's modular blockchain solutions provide consumers with all of these attributes, but they are not all available in the same location.
In 2020, blockchains are monolithic, offering two of three attributes to the end user: speed, cost, or security. Then we envisioned a rollup-centric or modular future that unlocks all three of these attributes at the same time.
Today, we've laid the groundwork for this rollup-centric infrastructure. L2 offers cheap and fast block space, while most L2s offer permissionless block space. Instead, L1 provides WW3-resistant secure block space (you can read more about the security provided by L1 and L2 and the trade-offs between user experience in my article). These L2s are securely connected to L1 via a canonical message path, laying the foundation for a modular and interoperable network. Over the past four years, we've built fiber optics between blockchains that support useful crypto applications. But why is modular blockchain so unavailable?
The inevitability of a modular blockchain network is that capital assets will be clustered on the most secure layer, and user clicks will be clustered on a faster and cheaper layer.
The modular blockchain topology encourages secure block space to be provided on a different layer than the cheap and fast block space. Users will naturally tend to store their value on the most secure network, but they will demand frequent interaction with cheap and fast networks. By design, the canonical path between L2 and L1 is slow and/or expensive. These phenomena explain why users must traverse these canonical paths and pay for L2 interactions using L1 assets. This results in an "unusable" crypto user experience.
The goal of chain abstraction is to reduce the friction of users sending value across these protocol paths. Chain abstractors assume that users are more inclined to assign their desired end state to the dapp as an "intent", and that the dapp is responsible for implementing their intent. Users shouldn't compromise on the custody of secure assets for the sake of low fees and low latency for access.
Therefore, the chain abstraction is that users are able to transfer value across the network securely, cheaply, and quickly. A common user flow today is that a user with a USDC balance on a "secure" chain (such as Ethereum) wants to mint an NFT or exchange a new token on a new chain (such as Blast or Base). The way to do this in as few steps as possible is to perform a sequence of transactions (or swap → bridge → mint sequentially, → swap → minting).
In this example, the user's intent is to mint an NFT on another chain using their USDC on a secure chain. Users will be satisfied as long as they receive the NFT and their USDC balance is deducted from the depository location of their choice.
Intent-based architecture is the only way to build chain abstractions
Chain abstraction relies on cross-chain value transfer, but sending value through canonical message paths is either expensive or slow. "Fast bridges" provide users with a cheap and fast alternative to sending value across networks, but they introduce new trust assumptions. Messaging is the most intuitive way to build a fast bridge because it is modeled on a TCP/IP architecture that relies on a bridging protocol to connect the two chains as a TCP router.
ResearchGate的TCP/IP图表
Value transfer via messaging involves a bridge protocol that sends messages between contracts on the origin chain and the destination chain. This message is triggered by the user's transaction on the original side, and once the "validity" of the message is verified, it is relayed to the target side.
A message can only be verified after the original chain transaction that initiated the message has been completed, i.e., the transaction has been permanently included in the canonical blockchain of the original chain. This verification can be done through a validity proof, which proves that the transaction has been included in the original chain's consensus, or with an optimistic offer, or after a certain number of witness signatures have accumulated on the original side. Once the message is relayed to the bridge contract on the destination chain, the tokens are released to the user.
There are several fundamental problems with this architecture:
- The verification mechanism must wait for full determinism before sending a message to the destination chain protocol contract. For L2 with an optimistic determination period, this can take up to seven days.
- Each bridge transaction sends only one cross-chain message, or batches messages together, but the batch can only be sent after the last message in the batch is complete.
- The bridge has limited ability to access external liquidity to provide price improvements to users, as it must declare a fulfillment path of user intent.
Fast messaging-based bridging can be insecure, slow, or expensive depending on the verification mechanism. The Intent Marketplace is an alternative architecture for fast bridging that stems from a key insight:
Value is fungible, and it doesn't matter to the recipient how the value is transferred as long as the funds can be received
Can bridging outsource value transfer to a complex proxy to increase speed and reduce costs? Liquidity is dynamic on-chain and off-chain, and price improvements can be achieved if the bridging mechanism has the flexibility to choose the best execution path when bridging the transfer.
The intent mechanism allows users to specify the precise conditions or contracts that their value transfer transactions can execute.
The most simplified intent is to pay X tokens from chain A to receive an order for Y tokens on chain B.
The bridging protocol does not require messages to be sent between domains in order to satisfy the user's cross-domain intent. Instead, the protocol outsources the transfer of value to an agent selected from a network of unlicensed solvers, and the individual solver will later seek repayment from the bridging protocol. In contrast, messaging-based mechanisms specify exactly how their transactions should be executed and do not need to rely on the availability of the broker.
Intent to settle the agreement
Intent-based bridging protocols can be more precisely labeled as intent settlement protocols, and they are responsible for ensuring that the solver does not violate user-specified conditions. The intent settlement protocol provides security to solvers that they are repaid and rewarded for fulfilling the user's intent. To do this, the intent settlement agreement needs to appeal to Oracle to verify the authenticity of the intent fulfillment. The security of an oracle can be based on an optimistic challenge period, a witness threshold, or a ZK validity proof, etc.
Because a single solver takes the ultimate risk and determines the best execution path, the intent settlement protocol provides a fast, low-cost transfer of value
Messaging bridges can only communicate when the original chain has reached finality. Today, the finality time on the Optimistic Rollup is seven days, while on the ZK Rollup it is one hour. While these finality times should decline with the widespread adoption of ZK light client technology and advances in shared sequencer pre-confirmation technology, it is never likely to feel "instantaneous" to users for all blockchains, indicating the ongoing need for fast bridging solutions. Without risking finality, even if the bridge wants to add an additional trusted agent to the relay path to guarantee losses due to chain reorganization, it will not be able to increase the message delivery speed beyond the finality period.
The acceleration provided by an intent-based architecture is because a single solver in a heterogeneous solver network can take more finality risk than a messaging protocol and satisfy the user's intent before the chain reorganization risk disappears completely. The solver then charges the user for the finality risk they would have taken at the faster time of the exchange.
Outsourcing cross-chain intent fulfillment to an agent will also improve prices for users on average. In an intent-based bridging, in order to fulfill the user's order on the target chain, the solver on the front-end will be returned by the system after verifying their fulfillment. These intent settlements can be batched together to spread costs. Unlike users, fillers do not require immediate repayment and will charge users a funding upfront fee accordingly. Batch settlement isn't the only feature of an intent-based architecture, but it is more synergistic with bulk settlement because it separates the repayment step from the intent fulfillment step.
A larger source of price improvement comes from the intuition that value is fungible and that finding the best path in time is often better than transferring value, however, there are some paths that cannot be beaten in time in terms of cost, such as when transferring USDC over CCTP.
Messaging bridges must encode how they will deliver value to users. Some choose to send tokens from liquidity pools at a predetermined exchange rate, while others mint representative tokens to recipients who need to subsequently exchange the required canonical token assets.
When fulfilling user intent, agents can obtain liquidity from a combination of on-chain and off-chain liquidity venues. Competing solver networks theoretically provide users with unlimited sources of liquidity (but even these sources of liquidity can be quickly depleted in one-way trends during high-volatility on-chain events, such as popular NFT minting, airdrops, and rug pull events).
Once the cross-chain order is submitted as an intent, the solver can internalize the MEV generated by the order as a price improvement.
Intent-based architecture is fundamentally designed to be secure
Intent-based bridging can be built securely because they separate the urgent needs of users from the complex needs of the settlement network. Solvers can wait for repayment, unlike users, who will charge users for the time they wait to be repaid based on the settlement agreement. As a result, intent settlement can be verified using a very robust mechanism without strict time constraints. This is preferable from a security standpoint, as validating intent implementation is intuitively complex.
As an example of proof-of-intent in production, Across validates and reimburses fillers in batches after a 90-minute optimistic challenge period. Of course, the billing network should strive to repay the filler as soon as possible to reduce the cost to the end user. An improvement to the optimistic challenge mechanism would be a ZK validity proof mechanism, which would require the intent verification logic to be encoded into a ZK circuit. In my opinion, it is inevitable that the verification proof mechanism will replace the optimistic challenge mechanism and enable the intent settlement network to repay users more quickly.
So, how did chain abstraction emerge from intent-based architecture?
Recall that chain abstraction requires fast and cheap cross-chain value transfer. It also shouldn't require users to submit on-chain transactions on the network where their assets are stored.
If a Permit2 or EIP 3074 signature is included, the user's intent does not need to be submitted on-chain by the user. This is true for both messaging and intent-based bridging. Both architectures can take advantage of the Permit2 model, which allows users to sign the number of tokens they are willing to pay offline on the origin chain wallet.
Intent-based marketplaces best support chain abstraction because they provide cheap and fast cross-chain value transfer. Imagine that a user can request a solver to provide them with a quote to enter a WETH collateralized position in Arbitrum with their USDC on Optimism as payment. Users can send this intent to an RFQ auction where the solver can bid on it. The winner of the auction can then receive the user's signature intent, which contains a copy that allows them to spend their USDC on Optimism, the amount of WETH earned on Arbitrum, and the calldata used to deposit this WETH into the Arbitrum collateral position. The solver can then submit this transaction on Optimism (on behalf of the user) to initiate cross-chain intent and withdraw USDC from the user's Optimism wallet. Finally, the solver can populate the user's intent by sending WETH to the user and forwarding the calldata to the user's on-chain collateralized position.
Building a chain abstraction infrastructure means making user processes feel instant and cheap without requiring them to commit on-chain transactions. Let's conclude this article by discussing the barriers to wider adoption intent.
In order to achieve the best user experience from intent-based chain abstraction, we need a competitive network of solvers
The key to achieving the best user experience with intent-based chain abstraction lies in building a highly competitive network of solvers. Bridging of connection intents depends on solver network effects to perform better than messaging variants. This is a core trade-off between intent and messaging architecture. The reality is that not all intent-generating applications need access to a perfectly competitive set of solvers, and some may be more inclined to route their intents to an oligopoly solver network. However, the current state of solver networks is immature and falls far from the level of solver network activity assumptions on which the intent market depends.
We don't want every DApp to route intents to an isolated network of solvers. The best user experience scenario is that many DApps communicate with the same solver pool, and all DApps have solver pools that are free to change the intent they send.
How do I bootstrap a solver network?
We had to make the solver user experience a top priority.
Running an intent solver is complex and requires expertise in building high-performance software and managing cross-chain inventory risk. Naturally, there will be a handful of parties interested in paying for the startup costs of running this code. In the best-case scenario, a solver written for one DApp, such as the UniswapX solver, can be reused to solve other intent-generating DApps, such as Across and CowSwap.
We really need to improve the total capital efficiency of the solver network across all intent-based DApps. This will require addressing the impediment of running a solver.
To do this, we need intent-generating DApps that are visible to any solver and ensure that all solvers have access to multiple differentiated and competitive intent settlement networks. This will give solvers confidence that they can choose to route their intent fulfillment to a settlement network they trust. Competition between settlement networks will also reduce costs for solvers.
The value proposition of the intent settlement network is to provide security to the solver and other features that can affect the solver's fill intent.
The solver's choice of the intent settlement network will affect their ability to provide users with fee and execution time guarantees. Some settlement networks may offer a solvator-exclusive period, which will support the development of off-chain auctions, where solvers and users can negotiate and commit to relay fees. (In addition, these intent auctions may also provide financially secured pre-confirmation, further enhancing the user experience.) To understand the user flow for intent discovery through auctions and pre-confirmations, I recommend this presentation by Karthik of Sorella)
Some settlement networks may offer intent expiration (i.e., sending value back to the user after a certain fulfillment period has been reached), intent support (i.e., the settlement network uses its own balance sheet to fulfill the user's intent if no solver fulfills), or flexible repayment chains (i.e., allowing the solver to choose the chain of their choice for repayment).
Ultimately, settlement networks will compete fiercely in order to repay solvers quickly and cheaply without compromising on security. Solvers, in turn, will send their order flow to a settlement network that allows them to offer the cheapest fees to users in order to win the order flow of the DApp. Competition in settlement and solver networks depends on intent that all parties in the supply chain coordinate to use the same language, and competition will result in the best user experience for cross-chain value transfer.
Obviously, we need a cross-chain intent standard
If solvers can assume that intents will share common elements, then they can reuse their code to solve different DApp-initiated intents, reducing their setup costs. If different DApps create intents that conform to the same criteria, they can all route their intents to the same solver pool. This will help provide access to the next generation of DApps by enabling them to plug their cross-chain intents directly into existing mature solver pools, without the need for separate access to solvers, and will have cheap, fast, secure, and permissionless value transfer.
Third-party tracking software will also make it easier to track the intent status of any new DApp if the criteria are met.
This intent criterion should allow the intent principal or solver to specify which settlement network they wish to settle their intent on.
I envision competing settlement protocols (such as SUAVE, Across, Anoma, and Khalani) that offer different characteristics for solvers. Depending on which settlement network is repaying the solver, the solver can offer different price and time guarantees to the intent owner. DApps and solvers can agree to route the user's intent to a settlement network they trust to avoid censorship, maintain data privacy, and be secure enough for the solver to trust their repayment.
By writing the choice of the settlement network into the intent order itself, solvers can incorporate this certainty into the quote they present to the user. Solvers and users can reduce costs by removing upfront uncertainty in bridge pricing before committing an intent on-chain.
In partnership with Uniswap, and based on feedback from the CAKE Working Group, Across and I proposed the following cross-chain intent criteria, prioritizing the solver user experience
The standard is designed to simplify the work of the solver. One assertive choice it makes is to natively support Permit2/EIP3074 with nonce and initiateDeadline, and provide some guarantees to form-fillers, such as the amount of refund they will receive from the billing network, and the user's intent format they can track. In addition, there is a launch function defined in the standard that allows the filler (the person who brings the order on-chain) to specify additional "fillerData" on-chain, which the user is unaware of when signing the CrossChainOrder. This way, fillers can ensure that they are rewarded for settling the contract for submitting the user's meta-transaction, and can also set up repayment-specific information such as repayment chains.
This standard is also designed to make it easier for DApps to track intent completion status. Any settlement contract that implements this standard should create a custom subtype ResolvedCrossChainOrder, which can be resolved from any orderData field. This may include tokens involved in the swap, destination chains, and other fulfillment constraints. Included in the standard is a resolve function that enables DApps to understand how to display the intent state to the user, as well as to let the solver know the exact intent order structure they are working on.
The goal of this standard is to enhance the solver user experience, make it easier for them to support multiple settlement networks, and calculate their rewards deterministically. I believe this will allow them to provide users with more accurate and compact offers. You can read more details in this post and in the discussion on the Ethereum Magicians forum about this standard, which has been named ERC7683.
Conclusion
"Intents" are confusing because they are not defined, and this lack of definition is creating real user experience flaws.
Everyone wants others to use their standard definition of intent, so I fully admit that standards are practically impossible to establish. I think defining the intent settlement system first and then trying to attract order flow is the right way to establish an industry standard.
In my opinion, a more feasible approach would be for DApps that already have a lot of user traffic and generate many user intents to agree to meet some minimum standards that will be adopted by their existing solvers. This will form a new and larger pool of solvers. By capturing consolidated order flows from already prominent venues, this new pool of solvers will earn more profit and be able to offer better prices to end users. Eventually, new DApps will also require their intents to be routed to this solver pool and support their intent criteria.
To kickstart this process, Across and Uniswap have jointly proposed a standard that all intending supply chain participants use when processing user orders that send X tokens from chain A and receive Y tokens on chain B. Order flows run through UniswapX (which has a comparative advantage in auction design and intent origination) and Across (which has a comparative advantage in settlement intent fulfillment) can be combined to kickstart the process of nurturing a larger, more competitive network of solvers.