Blockchains have grown to prominence as the primary type of distributed ledger technology during the last decade. Regardless of their present prominence, a rising number of initiatives are offering alternate solutions to key scalability concerns inherent in blockchains. One of these suggested technologies is the DAG, or Directed Acyclic Graph, which has been pushed as a more effective option than standard blockchains by a number of alternative layer 1s. However, there is still some misunderstanding in the web3 sector regarding what a DAG is and how it relates to current blockchain technology. This article aims to educate readers on L1s that use DAG technology by fully describing how they work and how they can be used within crypto applications while also providing a method to classify various uses of DAG technology and provide knowledge of how they function.

What precisely is DAG?

DAG is an abbreviation for Directed Acyclic Graph. This may be a mouthful for anyone unfamiliar with computer science principles, so we've broken each phrase down below:

- Directed: The database model only flows one way.

- Acyclic: The data structure cannot revert from its present state to a prior one; it is "non-cyclical."

- Graph: The data structure emerges as an interconnected collection of interactions between vertices when displayed.

What is the appearance of a DAG structure? The simplest approach to tell whether a data structure is a DAG or a blockchain is to look at how the data is organized. The sequence of transactions in time is referred to as ordering. Because our sense of time is linear, we have usually thought of events happening in a definite order. Humans normally agree on a time, and we all agree that events occur in sequential order.

The sequence of events will always be determined by whatever event happened first. We know the precise, complete order of each event in a series of events that are entirely ordered. Using a complete order, Event A comes first, followed by Event B, and finally by Event C. This is how blockchain events are stored.

A distributed ledger's total ordering, on the other hand, may restrict scalability in terms of speed and latency. To address some of these concerns, we may "partially order" the ledger. The precise ordering of each event in respect to every other event is unknown at this point. Rather, just the order of related events is known. We can't be certain of the order of all events, but we may be certain of the order of events that are dependent on one another.

For example, we may assert that Event B occurred prior to Event C. In a partly ordered system, however, we don't know when Event A happened. It may have happened before, after, or even in the middle of these occurrences. Event A has no bearing on the other events.

In general, why would we care about the sequence of these transactions? The goal of arranging events is to determine how one event led another to occur. Because partial ordering has no sense of time, how can we sequence events without having to guess when each event occurred?

"Causal ordering" is the solution to this issue. Causal ordering is a partial order that does not take into consideration when the events happened but rather the cause-and-effect connection between them. We can arrange the events if we know which events triggered which others.

Above is an example of causal ordering. Because there are no timestamps, determining when these events occurred may be impossible. However, we can see that A caused B to occur, and B caused C and E to occur. It follows that A ultimately caused D and F to occur. We can ascertain the causal order of C in regard to D and the causal order of E in relation to F since C caused D and E caused F. We do not, however, need to define the order of C in regard to E or F, or E in relation to C or D. Because unconnected occurrences do not need to be ordered in regard to one another, not all events have causal links to one another and are only partially ordered.

We are no longer restricted to a "chain of events"-like structure when we use causal ordering, enabling us to design a DAG structure instead. Ordering events that have nothing to do with one another is unnecessary. A DAG is a distributed ledger with causally-ordered transactions, while a blockchain is a completely-ordered ledger. Because causal ordering enables some transactions to bypass sequential processing altogether, a DAG-based ledger may provide a scaling benefit in terms of throughput and latency over a blockchain-based ledger.

Many layer 1s now advertise DAG technology as a design differentiator, but not all of them employ DAGs to achieve causal ordering. Unfortunately, no framework exists to split the DAG space. For the sake of this article, we shall determine what genuinely constitutes a DAG layer 1 and attempt to categorize relevant projects into two groups depending on how their transactions are organized. First, we'll look at layer 1s, which employ DAGs to execute transactions but have completely ordered ledgers. Then, we'll look at layer 1s, which have causally-ordered ledgers and employ DAGs as data structures to record events and transactions. It is critical to distinguish between protocols that employ a DAG-based ledger and those that use a DAG as part of their transaction processing since the latter may not achieve the same boost in transactional throughput.

DAG-based blockchains

How are DAGs used in some totally-ordered blockchains?

Fantom is an example of a blockchain that uses a DAG to accelerate its consensus mechanism while producing results in a conventional, completely ordered blockchain structure. When a blockchain claims to be DAG-based, it is usually because layer 1 uses a DAG-based consensus process rather than a DAG-based ledger.

Fantom - DAG technology consensus

Lachesis, Fantom's consensus mechanism, creates the Opera Chain, a DAG-based structure. The network is made up of nodes, which are computers that execute Fantom's software. "Event blocks" are the building components of Fantom's consensus process. Fantom's understanding of blocks differs from the word "blocks" as it is typically used.

At a high level, nodes generate event blocks, which combine to build a DAG. Fantom produces a blockchain by using a DAG of event blocks.

Fantom records information in event blocks that include financial, and technical information. A single node creates event blocks to exchange transactions and user data with the network's other nodes. The DAG structure is seen above, with event blocks created by nodes represented as circles. Every node generates event blocks. Every time a node exchanges transactions, a new shared event block is created. Event blocks are distributed over the network. When one event block connects with another, the event block that was communicated with saves the transactional information of the preceding event block, which then produces a new event block. This data is then passed on to the following event block. Each event block includes a hashed value of one or more preceding event blocks, and transactional information is hashed. Because earlier event blocks cannot be modified or deleted without modifying their hashes, the data becomes immutable.

Source: Fantom

The Opera Chain DAG's green highlighted sections are event blocks that interact with one another until they discover a single event block known as a "Clotho" block (the blue block in the above picture). The Clotho block includes a "flag table," which is a data structure that stores all connection data between particular event blocks. Clotho blocks must have a supermajority of more than 23 connections to a preceding set event block to be designated Clotho blocks. The flag table data structure is used by Clotho Blocks to connect with other Clotho Blocks in the DAG Structure.

Clotho Blocks reached an agreement to build another event block termed an "Atropos" block based on the knowledge offered by conversing with one another (green blocks in the above chart). When a Clotho block is formed, it contains a timestamp. If at least two-thirds of all nodes have the same time, the Clotho block transforms into an Atropos block. The "Main Chain" is made up of Atropos blocks connected together. Within the DAG structure, the Main Chain may be considered a blockchain. Each Atropos block is linked to the others, sharing the information obtained from all other occurrence blocks, which is gathered from the Clothos blocks.

This Main Chain provides the overall order of all occurrences. Every participating node has a copy of the Main Chain and may use the Lachesis consensus mechanism to look up the historical location of its own blocks. Nodes are not required to hold all of the information from each event block and may instead refer to the Main Chain. This allows for quick access to the prior events' ordering.

It is critical to note that most DAG protocols are unable to include smart contracts since smart contracts often need the sequencing of all transactions that interact with them in order to function effectively. This is shown via IOTA and Avalanche's X-Chain. The Opera Chain, on the other hand, is designed to provide for the proper timing and sequencing of transactions. While the Fantom Opera Chain improves transaction performance over Ethereum Mainnet, it may not provide the same delay and speed as other causally-ordered DAGs. This is because the Ethereum Virtual Machine (EVM) used by Fantom's Opera Chain is a limiting factor in and of itself. By enabling the Cosmos SDK to be developed on top of Lachesis rather than the EVM, Fantom's Opera Chain alleviates part of this bottleneck. Fantom intends to develop the Fantom Virtual Machine (FVM) in the future, which should boost scalability even more. Since Fantom's ascent, Ethereum has become the foundation for new Layer 2 scaling solutions. In this wave of new scaling solutions, Fantom's EVM layer is losing relevance, and it makes sense for Fantom to concentrate on the FVM to go beyond the limitations of what is presently achievable with its existing solutions.

DAGs with causally ordered output. When most people mention "DAG," what they mean is a causally-ordered distributed ledger. How do these DAGs function, and what makes them distinct from their totally-ordered counterparts? Avalanche's X-Chain, IOTA, and Sui are instances of causally ordered distributed ledgers.

Avalanche X-Chain - a DAG based on UTXOs.

To record the status of transfers between wallets, Bitcoin adopted the unspent transaction output (UTXO) paradigm. Each UTXO is a chain of ownership, with the current owner signing the transaction to transfer UTXO ownership to the new holder's address. Bitcoin is best defined as a blockchain in the context of UTXO, while Avalanche's X-Chain is best described as a DAG. The X-Chain employs the causally-ordered Avalanche consensus technique. You are utilizing the X-Chain when you send someone AVAX. Knowing how Avalanche's DAG works begin with understanding how Avalanche's DAG structure is produced.

The Avalanche consensus is made of four basic building blocks: slush, snowflake, snowball, and avalanche. Snowman is distinct from Avalanche, as we shall see later. Let us first examine how Slush consensus works. The Avalanche network is made up of numerous nodes. Each node may be in one of three states: neutral, true, or false. This is best represented by the colors uncolored, blue, and red.

Every node begins uncolored and must decide whether to vote true or false (red or blue). After selecting a color, the node connects with many other nodes in the chain. If the nodes do not yet possess a color, they will take the color of the node with whom they communicated. If a majority of the nodes share the same color, the original node's vote remains unchanged. If a different color is represented by a majority of the nodes, the original node will change its vote to that color.

Multiple rounds of communication will take place between nodes until all of them are on the same page. The aim is for everyone to agree on what color it is. The nodes with the most of a certain color should determine what the right color is. This is the foundation of Avalanche, upon which everything else is built.

Snowflake consensus is Avalanche's second building component. Memory is implemented in the nodes at this point. A counter is assigned to each node. The number increases for each Slush communication that returns the same color. The number restarts every time the node changes color. When the counter hits a certain threshold, it locks its state and prevents the node from changing color. This helps to establish the genuine color.

In the third building block, Snowball, nodes begin to get more memory. Snowball adds a sense of confidence on top of Snowflake. Rather than changing color depending on the nodes with whom it interacts, it will examine all of its own color changes and alter its color based on the node's confidence level, as assessed by its vote change history.

All of this builds up to Avalanche. Avalanche is a DAG that is append-only (transactions add to preceding ones). Avalanche may work without a DAG structure, as shown by its linearization on the Contract chain (C-Chain) and Platform chain (P-Chain). The company behind Avalanche consensus, Team Rocket, believed that the DAG design was preferable to a blockchain method because it allowed for more efficient voting since one transaction represents a vote for all transactions it is added to.

The Avalanche consensus uses many Snowball instances to create a dynamic DAG of all known transactions – each Snowball instance is a graph vertex. In a linear blockchain, a vertex is analogous to a block. It holds the hashes of its parents as well as a list of transactions. Avalanche consensus relies on Snowball and the concept of confidence counts but applies it to DAG nodes. Instead of the previously stated red and blue choices, nodes in the Avalanche consensus establish an agreement on whether a transaction is valid or whether it clashes with another transaction. Each transaction is linked to a parent transaction, which in turn is linked to a genesis vertex. A transaction may contain child transactions that relate to it as well as all of its parents. A genesis vertex is required because one transaction must serve as the foundation for the others (IOTA also includes a genesis vertex); this is crucial since all append-only transactions must contribute to something. Handling conflicting transactions or duplicate spends is one unresolved issue generated by directly applying Snowball to a DAG of nodes. The notion of "chits" is introduced in Avalanche, which expands on Snowball. When a confidence level is attained, a chit counter is added to the transaction, with a value of "1." If it was not assigned a value, the chit counter is set to "0." As an extra confidence mechanism, the node will count the total of chit values, similar to Snowball. Nodes then utilize the number of chits to assess their trust in not just the individual transaction but also in all of its progeny.

Avalanche is capable of converting the Slush, Snowflake, and Snowball building pieces into linear chains. This is done by Avalanche for their Snowman consensus, which is distinct from Avalanche consensus. Snowman consensus is account-based, unlike Avalanche's UTXO mechanism. The Snowman consensus is employed by the Avalanche networks' Platform chain (P-chain) and Contract chain (C-chain). The procedure is the same as stated above, except that each vertex has just one parent rather than several. This results in total vertices ordering. As a result, the overall structure is a blockchain rather than a DAG. This is helpful for applications where it is necessary to know whether one transaction preceded another, and it also conveniently enables smart contracts.

The Avalanche consensus protocol is excellent for monetary transactions and may be used with a variety of other protocols. The Avalanche DAG structure increased transaction speed, while the absence of smart contracts did not hinder Bitcoin Cash since it does not need such applications. Avalanche demonstrates how a DAG-based ledger may scale effectively in the context of a payment, ignoring smart contract requirements.

IOTA - a transaction-based DAG that employs Proof of Work.

Tangle, IOTA's causally ordered architecture, is a system of parallel-processed transactions. The Tangle is the data structure that underpins IOTA and generates the DAG. IOTA's tangle stores transactions, with each transaction symbolized by a graph vertex. When a new transaction enters the Tangle, it picks two prior transactions to approve, resulting in the addition of two new links to the graph.

Transaction G in the figure below authorizes transactions E and F. Transactions to include data like "Alice handed Bob 10 IOTA currencies." Unapproved transactions are referred to as "tips." Transaction G is a suggestion since it has not yet been accepted. The purpose of each incoming transaction is to link to two tips for approval. There are other ways to select which two recommendations to approve, but the easiest is to choose two at random. This technique is very scalable for new transactions picking tips to approve.

Source: IOTA

The red transactions, I and G, are unauthorized tips since they are not linked to any other transactions. Every other transaction is accepted because it is linked to another transaction.

However, another essential feature that supports IOTA's DAG design is the use of weights. How can we tell whether a transaction may be trusted? It is normal to observe how many confirmations a blockchain has in a regular blockchain. IOTA uses a similar mechanism to determine the weight of a transaction.

The weight of a transaction represents the amount of activity done by a node to construct this transaction. Each transaction has a starting weight, which might be 1, 3, 9, or other values (n3). A higher weighted transaction indicates that the node worked more on the transaction. Each transaction also has a cumulative weight, which is a sum of its own weight plus the weights of any transactions that approve it directly or indirectly. Let's have a look at how this process works.

Each transaction has its own weight, as well as a cumulative weight that grows with each tip added to the tangle.

Source: IOTA

Transaction D is directly authorized by transactions E and H, and it is indirectly approved by transactions G and I, as shown in the diagram above. D's total weight is 3 + 1 + 3 + 1 + 1, which is the sum of its own weight and the weights of E, H, G, and I.

A transaction with a higher cumulative weight is more significant than one with a lower cumulative weight. Each new transaction added to the tangle raises the cumulative weight of the predecessors by the weight of its own transaction. Older transactions gain significance with time. The use of cumulative weights prevents spamming and other attack vectors since it is presumed that no entity can create a large enough number of transactions in a short period of time.

Despite being very scalable, akin to Avalanche's X-Chain, this strategy makes integrating smart contracts almost unfeasible. IOTA is launching a distinct smart contract layer called "Assembly" in order to compete with other smart contract chains. Assembly is a completely organized layer 2 with the goal of supporting both EVM and WASM smart contracts.

Sui - a Proof of Stake DAG.

While Sui is included in the article's causally ordered part, it really utilizes both total and causal ordering. Sui's transaction processing architecture is divided into two parts: one for dependent transactions that are completely ordered and processed sequentially and one for independent transactions that are causally ordered and executed concurrently. Dependent transactions use Sui's Narwhal and Bullshark protocols. Narwhal is a DAG-based mempool, and Bullshark is a consensus mechanism that works with Narwhal to achieve consensus. Dependent transactions only need to be completely ordered alongside the transactions on which they rely. When transactions are completely independent, Sui uses a different mechanism. Sui does not employ Narwhal or Bullshark for these transactions. Instead, it employs a technique known as Byzantine Consistent Broadcast (BCB). Because there is no requirement for global agreement with this mechanism, transactions are processed and published to the ledger very instantly.

Sui's ledger is concentrated on "objects," as opposed to addresses, which are the focus of other distributed ledgers. It's critical to realize that objects may be NFTs, dapps, tokens, or anything else that can be built as a smart contract on a standard blockchain. Every object has an "owner" attribute that specifies who may interact with it. There are four unique categories of ownership for an item. The first kind is an item held by an address, which allows a user to have anything on Sui, such as coins in their wallet. The second form of ownership is when one thing owns another, such as a token object stored inside a multi-sig smart contract object. The third sort of ownership is that an object is immutable, implying that it has no owner. An immutable object cannot be changed, yet it may be interacted with. A shared item is the fourth and final kind of ownership. A shared item, such as an AMM, may be read or written to by anybody.

All transactions are executed in parallel on the same network, regardless of how they are arranged.

Source: Sui

Transactions accept items as inputs and read, write, or manipulate these inputted objects to generate newly created/updated objects as outputs. Each object is aware of the hash of the most recent object that created it as an output.

Objects may be classified as either totally-ordered or causally-ordered in Sui's consensus architecture. Because every user's transaction may affect the object with which they are dealing, total ordering must be included in transactions with shared objects. If an item is owned by an address, only that address may change it in a transaction. As a result, transactions posted to this object have no link to other transactions, allowing it to employ Byzantine Consistent Broadcast. While the combination of Narwhal and Bullshark results in a quick consensus architecture, BCB is almost instant.

Sui's ledger is an "object store" or "object pool" that stores data in a DAG. Sending USDC, for example, is the act of altering an object's "owner" property, which has no impact on the other objects.

Sui's ledger is an "object store" or "object pool" that stores data in a DAG. The nodes in this DAG are objects, and each arrow in the diagram indicates a transaction that alters the characteristics of a specific item or object. The Genesis transaction, which accepts no inputs and generates the objects that exist in the system's initial state, is not shown in this diagram.

While previous DAG-structured distributed ledgers have failed to provide an integrated smart contract answer, Sui seems to have overcome these challenges with a novel method. Sui's smart contract language, Move, allows object type and parallel execution of Sui's transaction by default. Sui's smart contract architecture may not have been conceivable without Move.

Conclusion

In terms of speed and throughput, causal ordering of transactions seems to provide a number of benefits over total ordering. However, the absence of ordering causes problems when attempting to design applications that demand tight time-based ordering, and many projects have been unable to get smart contracts to perform effectively on their DAG architecture. Fantom's totally ordered, blockchain-like structure supports EVM and smart contracts. Despite having a completely ordered output, Fantom's engineers were able to optimize its layer 1 utilizing a DAG-based consensus process. Avalanche selected a different approach and developed Snowman, a separate consensus mechanism, to support the EVM and offer simple, smart contract capabilities. IOTA, on the other hand, selected a different path and is developing a framework for simply deploying blockchain instances on top of IOTA to support the EVM, thereby building a fully-ordered layer 2 infrastructure. Sui's one-of-a-kind architecture is promising, as transactions may be totally ordered or causally ordered as required, enabling smart contract capabilities on the network while also lowering latency.

Sui is the most recent DAG-based layer 1, yet it seems to distinguish itself enough and iterate on problems previously identified in the field to the degree where DAGs as a structure may actually acquire popularity as a distributed ledger. Even though temporally organizing transactions is not the future, DAG-based technology aids in the scaling of current blockchains. While DAGs may not be the best scaling mechanism for every case, they seem to perform well for Avalanche's X-Chain and IOTA in terms of speed and capacity. However, the absence of smart contract compatibility reduces its significance in today's competitive scene, particularly in the era of layer 2 roll-ups and off-chain Zero Knowledge scaling options. While most DAG-based ledgers improve latency with no loss of decentralization, blockchains, and DAGs as distributed ledgers are built in such a way that every node on the network must execute every transaction. This is one of the most difficult issues that any distributed ledger must address in order to be completely scalable. Sui was able to overcome this using its unique BCB architecture, which allows transactions to bypass consensus. This is not a need for every DAG-based design and should not be used to argue that all DAG-based architectures are superior to all blockchain-based systems. However, at the end of the day, a DAG is merely a data structure, and we are seeing applications for it throughout distributed ledger technologies. Sui's Mysten Labs is collaborating with Celo, a layer 1 blockchain, to include the Narwhal design onto its mempool. Narwhal is a mempool protocol that is built as a DAG. Celo is a blockchain-based ledger in every way, however, it has improved speed by including a DAG in its backend. More current scaling techniques may make the debate between DAG and blockchain ledgers less important. The goal of this study is to enlighten readers on existing architectures. With applications like Narwhal, we may see the greatest use of DAGs in the future. It is tough to anticipate how commonly utilized DAGs will become in distributed ledgers, although their importance as technology seems to be expanding.

Disclaimer:
This article is intended for and only to be used for reference purposes only. No such information provided constitutes advice or a recommendation that any investment or trading strategy is suitable for any specific name.

The DAG-based blockchain landscape