An Overview of Anoma's Architecture

18 March 2022Awa Sun Yin
  • blockchain
  • Anoma Tangram

Anoma incorporates many different concepts, components, and mechanisms in its protocol. Learn about Anoma’s architecture on a high level and understand how it all works together to deliver an innovative universal coordination mechanism.

Introduction

In a barter economy, the simplest form of bartering consists of two parties who meet and trade, requiring a double coincidence of wants, as well as both parties being available so the goods in question can easily be transferred. It has become increasingly difficult to coordinate with existing mechanisms in a way that is mutually beneficial, something that is detailed in Anoma’s vision paper. Anoma implements a digital bartering scheme that can facilitate the trade of goods, services or digitally represented value that is only subject to computational constraint. Anoma requires neither a double coincidence of wants nor the usage of a particular currency. Instead, the exchange of value in this digital bartering scheme is possible for up to n parties as long as all parties desire the exchange.

In order for digital bartering to function, Anoma requires, at the very least, users to be able to find each other and be matched in order to execute a mutually beneficial trade. The intent gossip network contains two key roles in the Anoma network: intent gossip node operators who help users communicate their intents, and matchmaking node operators who are running software that checks if these intents are compatible with each other, in order to create a transaction to match them. Following the article on intent gossip node operators, which describes the first essential component of the intent gossip network, this article builds upon this process of enabling counterparty discovery for the purpose of bartering, where intents get matched by matchmaking node operators before being sent to the ledger to execute the transaction.

Basic Concepts

Transactions

A general transaction is foundational to both blockchains and coordination. Transmitted via a network of decentralized computers, a new transaction can be validated and submitted to a validator. These blocks are then chained together by validators using cryptography, creating a long history of permanent transaction information that cannot be altered or reversed. This transaction could be as simple as Alice exchanging 1 BTC for 5 ETH with Bob, or more complex content that intents enable, ultimately validated by validity predicates.

Intents

While every blockchain has transactions, none of them utilize intents. Unique to Anoma, an intent is a way of expressing a user’s desire that can describe what they want - what they want to buy and sell, and constraints (see customizing intents in ‘Enabling counterparty discovery with Anoma’s intent gossip and matchmaking system’), with varying degrees of complexity. This is defined by arbitrary data, allowing users to express wants that range from defining a selling order for a specific token, such as BTC, to offering experiences such as a boat tour in Paris, to only buying from manufacturers who have incorporated carbon costs in their supply chains. This piece of code more explicitly states what future state a user is willing to accept.

Struct Intent { version: 1 asset_sell: { #btc: a1v4ehgw368ycrgv6xg5erz32rx56nqsjzg3zyvdzzgy6n2djyxprygv2rxvcrjv34xpqnvvzyhq0gj4 } asset_buy: { #eth: a1v4ehgw36xymyz3f58qc5gv6rxcmyy3fsg5mrws3jxepr2335xsunsd33g4znqs2rxvcyzs3s47deg0 } price: { #eth: [ Min(#eth, 10000000000000000000) Max(#eth, 10000000000000000000) Max(#btc, 100000000) ] } expiration: 1641026034 fee: { matchmaker: { source: #btc, amount: 100 } gossip: [] } }
Fig. 1: An example of an intent where a user wants to trade 1 BTC for 10 ETH in Rust.

For example, if a user has 1 BTC but is willing to hold 0 BTC if they receive 10 ETH, they can write an intent stating so (shown in figure 1). This intent, among many others, gets “gossiped” i.e. communicated by intent gossip nodes that communicate data that represents the user’s desire in seeking compatible intents. Intents are scouted by matchmaking nodes, trying to find two or more that are compatible. In this case, this would be an intent from someone who is willing to sell 10 ETH against 1 BTC. Because matchmakers are responsible for finding other compatible intents to create valid transactions, intents must be written in code legible to matchmaking nodes.

The Role of a Matchmaking Node Operator

The role of a matchmaking node operator, in essence, is to run software that sees if intents are compatible with each other. Matchmaking nodes take intents from the gossip layer containing a local subset of intents, which consists of all known and matchable i.e. valid intents, and find compatible intents before crafting and submitting corresponding transfers to the ledger. As previously mentioned, intents must be understood by the matchmaker, therefore particular matchmaker algorithms are tied to specific formats of intents. These assets are encoded into a specific schema, which enable matchmakers to easily decode the intents to discover matches from the intent gossip network.

The matchmaking node is a novel feature that enables bartering. Subsequent updates of the current matchmaker will not only allow the exchange of tokens, but also NFTs, which will mean an added language on top of current intents for more constraints to be expressed. For example, if user Alice wants to sell BTC and buy a CryptoKitty, constraints can be written in a way that specifies that Alice only gets a match if the kitty has blue eyes.

Another example would be a multi-asset exchange, which expresses constraints between the assets that one wants to buy, such as a concert ticket or a flight, or a concert ticket and a flight. In this situation, a user can write intents that specify that they only want matches where the concert ticket and flight have to be on the same day. The matchmaking node operator runs the software which allows all these intents to find each other, including partial intents that enable n parties to be matched. In the previous example, this would be in the case that different users are offering the concert tickets and flights.

The design of most public blockchain protocols so far have not included components like the matchmaker, but the flexibility they enable is crucial for the full utilization of Anoma’s features. Anoma’s protocol fundamentally differs from the design of existing Decentralized Exchange (DEX) protocols (built on top of smart contract platforms) in which this flexibility allows more peer-to-peer-oriented and permissionless transactions. Limit order books, such as a market for USD against ETH, mean that things traded on exchanges and DEX protocols are preconceived and predefined. Not only does this not exist on Anoma, but it is user defined, meaning that an active market can be created for something that has never been traded before. The existence of the matchmaker allows the coordination of digital representations of value , working in a way that if ‘matchmaker 1’ cannot match, they can either wait and keep the intent to themselves, or propagate it and let other matchmaking nodes match the intent, charging a small fee for matches. Matchmaking node operators may also run multiple matchmaking nodes, where each of them understand different topics, in order to match intents more efficiently.

The Matchmaker Process

Prior to the matchmaker process, intent gossip nodes who have connected to each other create the intent gossip network, which has knowledge of all matchmakers subscribed to them. This includes a list of which topics these respective matchmakers are interested in and looking for intents of these topics, for example BTC, or CryptoKitties. The intent gossip nodes also keep all the intents and distribute them to the matchmakers that correspond to each topic. Following this process, different matchmakers receive intents from the topic of their choice, such as intents that specify that the user is looking to trade above a certain amount of ETH, kickstarting the matchmaker process, described in figure 2.

Figure 2
Fig. 2: The matchmaking process, and the intent gossip network / layer in relation to matchmaking nodes.

The matchmaker process and node is composed of four different services, starting with the RPC, which controls the way that the matchmaker communicates with the gossip nodes, and vice versa. If the intent gossip node receives an intent with the topic that the matchmaker wants, the RPC receives the intent and sends it to the next service, the filter. The filter checks the validity of the intent, an invalid example being a user not having enough BTC that they want to sell. By eliminating invalid intents, the matchmaker process is more efficient, making sure all transactions going to the ledger are correct and possible. Without checking the integrity of the matched transaction, a matchmaker faces the risk of losing gas fees, if the transaction included in the ledger would not be valid. The filter can be modified by the operator, allowing the operator to set the matchmaker to only match, for example, high volume intents above a certain amount of currency, or only matching intents with less than 3 constraints, therefore making computing easier.

Succeeding the filter is the matchmaker, with the service of actually matching intents. The matchmaker within the matchmaking node is connected to the state, which is where the matchmaker stores everything, including intents and data structures. If a match is found, the matchmaker sends the transaction to the ledger node, leaving the matchmaker process. If a match cannot be found from the intents that the matchmaker draws from the state, it can save it to the state or send it back to the intent gossip node for rebroadcasting.

Join Anoma as a Matchmaking Node Operator

Anoma’s most recent release of the first public testnet, Feigenbaum offers two ways to interact with a matchmaking node. The user guide will guide you through the process of installing the testnet and running an intent gossip node (that includes a matchmaker) starting from:

  1. Installing Anoma by pulling the code from the repository and following the instructions on the docs.
  2. Joining the testnet by running anoma client utils join-network --chain-id=anoma-feigenbaum-0.ebb9e9f9013
  3. Run and intent gossip node with the intent gossip system, a token exchange matchmaker and a RPC through which new intents are requested by running: anoma node gossip --rpc "127.0.0.1:39111" --matchmaker-path wasm/mm_token_exch.wasm --tx-code-path wasm/tx_from_intent.wasm --ledger-address "127.0.0.1:26657" --source matchmaker --signing-key matchmaker (mind that matchmaker should be a valid key in your wallet)

This method offers the first way of interacting with a matching node, using a pre-built matchmaker implementation that has the ability to submit transactions from matched intents to the ledger. The second method of creating a custom matchmaker, can be built from wasm/mm_template. A matchmaker code must contain the following function, which is called when a new intent is received:

#![allow(unused)] fn main() { use anoma_vm_env::matchmaker_prelude::*; #[matchmaker] fn add_intent(last_state: Vec<u8>, intent_id: Vec<u8>, intent_data: Vec<u8>) -> bool { // Returns a result of processing the intent true } }

Subsequent instructions on other functions, such as updating the state and the interface available in a matchmaker can be found under the instructions for creating a custom matchmaker.

Conclusion

Matchmakers are the second puzzle piece in the intent gossip network that are responsible for matching intents together that intent gossip nodes have propagated for the purpose of counterparty discovery and bartering. Matchmaking node operators have the flexibility of customizing and running multiple matchmakers in topics of their liking, earning a small fee for successful matches and being a facilitator for user wants and desires. The role of the matchmakers are integral to Anoma’s growth, increasing accessibility for users looking to coordinate. Whether coordination happens across geographical or cultural proximities, they bring the network closer to its vision of private bartering, especially among any number of parties.

If you have any questions or need assistance regarding the setup and details of running a matchmaking node, members from the team building Anoma are on the #feigenbaum channel on Discord to answer testnet-related questions. On this channel, you can connect with other members of the community who are also running nodes.

To stay updated with all testnet-related news, we recommend that you sign up for the testnet newsletter, and follow us on Twitter.

Explore Further: