[Draft v0] Anoma is unbundling technology, literally

Anoma is unbundling technology, literally.

Note to the reader: this is a very raw version of a first draft which the author intends to complete over the coming week. One of the challenges is trying to distill some of the core concepts into a digestable form for a builder, researcher audience while remaining above low level details while allowing for light-hearted philosophical musings. Feel free to complain if you think the structure or direction of this art is off-the rails or has somehow found its self in the gutter.

There have been many attempts to explain Anoma over the last few years. Explanations span from a unified architecture for full-stack decentralized applications [1] to a tool for coordination [2], and further to contemporary explanations such as, Anoma as the universal intent machine for Ethereum [3].

The Anoma vision paper laid out something else, Anoma: Undefining Money (versatile commitments to value) [4]. 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.

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 [5]. Though its 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. Therefore, we’ll not only discuss four examples of how Anoma unbundles technology, taking inspiration from Virgil Griffith [6], we’ll also explain the motivations or raison d’être.

Example 1: Anoma unbundles protocol architecture from network topology with intents

Network architecture is a framework for the specification of a network’s physical components and their functional organization and configuration, its operational principles and procedures, as well as communication protocols used.

Network topology, on the other hand, is the arrangement of the elements (links, nodes, etc.) of a communication network.

Let’s break this down by way of a thought experiment. Imagine you are designing a city. The citiy’s architecture is the high-level design for the city, including where everything is supposed to be and how it all works together. The city’s topology would be how you decide to connect everything, roads, bridges, parks, sidewalks, etc. The topology determines the best way for people to move around the city.

More concretely, Ethereum’s Architecture is like the protocol stack. It defines core components like EVM, accounts, transactions, blocks, and consensus. The architecture specifies high-level system design principles and interactions which includes features like smart contract languages, EVM upgrades, and Ethereum improvement proposals (EIPs).

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 [7], signaling signs of a healthy network [8].

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[9]. 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 hardcoded 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…).

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.

Indeed, Anoma unbundles protocol architecture from network topology with intents, which affords greater flexibility for users and developers with varying degrees of preference expression.

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

  1. Adrian Brink, Awa Sun Yin, Christopher Goes, Anoma: a unified architecture for full-stack decentralized applications, 2022. ↩︎

  2. Christopher Goes, Anoma: Endgame - Anoma Huddle Amsterdam, 2022. ↩︎

  3. Christopher Goes, [RFC] [DRAFT] Anoma as the universal intent machine for Ethereum, 2024. ↩︎

  4. Christopher Goes, Awa Sun Yin, Adrian Brink, Anoma: Undefining Money, 2021. ↩︎

  5. Wikipedia contributors, “Unbundling,” Wikipedia, The Free Encyclopedia, 2024. ↩︎

  6. Virgil Griffith, Ethereum is game-changing technology, literally., 2019. ↩︎

  7. Frontier Research, Infinite Games, 2024. ↩︎

  8. Christopher Goes, Towards an intent-centric topology, 2024. ↩︎

  9. Anthony Hart, D. Reusche, Intent Machines, Anoma Research Topics, 2024. ↩︎

1 Like

Slight quibble - I would define the architecture of a city as what components make up the city and what interfaces they have - for example, a bank (deposit/withdraw money), a school (attend), an apartment building (sleep), a disco (party), etc. - but not where they are - I would consider where to place these components rather part of the topology (consider a graph: the components are the nodes, the interfaces determine which connections are possible, and the edges are the connections, with some kind of edge weight distance corresponding to the physical locations).

General feedback:

  • I think the concept of “unbundling” is generally useful and applies to a lot of cases within / aspects of Anoma, especially comparing Anoma to existing systems.
  • I think “unbundling” could easily become a series of blog posts or such where we talk about how Anoma unbundles different things.
  • I think it would also be helpful to relate unbundling to choice. In particular, if we think of unbundling two dimensions A and B:
    • Before unbundling, users have a choice of either (A and B) or (not A and not B), since these dimensions are coupled.
    • After unbundling, users have a choice of (A and B), (not A and B), (A and not B), and (not A and not B), since these dimensions are decoupled - twice as much choice (and exponentially so with more unbundled dimensions)!
    • 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.
  • Some other words we could consider are:
    • Coupled and decoupled

Additional cases of unbundling which might be interesting to cover:

  • Information flow control can be understood as unbundling revelations of different information - e.g. without privacy-preserving transfers, one must transfer and reveal to everyone, or not transfer and not reveal to everyone. With information flow control, one can transfer and reveal to anything between everyone and one person.
  • Unbundling store of value, unit of account, and medium of exchange in terms of functions of money.
  • Unbundling choices of who to trust from which interactions are possible, as much as possible.
1 Like

Slight quibble - I would define the architecture of a city as what components make up the city and what interfaces they have - for example, a bank (deposit/withdraw money), a school (attend), an apartment building (sleep), a disco (party), etc. - but not where they are - I would consider where to place these components rather part of the topology (consider a graph: the components are the nodes, the interfaces determine which connections are possible, and the edges are the connections, with some kind of edge weight distance corresponding to the physical locations).

This is a good quibble, and I don’t have a counterpoint. All I’ll say is this is where reasoning by analogy goes wrong. I’ll try to think of a clearer example. It may not be relevant to include though for this audience, wdyt?

By unbundling increasing freedom, is this what you meant by preference entropy, if we define preference entropy in the context of Anoma;

It means that Anoma automatically selects what chains / validators to use for consensus in a particular interaction from the trust models of the users involved, which are themselves built up over time by individual choices (expressions of preferences).

The more individual preferences that users have over time coupled with more users joining the network, the set of available choices increases as the set of preferences grows.

If I may pivot to the example of money for a moment. Today, fiat money is understood to play three roles;

  1. Medium of exchange (MOE) - any item that is acceptable for exchange of goods or services.
  2. Store of value (SOE) - any item that may retain purchasing power into the future and retains its purchasing power when used in the future.
  3. Unit of account (UOA) - a standard numerical unit of measurement of market value of goods / services / transactions.

Today fiat currency, particularly the United States dollar, takes on all three of the above properties.

  • I can exchange my Jerome Powell tokens for most items (goods and services) throughout the world.
  • I can redeem my JP tokens and retain my purchasing power (assuming I can stake them and receive rewards commensurate with the rate of inflation; e.g. checking / savings account, or smart contract based DeFi application).
  • Most of my purchases globally or at least in the United States are accounted for in JP tokens (I say globally because as I travel I can always choose to pay in dollars and do the conversion at point of sale).

While it’s convenient for JP tokens to take on these three roles of MOE, SOV, UOA, I don’t have many other choices. Indeed, I can choose to store my earnings in an alternative fiat currency, but that takes on exchange rate risk If I do not spend in said currency in the future. Additionally, I can choose to purchase commodities or “invest” in Equities / debt instruments, but these are not money and are subject to liquidity constraints when I want to exit back to fiat as well as various taxation laws. Indeed, I can choose to denominate my net worth in Gold but practically, most of my friends and family do not do this and so when we exchange goods and services, there is not an easy way to virtually account for this preference.

Therefore, we can claim that the current fiat monetary regime has a low preference entropy and, due to network effects and convenience, pushes everyone to use it. However, a system with high preference entropy would allow us to unbundle or decouple the three common functions of money. For example, I could choose to earn in fiat currency, pay my bills with gold, and store my earnings in @cwgoes coins. And I could also rebalance my portfolio to change these assignments should that be my desire, at any time.

In a future world, I could virtually walk into a grocery bazaar have my robotic assistant (at the bazar) bag the freshest fruit for me and process my intent to pay with a direct connection to my human brain interface. The payment could be in Gold, where the merchant accepts only apriori coins, but the conversion happens in real-time without either of us knowing. (joking about the robot - I’d rather go to the bazar myself, sounds like a dystopian world otherwise).

As the functions of money become unbundled it allows for interesting and unique combinations of preferences, which ultimately gives people more freedom to live their lives based on their individual values and those of the communities they associate with.


I do like unbundle, primarily because it is already used in the Ethereum community; e.g. Unbundling Staking: Towards Rainbow Staking

Agree. I think I covered the middle point above. I’d be curious of @nzarin thoughts on the latter in terms of trust if he has any opinion there as well as yours @cwgoes.

On the information flow control, I see the direct link to preference entropy referred to above, assuming my dissemination is correct :sweat_smile:.

I like the analogy, actually - everyone understands cities, and I think you can go into some more detail of what architecture and topology mean in the context of city design while providing useful intuitions for the reader.

Not exactly, but they’re related - I would define preference entropy rather as something like the variance in preferences amongst network users w.r.t. some specific dimension. For example, we could define trust preference entropy as the variance of trust preferences:

  • if all users trust X fully and no one else, the preference entropy is 0 (and a distributed network is pointless, since X can just run a single server)
  • if each user U_i trusts only some party P_i, where P_i \ne P_j for all i \ne j, the preference entropy is very high (in some sense maximum for a specific number of users) - in fact, it’s so high that a distributed network is also pointless, because the users share no trust assumptions and thus cannot agree on anyone to trust for storage, compute, ordering
  • the spectrum in the middle, where users’ trust preferences have some but not total overlap, is the interesting bit

The freedom of preference expression aided by decoupling is necessary to represent/instantiate large parts of this spectrum - I think one can understand more coupled systems as making it impossible to instantiate whatever parts of this spectrum cannot be decoupled in those systems. This would benefit from more mathematical language, which will take some time to work out, but hopefully the intuition is helpful.

Yes, that’s right - there’s also a nice connection here to typical philosophical arguments about individual and collective freedon. For example, take the relatively accessible Sartre (p12):

Furthermore, I can pronounce a moral judgment. For I declare that freedom, in respect of
concrete circumstances, can have no other end and aim but itself; and when once a man
has seen that values depend upon himself, in that state of forsakenness he can will only
one thing, and that is freedom as the foundation of all values. That does not mean that he
wills it in the abstract: it simply means that the actions of men of good faith have, as their
ultimate significance, the quest of freedom itself as such. A man who belongs to some
communist or revolutionary society wills certain concrete ends, which imply the will to
freedom, but that freedom is willed in community. We will freedom for freedom’s sake, in
and through particular circumstances. And in thus willing freedom, we discover that it
depends entirely upon the freedom of others and that the freedom of others depends
upon our own.

To fully characterize this kind of statement mathematically, we need to assume more about the nature of the world and action spaces extended into the future - but we can already proceed in this direction here with intents and dimensions of choice / decoupling: decoupling your choices (increasing your freedom) provides you with additional choices which I might be interested in making in concert with my choices (via intents and atomic transactions providing “collective choice”), thereby increasing my freedom.

These distinctions aside, I think I agree with your characterization of the case of functions of money.

Good point!

1 Like

This reminds me of a black hole, the highest known source of entropy in the universe, where information is lost or not accessible to any observers outside the event horizon (Hawking radiation withheld). In our network, without consensus because of too much entropy, the system collapses into a high entropy state - a black hole.

1 Like

In a network with components / services 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 Etheruem’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 in order 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.

1 Like

[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 [1] to a tool for coordination [2], and further to contemporary explanations such as, Anoma as the universal intent machine for Ethereum [3].

The Anoma vision paper laid out something else, Anoma: Undefining Money (versatile commitments to value) [4]. 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[5] 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 [6]. 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[7] (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[8] 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 [9]. 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 [10].

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[11]. 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.

Anomap2p

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

  1. Adrian Brink, Awa Sun Yin, Christopher Goes, Anoma: a unified architecture for full-stack decentralized applications, 2022. ↩︎

  2. Christopher Goes, Anoma: Endgame - Anoma Huddle Amsterdam, 2022. ↩︎

  3. Christopher Goes, [RFC] [DRAFT] Anoma as the universal intent machine for Ethereum, 2024. ↩︎

  4. Christopher Goes, Awa Sun Yin, Adrian Brink, Anoma: Undefining Money, 2021. ↩︎

  5. Christopher Goes, ethresear.ch, Anoma as the universal intent machine for Ethereum, 2023 ↩︎

  6. Wikipedia contributors, “Unbundling,” Wikipedia, The Free Encyclopedia, 2024. ↩︎

  7. Rahul Nayar, CS Department, University of Wisconsin - Madison, Introduction to Computer Engineering , 2017. ↩︎

  8. Nicola Dragoni, Embedded Systems Engineering, DTU Compute, Introduction to P2P computing ↩︎

  9. Christopher Goes, Anoma blog, Towards an intent-centric Topology, 2023 ↩︎

  10. Christopher Goes, Towards an intent-centric topology, 2024. ↩︎

  11. Anthony Hart, D. Reusche, Intent Machines, Anoma Research Topics, 2024. ↩︎

1 Like

Unbundling… :

Some initial thoughts re Unbundling Anoma v1 feedback… Wrote this very quickly so there are probably misconceptions but generally want to know if this is directionally correct wrt feedback @cwgoes (can wait till thorough discussion). Or are you looking for a full synthesis?

The coupling of architecture and topology forces application developers to reason about trade-offs that impact their users. If someone builds a rollup by default, they are fixing their topology by choosing to connect to another blockchain that has the ability and/or desire to act as a host.

This choice tightly couples outcomes. For example, consider CAP theorem, when choosing between availability and consistency during a network partition. If you pair your rollup with a base layer that optimizes for availability over consistency, it is possible the base layer block containing rollup transactions could be re-orged out of the canonical ledger at a later time. Versus if you choose a base layer that optimizes for consistency over availability, if the base layer stops or halts, you are SOL and have a liveness failure.

This is where building an app-chain on the cosmos stack gives you more flexibility w.r.t. to the architecture of how you design your chain and the topology. For instance, you can customize how block construction works with things like Block SDK allowing users to specify lanes for threshold decryption, arbitrage auctions, EIP 1559 style fee markets, and community subsidized lanes to on board new users. Your community can also choose to enable IBC connections to any chain that is also running the IBC protocol (both chains most approve with a governance vote / or permissionless deployment of smart contracts in the case of Ethereum main-chain). While this is still somewhat limiting and requires 3rd party trust assumptions to pass messages to outside ecosystems (which the case for every other blockchain without native or trust-minimized interoperability) fundamentally you retain sovereignty and interoperability. The choice of which chains to connect to will depend on the preferences of the community. Here you can customize the architecture within some bounds e.g. Cosmos SDK, build on top of IBC, or add a new mempool protocol for Tendermint while retaining flexibility w.r.t. to the Network topology both within your local network and the interchain as a whole. Cosmos app chains separate architecture from topology within limits.

If you choose to build applications on Solana, then you are stuck with Solana’s architecture and topology. There are some choices you can make in terms of which RPC providers to use which will impact the inclusion rate of transactions for the users of your applications, but generally the topology is fixed, there is not much flexibility.

In contrast, Anoma’s intent-centric approach to protocol design aims to unbundle architecture and topology, affording application developers and users more choices. With intents users express what they want with preferences and constraints without being bound by the limitations of any single network…

Go into heterogeneous trust. How deep? Math?

Heterogeneous chains are operationally expensive if you have to run a separate node for each one - so Anoma’s node architecture supports many networks with a single node. The operator simply configures which networks they’d like to participate in and the node software takes care of all the bookkeeping. Processes within the ordering machine, for example, can be spun up or spun down automatically based on which consensi the operator is participating in and how much throughput each needs at the moment.
A full paper on the heterogeneous trust node architecture is still in the works, but the curious reader may be interested in more about multi-chain atomic commits 4 or a brief introduction to Anoma’s P2P layer.

1 Like

Towards unbundling Architecture from Topology – Ethereum, Cosmos & Anoma

Note this is very rough draft/ outline (much meditation on it). The majority of the writing here still needs to be completed, but from a conceptual perspective, it would be helpful to get feedback.

tl;dr

  • Problem statement
  • Ethereum
  • Cosmos
  • Anoma
  • Open Questions and discussion
  • Conclusion

Introduction

The goal of this exploration is to understand the architectural choices of Ethereum, Cosmos, and Anoma and how they relate to the network’s topology. We will begin by articulating what we mean by architecture and topology. We will use a thought experiment of building a city to illustrate this point. Thereafter, we will start with Ethereum, progress with Cosmos, and finish with Anoma. Finally, we will discuss the finer points of the information presented and make some speculative claims which may be useful to formalize. In each section we will cover Architecture by enumerating affordances, counter-affordances, and mechanisms. Topology will dive into current network topologies and their relevant histories and future states. We’ll also include case study examples of applications, which will make the theoretical discussion more concrete. Each section will conclude with an Architecture-topology discussion based on the preceding analysis. The ordering of Ethereum, Cosmos and Anoma is intentional as it foreshadows staring with a tightly coupled architecture and topology and progressively taking unbundling to its natural endgame with Anoma.

Problem Statement

The contemporary blockchain development patterns tightly couple protocol architecture with network topology. This coupling limits the autonomy of both users and application developers which leads to application lock-in for users (security domain) and forces developers to evaluate difficult decisions with respect to where to deploy their applications. The goal of this art is to explore the benefits of drawing a clean line between the protocol architecture and network topology. A separation of architecture and topology can lead to more preference entropy or choice for users to express their preferences.

Protocol architecture is a mathematical specification of what the protocol is and does. In particular, what (complex) pattern of messages will be sent in response to (complex) patterns of messages received. The architecture of the protocol is chosen by protocol designers. The architecture of the network is a fixed variable, its static (mostly - you could decide to modify the architecture as in Ethereum’s Merge).

The topology of a network is the specific structure of connections. In the case of intent-centric systems like Anoma, connections derived from what the user’s intents are and they decide to send their intents. The topology of a network is chosen by the user. The topology can change frequently based on internal and external incentives of the network - MEV being one example.

Before we can draw any meaningful conclusions we would do well to examine the existing architectures and topologies of various blockchain systems. We’ll spend some time discussing Ethereum, Cosmos and Anoma diving into their unique architectures by exploring the mechanisms, affordances, counter-affordances, and examples. At the end of each section we’ll summarize our analysis and see if we can make progress on the problem statement.

Ethereum

  • Brief History from White paper to current.
  • Emphasis on applications
  • Brief on where the roadmap is taking Ethereum

Architecture

Affordances

  • Permissionless Smart Contracts (World Computer)
  • Decentralized trust
  • 3rd party verification (Full Nodes / Light Nodes - Sync Committee)
  • Atomic Composability (Main-chain)

Counter-Affordances

  • Liquidity fragmentation across L2s
  • Bundled Resource pricing (4844 helps)
  • Slow upgrades (governance process) - no in protocol governance mechanism
  • No Privacy

Mechanisms

  • EVM - smart contracts and account model, solidity / vyper, compiler
  • Gasper - Longest chain with finality gadget (LMD GHOST + Casper FFG )
  • Lib p2p - tx mempool - monolithic overlay

Topology

  • MEV Supply Chain - from simple public mempool to complex off-chain order flow auctions / private mempools / suave and other MEV redirection devices
  • Rollups/L2s - trade-off grid (left to right) Sovereignty → Interoperability. (top to bottom) Centralized → Decentralized
    • Centralized sequencer, decentralized sequencer, shared sequencer, based sequencer
    • Enshrined ZK-EVM “endgame”
  • Rainbow Staking - unbundling the roles of node operators (heavy and light) - who does what
  • Eigen Layer - different security models for different types of services (Oracles, verifiable compute, MEV services, data Storage)

Examples of applications - demonstrated topology (fixed)

  • Uniswap X - send intents to white-listed group of “fillers” (solvers) - use Uniswap Liquidity pools
  • L2s - all order flow sent to a particular L2 sequencer

Ethereum AT Discussion

Ethereum’s network topology is a function of the architecture.

for example, let’s consider the notion of the MEV supply chain. MEV arises because there is ordering on multiple domains like centralized exchanges. Decentralized exchanges which on Ethereum rely on the Constant Function Market Maker xy = k require market makers or traders to arbitrage their liquidity pools to keep the CFMM price in alignment with the centralized exchange price like Coinbase or Binance who typically house far more trading volume and liquidity than what exists on chain.

Because the EVM has sequential message passing for updating its state: step 1, step 2, step 3,…, step n, MEV agents are incentivized to place their own transactions in front of user transactions or re-order transactions to execute in a specific order or place their own transactions in a block in a specific order to benefit themselves and capture excess value; back runs, stat arbitrage, front-running, sandwiches, liquidations, long-tail strategies, et al.

Another constraint imposed on the topology as a result of the architecture is the Beacon chain’s 12 second block times. As a result, MEV agents have ample time to create profitable bundles and blocks by waiting for more order flow.

Fast block times and parallel execution are two architecture changes that would likely impact the network topology.

Finally, because the architecture is designed around the concept of don’t trust, verify it is a core value to allow end users to run their own nodes. As a result, scalability trade-offs have been made to push excess user demand to off-chain protocols like rollups or L2s which can be verified on Ethereum by running a full node and computing the current committed state of the rollup and checking its proof.

Here we’ve illustrated how architectural decisions impact the network topology and create a reinforcing feedback loop where the topology reinforces the need for the existing architecture. Changing the architecture is difficult because there are many stakeholders with various preferences but also there is much value locked up in Ethereum smart contracts / staked in consensus. Switching costs are relatively high for these folks.

Cosmos

  • Brief history of the interchain
  • Emphasis on app-chains
  • Can introduce Modular as well - app-rollups (don’t want to spend much time here)

Architecture

Affordances

  • Sovereignty
    • there is no center or middle of the interchain, all the coordination happens on the edges
    • user - operator separation
    • 3rd party verification
  • Interoperability
    • enabled by fast finality and shared standards
      • consensus and inter-consensus communication standards
    • trust-minimized, community decides whom to trust
  • Modularity
    • customize applications for user needs
    • outsource roles to specialists for a fee.

Counter-Affordances

  • There is no central point of failure - coordination is at the edges, messy and hard. while this is an affordance to a degree, it can increase coordination overhead (see Meditations on Molach - monarchy vs. democracy).
  • On-chain governance is inherently political; it provokes conflicts
  • Complex developer experience - launching an app chain is not as trivial as deploying a set of solidity contracts (not to mention difficult to find the right people to answer questions)
  • No Privacy for applications - there is no interchain-shielded pool. While Secret network does offer data privacy, there have already been known side-channel attacks, this network also struggled to gain a large anonymity set which is required. Namada and penumbra are two emergent options.
  • Application Lock-in - applications are tied to a particular blockchain, though asynchronous composability may be sufficient for many user experiences users are tied to a particular security / settlement domain to use a given application.

Mechanisms

  • Comet BFT
    • All to Leader to all communication, Favors safety over liveness (1/3 byzantine threshold). Single-slot finality, block times can be sub-second like injective or Sei. Mature software, formally verified. Proof-of-Stake and Proof-of-Authority Sybil resistance mechanisms.
    • ABCI++ - Provides hooks for applications to directly interact with each step of consensus including mechanisms like threshold decryption (Ferveo), native oracles (slinky), order books (DyDx), custom fee markets, multiple-concurrent block proposers
    • Legacy p2p layer is not ideal for developers looking to build unique features
  • Cosmos SDK - framework for writing blockchain state machines - customize application-specific business logic to suit developer / user needs.
    • VM support - CosmWasm, Ethermint, Polaris, and others.
  • IBC - standard message passing protocol
    • composed of three layers - transport, authentication and ordering - used to establish connections b/w chains
    • application standards - fungible and non-fungible token transfers, remote interchain queries, and remote execution with interchain accounts (ICA)
    • requirements - light clients & relays (permissionless)
    • blockchain agnostic - protocol can be run on a solo machine

Topology

  • Fixed per zone but user and community defined over the interchain
  • IBC is powerful it - allows developers to build distributed programs that can execute across domains
    • IBC.fun as an example
    • Interchain accounts applications
    • Packet Forwarding Middleware (canonical token representations - solve fungibility problem)

Examples of applications - demonstrated topology

  • DyDx - custom order book perpetual DEX, MEV social norms enforced by community, Left Ethereum
  • Celestia - designed as a pluggable consensus for rollups providing data availability sampling / and temporary data storage to customers.
  • Osmosis - Interchain AMM DEX, with various applications building on-top

Cosmos AT Discussion

  • Topology still partially fixed

Anoma

  • Intent Machine
  • Interface not intermediary
  • Novel applications
  • Global state synchronization

Architecture

Affordances

  • Permissionless intent infrastructure
  • Information Flow Control
  • Intent-level composability
  • Heterogeneous Trust

Counter-Affordances

  • Developers must learn a new programming language
  • Node side-car may increase resource requirements of node operators

Mechanisms

  • Resource Machine - unbundles state architecture from instruction set and storage format. Stateless machine that creates, composes and verifies transaction candidates - global reads / local writes
    • type of intent machine
    • Shell - produce, compose and evaluate transaction candidates
    • Core - Create (incl. compute nullifies of consumed resources, commitments of created resources, transaction delta, resource logic proof, compliance proofs) compose, verify, format data storage
  • Ordering Machine - Engines (Mempool, Consensus, Execution)
    • Mempool - Heterogeneous Narwhal - “logged mempool” workers hash txs provide DA
    • Consensus - Heterogeneous Paxos
    • Execution Engine - Calvin - parallel execution
  • Networking Machine - Intra and inter-domain communication, pub/sub protocol

Topology

  • It’s up to the user - Node architecture allows this - all agents of the system can subscribe to any others and perform different roles on a per-intent basis
    • Ethereum-centric
    • Cosmos-centric
  • Implementation
    • Protocol Adaptor / Side car - emulate resource machine, verify succinct proofs / run Anoma protocol
    • Anoma Node integration - Resource Machine instead of cosmos SDK or EVM + Ordering machine

Examples of applications - flexible topology

  • Public Signal - Aggregate demand from multiple domains
  • Mario Swap - Cow Swap on Anoma what would this look like?

Anoma AT discussion

  • Intents unbundle everything
    • User chooses application first, security domain second

Open Questions to address Meta AT discussion

  • What is the problem statement specifically, and are we even answering it?
  • How does Anoma’s explicit unbundling of architecture and topology beneficial for users? Does the additional preference entropy overwhelm users?
  • What does the user interface for intents look like? Would it be possible to compile intents with the assistance of LLMs from Natural language? Is there some type of interactive dialogue that could help?
  • More… (can’t think right now)

Conclusion

  • Summarize learnings
  • Further exploration - mathematical formalism
1 Like