Generality is difficult to address. Account abstraction addresses some special problems. Limit orders other special requests. What brings them all together in a general framework?
Before we try to address intents head on, let's start with some concrete cases that illuminate the concept. Mathematics, Physics works by abstraction. Numbers, functions and fields etc are all inspired from real world usage of a lot of concepts before they are abstracted. We will also take a similar path. Before talking about Intents and what they are, let's see a few cases which make the intuition of intents much clearer and less abstract.
MEV is a consequence of blockchain transactions being processed sequentially and being transparent in public mempool. They are at the mercy of the searchers, builders and validators to add it to the block. These actors, motivated by profit, are able to use transparency of transactions to their advantage and insert transactions before and after the user generated ones to extract value. Encrypted mempools are one of the ways to solve this extraction of value by committing to the order of transactions first and then decrypting them. More on this later and how it relates to the concept of intents.
Cowswap came with batched transactions and off chain solvers for MEV mitigation and better prices. The offchain solvers are incentivised to offset buy and sell orders and batch them together to reduce slippage. COWs or coincidence of wants is an offchain intent that is passed on to the solvers instead of the transactions themselves. These are matched by solvers with other COWs that are able to balance the other side. Cowswap takes this to the next step - ring trades or multidimensional swaps where there might be 3 or more asset trades that don’t offset each other directly, but when they are executed together, can offset as a whole. Uniswap X also uses off chain MEV searchers, solvers that would find the best price for the swaps.
Batched transactions and limit orders are special cases of intents, and Anoma is working towards a more general infrastructure. Anoma and SUAVE are addressing the missing component in the current paradigm for the users - Limited discovery of all options / counterparties and computation required find the best path.
Growing Complexity of intents
Let's look at intents from another angle. UX is one of the biggest problems in web3 dapp experience. Users have to sign for every interaction on dapps using current wallets. Account abstraction is trying to tackle that by creating smart contract accounts. These smart contract accounts can be set up with arbitrary validation logic for transactions, unlocking things like batched transactions, session keys, multifactor authentication. Account abstraction captures some common workflows. How are intents related to all this? Though account abstraction is a way to customise transaction validation, they are not able to express arbitrary demands themselves. Account abstraction is a developer focused tool to customise things. Intents is a more user focused solution. After the intents are expressed by the users, solvers create transactions that would satisfy them. AA is a more permanent logic that can be encoded into smart contract wallets, but intents can include potentially anything and hence needs dynamic encoding every time.
The amount of options and counterparties that are available for a user determines the quality of the decision. If there is less liquidity, prices are worse. If the marketplace doesn’t have the widest options, the buyer gets a bad deal. If there are limited buyers, sellers get a bad price too. Applications fragment the counterpaties for satisfying needs. Users typically just go to the largest collection, like Amazon, Doordash, Uniswap, Opensea and discover their counterparties. But it’s possible that a better option is available somewhere else. Intents want to bring all these options of all kinds, physical goods, financial products, services under one single roof.
Current users use applications like AMMs, order book based DEXs, centralised servers, marketplaces for counterparty discovery. These ways serve the well defined usecases. In most cases our intentions are more complex than a simple buying decision, for example planning a trip. It has ticket buying, hotel booking, food and lot of inter-related activities that we make decisions about together. There aren’t applications to address and optimise for things like these. Again, we need dynamic search for all options and find the best options that work together.
Now that we have seen limits in multiple areas like account abstraction, applications, limit orders etc, we take a look at the solution space in terms of blockchain paradigms.
There have been at least 3 major shifts in the blockchain paradigms. The first one the invention of Bitcoin and scriptable settlement. Using this, it was possible to come up with things like Color Coins etc but it was still rudimentary. Vitalik came with an insight of a general purpose Turing complete VM and a programmable settlement. This unlock in the capabilities of infrastructure lead to new generations of apps. NFTs, ERC-20 tokens, DAOs, AMMs and on-chain lending were possible while maintaining a censorship resistant system. Next came a wave of improvements to the Programmable settlement on multiple fronts. In scaling, we had optimistic rollups, zk rollups, zkevms, subnets. On the UX front, account abstraction, seedless wallets came. POS became the dominant sybil resistance mechanism. This has led to improvements in apps, low gas costs, better UX, zk bridges and a lot more.
Anoma and SUAVE are trying to bring a new paradigm in blockchains - intent centricity. Even though there are serious improvements in the blockchain infrastructure, users are still expected to understand security, differences in protocol architecture, bridging standards for getting simple things done. Merely solving the UX problems using Account abstraction won’t take away the underlying complexity of choosing among so many different protocols and risk/ rewards. Sophisticated entities like searchers / builders / solvers, good at finding best execution are the beneficiaries of this infrastructure. Why not abstract away and outsource the underlying complexity of information, choice and decision making to stakeholders like these?
Goal + Path = Transaction; Sum(Intents) = Transaction
Blockchains have transactions as their basic unit. Transactions trigger changes in the state machine. Because the transactions are imperative and executed as it is, they presuppose that the user has a complete idea of the options and how to get it executed. The EVM and Turing complete machine deals with deterministic steps for execution. Transactions specify how to interact with the protocols to get to some goal. It is effectively a sum of goals and steps on how to get it done. Intents are partial transactions, and a bunch of them together form one whole transaction. Intents don’t go to the execution engine directly. Intent just expresses the end state that the user wants and a list of preferences that he would like to have satisfied. It is the job of solvers to find counterparties, path to execution and craft the transactions and send it to the execution engine.
Anoma defines intents as “ binding commitments of preferences over state space”, which means intents don’t specify the ‘how’ but just the preferences that constrain the end state that the user may like.
Intents are partial transactions. This is because the counterparty and the particular execution are unknown and kept open. It is the job of the searchers to fill these fields according to the preferences and end state that the user state. The searchers scan the sea of intents to match the ones that satisfy all of the intents that balance each other to create a transaction.
Let’s have a look at the components that Anoma has created to make all this possible.
Anoma architecture is designed to bring forth these principles.
Let’s take a look under the hood of what makes all this possible.
As we mentioned in the beginning, MEV is a result of transparent transactions. If intents are public, they will be taken advantage of by extraction of MEV. TEEs is one way to do it. This requires the mempool observers to use Intel SGX or similar hardware to encrypt the transactions before they’re ordered and committed. SUAVE is actively testing it. Distributed Key Generation (DKG) and Threshold encryption is another way of making the mempool encrypted till the order of transactions is committed. Anoma is using DKG and Threshold cryptography for creating private mempools. DKG creates a single public key with distributed pieces of the private key called key shares. When the user submits the intents, they’re signed with this public key and encrypted till they’re ordered. After the order is committed, the validators can use threshold signatures to decrypt the transactions. This requires 2/3 majority of validators to decrypt, giving us crypto economic guarantees of privacy.
When the users create intents, they’re passed to the gossip layer for wider dissemination. It is permissionless for anyone to join, including the users that send the intents. The gossip layer is path authenticated too. This means that if the intent is complex and needs series of intent matching, intermediate solvers and gossip nodes are tracked and rewarded for their participation. If a solver finds a new intent that only partially fills a given intent, they can put a claim on their efforts and provide the resulting partial intent to other solvers. After other solvers are able to find the offsetting intents, both the solvers get their share for their efforts based on path authentication. Using path authentication, the solvers can also maintain local trust graphs for frequent collaboration.
Since intents are partial, group of intents as transactions are atomic in nature and it is quite likely a lot of the intents would leverage cross chain transactions. Typhon is built to replace the Tendermint consensus Anoma currently uses. The mempool uses Narwhal for better transaction dissemination, Consensus uses Heterogeneous Paxos and Chimera chains for cross chain atomic transactions. Multiple base chains can connect to a Chimera chain which settles atomic cross-chain transactions between them. Different chains have different validators and for achieving atomic cross chain transactions, it becomes necessary to have multiple rounds of consensus. This increases the latency. Heterogeneous Paxos avoids this and instead relies on the chimera chain consensus between all the other chains for atomic transactions. The execution engine is concurrent that allows for parallel execution as long as the different states are unrelated to each other.
Typhon components
Taiga is a protocol for shielded state transitions. It is based on the UTXO model consisting of notes. The applications built on Taiga have state in form of notes that belong to the application and validity predicates as its logic (like smart contract). These validity predicates are a form of account abstraction, defining the authorisation logic. There are validity predicates for the applications and other set for the users. The applications set how the notes are spent using application VP and users have their VP for intents. When the user creates intents and intent notes, the solvers find another notes that follow the validity predicate of the application, user intents. Taiga is shielded by default and uses zkps to shield the data about the user, transactions and the validity predicates.
Every account on Anoma has validity predicates as invariants. Traditionally, supply of the cryptocurrency supply etc are invariants baked into the core protocol itself. Validity predicates can be viewed as persistent expressions of preferences and intents as ephemeral expression of preferences. Transactions created by solvers are checked against Validity predicates to ensure. Validity predicates are arithmetic circuits created after the intents are specified, passed to the Taiga Circuit to check against transactions created by solvers. These use Halo2 currently but will be using Anoma’s own intermediate language called Vamp-IR.
Vamp-IR is a target agnostic intermediate language for writing arithmetic circuits. Vamp-IR is not meant to be writing the circuits or even executing it. Other languages like Circom, ZoKrates, Alucard, Juvix (last 2 created by Anoma) can be used to write the circuits that can be converted to Vamp-IR. It is also target agnostic, meaning it can be further compiled to Halo2, R1CS, PLONK, PLONK with Lookup etc.
Vamp-IR, similar to LLVM
To wrap up the overview on Anoma, it uses
The expressivity of the intents is inversely related to the amount of computation required to solve it. One of the edge cases being, regular transaction that is not expressive requires no solving. There isn’t much Mathematical formulation of how intents would be represented and solved, except this amazing blog.
Summarising the blog, the blockchain state space can be modelled as a physical space. The initial and final sates that users express via intents are similar to moving from a point to another. There are some constraints via intent preferences that can be seen as holes in the space where the particle is not allowed to move from. In physics there is a well known method to find the motion of particle when end points are given and we have to find the best path subject to some constraints. It is called Lagrangian mechanics that can find paths that minimise energy, time, distance. In the case of intents, these constrains could be MEV and others. It’s a very interesting model for optimising paths (transactions) based on the end states (intents).
Discovery ⇒ Commitment ⇒ Execution ⇒ Settlement ⇒ Discovery
At the MEV day event, Mekatek founder presented the idea of combining curation with Intents. The flywheel would be made up of common intents after their settlement in the public ledger and interface that suggests them to the users. Intents, in combination with LLMs built using these curated intents would serve as a great UX alternative for the web3 dapps.
Solvers or searchers are usually profit seeking parties that are playing short term games. These build bundles that are sent to different builders in the current MEV supply chain. Even in the current paradigm, very few searchers have a long term engagement with builders. They send the bundles to as many builders as possible.
For alignment of incentives with the users, we could have reputation based systems to build trust with the users based on their repeated engagement and enforcement of accountability. In this case since the user delegates the searching to the solvers, they are accountable and build a reputation. The user can delegate the enforceability of the rules with the chain, with proposers or validators.
PBS was an attempt to reduce the centralization effects at the validator level, creating searchers and builders for specialized building. The builders and searchers collaborate to extract maximum MEV in form of front running, back running and arbitrage. Bringing intents into the picture introduces an extra variable towards which the searchers will have to optimize. The searchers can no longer build bundles and builders build blocks that are highest in value for the proposers. The searchers have to build bundles that are highest in MEV value for getting accepted by the builders while ensuring that they build bundles that comply with the user intents. The proposers also have to check for compliance with the intents, highest value in terms of MEV extracted for selecting blocks.
COWSwap, Uniswap X, 1Inch Fusion use intents and off chain solvers and optimisation already. There is lack of privacy and composability of intents in these applications. They also have to maintain a separate infrastructure for off chain solving, execution etc. Anoma can be similar to AWS which provided servers, compute as a service to the applications, allowing them to focus on the product related problems. This is similar to zk proofs as a service for teams, so that they don’t maintain the provers, verifiers etc. Apart from freedom of maintaining the infra, Anoma also provides composable privacy and arbitrary intents. The intents can be as general as possible while the solvers and applications focus on specialising using the stack provided by Anoma.
