Some people regard intent as a new term for transactions, advocating for the execution based on the intent expressed by users, simplifying the complexity of user interaction with the blockchain, and achieving the goals that users want without the need for detailed intermediate step specifications, emphasizing that intent is declarative. So what exactly is intent?

Author: Delphi Creative / Source: https://members.delphidigital.io/reports/wtf-is-anoma-part-1

Translation: Huohuo / Plain Language Blockchain

While Anoma's intent fits this rough definition, Anoma has its own formal definition of intent.

Anoma intent is defined as a binding commitment to state space preferences. In short, they are signed off-chain messages authorizing one or more future states. For example, the signer of the intent [-2000 USDC, +1 ETH] declares "I authorize any future state where I have 1 more ETH and 2000 less USDC, I don't care how this happens."

The requested ETH may come from a single party or multiple independent parties. Users are not interested in who their trading partners are or what their motivations might be.

In fact, there is no guarantee that users will get what they want. Perhaps there will never be a trading partner who believes in them. Users have signed off on a preference for a certain state, but that state does not yet exist. To achieve it, their intent needs to be compatible with other intents with compatible preferences and be resolved. In the simplest case, we can imagine our intent [-2000 USDC, +1 ETH] matching its exact mirror image [+2000 USDC, -1 ETH].

In practice, intent matching does not require direct overlap of demands. We really don't need another person to make the exact opposite trade in the same scale as us. As we will explain later, intents with compatible preferences can be identified and matched in many different and complex ways involving many independent trading partners. This process is called counterpart discovery and resolution, executed by permissionless agents running special algorithms called solvers.

From the user's perspective, all of this looks like a black box. Users do not know or care about the intermediate steps of resolution. If a successful match is found, the intent can be settled on-chain and verified by the user (settlement will be detailed later). Once verified, the user will directly "jump" to the future state they committed to, otherwise they will remain in the current state.

Source: Anom Document

2. Anoma Intent vs. Ethereum Transactions

Let's compare Anoma's intent-centric execution with the transaction-based execution we are used to in Ethereum. Please note that we use EVM as an example, but the general description applies to all Von Neumann VMs.

In EVM, transactions do not enforce future states; they authorize execution paths. Traders send messages to smart contracts holding code and storage. The contract takes the message as input and runs its code step by step. At the end of execution, it may call some other contracts to pass on control. Execution continues until successful termination or gas exhaustion.

In contrast to Anoma intents, which can only lead to binary state changes, Ethereum transactions can transform states arbitrarily based on the execution path. The execution path is determined by the order of execution of transactions. The execution order is important!

Let's take a moment to reflect on our findings. Below, we will compare the properties of Ethereum transactions with Anoma intents.

Ethereum Transactions vs. Anoma Intent:
- Sequential, imperative execution vs. commitment-based declarative execution
- Authorize execution paths vs. authorize future states
- Final state depends on execution order vs. execution and verification are interleaved
- On-chain execution only vs. off-chain execution, on-chain verification
- Settlement is guaranteed vs. settlement is not guaranteed*
- Known counterpart vs. unknown counterpart
- Arbitrary state changes vs. binary state changes
- Settlement does not require other transactions vs. resolution requires other intents
- Settled by the user vs. settled by a third-party agent

*In the absence of compatible counterparts, an on-chain execution path may not be found. Users can specify an expiration date for their intent to ensure its expiration in this case.

So far, we have a good foundation for understanding the differences between Anoma intents and Ethereum transactions. To truly understand their powerful capabilities, let's look at most of the use cases they can achieve.

3. Intent is Not Just Limit Orders

Our example [-2000 USDC, +1 ETH] intent is a limit order; it only commits to the exchange price of the transaction. While limit orders are an important use case for intents, they are just one of many. Intents can express any form of generalized commitment. For example, it is entirely possible for an intent to simulate an AMM order by committing to trade based on the xy = k curve. In fact, intents can be programs, and can even be algorithms encoding fairly complex commitments. These can be conditional or unconditional. They may also depend on other commitments (so-called higher-order commitments), paving the way for powerful applications that would otherwise be impossible.

Next, let's look at some example use cases that intents can enable.

1) Composite Auctions:
Market makers or sophisticated users can use intents to make various expressive bids based on their unique needs:

- Economic Complementarity: Buy two items A and B at a price of 10 USD, each item only costs 4 USD, because they are complementary.

- Economic Substitution: Buy as much USDC or USDT as possible with some ETH.

- Discriminatory Counterparties: Sell at most two units of A, with pricing by counterparties C1 at 10 USD, C2 at 9 USD, and C3 at 8 USD.

Expressive bidding better aligns with the motivations of sophisticated users in any type of market (financial trading, power grid, logistics, carbon credit, etc.) to improve efficiency. Historically, a significant challenge of expressive bidding venues has been the inability to match multi-dimensional bids due to computational complexity. With advances in deep tech and AI, we may see this no longer being a problem in the coming years.

2) Crowdfunding:
Crowdfunding is an interesting intent use case as it involves many independent agents. Intents can enable many cool use cases:

- Risk-mitigated investment: Commit to providing funds for a project only when commitments exceed X USD.

- Users commit to donating to a winning project, but do not know which project it will be.

- Peer pressure: Commit to funding an activity only if your favorite influencer also commits to funding it.

3) P2P Lending: Lenders choose acceptable collateral, LTV, interest rates, and quoted assets, and match with borrowers. Even after the borrower repays the collateral, the lender may still be willing to lend, in which case the resolver can find another counterpart on their behalf. Lenders can bring their own oracles, and bad debts can be isolated to certain parties. In this model, there is no distinction between DeFi lending protocols, NFT lending protocols, or other areas; any asset can be lent/borrowed.

4) OTC NFT Trading: Over-the-counter NFT trading typically revolves around the exchange of NFTs and involves characteristics. For example, a user may be willing to sell a rare (and illiquid) NFT at a price of "x" ETH, but would also accept 2 identical collections if they have certain features. These are preferences that cannot easily be put on-chain, so counterpart discovery typically involves Discord DMs and exposes users to phishing/scam risks during execution.

5) Automated Operations:
- Good After Time (GOAT) orders: For example, buy a token at a specific time in the future only when the price is within a specified range.

- Subscription: Pay a fixed amount per unit of time within a predefined time period.

- MTCS, also known as mutual trade clearing system, is a unique and powerful technology that can save liquidity for an economy.

The idea of MTCS is simple. If Alice owes Bob 1 ETH, Bob owes Greg 1 ETH, and Greg owes Alice 1 ETH, then in reality, no one needs any "money" to fulfill their obligations. All we need to recognize is that the total obligations form a closed loop; all debts can offset each other and be cleared.

Similarly, in the real economy, companies often bear trade obligations. MTCS acknowledges that one company's accounts payable is another company's accounts receivable. In theory, as long as these loops in the trade graph can be identified, companies can clear their obligations by offsetting each other. This reduces their concerns about cash flow and increases the productivity of the economy. MTCS has been deployed in some economies, and research shows significant liquidity savings. It is also worth noting that MTCS is part of a broader movement called collaborative finance (CoFi).

In the future, intents and resolvers can enable MTCS or similar technologies to allow companies to clear their obligations and settle on-chain without relying on centralized clearinghouses.

6) Any multi-domain and/or privacy-preserving applications:

- Multi-domain: Ethereum users want to buy Bad Kids NFTs on Stargaze. This path involves many steps, wallets, research costs, operations (i.e., bridging and wrapping assets), and risks across four blockchains spanning two ecosystems. We will delve into this in the Theia and Chimera chain section.

- Privacy-preserving applications: Intents are suitable for generalized privacy-preserving computation. Through intents, we can build private multi-party barter, private DAOs, and more. We will discuss the privacy aspects of intents later in this section.

4. Counterpart Discovery and Resolution

Anoma intents consume and create some "resources." To simplify a bit, in our intent example [+1 ETH, -2000 USDC], we can consider the created resource as 1 ETH and the consumed resource as 2000 USDC. When the created and consumed resources of the same type of intent do not offset each other, the intent is considered unbalanced. To pass the balance check, the sum of created resources must equal the sum of consumed resources for all involved resource types.

Technically, this balance check is the only factor distinguishing Anoma intents from Anoma tx (not to be confused with Ethereum tx). In short, in the Anoma world, balanced intents are called, you guessed it… transactions. By the same logic, Anoma intents are just partial Anoma transactions.

Intents are combined by solvers in a p2p intent gossip network. When two Anoma intents are combined, they produce a composite intent, which is another intent with resources that aggregate the resources of its constituent intents. Intents can be combined with each other as long as the solvers are willing. Ultimately, solvers form a transaction through "balance checks," at which point they can choose to settle on-chain.

Below, we see some unique ways to match intents to form fully balanced transactions.

- Resolver brings its own liquidity: The resolver acts as the counterparty by accepting the transaction.

- Partial fill: The tokens sold are collectively purchased by many independent parties.

- Direct mirror: Two intents are directly opposite to each other.

- Circular trade: Even without a direct match, intents can be resolved. For example, 3 intents can produce a balanced transaction, even if no pair of intents satisfies each other's preferences.

5. Resolver Incentives, Review, and DoS Resistance

Creating a network that can resist DoS and withstand review is very challenging. To achieve this, Anoma's intent gossip layer is designed to default to path verification; all gossip messages are signed by the sending node, forming a signature chain that can be traced back to its originator. Path identity verification plays a crucial role in DoS and anti-censorship. First, we enhance resistance to censorship.

In most cases, solvers are likely profit-seeking agents. They execute and settle intents in exchange for fees, with settlement as a condition for fees; intents contain fees, and solvers can only collect these fees when they settle on-chain. This creates a competitive environment where solvers compete with each other to be the first to resolve an intent. Resolver competition is beneficial and desirable as it improves the quality of execution for users (speed, price, etc.).

On the other hand, if incentive measures are mishandled, competition may spiral out of control, stimulating greed and corruption in the network. Nodes may start "hoarding" intents to gain a competitive advantage in resolving intents, hindering the censorship resistance of users. Path verification elegantly addresses this issue by laying the foundation for incentive mechanisms that encourage widespread intent propagation.

Consider the following example:

A resolver observes two intents, [+2 ETH, -4 NFT] and [-1 ETH, +2 NFT], which, although compatible, do not form a fully balanced transaction. To form a complete solution, the resolver needs to find other compatible intents. To propose a complete solution, the resolver can spend time observing incoming intents. However, this is risky because there may be other solvers handling the same intents. If the solution is resolved by another resolver, they may miss the opportunity to collect any fees.

Path identity verification provides an alternative, allowing nodes to prove their efforts to the network. Instead, nodes can claim partial fee and pass their partial solution [+1 ETH, -2 NFT] to other nodes to continue the resolution process. In the end, each of them can receive a fair share for their contributions to gossip and resolution. In this way, the intent gossip layer can be imagined as an incentivized data availability layer. Even with giant solvers with deep liquidity and closed-source algorithms, smaller solvers can contribute and earn fees, continuing to contribute to the censorship resistance of the network.

Path identity verification is also crucial for resisting DoS. In the case of conditional fee settlement, solvers spend computational resources without any guarantee of reward. Looking back at the history of account abstraction (AA) in Ethereum, we know that this opens the door to cheap DoS vectors. Path identity verification plays an important role in protecting nodes from malicious actors. That is, nodes can track the behavior of their peers (and users). Over time, they can build their own local trust graph to determine who to trust in the network and to what extent.

6. Information Flow Control

Information control in the crypto space is still an unsolved problem. In general, users lack the ability to control who they disclose information to. In most cases, all user activity information is exposed to all on-chain observers. This fundamentally limits the use cases that decentralized applications can promise to enterprises and retail users.

For those interested in a comprehensive understanding of the privacy landscape, we recommend our "Everyone Needs Privacy" report.

The Anoma architecture paves the way for novel privacy-preserving applications through its unified execution environment (EE) called Taiga. To understand Taiga, we must first understand the meaning of information flow control.

Privacy is meaningless without observers. When we talk about privacy, we must first define who the observers are. In our context, observers are divided into two camps. We may be dealing with observers of on-chain activity (almost anyone in the world) or off-chain agents (such as solvers and gossip nodes). Additionally, the information we care about may be about "who," i.e., the identity of the intent signer, or "what," i.e., the functionality and/or data expressed in the intent.

Based on this framework, Taiga defines three types of intents: transparent, shielded, and private. Shielded intents hide "who" from everyone but expose "what" to off-chain ZK provers. Private intents go further, using various privacy-preserving techniques (TEE, MPC, threshold FHE, etc.) to hide certain information about the "what" from solvers.

Taiga is a unified execution environment that provides composable privacy. Composable privacy means developers can release applications and allow users to interact with each other through transparent, shielded, or private intents in the same application. This makes privacy a choice for users, in stark contrast to the current state where privacy is always a choice of the application/infrastructure (DEX is either private or transparent).

Intuitively, there is a fundamental trade-off between counterpart discovery and privacy. Intents that hide information about the "what" can receive fair treatment, but may be more difficult to find compatible counterparts. Therefore, the market can price transparent, shielded, or private intent resolutions based on the quality of execution.

It is worth noting that there are some research challenges. In particular, while solvers can match shielded intents with transparent intents, and vice versa, the feasibility of combining them with private intents is still an open research problem.

Today, most (if not all) privacy projects only focus on information control at the settlement layer. This is understandable, as it is urgently needed. We first want users to be able to hide certain information from on-chain observers. However, in doing so, projects often sacrifice information control at the counterpart discovery layer. In contrast, Taiga focuses on information control at both the settlement layer and the counterpart discovery layer.

Privacy at the settlement layer is typically achieved through ZKP to shield on-chain data. However, ZKP has significant limitations in privacy. They are usually only useful in specific cases, where users prove properties of states they exclusively own. This is suitable for payment or identity-related applications, but not for applications where multiple users interact with each other.

Typically, multi-user applications address this limitation by introducing a shared ZK prover that collects all private user data, performs some computation on it, and publishes a ZK proof of the computation on-chain on behalf of the users. At best, this only provides Web2-style privacy. While user activity is hidden from on-chain observers, it is fully exposed to a single, shared, centralized solver; the ZK prover. It may also bring new challenges to unauthorized and censorship resistance.

Taiga offers something unique in this regard. Because intents do not assume immediate resolution, they can be executed by independent solvers through many partial steps. Solvers can match some shielded intents with other shielded/transparent intents and pass this matched ZK proof to other solvers to continue the resolution process. Proofs generated by independent parties at the network edge can be combined with each other.

In the architecture we ultimately obtain, no single observer can fully understand the partial execution leading to transaction settlement. As shown in the diagram below, each of the three solvers has local visibility into some intents, but no single solver has complete visibility.

Last but not least, Anoma also focuses on information control at the settlement layer. In fact, the first application to be launched in the Anoma ecosystem will be Namada: a privacy-preserving settlement layer. Namada's unique product is a unique multi-asset shielded pool (MASP), where all fungible and non-fungible assets can share an anonymous set. In turn, this allows owners of these assets to form a large anonymous set to protect each other's privacy. Namada will soon be launched as a compatible application chain with Cosmos and IBC, aiming to be a multi-chain privacy layer, initially focusing on the Ethereum and Cosmos ecosystems.

7. Intent Settlement

The lifecycle of Anoma tx is as follows:

User signs intent → Intent propagates in the p2p layer → Solvers match compatible intents and form a tx (counterpart discovery and resolution) → Tx settles on-chain. In this section, we will delve into settlement.

Settlement requires validation on-chain. Validation is done through on-chain functions called predicates. Every account (user and token) in Anoma has an associated predicate that restricts the possible future state sets authorized by that account. The simplest way to conceptualize predicates is to view them as restrictions that can be imposed on their bank accounts or smart contract wallets.

• Whitelisting/Blacklisting: Only send funds to accounts X, Y, Z, only perform ETH transfers, etc.
• Rate limiting: Not to exceed X amount per day.
• Access control: 2 out of accounts X, Y, Z must sign the transfer.

Intents and predicates are similar in function; they both express preferences for the state space. The main difference is that intents, as a transient expression of preference, exist off-chain, while predicates, as a persistent expression of preference, exist on-chain (although they can be updated at any time). Together, they constitute a two-layer authorization scheme. Transactions must satisfy both to successfully settle on-chain.

The primary role of predicates is to ensure atomic (all or nothing) settlement. For a transaction to settle and progress the on-chain state, it must satisfy the predicates of all accounts involved.

For example, the ETH>USDC swap between Alice and Bob can only settle successfully if the predicates for Alice, Bob, ETH, and USDC are all satisfied. If the state transition cannot satisfy any of these involved account's predicates, the state transition will fail, and the on-chain state of any of the accounts will not change. In short, if all parties involved give the thumbs up, the state transition succeeds; otherwise, it fails.

8. Expectations vs. Smart Contracts

Expectations and smart contracts are similar in some ways and different in others. While both exist on-chain, code expectations are only concerned with validation and not execution. They do not execute step-by-step imperative commands. Given a transaction, they only need to check if they are satisfied and return a boolean value; either authorize or do not authorize.

In this regard, intents and expectations may provide a safer way for users to interact with applications. Users no longer need unrestricted access to smart contracts and reasoning about the opcodes in their execution path.

Another significant difference between the two is that functions run by expectation words do not have any state. Because they are pure functions, validation can always be fully parallel.

8. Open Research Areas

Declarative execution has many open research areas worth further exploration. As we conclude the first part of our series, we leave you with some thoughts as we move on.

- Resource Pricing: As we have seen, conditional fee settlement may make it difficult for nodes to correctly account for the resources they consume. In addition to token gating and fees, we can also expect new trust network-style witch resistance technologies to emerge in the future. A user's on-chain history, identity, and reputation will play a crucial role here.

- User Interface Security: With execution moving off-chain, frontends and wallets will bear more responsibility to ensure that users accurately sign their intents as expected. Therefore, user interfaces will play a more important role in security. How they will adapt remains to be seen. Can blind signature hardware wallets become a thing of the past?

- Solver DAO: Solvers may have reasons to coordinate with each other during the resolution process. They can find value in aggregating their liquidity, providing better guarantees for solving problems, and reducing wasteful failed attempts to resolve transactions. In some cases, solvers may want to coordinate with each other through consensus protocols and/or run MPC between each other. The topology of the solver network will correspondingly form.

9. Conclusion

With this, we conclude the first part of our Anoma series. In the second part, we will focus on the application layer. We will highlight the growing trend of well-known dApps transitioning to intent-based architectures. We will also analyze the unique value proposition of the Anoma architecture for these existing dApps and upcoming new dApps.

Stay tuned.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。