WTF Is Anoma? Part 3: WTF is Typhon?

Typhon: The Mempool, Consensus & Execution Engine

We’ve talked about intent-centricity a lot up until this point, and for good reason. Intents, and moving from an imperative to a declarative paradigm, is the bedrock of what makes Anoma. We now shift our focus to Typhon; Anoma’s mempool, consensus and execution engine. 

When we think of Anoma we think of it like Cosmos. Not a single chain like the Cosmos Hub, but the world of interconnected blockchains through IBC built with the Cosmos SDK. Anoma looks to extend the Cosmos vision one step further; not only allowing sovereign chains the ability to communicate with each other, but to be aware of and coordinate with each other atomically on-demand. Most importantly, Typhon enables Chimera Chains, a new kind of on-demand chain to enable this cross-domain atomicity.

A side note: You may know the term Chimera from greek mythology, but what it really means is a single organism made up of two separate sets of DNA, like this cat. Chimera Pools/Chains are the combination of “DNA” from different domains.

There are three main architecture changes Typhon makes over Comet (Tendermint successor) that we’ll highlight in this section.

1. The Block Proposer Bottleneck (mempool): In Comet, the leader uploads and propagates blocks with full transaction data to all other validators. This centralized block propagation decreases throughput and increases latency as large amounts of data are constantly being sent from a single validator to multiple. Instead, Narwhal’s DAG-based mempool takes advantage of the fact that other validators already have these transactions locally, and the proposer just sends the block with references (hashes) of transactions that we already know are available. Narwhal is already used in Aptos and Sui; Typhon adapts it to Heterogeneous Narwhal to enable Chimera Chains.
2. Cross-Domain Atomicity (consensus): Today many blockchains have overlapping validator sets. In theory, this means chains can, to some degree, be aware of and influence transactions taking place on other chains. In practice however, we don’t see chains taking advantage of this. Chains run consensus protocols in siloes, without the ability to recognize overlaps in each other’s active validator sets. With Typhon, independent chains can be aware of overlaps in each other’s validators and take advantage of it to communicate with stronger atomicity guarantees.
3. Parallel Transaction Processing (execution): Most blockchains today have serial execution engines. This means that transactions are executed one by one, regardless if they have any relation to one another which fundamentally limits throughput. Typhon allows for serializable execution, which allows us to execute non-conflicting transactions in parallel and arrive at the same result as if we were to do them one by one. This is similar to Solana’s Sealevel and a common direction we see from new blockchains like Fuel, the Move chains Sui and Aptos, and even with the EVM in Monad.

We’ll dive into all three, starting with the mempool.

Mempool: Fixing the Block Proposal Bottleneck & Chimera Pools

Typhon uses Narwhal to remove the leader-based bottleneck and then adapts it to enable Chimera pools, “Heterogeneous Narwhal”. In other words, the superposition of multiple Narwhal mempools. First, let’s talk about the bottleneck.

In Comet there are 3 steps in consensus: propose, pre-commit, and commit.

1. Propose: the leader takes transactions from their local mempool and proposes a block containing all of the transaction data to the other validators.
2. Pre-commit: the leader receives back messages from the other validators to confirm that they have received and that the block and all transactions in it are available.
3. Commit: the final round of consensus takes place where validators vote to confirm the block and execute the transactions.

The problem here is that resources are fully-utilized for the leader and under-utilized for everyone else, as only one machine (the leader) is using its full capacity at a time.

Narwhal

In Narwhal, instead of the proposing validator sending all transactions in a block to the other validators they just send references to transactions that we know are available (that other validators have already received in their local mempools). The transaction data can thus bypass the consensus process, removing the large data transmission step from it. This propagation of data is often the limiting factor/bottleneck in consensus. The more validators you have, the longer it takes to propagate data to all of them and get 2/3 to commit to a block. In essence, instead of being tied together, the mempool (availability) and ordering (consensus) are decoupled. You isolate the data propagation to the mempool and then just reach consensus on metadata, and reaching consensus on metadata is cheap. Consensus gets rid of the “baggage” that is transaction data which just skips consensus and goes straight to the execution engine.

Narwhal then runs the mempool protocol with these hashed batches of transactions. Validators propose blocks to others and receive back signed certificates of availability and integrity. In the genesis round, a single block will be finalized by consensus. Other validators then do the same, broadcasting their own blocks and receiving back certificates of availability in the process. New blocks reference previous certificates of availability from past blocks (and the genesis) and continue to build on top. Notably, these blocks continue to get built in the DAG without involving consensus. Every once in awhile, consensus will run to vote on and finalize a block in the DAG and in the process finalize all previously referenced blocks with certificates of availability.

To illustrate: in the chart below the green “GEN” is the genesis block. New blocks are then built by all validators with their own certificates labeled “X2”, referencing the Genesis certificate. A new round of consensus is then run again which commits the red block “2”. All of the “X2” blocks referenced by red block “2” then get committed and ordered. Then another round “3” runs later, again committing new blocks (X3) with referenced certificates. This is how we decouple the building and partial/pre-ordering of the DAG of transaction data from finalizing the total order through consensus.

There are some other nuances to Narwhal like workers and primaries, but this is it in a nutshell. 

More specifically, this is how Narwhal works for a single chain. We needed to understand Narwhal so that we could understand Heterogeneous Narhwal. Heterogenous Narwhal is Typhon’s adaptation of Narwhal that looks to answer the question “How do we get multiple different Narwhal mempools working together”, giving us the cross-chain interaction we so desire. Typhon does this through superimposing multiple Narwhal mempools, called Chimera Pools, and are necessary to make Typhon’s Chimera Chains work. If we have several Narwhals running, Typhon makes sure they work together.

Heterogeneous Narwhal

Consider that we have two separate chains with their own DAGs, a blue chain and a yellow chain. We also have 5 validators that are validating these chains, broken down as follows:

• Validator 1: only validates for blue chain
• Validators 2, 3, 4: validate for both blue and yellow chain
• Validator 5: only validates for yellow chain

These validators are running independently and running their respective DAGs. The Chimera DAG is then the superposition of these, and allows us to have a separate DAG (the Chimera) with validators 2-4 whose blocks can reference transactions from both blue and yellow chains, and is represented by the green validators below. We assume 3/4th of validators in yellow and blue chains are live and honest, which gives us the property that at least 2/3rd of the green chain is live and honest as well. This is what gives Anoma transactions the ability to atomically settle across domains. The Chimera DAG can for example have a block that includes a cross-chain swap between the blue and yellow chains.

The Chimera DAG has a slight difference vs the single chain DAGs in that it just runs off of block headers, receiving certificates from each chain. The important takeaway is that we are composing two separate DAGs, a critical step in order to enable cross-chain atomicity. We could draw another DAG here but I think you get the point, and quite frankly drawing DAGs sucks. 

Now remember, Narwhal DAGs are just for pre/partial ordering. To finalize we need a consensus protocol, and more specifically, one that’s cross-domain aware. Enter Typhon’s Heterogeneous Paxos.

Consensus: Atomic Cross-Domain Transactions Through Chimera Chains

The main concept you should take away from Typhon is Chimera Chains.

That is, Typhon is built on Heterogeneous Paxos & Heterogeneous Narwhal to specifically enable Chimera chains. Heterogeneous Paxos will take our transactions/blocks from the Narwhal DAG and order them. Like how Heterogeneous Narwhal is adapted from Narwhal, Heterogeneous Paxos is adapted from Paxos. You see this word Heterogeneous a lot, which more specifically describes security models of Heterogeneous Trust. So what does Anoma mean by Heterogeneous Trust, and why such a focus on it? We start from the reality that blockchains are moving towards a multi-chain world and have heterogeneous participants by nature.

Heterogeneous Trust

The ecosystem that most represents this is Cosmos. You have different blockchains with different validators, participants & state machines, all with different (heterogeneous) trust assumptions. The drawback to this model, and a common critique of appchains, is that while you gain sovereignty, applications as sovereign chains are not able to benefit from atomicity like they can when they’re deployed as contracts on the same chain. But when you dig into Cosmos, you notice something glaring that stands out: these chains often have overlapping validator sets. This map from Numia data shows all of the different Cosmos chains and how the voting power overlaps between them. The darker the green, the stronger the overlap between them.

Zooming in we can look at the Cosmos Hub, and by doing so come to the conclusion that the majority of Cosmos chains have at least 1/3 of their voting power also validating for the Hub. If you take a step back and think about it without any knowledge of how distributed consensus works under the hood, you may assume that these chains are able to take advantage of this and come to consensus on multiple systems at once.

Unfortunately, Tendermint / Comet is oblivious to it. Even consumer chains who have a 100% overlap in their validators through the Cosmos Hub can’t communicate synchronously with each other because consensus doesn’t understand that validators are one and the same. 

With Heterogeneous Paxos we enable every chain running Typhon to be aware of these overlapping quorums and can come to consensus on cross-chain transactions atomically. But before getting to Chimera Chains, we should describe how cross-domain transactions work today, and what the drawbacks are.

Cross-Domain Transactions Today

The way blockchains try to do cross-chain transactions today usually involves a Multi-Phase Commit protocol. Take the example of someone trying to buy a hotel room and plane ticket; they want to be sure they can buy both at the same time to avoid buying one and then having the other become unavailable or sold out. The way this works is as follows:

1. Chain B (plane ticket) puts a lock/hold on the state (ticket purchase) on that chain. The ticket hasn’t been purchased, but it’s reserved for this one user. While other transactions and blocks are built on this chain, the plane ticket stays locked.
2. Chain A (hotel room) puts a lock on the hotel ticket.
3. Chains A and B need to coordinate through IBC (or another messaging protocol) to indicate that each chain has indeed locked the relevant state.
4. The plane ticket is booked on Chain B and Hotel room on Chain A, and the state is unlocked.

While this can work, there are three main drawbacks to the approach:

1. Liveness: Chains A and B are now affected by the other’s failures. If B locks state and then A fails, B’s state will continue to be locked due to failures outside of its control, caused by a set of validators/separate consensus it has no interest in.
2. Latency: A multi-phase commit requires at least 2 rounds of consensus, as it is not possible to send an IBC message to one chain and receive back a response in the same transaction.
3. Game Theoretic Problem: One of these chains will lock their state after the other, giving them a “free option” on whether to execute or not. We can best illustrate this with a cross-chain swap, as prices could change after the first chain locks and the second gains an advantage. It incentivizes the second chain to delay, which should be avoided.

Shared sequencers and SUAVE will still have to deal with this fundamental limitation. While shared sequencers can provide atomic inclusion they cannot provide atomic execution, as you still have the problem of one chain’s state machine executing one transaction and the other reverting. The work-around here is the expectation that builders/solvers will essentially front the liquidity from their own inventory to provide atomic execution for a fee, but this is at a different layer than each blockchains’ consensus and re-enforces centralization of builders and solvers. Shared validity sequencing is also a promising idea, but still has some trade offs like less sovereignty and higher resource utilization on the sequencer.

Chimera Chains for Cross-Domain Atomicity

Typhon wants to go one step further here and give any chain the ability to execute cross-domain transactions by default. They do this by exploiting the validator overlaps we have discussed with a heterogeneous consensus protocol that is able to commit to atomic cross-chain transactions. 

To understand how this works we first need to talk about quorums.

A quorum is a set of validators who can decide on a block by themselves, w/o having to communicate with anyone else. 

Typically, blockchains are designed to tolerate up to 1/3rd byzantine nodes (determined based on stake weight in PoS). Consequently, a quorum is defined as any set of validators who collectively own 2/3rd of stake. 

Let’s see why this is the case in more detail. For sake of simplicity, we can consider a consensus where stake is equally distributed amongst 100 nodes. In this case, a quorum would be any set of at least 67 nodes.

As any quorum (a set of 67+ nodes) can unilaterally decide on a block, we need to make sure that each pair of quorums has at least one honest node at their intersection. Otherwise, two separate quorums within the same consensus set (100 nodes), can vote on two conflicting blocks at the same height, and the chain can fork. Assuming there are at most 33 byzantine nodes, we know for a fact that any two distinct quorums must have at least 1 honest node at their intersection. As this honest node wouldn’t equivocate, quorums can’t decide on conflicting blocks. This is where security properties originate from within a single chain.

The security assumptions behind Chimera chains are no different. Say chain A and chain B, spin up a chimera chain AB. We want the Chimera chain AB, to commit to a bundle of multichain txs (txs of A & txs B) atomically; either both of them are executed or neither is. The security assumptions behind this atomicity guarantee rely on overlaps of validators of chain A and B. More overlaps in validators can tolerate higher numbers of byzantine nodes and thus provide stronger atomicity guarantees. 

More precisely, we want at least one honest node at the intersection of quorums of chain A and B (shown as the green triangles in above diagram). This would in turn ensure that both chain A and B will retain a consistent view of chimera chain AB. In other words, they will always agree on whether to commit to a shared bundle of txs or not. 

In any case, assuming the overlap in validators is <100%, the atomicity guarantees of Chimera chain AB will have stronger assumptions than that of either chain. In other words, the Chimera chain AB will be able to tolerate fewer byzantine nodes than chains A and B to guarantee atomicity. 

If the trust assumptions don’t hold and the Chimera chain is taken over by byzantine nodes, the atomicity guarantees of Chimera Chain AB can be broken. In this case, chain A and chain B can start having non-consistent view of the Chimera Chain AB.  For example, Chain A might think, some tokens on Chimera chain AB as currently owned by Bob, whereas Chain B might think them as currently owned by Alice. 

Even in this bad case however, byzantine nodes that corrupt Chimera Chain AB’s quorum won’t necessarily be enough to corrupt those of Chain A and Chain B. Therefore they can’t corrupt the security (safety and liveness) of neither chain; causing them to be stuck or make an invalid state transition. Chain A and B quorums can continue to decide on blocks in their respective chains as they normally would. This situation is analogous to 2 secure chains with a corrupt bridge between them. In practice, identification of corruption on the bridge may or may not trigger an intervention via social consensus depending on the impact. 

The goal of Typhon is to allow chains to keep their sovereignty with their own security models, state machines, applications, liveness and integrity guarantees w/o having to give up on atomic execution; chains can spin up and commit to Chimera Chains when desired. Assuming the security assumptions hold, Chimera Chains would be a much faster way for chains to cross-communicate (w/o locking resources) as they remove the need for multi-phase commits prevalently used in existing bridges.

While we have walked through a simple example of a pairwise Chimera Chain with overlapping quorums, Chimera Chains, powered by Heterogenous Paxos, can have a much broader design space (Chimera Chain with more than 2 base chains, trading off liveness for safety etc.) These solutions and their technical challenges are explained in much detail here and here. We highly recommend both resources for the interested readers.

Chimera Chain Use Cases

Now, Chimera chains aren’t useful to run all the time. For starters, running high throughput blockchains are resource intensive and you really only want to spin up a Chimera when there are real benefits to the atomicity. For two DEX’s on separate chains this probably makes sense. If the arbitrage opportunity between the two are frequent and thousands of dollars, sure. But if infrequent and small, maybe not. For a gaming and DEX chain, again probably not, as the opportunity cost of foregoing atomic execution is not as high. 

The point to get across here is that cross-chain communication guarantees can be decided dynamically by the demand side.

In current state of the world users are presented with a static, binary choice; either everything is atomic (and gain composability) or nothing is atomic (and lose composability). More importantly this choice is driven by the supply side; whether or not a Cosmos chain should be fully sovereign, or a consumer chain to the Hub, is decided by those who build the chain.

Chimera chains flip the equation. With Chimera, chains can retain their sovereignty with the option of atomicity on-demand. The decision is driven by the demand-side; ie. users. Users can choose to pay more for better cross chain atomicity guarantees, if and when the economics make sense. You could even make a version of the Interchain Scheduler from the ATOM 2.0 whitepaper to schedule rounds of consensus on a Chimera in advance.

Chimera Chains pair well with the solver network. The question will be when is it ok to accept some latency vs when is atomicity critical. Consider the tweet below.

If one wanted to buy a Bad Kid NFT from Ethereum they would need to go through the following steps:

1. Send ETH to Osmosis through Axelar using an Ethereum wallet like Metamask and receive axlETH
2. Swap axlETH on Osmosis for STARS with Keplr or another Cosmos wallet
3. Send STARS from Osmosis to Stargaze
4. Buy Bad Kid with STARS on Stargaze

Each step here is a separate transaction dealing with multiple wallets, blockchains and bridges. Not only is it cumbersome and slow, if you’re never done it before you need to spend some time researching on how to actually do it. The buyer also needs to acquire two intermediary assets on the path to get what they want. Instead, consider the intent [swap ETH for Bad Kid] was sent to Anoma’s solver network.

If Ethereum is integrated with Anoma’s solver network, then perhaps the first leg would be handled by some solvers specialized in bridging. A solver could complete the intent partially {bridge ETH for axlETH} and then pass it off to another solver pool. The remaining steps 2-4 {swap axlETH for STARS on Osmosis, send STARS to Stargaze, swap for Bad Kid} could then be completed by another solver. Do we need a Chimera Chain for this? Maybe. The first step couldn’t use one as Ethereum doesn’t run Typhon, but steps 2-4 could be combined in one transaction. Stargaze doesn’t have any liquidity for STARS or other tokens and so Cosmos NFT buyers need to go somewhere else to even be able to buy an NFT on Stargaze, often in multiple steps. Crucially, by utilizing the solver network the user doesn’t need to research the steps in the process, deal with bridging (which has its own risks), receive fast execution, and abstract away the buying and selling of multiple intermediary assets. A Chimera Chain would be useful here, but not critically necessary, as the solver network can handle the bulk of the user’s problems, which is more UX-based than time-sensitive. However, if Stargaze and Osmosis have significant volumes between them then it will probably make sense to reduce any execution risk given the economics at stake and reduce the need for solvers to carry inventory/take on price risk. Also, as we mentioned above with the “Interchain Scheduler”, chains could schedule rounds of Chimera blocks in advance, setting a known window of time (every x blocks) that solvers know they can re-balance between them.

Now consider a money market chain like Umee where someone has an outstanding USDC borrow with ATOM collateral that is facing liquidation. USDC and ATOM liquidity sits on external chains to Umee, so when prices are moving fast there’s a risk that multi-hop bridging will be too slow to liquidate in time. In this case, it makes a lot of sense for Umee and a DEX chain like Osmosis to have a Chimera chain between them. While Umee could launch as a contract on Osmosis, they would be sharing blockspace with Osmosis and have to build to more constrained specifications. Osmosis also has various contracts and applications deployed on top which are irrelevant to Umee and they only really need to facilitate transactions between them when it comes to liquidations. By utilizing a Chimera for liquidations, they can keep their money market chain optimized for their own application and then coordinate with Osmosis less frequently, only when needed. Scheduling rounds of Chimera blocks in advance could be useful here as well, but liquidations (especially large ones) are sporadic, and having the option of true on-demand atomicity would be more critical.

Alternative Solutions to Cross-Domain Atomicity

While Chimera Chains are one solution to cross-domain atomicity, there are other teams working on competing solutions that we’ll go over here. The two most important distinctions Chimera Chains have over other solutions are as follows:

1. Chimera Chains allow cross-domain atomicity with heterogeneous trust assumptions (different validator sets) while others operate under homogeneous assumptions and thus share sequencers/validators/builders.
2. With Chimera Chains, cross-domain atomicity guarantees aren’t a static design choice taken by the supply side (builders). Instead, they can be dynamically determined by the demand-side (users). 

Shared Sequencers: When we say shared sequencers it can mean a single, centralized sequencer sequencing for multiple rollups or a decentralized set of sequencers doing the same. A shared sequencer is able to guarantee atomic inclusion between two rollups but cannot guarantee atomic execution. In order to get some sort of execution guarantees we would need to have builders (or SUAVE) build & commit to blocks on both rollups and to be slashed if misbehaving. While workable, this places a lot of centralizing trust/dependence in builders and does not give us the atomicity property we desire between two domains, and thus has led to another idea, Shared Validity Sequencing.

Shared Validity Sequencing: From Umbra Research, Shared Validity Sequencing adds a few things to the shared sequencer design, namely (1) a method for the sequencer to accept cross-chain actions, (2) block building algorithm respecting atomicity & conditional execution guarantees and (3) shared fraud proofs between rollups. These 3 additions solve our problem of atomic execution as all the rollups are coupled together. Essentially, rollups that share the same validity sequencer (either centralized or decentralized) are kind of like shards with their own fee markets but act similarly to a singular entity.

This is achieved by adding another contract to each rollup which represents cross-chain actions. The simplest, is a burn and mint contract on each rollup. For example, the diagram below shows the burning of assets on Chain A and minting on Chain B for an atomic cross-chain bridging transaction.

The Merkle Root on each rollup matches exactly, and then that root (along with tx batches) is posted by the sequencer to the L1 in the same transaction. The rollups then also share the fraud-proof mechanism, if the root from the burn on one chain doesn’t match the mint on the other, the sequencer will be penalized. What you get here is a tightly coupled rollup ecosystem where interoperating between them all becomes easier. Of course, the tradeoff is that rollups as applications lose their sovereignty and the sequencer has more demands placed on it. Chimera Chains have the benefit of more flexible validator sets and sovereignty (i.e. don’t need 100% overlap), but with that comes weaker atomicity guarantees. Chimera Chains also have the advantage of allowing atomic communication or arbitrary message passing (don’t need to deploy contracts for certain actions) as communication between them happens locally.

One project recently announced in this area is Rome Protocol, a shared sequencer network using Solana as a shared blockchain. Rollups using the Rome network will deploy an identical Neon EVM instance on Solana, and can utilize some of the functions described above. Solana already has high hardware requirements for validators, a large stake backing it, and fast finality, so the architecture is quite interesting.

Atomic IBC: This is the newest entrant to the “cross-domain atomicity” market, outlined in a post from Jehan at Informal Systems in September. Atomic IBC is an addition to Replicated Security and Consumer Chains. Like Shared Sequencers, Atomic IBC requires all chains to use the exact same validators/sequencers. It’s also similar to shared validity sequencing in a sense that every consumer chain will have its own fee market and application(s), allowing for strict parallelized execution through separate chains.

Atomic IBC uses the concept of “megablocks”, giving every consumer chain who wants to participate in Atomic IBC share the same mempool and blocks. Note that not every consumer chain needs to participate in Atomic IBC, but if it does it needs to signal to be included in these megablocks. While these chains share a mempool and blocks, transactions will still run in parallel in their own lanes unless they need atomicity. Atomic IBC transactions are scheduled to run at the beginning of each block and then normal transactions follow. This is a novel solution and has the potential to work quite well, but only for chains in the AEZ (ATOM Economic Zone). It only works if you’re a consumer chain secured by ATOM and opting in to it. As we said earlier, Comet doesn’t allow consumer chains to naturally get atomicity even though they have overlap. Atomic IBC is the solution to that problem.

The biggest difference with all three, as we can see, is that Chimera Chains, and Heterogeneous Paxos, is the only solution that can enable “on-demand” atomic transactions without a strict 100% overlap requirement in validators/sequencers. Shared Validity sequencing and Atomic IBC will have stronger atomicity guarantees because of the 100% overlap but then these chains are essentially locked-in to these eco’s. For some rollups/appchains this may be the correct solution, for others they will want something more flexible.

Open Questions

Intents and the solver network, combined with Chimera chains, can remove a lot of the cross-chain coordination and UX nightmares that chains face today. From the perspective of a user, we see this as mostly a UX improvement where a lot of the complexities are abstracted away. For a solver, we see it as an execution & settlement improvement with atomic execution across domains, allowing them to take on less inventory risk to settle user intents. As solvers take on less risk to settle transactions across domains, they can offer users better execution (i.e. better price). We see Chimera Chains in this regard, mostly as a tool for solvers to offer better execution to users, with users never directly interacting with them themselves. With that being said, Chimera Chains are a new concept and there are still unsolved questions that will need to be answered.

• Who pays for Chimera and how? If a number of users want to benefit from it, how does the cost get split amongst them? Will users on base chains have some % of transaction fees continuously routed to keep Chimera running, or will they be collected lump-sum when transactions are demanded? Alternatively, can a solver front the cost on behalf of users? 
• When do you kill a Chimera chain? There’s a cost/benefit to keeping open and maintaining vs having to re-deploy in the future.
• Quorums in blockchains change all the time, and chains may fork. Do you update the Chimera whenever they happen or just when there’s a new transaction?
• Are solvers incentivized properly for cross-chain batches? Chimera Chain MEV?
• If two or more chains frequently commit to Chimera chains, does it still make sense for them to be standalone? What’s the frequency of atomic cross-chain commits where it makes more sense to combine them?
• Will the parallelization trend of VMs negate the need for many chains and thus the need for Chimeras? How many different blockchains will people want to settle between?

While there are open questions, the cross-chain composability Chimera Chains give to sovereign chains is exciting. Lastly, all of the transactions need to be executed, and this is done with a serializable execution engine.

Execution: Adding Concurrency in State Machines

Typhon’s components work together in the following ways:

1. The mempool handles receiving transactions from solvers/clients, storing them and then partially ordering through the DAGs and Chimera DAGs.
2. The mempool sends block references to consensus and the transaction candidate contents + the partial order information to the execution engine.
3. Consensus takes the transactions and decides on a total order, both for base chains and Chimera chains. At the same time, the execution engine is able to execute some of the transactions from the information it received from the mempool.
4. The execution engine gets the total order from consensus and executes all transactions and does a state transition.
5. The execution engine sends “garbage collection information” to the DAG letting it know when its completely ordered and executed parts of the DAG and no longer needs to store the referenced transactions.

These, along with the P2P layer, are Typhon’s main components.

At a high level, the execution engine does concurrent or serializable execution, i.e. executing non-overlapping transactions at the same time. It does this by having transactions specify what parts of the state it will read/write upfront, and if you read our Solana The Monolith report you will notice it’s similar. State machines (EVM, SVM, etc) are independent to Typhon and thus can support a variety of VMs as long as they conform to Typhon’s API.

So… What is Anoma?

“Anoma is about intents… no, Anoma is about privacy… actually, while intents and privacy are cool, Anoma is really about cross-chain atomicity and Chimera Chains”. If this is you when researching Anoma, you are not alone. Just when you think you understand it you stumble onto something else.

Anoma can be overwhelming to understand because of how vast its scope is. It’s not a blockchain, or an L1, it is merely an architecture for an intent-centric world. Putting it all together, we can visualize Anoma and its numerous parts in the diagram below.

While confusing at times, we hope this three-part series has answered the question of what Anoma really is.