Author: Delphi Creative

Translation: Huohuo, Plain Language Blockchain

What is Anoma? Anoma is not a blockchain. Or, more accurately, it is not just a blockchain. Let's take a look at the pre-released Anoma whitepaper for some hints.

"The programmable settlement architecture cannot achieve transaction counterpart discovery and resolution, both of which are necessary to build most interactive multi-party applications. The limitations of the programmable settlement architecture mean that contemporary application protocols must have at least one Web2 component, which becomes a centralized point. We introduce Anoma, a unified architecture for full-stack decentralized applications. Anoma's design follows the principles of intent-centric and homogenous/heterogeneous security, together forming a declarative paradigm for building decentralized applications. Anoma's architecture also introduces novel primitives, such as composable privacy, which enables applications to handle transparent, shielded, and private states and operations; and multi-chain atomic settlement, allowing users and applications with different security preferences to achieve atomicity."

If the highlighted terms above currently don't make much sense to you, don't worry; that's why they are highlighted. We assure you that as we become familiar with the Anoma architecture and the unique problems it aims to solve, they will start to make more sense, which is also the purpose of this report. Due to the broad scope of Anoma, we will divide this report into three parts, to be released as separate reports.

1) Intent, Transaction Counterpart Discovery, Solver

2) Applications (Why do we need Anoma when intent already exists?)

3) Typhon, Chimera Chains, and Multi-Chain Atomic Settlement

1. Intent is Not Just a Meme

Let's start with intent-centric.

Although intent-centric Anoma architecture has been developed for many years, intent is still a new term for many people. From our observations, intent does not yet have a standardized definition. Some people think intent is not much different from a transaction, or even just a new term for a limit order. This is common in a space where all words are made up of cryptic components.

The good news is, we have indeed reached some rough consensus on what users can do with intent. Intent-centric execution is generally understood as a paradigm in which users express what they want and rely on third-party agents and intermediaries to achieve it. To put it more clearly, users retain custody of their assets, but the complexity of interacting with the blockchain is abstracted from the user and pushed to these complex third-party agents. A major motivation here is to simplify the user experience.

Intent is considered declarative, not imperative. In intent-centric execution, users can define what they want without specifying the intermediate steps required to achieve the goal. Intent only cares about "what," not "how."

While Anoma's intent aligns with this rough definition, Anoma has its own formal definition of intent composition.

Anoma intents are defined as binding commitments 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, 2000 less USDC, and 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 transaction counterparts 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 transaction counterpart who believes in them. Users have signed off on a preference for a state that does not yet exist. To achieve it, their intent needs to match with other compatible intents and be resolved. In the simplest case, we can imagine our intent [-2000 USDC, +1 ETH] matching with its exact mirror [+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 ours. As we will explain later, intents with compatible preferences can be identified and matched in many different and complex ways involving many independent transaction counterparts. This process is called transaction 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 settle on-chain and be verified by the user (settlement will be detailed later). Once verified, the user will directly "jump" to the future state they committed to, or else they will remain in the current state.

Source: Anom Documentation

2. Anoma Intent vs. Ethereum Transactions

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

Recalling, in the 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. Upon completion, it may call some other contracts to pass on control. Execution continues until successful termination or gas exhaustion.

In contrast to Anoma intents that 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. The order of execution 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 intents:

• Sequential, imperative execution vs. declarative execution based on binding commitments
• Authorizes execution paths vs. authorizes future states
• Final state depends on execution order vs. execution order is not important
• On-chain execution only (execution and verification interleaved) vs. off-chain execution, on-chain verification
• Settlement guaranteed vs. settlement not guaranteed *
• Known transaction counterpart vs. unknown transaction counterpart
• Arbitrary state changes vs. binary state changes
• No need for other transactions to settle vs. need other intents to resolve
• Settled by the user vs. settled by third-party agents

* In the absence of compatible transaction 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 laid 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 trade. 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 AMM orders by committing to trade based on the xy = k curve. In fact, intents can be programs, and can even be algorithms with quite complex commitments. These can be conditional or unconditional. They may also depend on other commitments (so-called higher-order commitments) to pave 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, as they are complementary goods.
• Economic substitutes: Buy as much USDC or USDT as possible with some ETH.
• Counterparty discrimination: Sell a maximum of two units of A, with counterparty C1 pricing at 10 USD, C2 at 9 USD, and C3 at 8 USD.

Expressive bids better align with the motivations of sophisticated users in the market. It can be used 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:

• Investment with reduced risk: Commit to providing funds for a project only when commitments exceed X USD.
• User pre-commitment to donate to a winning project, but not knowing which project it will be.
• Peer pressure: Commit to funding an activity only if your favorite influencer also commits to 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 transaction 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:

OTC trading of NFTs 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 transaction 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 future time only if the price is within a specified range.
• Subscription: Pay-as-you-go model, where users commit to paying a fixed amount per unit of time within a predefined time period.
• MTCS, also known as debt settlement, is a unique and powerful technology that can save the liquidity of an economy.

The idea behind MTCS is simple. If Alice owes 1 ETH to Bob, Bob owes 1 ETH to Greg, and Greg owes 1 ETH to Alice, 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 settled.

Similarly, in the real economy, companies often take on trade obligations. MTCS acknowledges that one company's accounts payable are another company's accounts receivable. In theory, as long as these loops in the trade graph can be identified, companies can clear their obligations through mutual offsetting. This reduces their concerns about cash flow and increases economic productivity. MTCS has been deployed in certain economies, and studies have shown significant liquidity savings. It's also worth noting that MTCS is part of a broader movement called Collaborative Finance (CoFi).

In the future, intents and solvers could enable MTCS or similar technologies to allow companies to settle their obligations and perform settlements on-chain without relying on centralized clearing.

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

• Multi-domain: Ethereum users want to purchase Bad Kids NFTs on Stargaze. This path involves many steps, wallets, research expenses, operations (i.e., bridging and wrapping assets), risks, and spans 4 blockchains across two ecosystems. We will discuss this further in the Typhon and Chimera Chains section.
• Privacy-preserving applications: Intents are suitable for generalized privacy-preserving computations. 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. Transaction 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 view the created resource as 1 ETH and the consumed resource as 2000 USDC. When the consumed and created resources of the same type in an 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 resource types involved.

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 world of Anoma, balanced intents are, you guessed it… transactions. By the same logic, 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 composing 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.

• Solver brings their own liquidity: The solver acts as the counterparty by accepting the intent.
• 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 satisfy each other's preferences.

5. Solver Incentives, Review, and DoS Resistance

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

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

On the other hand, if incentive mechanisms are mishandled, competition can 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 scrutiny system. Path verification elegantly addresses this issue by laying the groundwork for incentive mechanisms that encourage widespread intent propagation.

Consider the following example:

A solver observes two intents, [+2 ETH, -4 NFT] and [-1 ETH, +2 NFT]. Although compatible, they do not form a fully balanced transaction. To form a complete solution, the solver needs to find other compatible intents. To propose a complete solution, the solver can spend time observing incoming intents. However, this is risky, as 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 verification provides an alternative, allowing nodes to prove their efforts to the network. Instead, nodes can propose partial fee claims and pass their partial solution [+1 ETH, -2 NFT] to other nodes to continue the resolution process. In the end, everyone 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 scrutiny system in the network.

Path verification is also crucial for resisting DoS. In the case of conditional fee settlement, solvers expend 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 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 what information they disclose to whom. 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 privacy, 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 deploy applications and allow users to interact with each other through transparent, shielded, or private intents within the same application. This makes privacy a choice for users, in stark contrast to the current state where privacy is always a choice made by the application/infrastructure (DEXes are either private or transparent).

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

It's also 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 matching 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 transaction counterpart discovery layer. In contrast, Taiga focuses on information control at both the settlement layer and the transaction counterpart discovery layer.

Privacy at the settlement layer is typically achieved through ZKP to shield on-chain data. However, ZKPs have 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 solve this limitation by introducing a shared ZK prover, which 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 can only provide 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 introduce new challenges for unauthorized and scrutiny systems.

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.

In the architecture we ultimately arrive at, no single observer can fully understand the partial executions leading to transaction settlements. 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 certainly 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 offering is a one-of-a-kind Multi-Asset Shielded Pool (MASP), where all fungible and non-fungible assets can share an anonymous pool. This, in turn, allows the owners of these assets to form a large anonymous pool to protect each other's privacy. Namada will soon be launched as a Cosmos and IBC-compatible app chain, 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 tx (transaction counterpart discovery and resolution) → Tx settles on-chain. In this section, we will delve into settlement.

To settle a transaction, validation is required on-chain. Validation is performed by 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 transact ETH, etc.
• Rate limiting: Not to exceed X amount per day.
• Access control: 2 out of accounts X, Y, Z must sign for a transfer.

Intents and predicates are functionally similar; they both express preferences over 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 those accounts will not change. In short, if all parties 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 more secure way for users to interact with applications. Users no longer need unrestricted access to smart contracts and to reason about the opcodes in their execution path.

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

9. Open Research Areas

Declarative execution has many open research areas worth further exploration. As we conclude the first part of our Anoma 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.
• UI security: With execution moving off-chain, frontends and wallets will bear more responsibility in ensuring that users accurately sign their intents as expected. Therefore, the user interface will play a more important role in security. How they will adapt remains to be seen. Will blind signature hardware wallets become a thing of the past?
• Solver DAO: There may be reasons for solvers to coordinate with each other during the resolution process. They can find value in aggregating their liquidity, providing better guarantees for resolving issues, 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 accordingly take shape.

10. 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.

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