Date

November 30, 2023

What is Intent?

A transaction is imperative, explicitly indicating "how" an action should be performed.

On the other hand, an intent is declarative and indicates "what" the desired result of the action should be.

A transaction, for example, can be expressed as follows.

Sources：Intent-Based Architectures and Their Risks　

I used a $20 pizza order as an example to describe the difference between an intent and a transaction.

An intent expresses what the user wants to do (declaration) e.g. Pay $20 for a pizza in Hawaii by 8 pm.
A transaction specifies what to do in detail (route) (instruction) Example Hop on your scooter, go to Domino's around the corner, order item #4, and bring it to me!

We will also show how an intent is defined by the players in this area.

an intent is signed a set of declarative constraints which allow a user to outsource transaction creation to a third party without relinquishing full control to the transacting party. (Source: Paradigm Intent-based architectures and their risks)
"A trusted commitment to preferences for the state of a system" and "a trusted commitment to control information flows" (Source Intents with Chrsi Goes from Anoma)

Let's look at the differences between Ethereum transactions and Anoma, which is developing an architecture for Intents.

Source:　WTF Is Anoma? Part 1: WTF Are Intents? - Delphi Digital

In Ethereum EVM, you do not specify a future state, but rather an execution path. (e.g. Do A, then B, then C) Transactions are executed by a smart contract that receives a message and executes code step-by-step.

With intents, the user can specify the conditions and preferences for a particular transaction without calling the message as in the EVM above. This increases flexibility and potentially eliminates the complexity of on-chain implementation.

Let's look at how intents are handled in Anoma.

Once a user's intents are submitted, that intent essentially needs to be offset, using resources. If the intents are not offset, it is considered "unbalanced."

Specifically, that work is done in the Intents Gossip Layer, which propagates intents, discovers counterparties, and solves (the solver puts together multiple intents to create a valid transaction).

Intents can be combined for as long as the solver desires. Eventually, the solver forms a TX that passes a "balance check" at which point it can choose to resolve on-chain.

The important thing to remember about intents is that intents focus on the results the user wants, not the process. The user defines and shares the desired outcome. Someone else is responsible for how to achieve that.

How Intent changes the transaction value chain

The value chain of an Ethereum transaction from submission to being captured in a block is as follows.

Source:　EthCC: Understanding ERC-4337—How it works and exploring unknowns

The transaction value chain may differ for intent-based architectures such as SUAVE, Anoma, Essential, etc.. However, it will take time for intent-based architectures to become practical, so until then, intent will be implemented in a way that trusts off-chain and centralized entities.

To get a rough idea in mind of the flow to block construction in the case of intents assuming ERC4337, here is a diagram of the transaction flow assuming ERC4337 shared by Blocknative.

ERC4337 allows the User Intent Layer to be placed before the Public Mempool.

Source:　EthCC: Understanding ERC-4337—How it works and exploring unknowns

Intent-based applications

A common example of intents is the limit order, which is familiar from real-world stock and currency orders. Limit orders are an important use case for intents, but they are only one of many possible intents.

Intents can represent anything that can be generalized. Since many real-world events are complex, it is expected that as intents expand, more and more things can be realized on the Web3.

Many of the applications you are familiar with such as Uniswap X, CoW Swap, 1inch Fusion, dYdX, ERC-4337 wallets (Safe, Argent), OpenSea in the NFT marketplace, Blur, etc. DEX offers limit trading, complex conditions, and the NFT marketplace offers more flexible NFT trading, condition-specific trading, and more.

We will not describe each application in detail, but as a concrete example of DEX that is easy to understand, we will show you how CoW Swap works.

CoW Swap

I used it myself with a Limit Order for ETH swap from USDC. Set the limit price, specify the period, accept or reject the execution even partially, and sign the message without gas fee. Unlike regular swaps, I can say that it is relatively smooth to use.

Now, let's see how CoW Swap works.

CoW Swap uses batch auctions as the core of its pricing mechanism; CoW Swap does not execute trades instantly like AMMs such as Uniswap, but rather aggregates orders off-chain and settles them in batches. This mechanism allows uniform clearing prices across all trades in a batch, eliminating problems such as front running that are common with instant execution models.

Batch auctions can also optimize gas costs because they settle many transactions simultaneously. There is open competition among solvers, and order-settlement solutions that maximize profits for traders in each batch are submitted. The best solution will set the final uniform price. Overall, batch auctions offer fairness, efficiency, and MEV protection that instant execution does not.

A key innovation enabled by CoW Swap's batch auction model is the ability to find Coincidences of Wants (CoW, matches of wants) between orders. Finding mutually matching transactions within a batch allows for direct settlement (P2P settlement). CoW enables multiple assets to be involved in a ring transaction simultaneously rather than isolated liquidity pools. Settlements are executed using the CoW to the extent possible, with the remainder executed using on-chain liquidity.

The CoW Swap model is similar to the intent model, as shown in the diagram above.

the user communicates their intent to trade in the form of a limit order
it enters the order book and a batch auction is held
the solver uses the state of the order book to settle in two ways

ring trade (CoW)
through AMM

What we can see from this flow is that the user only mentions the price, but not the calculation path or where they want to execute.

The current architecture of the Intent application is a centralized structure that relies on a single application. As a solution to this, a growing number of protocols are aiming to become sovereign blockchains, such as dYdX. However, while this can solve the problem of centralization, it has its limitations as it only allows for Intent in a single blockchain.

The Challenges of Intent

Intent is an excellent alternative to transactions, but there are many challenges to its practical application.

First of all, the architecture for intents is currently not at the stage of practical application, and intents are forcibly implemented on top of the existing transaction-based architecture.

Let's take a look at the issues arising from the current implementation.

Intents Fragmentation

Currently, each project implements its intent off-chain. As a result, intents are not integrated, siloed, and fragmented, similar to the fragmentation of liquidity that is one of the challenges of Interoperability.

As a solution to this, architectures that assume generalized intents are emerging, and there are moves to allow intents to be handled across dApps and chains.

Intent Monopoly

As for MEVs, approximately 90% of Ethereum's current transaction flow is through MEV-Boost.

MEV-Boost is an out-of-protocol implementation of PBS (proposer-builders separation) first, due to the time required to implement it at the protocol level.

As introduced in Why Decentralization Matters, 6 block builders hold most of the market share, and so centralization is an issue.

Even if intents are introduced, there is a strong possibility of a move toward monopolizing the major source of transactions (Exclusive Order Flow, hereafter "EOF"). This is because it is essential for block builders to obtain EOFs to compete.

UniswapX has recently surpassed $1B in cumulative volume since its launch. However, it is a Top 3 Filler with 90% market share.

The solution to this is to enable solvers to discover counterparties that satisfy decentralized intent in a permissionless manner.

Lack of transparency

With the current architecture, there is the potential for opacity in how intents are handled; when the MEV issue was highlighted, the key phrase "Dark Forest " was used, but intents can also get lost in the Dark Forest. it was used in the MEV issue.

The reason for the opaqueness is that applications that implement the current intent assume that after signing the intent, it will go into a Permissioned mempool. There is a concern that this mempool and middleware ecosystem will become opaque.

The intent declares the state desired by the user. As long as that state is adhered to, there is a high degree of freedom in how subsequent mempools and middleware process it. The greater freedom also means more significant opportunities to obtain MEVs, etc.

We must design how much privacy is allowed and how much transparency is ensured.

Emergence of Intent-based architecture

We have seen the challenges of Intent. Intent-based architectures are emerging to solve these challenges. Based on the challenges, the following three elements are required for an intent-presupposed architecture.

Permissionless: Anybody can execute and match intents.
Transparency: Transparency in the intent execution process, with necessary privacy protection and checks on the quality of transaction execution.
Generalization: Intents should be generalizable and not dependent on a specific blockchain or app.

Anoma and SUAVE are examples of intent-prerequisite architectures. (There are others, such as Essential, but they are not included in this paper.)

Anoma

Anoma is an intent-based architecture. Anoma itself is not a blockchain, nor is it tied to a specific blockchain.

Anoma can be leveraged to develop L1 and L2 blockchains.

Source:　Adrian Brink - The 3rd generation is intent-centric

Above is an overview of Anoma's rough architecture. Let's look at each step.

1. Counter Party Discovery

出典：　Adrian Brink - The 3rd generation is intent-centric

The Who, What, Observer framework is important when considering privacy in blockchain. We can understand privacy with more resolution by clarifying who and what is and is not hidden from observers.

The user expresses an Intent. The user can choose between three types of Intents, Transparent, Shielded, and Private, depending on the level of Privacy. (see figure below)

Source:　WTF Is Anoma? Part 1: WTF Are Intents?

The fundamental difference is that Privacy is the user's choice, whereas the current situation is that the protocol side chooses Privacy.

Privacy is achieved using Zero-knowledge proof or Fully Homomorphic Encryption. Anoma's advantage is that it allows for different privacy settings to be handled in the same application.

The represented intent is gossiped and shared with the solver. The solver then attempts to combine and offset the intents of the various applications. The solver then tries to combine the intents of the multiple applications and offset them, and, as mentioned above, finally produces a transaction that passes the balancing check and can combine and cancel the intents.

2. Consensus

The solver submits transactions that pass the balance check to an encrypted mempool (Encrypted mempool). The encryption prevents front-running and other actions to obtain MEVs. Thereafter, a block is generated, followed by the Proposer, Validator, and the normal transaction flow.

Anoma introduces a consensus mechanism called Typhon, a proprietary modification of CometBFT.

Typhon is an execution engine that handles mempool (heterogeneous Narwhal) and consensus (heterogeneous Paxos). This consensus mechanism enables Chimera Chains to realize Atomic Transactions.

Block Proposer Bottleneck (mempool)

In CometBFT, the reader uploads a block containing complete transaction data and propagates it to all other validators.

This centralized block propagation reduces throughput and increases latency as large amounts of data are constantly sent from a single validator to multiple validators. The DAG-based mempool of Narwhal employed instead takes advantage of the fact that other validators already have these transactions locally. The block proposer sends a block containing a hash of transactions already known to be available. This allows for a Heterogeneous Narwhal, where Heterogeneous means "heterogeneous," but different blockchains Note: Narwhal is already used in Aptos and Sui.

Cross-Domain Atomicity (consensus):

Many blockchains currently have duplicate validators. In theory, this means that a blockchain can, to some extent, recognize and influence transactions on other blockchains. In practice, however, there are no examples of blockchains taking advantage of this.

Blockchains cannot run consensus protocols separately and recognize overlaps in each other's active validator sets. With **Typhon, however, independent blockchains can recognize and exploit overlaps in each other's validators to communicate with stronger assurance of atomicity. **

parallel transaction processing (execution):

Most blockchains today have a serial execution engine. This means that transactions are executed one at a time, regardless of whether they are related to each other, which fundamentally limits throughput. Typhon allows for serializable execution, which means that nonconflicting transactions can be executed in parallel and achieve the same results as if they were executed one at a time.

This is similar to Solana's Sealevel and is a common direction seen in newer blockchains such as the Fuel and Move chains Sui and Aptos, and even Monad's EVM.

3. Execution & Verification

Taiga is a unified execution environment that enables Information Flow Control using Zero-knowledge proof.

Information Flow Control is a concept used by Anoma. Specifically, the idea is that users can control the flow of their information, and sometimes disclose information to specific parties of their choosing (and sometimes only to themselves).

(I think this is a term that I would like to see spread in the future, as I think it more accurately describes what we want to do than the word Privacy).

Specifically, Taiga enables the Halo2 Zk circuit to deploy Zk-rollups to ethereum.

SUAVE

Source:　The Future of MEV is SUAVE

Basic Concept

Here is an overview of SUAVE based on a blog post by Flashbots.

SUAVE is an independent network that allows various chains to outsource the following two roles: SUAVE does not compete with existing chains, decouples the roles of mempool and block builder from existing chains, and provides a highly specialized and scalable alternative.

Mempool: allows users to send transactions to SUAVE's mempool instead of the mempool of a blockchain such as Ethereum.
Block Building: SUAVE can output blocks that can be accepted by other blockchain validators. (e.g. Ethereum's Proposer can accept blocks built by SUAVE)

Flashbots explains below why many chains have a common decentralized Sequencing Layer (Mempool and Block Building above).

Block Builders that operate in only one domain are increasingly disadvantaged by cross-domain MEVs. (Author's note: the more intents and transactions you have access to, the better)
Users will benefit from the efficiency of aggregating and clearing their preferences within the same auction.
We can leverage its Credible Neutrality to have many participants share their views, strategies, and opinions in one place, giving SUAVE an informational advantage over centralized block builders.
It is difficult to enable the computation of sensitive data (user order flow) in a permissionless manner. By resolving it across many chains, the entire ecosystem can amortize the cost and reach a solution faster and cheaper than individual participants.
Since sequencing is the basis of the blockchain stack, only other decentralized systems can provide the necessary security and trusted neutrality.

Sharing SUAVE as the same Sequencing Layer offers the following advantages

Blockchains: maximum distributed sequencing, neutral network resiliency
Validators: maximize block space revenue
Block builders/Searchers: open access to user and searcher transactions, representation of complex Preferences (user preferences, what they want to achieve), integration of Preferences across different blockchains.
Users: the ability to conduct transactions privately, under the best conditions and with minimal fees.

Flashbots predicts that a blockchain that allows competition for MEV acquisition will promote severe network externalities and centralization caused by MEV Searchers.

And they argue that the proposed SUAVE will prevent those centralizations.

SUAVE Architecture.

SUAVE is a single environment in which parties can collaborate in a decentralized manner on the Preference Statement, Execution, and Settlement SUAVE consists of three main components.

Universal Preference Environment: a chain and mempool dedicated to preference representation and settlement that aggregates user and searcher preferences from all participating chains in a single location.

By aggregating user preferences from many blockchains, a network effect can be achieved. Users will get better terms, and block builders and validators will also benefit because there will be a unified auction.

Optimal Execution Market: a network of special parties, called Executors, who interact with the SUAVE mempool and compete to provide the best execution for users' preferences.

When a user submits a preference to SUAVE, it is passed on to the Execution Market. Executors compete in an auction to provide users with the best possible terms of execution and to accommodate the preferences of many blockchain users.
The Execution Market is intended to be a decentralized place where users' order flow values are recognized and where users, wallets, and other order flow providers can benefit most from their transactions.

Decentralized Block Building: a decentralized network for block builders to access encrypted preferences from users and merge them into partial or complete blocks.

At the core of SUAVE is the concept of preferences.

A preference is a message that a user signs to express a specific goal and unlocks a payment when the user's conditions are met. This preference can range from a simple transfer or swap in a single domain to an arbitrarily complex series of events across multiple blockchains.

Preferences can be thought of as native transaction types in SUAVE. Preferences can include payloads that run in a specific domain, such as Ethereum. Alternatively, they can describe more abstractly what the user wants to accomplish and leave the optimal routing to the executor. (Author's note: Almost a similar concept to Intent)

SUAVE has been a key project of Flashbots, a significant player in Ethereum's MEVs. However, many challenges remain, including high Latency in building decentralized blocks, incentives for block builders, and how to securely share critical information such as order flow.

最後に

There are issues with the current architecture based on the transaction format, including limitations on what can be expressed in MEVs and dApps development. I hope you have understood the potential of intents to solve those issues.

However, it is necessary to move to an architecture based on intents to become popular while maintaining important Crypto concepts such as decentralization and censorship resistance.

Currently, SUAVE, Anoma, and others are working on a new layer to achieve a private and permissionless environment and a generalized solution that is intent-presupposed. However, it is envisioned that it will take a long time to complete.

We expect solutions that consider the trade-offs between the required elements will be used during the time it takes to complete.

Also, Anoma and SUAVE are very similar in their generalized treatment of user Intent and Preference; the Solver / Executor market will leverage privacy technologies for permissionless collaboration, and the user Intent / Preference and compete to satisfy user Intent / Preference. However, their goals are fundamentally opposite.

Anoma's vision is homogeneous architecture / heterogeneous security. The same architecture, different forms of security. A blockchain with shared standards will have many benefits as seen in Anoma's description.

SUAVE, on the other hand, is architectural in the view that many blockchains are likely to have different architectures. Therefore, SUAVE aims to exist as another layer for decentralized block building. It is intended to optimize as a Preference Layer for any blockchain and serve as a destination for outsourcing.

We will keep a close eye on the future implementation of the intent and architecture.

If you are interested in the business areas that Tané is working on (investments, validators, DAO governance), Web3 projects, or companies, don't hesitate to contact us here.

Reference

An Introduction to Intents and Intent-centric Architectures | Blog - Anoma

SUAVE, Anoma, Shared Sequencers, & Super Builders

This is not the SUAVE you are looking for | Blog - Anoma

Typhon's Chimera Chains

Intent-Based Architectures and Their Risks

WTF Is Anoma? Part 1: WTF Are Intents? - Delphi Digital

WTF Is Anoma? Part 2: WTF Are Intent-Based Apps? - Delphi Digital

WTF Is Anoma? Part 3: WTF is Typhon?

Adrian Brink - The 3rd generation is intent-centric

Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment. It should not be used to evaluate the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. This post reflects the current opinions of the authors. It is not made on behalf of Tané or its affiliates and does not necessarily reflect the opinions of Tané, its affiliates or individuals associated with Tané. The opinions reflected herein are subject to change without being updated.

Current Status and Possibilities for Intent