An article explaining in detail the new standard ERC7683 of Ethereum Uniswap cross-chain intention

What is the new cross-chain intent standard ERC7683? What does ERC7683 bring us? What does ERC7683 do? The expected adoption of the Ethereum ETF has ignited the ETH Beta gold rush. The recovery of mainnet transactions is bound to radiate to the various L2 ecosystems of Ethereum. For example, Farcaster’s announcement of huge financing has attracted attention again to DEGEN. In the wave of ETH Beta, everyone has begun to chase OP again...

Today’s site The editor will introduce to you in detail the new standard of ERC7683 cross-chain intent. Friends who like it should take a look together!

The total transaction volume of L2 on the Uniswap protocol is about to reach 300 billion US dollars

But returning to actual operations, due to the random appearance of instant hotspots in each chain, When users want to quickly chase hot spots, they may face different amounts of funds in each chain and need to cross-chain funds. The experience and operation are not good.

Recently, as the big brother of DEX trading on the ETH main network chain, Uniswap keeps up with current events and calls on everyone to pay attention to the new standard for cross-chain intentions jointly developed by it and Across---ERC- 7683.

Execution process of cross-chain transactions under ERC-7683 standard

Will this inject more vitality and catalyst into various ETH DeFi 1.0 projects? ?

Cross-chain is easy to understand, but what is the "cross-chain intention"?

Before explaining cross-chain intentions, we first introduce what "intent architecture" is:

Intent architecture is a design method where users only need to specify the final state they want to achieve ( That is, intention) without caring about the specific execution process. The system automatically finds and executes the best path to achieve the goal based on the user's intention.

Understanding the intent architecture, the concept of "cross-chain intent" is no longer abstract:

Cross-chain intent refers to executing user-specified transactions between different chains. For example, you have a USDC on Ethereum and you want to exchange it for MATIC on Polygon. In the cross-chain intention system, you only need to tell the system "Exchange USDC on Ethereum to MATIC on Polygon", and the system will automatically find the optimal path to complete the transaction, including cross-chain bridging and exchange.

ERC-7683, the first cross-chain intent standard

The cross-chain intent system theoretically simplifies the complexity of traditional bridging cross-chains and becomes the main solution for users' cross-chain interactions. However, the current key difficulty in these systems is the need for sufficient liquidity and an active filler network to execute cross-chain transactions.

As the number of chains and cross-chain requirements increase, when the flow is insufficient and the filler network scheduling is chaotic, users will experience higher cross-chain costs, longer waiting times, and higher failure rates.

ERC-7683 standardizes cross-chain intentions, optimizes the cross-chain transaction process, and solves current problems in cross-chain transactions through innovative methods:

Standardized transaction interface: ERC-7683 defines the standard The CrossChainOrder, and ResolvedCrossChainOrder structures parse orders into an executable standard format, making it easy for fillers to understand and process, making it interoperable between different blockchain systems. ERC-7683 proposes that all cross-chain intents follow the same sequential structure so that a common, shared shim network can complete transactions.

Shared filler network:

After a user signs an order through a standardized transaction interface, the order is propagated to multiple fillers through the network. The fillers grab orders through the bidding mechanism and provide the best quotation and Efficient execution path.

Automated processing:

Users only need to enter the specified transaction intention, and the system automatically completes complex cross-chain operations, reducing costs and time. Users enjoy lower costs + better user experience

Safe fund custody:

The settlement contract custody user funds is through a standardized verification mechanism, and is released to the filler only after the transaction is determined to be successful.

Imagine that the user's manual cross-chain behavior through the cross-chain bridge is like the original logistics chain. If the user wants to send a package from A to B, he needs to go through his own packaging and weighing process. For heavy or customized routes, you need to contact the transportation channel and finally track the package yourself. There are also cases where carriers have different capacities and asking prices, or even lost items. The steps are complicated and require users to independently understand and consider many factors.

ERC-7683 is like a mature express company, with a series of unified and complete standards including weighing pricing, route customization, capacity allocation, etc. For users, such "one-click cross-chain" saves worry and money.

Expectations from the project side

The world has been suffering for a long time.

From a theoretical process point of view, Uniswap does provide a convenient cross-chain process for the purpose of launching the ERC-7683 standard to promote the progress of cross-chain technology.

Not only users, but also many project parties such as Optimism and Krystal have expressed their respect for the launch of ERC-7683. Everyone is looking forward to a good and fast cross-chain protocol to liberate liquidity and provide benefits for the chain. Bring more life.

Currently, ERC-7683 is in the review and discussion stage and has not yet been officially launched. It is expected to be officially implemented after further improvement and approval.

Uniswap and AcrossProtocol will hold an exchange meeting on ERC-7683 at 1:00 pm EST this Friday. At that time, you can learn about the actual application of the ERC-7683 standard after it is launched and more information and details.

Introduction to ERC7683: a new standard for cross-chain intent jointly developed by Uniswap and Across

This article is divided into two parts. First, I laid out my belief that chain abstraction infrastructure is critical to consumer adoption of cryptocurrencies, and that an intent-based architecture is the best way to design it. Second, I describe the main barrier to intended widespread adoption: the activity of the solution network.

At the end of the article, I propose a solution and introduce the 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 so that most intents can be routed to this network, and ultimately enable larger, more competitive solution networks to flourish.

Agenda Question:

• Defining the End State: What makes a cryptographic application “usable”?
• Why is "chain abstraction" the solution to the user experience problems caused by the basic topology of modular blockchains?
• Why must usable cryptographic applications be built on chain abstraction infrastructure?

• Solution Space:

• How Intent-Based Architecture Generates Chain Abstractions
• Understanding the Intent Market When the Solution Network is Large and Competitive The best performing
• Launching Intent Solutions Network needs to introduce more apps that will generate intent

• Proposal:

• Why we need one that starts with " "Solution User Experience" as a priority cross-chain intent standard to scale the solution and intent market to a large enough scale to achieve network effects
• Without chain abstraction, it is impossible to build usable crypto applications

  

  Are our best and brightest building redundant infrastructure?

  Many people complain that the best crypto engineers are too focused on providing more block space to end users. This criticism is valid; there are too many L2 solutions for end users relative to demand.

  However, I refuse to accept that no useful cryptographic applications 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 purchase things of real-world value. The promise of self-custody data also offers a utopian alternative to individuals increasingly wary of trusting the FAANG monopoly to keep their data safe. .

  I believe that the real problem is not the lack of useful encryption applications, but the friction when end users try to access these applications. End users should experience the following when interacting with encrypted applications:

  • Speed: Applications should feel as fast as web2 applications
  • Cost: Unlike web2, all web3 interactions must Incurs some cost, but the "per click" cost should be negligible
  • Censorship Resistance ("no permission required"): Anyone with a wallet should be able to interact with the app, as long as they can afford the fee
  • Security: Clicks should complete the action expected by the user and should not be undone, all web3 updates should be permanent

  These are the properties of a "usable" cryptographic application.

  We’ve been trying to build usable crypto for a long time

  Today’s modular blockchain solutions offer consumers all of these attributes, but they’re not all available in the same place .

  In 2020, blockchain is monolithic, providing end users with two of three attributes: speed, cost, or security. We then envisioned a rollup-centric or modular future that unlocked all three attributes simultaneously.

  Today, we have laid the foundation for this rollup upgrade-centric infrastructure. L2 provides cheap and fast block space, while most L2s provide permissionless block space. Instead, L1 provides a WW3-resistant secure block space (you can read more about the trade-offs between the security and user experience provided by L1 and L2 in my article). These L2s securely connect to L1s via regulated message paths, laying the foundation for a modular and interoperable network. Over the past four years, we have built the fiber between blockchains that supports useful cryptographic applications. But why are modular blockchains so unusable?

  The inevitability of modular blockchain networks is that capital assets will gather on the most secure layer, while user clicks will gather on faster and cheaper layers.

  Modular blockchain topology encourages secure blockspace to be provided on a different layer than cheap and fast blockspace. Users will naturally tend to store their value on the most secure networks, but they will demand frequent interactions 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 use L1 assets to pay for L2 interactions. This results in a "unusable" encryption user experience.

  

  #The goal of the chain abstraction is to reduce friction for users sending value across the paths of these protocols. Chain abstractors assume that users prefer to assign their desired end states to dapps as “intentions” and that dapps are responsible for implementing their intentions. Users should not compromise the custody of secure assets for access to low fees and low latency.

  Therefore, the chain abstraction lies in the ability for users to transfer value across the network safely, cheaply and quickly. A common user flow today is that a user with a USDC balance on a "secure" chain (like Ethereum) wants to mint an NFT or exchange for new tokens on a new chain (like Blast or Base). The way to do this in as few steps as possible is to perform a sequence of bridge → swap → mint transactions (or swap → bridge → mint).

  In this example, the user's intention is to use their USDC on the secure chain to mint an NFT on another chain. As long as they receive the NFT and their USDC balance is debited to the custody location of their choice, users will be satisfied.

  Intent-based architecture is the only way to build chain abstractions

  Chain abstractions rely 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 fast bridges because it is modeled on the TCP/IP architecture; it relies on a bridging protocol that acts as a TCP router to connect the two chains.

  

  #ResearchGate’s TCP/IP Diagram

  Value transfer via messaging involves a bridge protocol sending messages between contracts on the original and target chains. This message is triggered on the origin side by a user transaction and is relayed to the destination side once the "validity" of the message is verified.

  The message can only be verified after the original chain transaction that initiated the message has been completed, that is, after the transaction has been permanently included in the canonical blockchain of the original chain. This verification can be done through a validity proof that the transaction has been included in the consensus of the original chain, an optimistic proposal, or after a certain number of witness signatures have been accumulated on the original side. Once the message is relayed to the bridge contract on the target chain, the tokens are released to the user.

  

  There are several fundamental problems with this architecture:

  • The verification mechanism must wait for complete finality before sending the message to the target chain protocol contract . For L2 with optimistic determination period, this can take up to seven days.
  • Send only one cross-chain message per bridge transaction, or batch messages together, but the batch can only be sent after the last message in the batch is completed.
  • Bridges are limited in their ability to access external liquidity to provide price improvements to users, as it must declare the fulfillment path of the user's intent.

  Fast bridging based on messaging will be unsafe, slow, or expensive depending on the authentication mechanism. Intent Marketplace is a fast-bridging alternative architecture that stems from a key insight:

  Value is fungible, and it doesn’t matter how the value is transferred to the recipient as long as the funds are received.

  ##Can Bridge outsource value transfer to a sophisticated agent to increase speed and reduce costs? Liquidity is dynamic on and off the chain, and price improvements can be achieved if the bridging mechanism can flexibly choose the best execution path when bridging transfers.

  

  #The intent mechanism allows users to specify the precise conditions or contracts under which their value transfer transactions can be executed.
  The most simplified intention is to pay X tokens from chain A for an order to receive Y tokens on chain B.

  Bridging protocols do not require messages to be sent between domains in order to satisfy the user's cross-domain intent. Instead, the protocol outsources value transfer to agents selected from a network of permissionless solvers, and individual solvers will later seek reimbursement from the bridging protocol. In contrast, messaging-based mechanisms specify exactly how their transactions should be performed and do not need to rely on the availability of brokers.

  Intent Settlement Protocols

  Intent-based bridging protocols can be more precisely labeled as intent settlement protocols, they are responsible for ensuring that the solver does not violate user-specified conditions. The intent settlement protocol provides guarantees to solvers that they will be reimbursed and rewarded when they fulfill user intents. To this end, the intent settlement agreement needs to appeal to Oracle to verify the authenticity of the intent fulfillment. The security of the oracle can be based on optimistic challenge period, witness threshold or ZK validity proof, etc.

  The intent settlement protocol provides fast, low-cost value transfer since a single solver can assume the final risk and determine the best execution path

  The messaging bridge can only reach finality on the original chain Communication can only occur during sex. Today, the finality time is seven days on the Optimistic Rollup and one hour on the ZK Rollup. Although these finality times should decline with widespread adoption of ZK light client technology and advances in shared orderer pre-confirmation technology, as with all blockchains, it is unlikely that finality times will ever feel meaningful to users. "Instant", which demonstrates the continued need for fast bridging solutions. Without taking the risk of finality, even if the bridge wanted to add an additional trusted proxy in the relay path to cover losses due to chain reorganization, it would not be able to increase message delivery speeds beyond the finality period.

  The acceleration provided by intent-based architecture is because a single solver in a heterogeneous solver network can bear more finality risks than a message-passing protocol and satisfy the user's intent before the risk of chain reorganization disappears completely . The solver then charges users the finality risk they take in exchanging faster times.

  Outsourcing cross-chain intent fulfillment to agents will also improve prices for users on average. In intent-based bridging, in order to fulfill the user's orders on the target chain, the solvers on the front end will be returned by the system after validating their fulfillment. These intent settlements can be batched together to spread the cost. Unlike users, fillers do not require immediate repayment and will charge users a funding front-end fee accordingly. Batch settlement is not the only feature of intent-based architecture, but this architecture is more synergistic with batch settlement because it separates the reimbursement step from the intent fulfillment step.

  The larger source of price improvement comes from the intuition that value is fungible and finding the best path in time will usually be better than transferring value. However, some paths cannot be beaten in time on cost, such as When transmitting 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.

  In fulfilling user intent, agents can draw liquidity from a combination of on-chain and off-chain liquidity venues. The competitive solver network theoretically provides users with unlimited liquidity sources (but even these liquidity sources can be quickly depleted in one direction trends during high volatility on-chain events, such as popular NFT minting, airdrops and rugs pull event).

  After submitting a cross-chain order as an intent, the solver can internalize the MEV generated by the order into a price improvement.

  

  Intent-based architecture is designed from the ground up to be secure

  

  The reason why intent-based bridging is secure Built 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 be charged according to the settlement agreement for the time they wait for repayment. Therefore, intent settlement can be verified using a very robust mechanism without strict time constraints. This is preferable from a security perspective, as verifying intent implementation is intuitively complex.

  As an example of intent validation in production, Across batch validates and repays fillers after a 90-minute optimistic challenge period. Of course, settlement networks should strive to repay fillers as quickly as possible to reduce fees for end users. An improvement to the optimistic challenge mechanism would be a ZK validity proof mechanism, which would require intent verification logic to be encoded into a ZK circuit. In my opinion, it is inevitable that the proof-of-validation mechanism will replace the optimistic challenge mechanism and enable intent settlement networks to repay users faster.

  So, how does the chain abstraction emerge from intent-based architecture?

  Recall that chain abstraction requires fast and cheap cross-chain value transfer. Nor should it 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 mode, allowing users to sign the number of tokens they are willing to pay offline on the original chain wallet.

  Intent-based marketplaces best support chain abstractions because they provide cheap and fast cross-chain value transfer. Imagine that users could request a solver to provide them with a quote to enter a WETH collateralized position on Arbitrum using their USDC on Optimism as payment. Users can send this intent to an RFQ auction and solvers can bid on it. The winner of the auction can then receive the user’s signed intent, which contains a copy of their USDC allowed to be spent on Optimism, the amount of WETH earned on Arbitrum, and calldata for depositing this WETH into an Arbitrum staking position. The solver can then submit this transaction on Optimism (on behalf of the user) to initiate a 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 calldata to the user's on-chain staking position.

  Building chain abstraction infrastructure means making user processes feel instant and cheap without requiring them to submit on-chain transactions. Let’s end this article by discussing the barriers to broader adoption intentions.

  

  In order to achieve the best user experience from the intent-based chain abstraction, we need a competitive solver network

  Intent-based Chain Abstraction The key to achieving the best user experience is building a competitive network of solvers. Bridging intent relies on solver network effects to perform better than the messaging variant. This is the core trade-off between intent and messaging architecture. The reality is that not all intent-generating applications require access to a perfectly competitive set of solvers, and some may prefer to route their intents to an oligopolistic network of solvers. However, the current state of the solver network is immature and far from reaching the level of solver network activity assumptions that intent markets rely on.

  

  We don’t want every DApp to route intents to an isolated network of solvers. The best user experience situation is when many DApps communicate with the same solver pool, and all DApps have the freedom to change the solver pool to which they send their intent.

  How to bootstrap a solver network?

  We must make solver user experience a top priority.

  Running the intent solver is complex and requires expertise in building high-performance software and managing cross-chain inventory risk. Naturally, there will be a few parties interested in covering the startup costs of running this code. In the best case, 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 overall capital efficiency of the solver network for all intent-based DApps. This will require resolving barriers to running the solver.

  To do this, we need intent-generating DApps to be 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 settlement networks they trust. Competition between settlement networks will also reduce solver costs.

  The value proposition of the Intent Settlement Network is to provide solvers with security and other features that may impact solvers filling intents.

  

  #A solver’s choice of an intent settlement network will impact their ability to provide fee and execution time guarantees to users. Some settlement networks may offer solver exclusivity periods, 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 guaranteed pre-confirmation, further enhancing the user experience. To understand the user flow of intent discovery through auctions and pre-confirmation, I recommend checking out this talk by Karthik from Sorella)

  Some settlement networks may offer intent expiration (i.e. sending value back to the user after reaching a certain fulfillment period), intent support (i.e. the settlement network uses its own balance sheet to fulfill the user's intent if no solver fulfills it) , or flexible payback chains (i.e. allowing the solver to choose a chain of its choice for payback).

  Ultimately, settlement networks will compete fiercely to repay solvers quickly and cheaply without compromising on security. In turn, solvers will send their order flow to the settlement network that allows them to offer the cheapest fees to users in order to win the DApp’s order flow. Competition in settlement and solver networks depends on the intention that all parties in the supply chain coordinate to speak the same language, and competition will lead to the best user experience for cross-chain value transfer.

  

  Clearly we need a cross-chain intent standard

  If solvers can assume that intents will share common elements, then they can reuse their code Address the intentions initiated by different DApps, thereby reducing their setup costs. If different DApps create intents that meet 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 allowing them to directly plug their cross-chain intentions into the existing mature solver pool without having to plug in solvers individually, and will gain access to cheap, fast, secure and Permissionless transfer of value.

  Third-party tracking software will also make it easier to track the intent state of any new DApp if it meets the standards.

  This intent criterion should allow intent subjects or solvers to specify on which settlement network they wish to settle their intents.

  I envision competing settlement protocols (such as SUA VE, Across, Anoma, and Khalani) offering different features to solvers. Depending on which settlement network is reimbursing the solver, the solver can offer different price and time guarantees to the intent owner. DApps and solvers can agree to route user intent to a settlement network they trust to avoid censorship, maintain data privacy, and yet be secure enough for solvers to trust for repayment.

  By writing the choice of settlement network into the intent order itself, solvers can incorporate this certainty into the offers they display to users. Solvers and users can reduce costs by eliminating upfront uncertainty in bridge pricing before submitting intents to go on-chain.

  Working with Uniswap, and based on feedback from the CAKE working group, Across and I proposed the following cross-chain intent standards to put solver user experience first

  

  This standard is intended to simplify the work of solvers. One of the conscious choices it made was to support Permit2/EIP3074 natively with nonce and initiateDeadline, and to provide form fillers with some guarantees about the amount of refund they would get from the settlement network, and user intent that they could track Format. In addition, a startup function is defined in the standard that allows the filler (the person who brings the order onto the chain) to specify additional "fillerData" on the chain, which the user does not know when signing the CrossChainOrder data. This way, fillers can ensure that they are rewarded with settlement contracts for submitting the user’s meta-transactions, as well as set up repayment-specific information such as repayment chains.

  This standard also aims to make it easier for DApps to track intent completion status. Any settlement contract that implements this standard should create a custom subtype of ResolvedCrossChainOrder that can be resolved from any orderData field. This may include the tokens involved in the exchange, the target chain, and other fulfillment constraints. A resolve function is included in the standard to enable DApps to understand how to display intent status to the user, as well as allowing resolvers to know the exact intent order structure they are dealing with.

  

  The design goal of this standard is to enhance the solver user experience, making it easier for them to support multiple settlement networks and calculate their rewards deterministically. I believe this will allow them to provide more accurate and compact quotes to their users. You can read more details in this post and in the discussion on the Ethereum Magicians forum about the standard, named ERC7683.

  Conclusion

  "Intents" are confusing because they are not defined, and this lack of definition is creating real user experience flaws.

  

  Everyone wants everyone else to use their standard definition of intent, so I fully acknowledge that standards are practically impossible to establish. I think defining an 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 is that DApps that already have a lot of user traffic and generate a lot of user intent will agree to meet some minimum standards that will be adopted by their existing solvers. This will form a new, larger solver pool. By capturing consolidated order flow from already prominent venues, this new pool of solvers will earn more profits and be able to offer better prices to end users. Eventually, new DApps will also be required to route their intents to this solver pool and support its intent standards.

  To start this process, Across and Uniswap jointly proposed a standard that all intended supply chain participants use when processing user orders to send X tokens from chain A and receive Y tokens on chain B. . Order flows running 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, starting the process of cultivating a larger, more competitive solver network.

The above is the detailed content of An article explaining in detail the new standard ERC7683 of Ethereum Uniswap cross-chain intention. For more information, please follow other related articles on the PHP Chinese website!