Anoma Protocol

Black Sky's Overview & Analysis

By Stellar Magnet, Serinko

Project Summary

Anoma is a new privacy-focused protocol that includes native features for counterparty discovery based on matchmaking intents, with support for multi-chain atomic settlements ¹. Anoma is being developed by Heliax AG (Heliax), who are the founding development team funded by the Anoma Foundation, the latter of whom raised a $6.8M seed round in January 2021 and a $26M follow-on round in November 2021, valuing Anoma at $260M. ²

The narrative around the Anoma protocol is heavily constructed around this concept of intents as a core aspect of the protocol design. Intents are envisioned to enable "any digital representation of value to be used as a means of exchange, payment or trade". Essentially, intents are a way for a user of the protocol to broadcast their desire to acquire a good or service for a particular price or within a particular price range. Anoma has broad goals for intents to be used for the bartering of goods and services in local physical communities ³, but there are currently no technical designs for how to realistically establish such barter economies.

In Anoma, validity predicates contain the logic that communicates with the state machine to ultimately identify whether a state change is valid. The validity predicate check is stateless and can be parallelized for any number of accounts that are involved in a transaction.

Initially Anoma is based on Tendermint, a Byzantine Fault Tolerant (BFT) consensus mechanism, but later versions will deploy Typhon, which is Heliax's implementation of Heterogeneous Paxos that enables consensus to be shared across the states of independent (heterogeneous) chains, enabling multi-chain atomic settlement in a singular consensus round. A heterogeneous chain within the Anoma network is known as a fractal instance. ⁴

Anoma utilizes zk-SNARKs to provide transaction privacy, initially with the Multi-Asset Shielded Pool (MASP) that offers a singular anonymity set for both Ethereum and IBC-compatible assets ⁵ within a single fractal instance. Namada is the name of Anoma's initial fractal instance, which utilizes Tendermint and will include the MASP. Future versions of Anoma will replace the MASP with Taiga, which will eventually support a singular anonymity set across multiple fractal instances. ⁶

Heliax is also developing various languages that will spawn private and verifiable interfaces, protocols, and applications within the Anoma network. These languages include Juvix, Alucard, and Vamp-IR. Together, this set of languages is known as the J-group. ⁷

The two main problems Anoma is trying to address are that of scaling the number of parties involved in financial transactions ("n-party bartering") and bringing privacy to these types of transactions.

Highlights

Heterogeneous Paxos and stateless validity predicate checks are each interesting designs in the landscape of scaling blockchain systems. We are curious to see whether Anoma bring this unique vision to life and whether they find success with it.
Vamp-IR, Anoma's language for creating universal representations of arithmetic circuits, can potentially be useful for other zk projects outside of Anoma.
Anoma's v3, with the full vision of Taiga implemented, is a more compelling offering compared to earlier versions of the protocol (v1, v2) that offer less privacy.

Production Stage: Testnet

Feigenbaum was Anoma’s first public testnet, launched in November 2021 ⁸, and is currently down. The next testnet will operate on Namada ⁹, Anoma’s first fractal instance operating Anoma v1. Currently, there is not a way for future users to join the testnet, but future users can submit an email to receive a newsletter of pertinent announcements ¹⁰. There are plans to take Namada to mainnet, but the timeline is unclear.

Overview

Consensus Protocol

Initially Anoma is based on Tendermint, a Byzantine Fault Tolerant (BFT) consensus mechanism, though later versions will deploy Typhon, which is Heliax's implementation of Heterogeneous Paxos that enables consensus to be shared across the states of independent (heterogeneous) chains, enabling multi-chain atomic settlement in a singular consensus round.

This will make possible the creation of multiple interoperable "fractal instances," which are sovereign chains that can have different functional utility and state machines, such as one being a bartering protocol, another supporting shielded assets, and another being a global settlement layer. Each of these fractal instances can have different security models as well, such as being proof of work, proof of authority, or proof of stake, etc.

This design is Anoma's solution for scaling, where diverse chains in the Anoma network will be able to easily intercommunicate with one another and settle transactions atomically, while utilizing independent state machines and security models. ⁴

Intent Gossip & Matchmaking Subprotocol

Anoma includes an intent gossip and matchmaking subprotocol which helps match and settle intents across multiple parties. Anoma does not require a double coincidence of wants, instead, as more intents are broadcast by gossip nodes, matchmaking nodes are able to help settle complex n-party trades atomically ¹¹. For example, if the following intents are individually broadcast:

Alice wants to sell at most 8 $tokenA and buy at least 1 $tokenB
Bob wants to sell at most 1 $tokenB and buy at least 4 $tokenC
Carol wants to sell at most 4 $tokenC and buy at least 8 $tokenA

Then the first matchmaking node to match the three intents can facilitate settlement of the transaction and receive a reward. Alice did not have to find someone who wanted her 8 $tokenA for 1 $tokenB. Instead, the intent was matched with another intent, which ultimately got her the asset she was looking for, and at the exchange rate within her limits.

Once an intent is shared with a gossip node, it is considered binding, although it is possible to include an expiry time within the intent for how long the intent is valid. However these standards are not requirements when it comes to the Anoma protocol: since the intent and gossip matchmaking system is considered a subprotocol of Anoma, it is possible for there to be even more specific subprotocols developed that are better catered toward different use cases.¹²

While Anoma markets itself as "privacy-preserving protocol for decentralized counterparty discovery", in the v1 design of the intent gossip and matchmaking system, it is not possible for matchmaking nodes to do their job without knowing the contents of the intent (e.g. the currencies and exchange rates), although it is possible to have privacy for the address of the counterparties ¹³.

Validity Predicates

Similar to other distributed virtual machines such as the Ethereum Virtual Machine (EVM), Anoma’s ledger contains multiple independent accounts with different state subspaces and code. What differs is the execution, as Anoma does not operate in a step-by-step order where contracts call each other. Instead, transactions execute arbitrary code in a WASM virtual machine, meaning any transaction is able to read or write any state as desired. For this to be written to the ledger, all accounts involved in the transaction must accept the transaction. The way this is handled in Anoma is with validity predicates. Validity predicates are code that each account has, in addition to each token (i.e. ETH, ATOM, BTC), or specialized accounts like zero-knowledge circuits. Validity predicates for each account are public code (in initial versions of Anoma), and contain the logic that communicates with the Anoma state machine, to ultimately identify whether a state change for an account is valid. The validity predicate check is stateless and can be parallelized for any number of accounts that are involved in a transaction.¹³ ¹⁴

Threshold Decryption

Anoma will use Ferveo, a threshold transaction decryption scheme for front-running protection, where the set of transactions for a newly proposed block are encrypted, meaning validators have no information about the contents of the transactions and hence do not have a game-theoritic advantage over other users. As described in the Anoma whitepaper ¹³, the cryptography process proceeds as follows:

Periodically, validators run a byzantine-fault tolerant distributed key generation protocol, generating a shared public key and private key shards split among the validators.
Before submitting them to the peer-to-peer network, users encrypt transactions to this shared public key.
The proposer then includes a set of encrypted transactions in a block, committing to a particular execution order.
Once the block has been finalized, the validators run a threshold decryption protocol, each generating and gossiping their share of the decrypted transaction.
Once the threshold is reached, the decrypted transactions can then be included in a future block, where it will be executed as soon as all prior transactions (in the previously committed-to execution order) have been decrypted and executed.

Namada

Namada is Anoma's initial fractal instance which deploys v1 of the Anoma protocol using Tendermint BFT consensus, and is under development by the founding team Heliax. Core to Namada's architecture is the Multi-Asset Shielded Pool (MASP), which allows all assets bridged to Namada from Ethereum or IBC chains to share a singular anonymity set ¹⁵.

Multi-Asset Shielded Pool (MASP)

Anoma supports both transparent and shielded transactions: it is not a fully shielded blockchain protocol. The MASP is the initial design included in Anoma v1, which provides support for shielded transactions in which transaction privacy is secured by a zero-knowledge circuit shared across all assets bridged to Namada. This results in a unified shielded pool where senders, recipients, amounts, and asset denominations for transactions taking place among two familiar parties are encrypted as far as the public is concerned. This means once users bridge their assets to Namada, the information will become part of a singular MASP with all of the different assets sent by other users, such as Ethereum ERC20 tokens and NFTs, or even IBC-compatible assets.


Image source: Introducing Namada: Shielded Transfers with Any Assets

Trusted Setup

To enable the MASP, Namada requires a trusted setup ceremony, which is a multi-party computation (MPC) ceremony that lets many participants contribute randomness to a zk-SNARK's public parameters. Trusted setups consist of two phases. For the first phase, Namada will leverage the Powers of Tau from Zcash's Sapling MPC seeing as the first phase is circuit agnostic, so it's possible to bootstrap this process utilizing the data from an existing ceremony. For the second phase, a new ceremony is required to construct the parameters for the MASP zk-SNARK, since the phase is circuit-specific.¹⁶

Cryptography Enhancements

The current version of MASP relies on Groth16, which means that any changes to the pool design will require a new trusted setup. Heliax is researching upgrade paths and are considering using PlonKup (PLONK+plookup) or Halo 2 instead of the Groth16 based design¹⁷. PlonKup is a universal circuit that still requires a trusted setup, but upgrades wouldn't require new trusted setups. Halo 2 doesn't require a trusted setup.¹⁸

J-group

Heliax is developing various languages that will help spawn private and verifiable interfaces, protocols, and applications within the Anoma network. These languages include Juvix, Alucard, and Vamp-IR. Together, this set of languages is known as the J-group.⁷

Juvix is a statically typed functional language that supports compiling validity predicates to the C language. Juvix can be considered Anoma's Solidity, except it has the goal of enabling formally verifiable smart contracts.¹⁹
- Various examples are available for review in the Juvix documentation, such as a simple fungible token.
ALucard (Alu) is a domain-specific language (DSL) for writing zero-knowledge circuits that are compiled into Vamp-IR. Alu's syntax is derived from Common Lisp. ²⁰
Vamp-IR is a language for specifying arithmetic circuits and consists of a parser, compiler, and a prover runtime. Vamp-IR stands for Vamp-IR Aliased Multivariate Polynomial Intermediate Representation.²¹ The compiler can transform an arithmetic circuit into a form compatible with any proving system backend, such as R1CS, vanilla PLONK, PLONK with lookups and/or custom gates, PLONKish Halo 2, etc. Vamp-IR enables a circuit IR to capture the intention of the circuit alone, and remains agnostic to both the proving system features and the specific constraint system it targets.²²

Taiga

Anoma predominantly describes and presents “transparent” Anoma in its whitepaper and blog documents. In transparent Anoma, validity predicate functions, as well as the asset type being traded via the gossip protocol, are public.²³ “Private Anoma”, named Taiga, is currently in R&D by Heliax, but will bring privacy to both the validity predicate functions as well as the asset type being traded.²⁴ An initial implementation of Taiga is expected to be included in v2 of Anoma ²⁵, but Heliax has not yet figured out the complex fully homomorphic encryption/multi-party computation cryptography involved for multi-party private state transitions which is slated for v3 of the protocol.²⁶

Analysis

Updated Analysis Coming Soon

Warning: there is a lot of subjectivity in this section. The majority of this analysis was performed by Stellar Magnet in October 2022. Black Sky will be releasing a new protocol analysis framework in Q2 2023, reevaluating Anoma and other projects to ensure consistent framing across the board.

User Privacy

Public Validity Predicates Leak User Preferences

Anoma’s documentation provides a few examples of how a user can customize their account’s validity predicate to add additional verifiers, such as not accepting any state changes that result in the user’s BTC balance going below 3 or requiring the signature of two private keys instead of one for transfers above a certain value ¹⁴.

In initial versions of Anoma, such as v1, validity predicate functions are public, meaning when a user customizes their validity predicates, Anoma will leak data around balance preferences and transaction threshold amounts that require greater security. In later versions, v3, once the full spec of Taiga is devised, developed, and released, it will be possible to have validate predicates with private functions that support multi-party transactions.

Note: Namada's release path includes taking Anoma's v1 to mainnet, which does not yet fulfill on Anoma's mission of creating a “privacy-preserving protocol”.

Anoma Can Be Transparent and/or Private

Compared to privacy layer 1 protocols like Aleo, Penumbra, and DarkFi, Anoma is not a fully shielded blockchain and supports both transparent transactions in addition to shielded transactions.

The clearest competitor to Anoma is Cosmos when assessing Anoma from the higher architectural level with respect to the vision around fractal instances. If the Cosmos ecosystem decided to replace Tendermint with Typhon, then perhaps the two ecosystems would not be competitors, and would instead be allies.

Anoma’s fractal instances can be thought of as similar to Cosmos’s concept of zones, but they will be more advanced assuming the Heterogeneous Paxos spec is brought to life successfully, which has the design goal of achieving a multi-chain atomic settlement in a singular consensus round. A potential evolution of the Anoma ecosystem, once systems such as Taiga are fully developed, is many fractal instances that are fully shielded.

Given the current fractal instance design, and Anoma supporting both transparent and shielded interactions, there can be a lot more ways privacy can go wrong within Anoma, unless each fractal instance is designed and deployed very intentionally and the user has sufficient warnings when performing activities that can be potentially de-anonymizing in one way or another.

Anonymity Set

Since Namada, Anoma's first fractal instance is not currently live, there is no size yet of Anoma's anonymity set. But one of the key properties of Namada's MASP is that all assets will be sharing a singular anonymity set, initially supporting fungible or non-fungible assets on both Ethereum or IBC-compatible chains. Assuming enough users adopt Namada, this can significantly strengthen privacy guarantees compared to single asset protocols such as Tornado Cash or Aztec Network's zk.money, and will be useful for assets with low transaction volumes or transactions with high values, assuming they remained within Namada.¹⁵

Once Anoma develops Taiga, as well as a solution for private bridging (see their work-in-progress spec), then a singular anonymity set can be shared across multiple fractal instances ⁶, which will be a compelling offering if it works. Penumbra founder Henry de Valence and Anoma co-founder Christopher Goes were having a Twitter debate on September 17, 2022 about this topic of private bridging, and de Valence believes it is a bad design decision ²⁷:

This is bad because private chains have meaningfully greater risks (e.g., secret inflation), and it’s important not to allow economic contagion between different shielded pools. Which is possible when the transfers are public, but isn’t when they’re private.

Although from a longer-term perspective, private bridging must be where the future of cryptocurrency is headed if one assumes there will be more private cryptocurrencies and people will always have the desire to transact between different types of currencies.

Networking Privacy

There are no mentions in Anoma's documentation for how the protocol aims to address privacy of networking data (e.g. IP address and packet sizes) for users or validators of the network. When the team was questioned in their Discord about this topic, co-founder Christopher Goes mentioned that they plan to eventually integrate a mix network such as Nym into the Anoma stack, but this was not an immediate priority.⁶

Nowadays, experienced privacy advocates understand that this is a crucial design consideration that is important to be addressed to offer stakeholders the best "state of the art" privacy. Given that Anoma co-founder Awa Sun Yin's prior job was working "at a company that developed tools to deanonymize user data on blockchains and sold them for profit" ¹⁵, it is unfortunate that this dimension is not addressed in the current protocol design. Networking privacy is quite often an afterthought among many privacy-focused layer 1 projects, yet this is where adversarial parties can gather ephemeral networking data to partially de-anonymize validators, users, and transactions.

Censorship Resistance

The Ferveo threshold decryption mechanism is great for censorship-resistance, ensuring that validators behave in a credibly neutral way, which has become a more prominent design consideration in consensus protocols, after the August 8, 2022 US Treasury sanctions against Tornado Cash ²⁸.

What is concerning when it comes to censorship resistance is this vision around fractal scaling proposed in the whitepaper ¹³:

The frequency of commerce is inversely correlated with the distance (of any form) between the counterparties: most buyers in Shanghai are buying from a seller in Shanghai, and most buyers in Berlin are buying from a seller in Berlin. The topology of a digital barter network should reflect this, for both reasons of latency and local sovereignty: transactions in Berlin should be settled on a Berlin-controlled ledger, transactions in Shanghai should be settled on a Shanghai-controlled ledger – and the (far more infrequent) transactions between Berlin and Shanghai should be settled when necessary on a global ledger.

With this scaling vision, local ledgers will potentially be less censorship resistant than global ledgers, since validators of local city-based ledgers will have to be more conscious of complying with local money transmitter laws, otherwise they can be fined or may go to jail. For example, let's say a Tehran fractal instance was created. Validators who are running a Los Angeles fractal instance will have to block incoming transactions from the Tehran instance, otherwise they will be breaking economic sanctions that exist between the USA and Iran.

While it seems possible in the future for Anoma to include private bridges wherein the “source fractal instance” cannot be identified ²⁹, that does not mean it will be legal for a Los Angeles fractal instance to use bridging technology that blinds them from the transaction origination source, especially once Iranian, Syrian, and North Korean fractal instances are created.

It’s also possible a jurisdiction may ban fully private Anoma altogether and require fractal city-based instances to comply with local banking laws. If the intention is to build a system that can’t be regulated by local authorities, then stakeholders securing the ledger of a city-based instance are going to need a lot more privacy and will have to figure out how to earn trust in their ledger without publicly revealing their identity, while additionally doing a good job of masking their location in the city.

Ledgers based on existing cities that are tied to a specific jurisdiction don't seem that great for privacy or censorship resistance. While Anoma's intention seems to be honest, it results in a network design that may be more fragile. We are hoping this concept does not take off, but if it does, we recommend city-based ledgers assume the following qualities moving forward:

They are fully shielded: they never have a concept of transparent transactions or transparent validity predicates.
There is no way to bridge onto city-based ledgers from transparent chains external to Anoma, such as Ethereum or IBC-compatible chains.
If city-based ledgers are delegated proof of stake networks, then there is great privacy for both validators and delegators (networking privacy, identities, etc.).

Anoma's whitepaper was written before the Tornado Cash event, so hopefully the event at least serves as inspiration for the protocol visionaries to come up with better examples for fractal instances that don't accidentally make it so easy to recreate the existing financial order with a blockchain protocol. When a fractal instance is thought of more as an app chain, similar to a Cosmos zone, it's a lot easier to comprehend. Alternatively, if the vision of city-based ledgers was situated toward enabling a Parallel Polis, it would be more aligned with cryptocurrency's cypherpunk spirit.

26-April-2023 Addendum: Lead analyst Stellar Magnet retracts the prior recommendation regarding Anoma's repositioning their vision around enabling a Parallel Polis. Since December 2022, she has shifted her perspective on narratives, embracing a more pragmatic approach. Black Sky will be releasing an analysis matrix in Q2 2023, reevaluating Anoma and other projects to ensure consistent framing across the board.

Community Incentives

Namada is offering incentives for participating in their trusted setup ceremony ¹⁶. Regardless that the vision behind the Anoma protocol is one that champions privacy, KYC will be required to earn rewards in this incentive program. This is unfortunate, although these sort of over-compliance measures are expected for early stage protocols managed by foundations or corporations that have yet to decentralize operations, and hence have to follow jurisdictional laws, such as those of Switzerland, in the case of Anoma ³⁰.

It’s instead possible to design incentive programs that maintain the full privacy of the community, such as allowing incentive programs and tokenomics of the protocol to be managed and distributed by a community DAO or guild, although this alternate method is not necessarily aligned with the current normative venture capital fundraising model in which the initial tokenomics are controlled by the founding stakeholders.

Strategy & Narrative

There are challenges in understanding Anoma based on its narrative when this research initially took place. First, it is difficult to imagine or understand how barter economies where farmers are exchanging goods can really be brought to life with Anoma or if a blockchain protocol is really needed for this use case, since tracking your harvest with a validity predicate doesn't seem practical.

In addition to these problematic bartering for physical goods examples, Anoma also quite often talks about the use case of a person trying to buy a festival ticket, a hotel, and a train ticket at the same time ¹¹, which doesn't seem like a very important problem to solve.

Anoma would be easier to understand if they focused on multi-asset exchanges, and used more relatable examples, as their existing narrative and usage examples generally weaken the value proposition of the protocol.

Support or Join Black Sky

If you appreciated this resource and would like to see more like it, please consider making a donation to Black Sky. Additionally, follow Black Sky on Twitter or join our Telegram.

Additional Resources

Cryptography Research

Anoma has a research page where the team shares cryptography research papers they have contributed to which are related to the Anoma protocol design, particularly:

Anoma Protocol

By Stellar Magnet, Serinko​

Project Summary​

Highlights​

Production Stage: Testnet​

Overview​

Consensus Protocol​

Intent Gossip & Matchmaking Subprotocol​

Validity Predicates​

Threshold Decryption​

Namada​

Multi-Asset Shielded Pool (MASP)​

Trusted Setup​

Cryptography Enhancements​

J-group​

Taiga​

Analysis​

Updated Analysis Coming Soon

User Privacy​

Public Validity Predicates Leak User Preferences​

Anoma Can Be Transparent and/or Private​

Anonymity Set​

Networking Privacy​

Censorship Resistance​

Community Incentives​

Strategy & Narrative​