[v1 Draft] Anoma is unbundling technology, Literally.
Note: we are still working through the topology section - will work on today. Publication today is unlikely. however publication by early next week is likely targeting Wednesday morning before research day is highly likely. Feel free to critique anything here, I will keep building this later today. Key things we need to work on still: topolgy, transitional arc, diagrams, conclusion. Note I havn’t edited top to bottom, so there could be errors.
There have been many attempts to explain Anoma over the last few years. Explanations span from a unified architecture for full-stack decentralized applications to a tool for coordination , and further to contemporary explanations such as, Anoma as the universal intent machine for Ethereum .
The Anoma vision paper laid out something else, Anoma: Undefining Money (versatile commitments to value) . While the versatile commitments to value is quite vague, undefining money pokes at a concept and framing the author thinks best describes the vision of what Anoma is.
Anoma is unbundling technology.
Before we dive head first into unbundling, let’s talk about Anoma at a high level. This will be useful for the reader as we deconstruct and rebuild concepts from general to specific.
Anoma aims to provide an intent machine interface for applications. An intent machine is a machine the processes intents by transforming the system state according to user-defined constraints and preferences. An interface can be understood as a protocol which translates one semantics in terms of another. TCP/IP is an interface, for example. It translates the semantics of declarative ordered packet delivery into imperative send, retry, and window management semantics of underlying network hardware.
In particular, the Anoma protocol is a distributed operating system. It is an operating system which translates one semantics in terms of another. An operating system is software which provides an operating environment for arbitrary user software. This allows application developers to build and execute arbitrary intent-centric applications.
Accidentally designed systems only succeed in uncommon circumstances, which can impose significant negative externalities on developers and users. Anoma opts for the deliberate development approach because it is well understood that accidental design may lead to poor systems.
At the heart of Anoma’s unbundling technology is the concept of an intent. A colloquial definition of an intent could be, an intent is a credible commitment to preferences and constraints over the space of possible state transitions. Mathematically, intents are atomic information flow constraints. A simple or more basic definition could be intents are signed messages specifying what actions users want without specifying the path of execution.
Intents and applications written with Anoma can be ordered, solved, and settled anywhere including Ethereum, L2s, Eigen Layer AVS, Cosmos, Solana, or even Bitcoin. Intents allow users to express their desires in terms of preferences and constraints.
- Constraints are inflexible and must be satisfied for the intent to adhere to the rules of the Anoma resource machine. An example of a constraint could be I want to send this_message to user_protinam
IFF it’s delivered by 04:20:00 UTC.
- Preferences are desires that cannot be enforced. For example, I want this_message sent to user_0xballoonlover as soon as possible.
Anoma’s intent-centric architecture allows for the creation of a diverse set of topologies.
- Roles and responsibilities explicitly defined based on intents.
- Programmable node configurations with dedicated nodes for routing, solving, execution, consensus, etc. - all agents run Anoma nodes configured at runtime for their desired roles.
- Promotes flexibility for different users/communities to experiment with suitable topologies.
This choice or preference entropy, which we’ll get into later, arises because users are not locked into fixed network Topologies. Anoma’s architecture allows users to choose their own topology at runtime.
Unbundling
Unbundling is a concept often used in the discourse to describe disruptive technology. In particular, by unbundling, we mean breaking up things that were previously offered in a group . Though it’s not enough to simply unbundle things without a proper motivation or reason, less of course it brings the unbundler child like joy or some other emotional fulfillment.
Alice exercises and eats
In the context of Anoma and other protocols, unbundling can be thought of as providing the participants of these networks with a choice. In particular, if we think of unbundling two dimensions A and B.
Let’s imagine Alice is trying to decide if she wants to exercise or eat, but she’s not sure how to assess her choices. In a world where AB are bundled, she either has to exercise and eat or neither. Since Alice is tired from conference hopping and a bit jet-lagged, she decides to not exercise and not eat.
A = "exercise"
B = "eat"
preference1 = (A, B)
preference2 = (f"not {A}", f"not {B}")
preferences = [preference1, preference2]
# Print table header
print("|Preferece| Exercise | Eat |")
print("|---------|----------|-----|")
for i, preference in enumerate(preferences):
choice1, choice2 = preference
print(f"| Preference {i+1}| {choice1:<8} | {choice2:<8}|")
| Preference |
Exercise |
Eat |
|
| Preference 1 |
exercise |
eat |
|
| Preference 2 |
not exercise |
not eat |
|
This is sad. However, in a world where A and B are unbundled, Alice has twice as many choices. For example, you can see in the python code snippet that Alice now has for preferences since exercise and eat are no longer bundled together. Unbundling A and B provides Alice with more choice
A = "exercise"
B = "eat"
preference1 = (A, B)
preference2 = (A, f"not {B}")
preference3 = (f"not {A}", B)
preference4 = (f"not {A}", f"not {B}")
preferences = [preference1, preference2, preference3, preference4]
# Print table header
print("|Preferece| Exercise| Eat |")
print("|---------|---------|-----|")
# print each preference in the table
for i, preference in enumerate(preferences):
choice1, choice2 = preference
print(f"| Preference {i+1}| {choice1:<8} | {choice2:<8}|")
| Preference |
Exercise |
Eat |
| Preference 1 |
exercise |
eat |
| Preference 2 |
exercise |
not eat |
| Preference 3 |
not exercise |
eat |
| Preference 4 |
not exercise |
not eat |
Before unbundling, Alice has a choice of either (eat and exercise) or (not eat and not exercise), since these dimensions are coupled. After unbundling, Alice has a choice of (eat and exercise), (not eat and exercise), (eat and not exercise), and (not eat and not exercise), since these dimensions are decoupled. Here we observe twice as much choice for Alice.
In this sense, if we understand freedom of a certain sort as related to the size of the set of available choices, unbundling increases freedom. Unbundling increases preference entropy. What is that? Preference entropy is the variance in preferences among network users regarding a specific dimension.
Anoma unbundles protocol architecture from network topology with intents
In sequential order, first we’ll discuss architecture, then topology, and finally, how intents unbundle the two. We’ll use a mix of reasoning by analogy to build an intuition, along with first principles reasoning to cement the concepts.
Architecture
The architecture of a protocol is a mathematical specification of what the protocol is and does - typically, what (complex) pattern of messages will be sent in response to (complex) patterns of messages received.
- Christopher Goes, Anoma as the universal intent machine for Ethereum
The above quotation is taken out of context, describing what a software architecture is and does. In particular, a protocol architecture is a precise description of how the protocol works. The architecture defines what messages the protocol sends in response to messages received. Let’s keep this in mind as we traverse the preceding architectural digest.
Design
The term architecture has many context - dependent meanings. One common definition, like this one from the dictionary of architecture and construction, suggests that architecture is the art and science of building structures, or large groups of structures, maintaining aesthetic or functional criteria. Other definitions from the field suggest that architecture provides place and support for all types of human activity. Architectural theorists may suggest that architecture is a human act that invades and displaces the natural ecosystem. The commonality shared by these definitions – architecture is an intentional endeavor to shape the environment while balancing functional aesthetics with artistic expression.
Hardware
In hardware and software design, the term architecture takes a slightly different meaning. In the physical world, a computer architecture refers to the system’s physical components and their interrelationships. An example of a hardware architecture is that of a mobile phone. The architecture could include a CPU, a battery, an input mechanism (touch screen /keypad), an LCD/OLED display, speakers, subscriber identity module (SIM), and a notification LED. A well-designed architecture incorporating aesthetic and functional criteria can lead to great consumer product.
Another example of a hardware architecture could be a computer architecture like a Von Neman Machine. Traditionally, the Von Neumann architectural components include (i) a memory for containing instructions and data, (ii) a central processing unit (CPU) for performing arithmetic and logical operations and (iii) a control unit which is for interpreting instructions – it orchestrates execution of the program. The purpose of the Von Neumann model is to efficiently store and execute programs. The architecture allows for both storing instructions and data in the same memory, which allows for various software applications to be built on top. However, this architectural decision of shared memory comes with its downsides, known as the Von Neumman bottleneck. The system bus, which connects the main components of a computer, limits the throughput of the CPU because the single bus in the VM machine can only access one class of memory at a time. Indeed, no architectural decision is without its trade-offs.
Networks
Now we take the analogy a step further by examining network architecture, a particular type of network architecture. P2P networks refer to a distributed collection of peer nodes, that act both as servers and as clients. Nodes in this network have equal privileges and responsibilities, whereby network participants share resources. P2P networks can be classified as pure, hybrid, overlays, structured, and unstructured. Common examples that may come to mind for the reader are Bittorrent, Ethereum, Kademlia, CAN, and Gnutella. The network architecture can be defined as the structure of separate components and their interrelationships or interfaces. The components may include the entities who communicate with relation to their specific roles and responsibilities within the architecture.
A P2P network, usually instantiated as overlays, enables the so-called democratization of the internet through decentralization. They are highly available, fault-tolerant, self-organizing, scalable, and censorship resistant. However, the choice of P2P network architecture does not come without challenges including construction and maintenance, data dissemination, data location, and tolerance to churn. The architectural choice of P2P can also enable design flexibility of the network topology, which is one considerable advantage.
Thought Experiment - designing a city
As with the above examples, both architecture in the view of observable reality, hardware, or network contexts, we can see that all involve designing components to create something purposeful.
Let’s break this down further by way of a thought experiment. Imagine you are designing a city. The architecture of the city can be defined of as the components that constitute the city and their interfaces. A component is a constituent element of a system. An interface can be thought of as a shared boundary where components of a system share information. For example, the components of the city could include; skyscrapers, museums, stadiums, bridges, schools, banks, parks, discos, etc… Notice that we did not discuss where to place the components or how they are connected – these things would fall under the City’s topology.
Ethereum
Zooming back out, let’s think about blockchain protocol architectures, as perhaps this is the most relevant example for our readers.
Consider Ethereum’s architecture, it is like the protocol stack. It defines core components like EVM, accounts, transactions, smart contracts, and consensus. The interfaces for these components include the Solidity, JSON-RPC, Web3.js, Application Binary Interface (ABI) and engine API.
In the case of Ethereum, the protocol architecture is tightly coupled with the network topology.
Anoma
Anoma’s architecture uses the concept of intents to organize of its internal components . In particular, the architecture is composed of machines which further decompose into engines. For example, the ordering machine is composed of mempool engines, a consensus engine and execution engines. While we want to cover all the intricacies and nuances of the Anoma protocol specification which outlines the high-level or abstract architecture and operational architecture, we will briefly call out a few key components
- The Networking Machine - is responsible for message passing between engine instances, both locally (intra-node), and over the network (inter-node). The core functionality includes message routing and transport, upon which more complex peer-to-peer (P2P) protocols are built. The Networking machine is the foundation of the protocol.
- The Ordering Machines - is a set of communicating engines that collaborate in receiving transaction candidates from users or solvers, ordering these requests for execution, executing the transaction candidates, updating the state accordingly, and making the state available. The ordering machine performs the core functions of a state machine.
- The Resource Machine - defines and enforces the rules for valid state updates that satisfy users’ preferences. The ARM provides means to express intents and ensures their correct and complete fulfillment and settlement
In the case of Anoma the protocol architecture is not tightly coupled with the network topology. We’ll discuss below.
Takeaways
Architecture as we’ve discussed to this point involves the intentional design and organization of components and their components to create a purposeful system. As we saw while examining architecture from different perspectives, they all appear to share this commonality. Architecture is only part of the story, though. Indeed, it can have a significant impact on network topology, which deals with the placement and connection of these components. We’ll discuss this next.
Topology
This section still needs work.
In the field of Mathematics, Topology is the study of properties which are preserved by deformations, twisting and stretching of objects. One common example of a topological object is a Möbius strip. Let’s say you went to a crypto conference and received a paper band with some adhesive holding it together. When you get back to your hotel room, you pull the scissors out of your toiletry travel bag a cut the band. Now twist the band so the back of the side that was cut is now connected to the edge of the cut. Apply tape and you now have a Möbius strip. The Möbius strip is a non-orientable surface, which means that an observer cannot consistently distinguish clockwise from counterclockwise.
Topology focuses on the connectedness of objects rather than their exact shape. For example, squares and circles are topologically similar, as they are both one-dimensional and divide a plane into two regions: inside and outside.
Network topology, on the other hand, is the arrangement of the elements (links, nodes, etc.) of a communication network.
Ethereum’s topology is how it works in practice. In particular, (i) it describes the organization and interconnections of different node types, (ii) outlines roles like full nodes, light nodes, miners/validators, boot nodes, (iii) illustrates flow of data/transactions between nodes, and (iv) is designed to support core functions like transaction propagation, consensus, execution. In simple terms, you can think of Ethereum’s topology as the MEV supply chain, which is continuing to evolve [^, signaling signs of a healthy network .
Intents
What does architecture and topology have to do with intents? Recall that intents are
- colloquial definition: credible commitments to a preference function over a shared state space
- mathematically: atomic information flow constraints
Precisely:
I :=(S ➝ S) x (S x S ➝ U⋆ [0,1])
Intents, I are formulated as a pair, consisting of a transition function (S ➝ S) and a partially weighted predicate over state transitions (S x S ➝ U⋆ [0,1]).
The guiding intuition for this formulation is to separate (unbundle) control from desire. In the prototypical example, intents will express a desire for some resource in exchange for another. The 1st component expresses a partial state transition, where the intent may create/destroy what it has control over. This aids in composing intents. The 2nd component expresses a weighted predicate over transitions. If the transition satisfies the intent, it returns an element between 0 & 1, representing a kind of utility.
Intent-centric architectures like Anoma provide a specific way of organizing subcomponents into a structure designed to serve the purpose of the overall system. Two relevant examples are p2p routing and transaction execution.
- Traditional P2P routing architectures have P2P routing hard-coded into the core protocol, see the Tendermint Mempool as an example. Alternatively, Intent-centric architectures separate P2P routing into subcomponents which allow different implementations prioritizing speed, programmable disclosure, and trust.
- Traditionally, transaction execution is tightly coupled with consensus (agreement on who owns what) and data storage. On the other hand, Anoma decouples counterparty discovery and settlement. This enables different execution environments (EVM, SVM, Move, ARM…).
Indeed, Anoma unbundles protocol architecture from network topology with intents, which affords greater flexibility for users and developers with varying degrees of preference expression.
Discussion
In a network with architecture / topology that are tightly coupled, users have limited freedom in preference expression. For example, if the system requires all users to trust the same party for all services, then users cannot express personal trust preferences for different parties or services.
Conversely, in a system where components are unbundled (e.g. rainbow staking), users have more freedom to express their preferences. In such a system, users would be able to choose trust preferences for different services, leading to higher preference entropy.
In particular, In the blockchain context, user choices are typically restricted, leading to a lower preference entropy. Let’s take Ethereum and Bitcoin, where preference expression is significantly constrained in terms of trust.
- In Ethereum’s case, unless one sends an OFAC sanctioned
tx or proposes their own block, they have little control over where their order goes if their tx is sent to the public mempool. If the tx is sent to a private mempool it is guaranteed to flow through builders and relays discussed below
- the user’s
tx is all but guaranteed to flow to a centralized “builder” and centralized “relay” entity (4 builders produce >= 80% of blocks), as 90% of blocks produced use the MEV-boost software.
- Likewise, in Bitcoin, you are at the mercy of ~ 4-5 mining pools that control block production.
As a user, you are forced to contend with these powerful entities to get a transaction included on-chain unless you wait a long time - which in Ethereum requires waiting for a proposer who builds Vanilla blocks or you mine your own block – about 2–3 times per year for an Ethereum solo-staker. In Bitcoin, solo mining is not feasible, (folks have tried), so you are stuck with randomness.
In this reality, users have no choice, aside from the special cases mentioned above, but to accept these defaults if they want to use applications or transfer native tokens like BTC or ETH on these networks.
Perhaps if you could specify with a predicate “I only want my block mined by a mining pool that is not Antpool, Foundry USA, F2Pool, or ViaBTC”, or “I only want my block proposed by a solo-staker,” the system would have more preference entropy. To my knowledge, there is no easy way to do this today, meaning users are stuck with the current network topologies without much recourse other than switching to a different network, e.g., Zcash.
Recall, this links back to our earlier discussion of Alice and her choices of exercise, eat. At first, the choice was bundled, and she had either the choice to both exercise and eat or do neither. After the choice was unbundled, she was able to double her potential preferences. Likewise, as intents provide users with the ability to finely control what messages they send to whom by allowing users to granularly control the flow of their information, new topologies become emergent. Intent data flows become diverse, and perhaps look something like this.
Future Work
Our work is only partially complete. In examples 2-4 we’ll discuss how:
- Anoma unbundles protocols from operators
- Anoma unbundles tokens from protocols
- Anoma unbundles money from convention
.