# DAG Chain Layer

## Introduction

Decracy data is stored and ordered using directed acyclic graph (DAG) rather than blockchain. This allows all users to secure each other's transactions by referencing earlier transactions created by other users, and also removes scalability limits common for blockchains, such as blocksize issue.

Most **blockchain** is a public ledger of all transactions that have ever been eveluated. It is constantly growing as _completed_ blocks are added to it with a new set of recordings. The blocks are added to the blockchain in a
linear, chronological order. To use conventional banking as an analogy, the blockchain is like a full history of banking transactions. Transactions are entered chronologically in a blockchain just the way bank transactions are. Blocks, meanwhile, are like individual bank statements.

The ever-growing size of the blockchain is a problem for storage and synchronization. Bitcoin network can process 7 transactions per second and the most capable blockchains could theoretically process a few thousand transactions per second.

### Blokchain vs DAG chain

Blockchain technology has provided a way to maintain consensus across all nodes with no central authority. However the technology faces fundamental issues like a lack of real-time transaction settlement and scalability. Despite improved consensus algorithms, Some blockchain implementations such Bitcoin or Ethereum synchronize one block at a time. This results in slow confirmation times, one of the biggest factors stopping blockchain technology from being widely used across many industries. Although Smart Contract platforms such as Cardano and EOS have started to emerge, public Distributed Ledgers are still not widely used.

To address these persistent issues, a new model based on the Directed Acyclic Graph (DAG) was next step of Blockchains evalutions. Decracy DAG chain is a new DAG based platform that intends to solve the scalability issues of existing public distributed ledger technologies. The platform intends to distinguish itself from the traditional block ledger-based storage infrastructure by attempting to employ an improved version of existing DAG-based protocols. The Decracy platform adopts a new protocol based on “Avalanche Consensus” to maintain consensus. This protocol is intended to be integrated into the DAG Chain. The aim is to allow applications built on top of the DAG Chain to enjoy instant transactions and near zero transaction costs for all users.

#### Blockchain Issues of scalability

In existing blockchains, all nodes verify and store a single block at a time, leading to longer time in creating blocks and limitations in block size. Therefore, no matter how many nodes are connected, the performance will be limited by the speed of each node. The more transactions require processing, the worse the performance due to bottlenecks on the network itself.

## DAG chain

### Preview

In addition to the information of the transaction, a DAG chain unit includes the signatures of one or more users who created the unit and references to one or more previous units (parents) identified by their hashes.

Units are linked to each other such way that each unit includes one or more hashes of earlier units, which serves both to confirm earlier units. The set of links among units forms a DAG (directed acyclic graph). There is no single central entity that manages or coordinates admission of new units into the database, everyone is allowed to add a new unit provided that he signs it and pays a fee. The fee is collected by other users who later confirm the newly added unit by including its hash within their own units. As new units are added, each earlier unit receives more and more confirmations by later units that include its hash, directly or indirectly.

### DAG chain basics

As a means to solve the problems of existing blockchain solutions, Decracy provide a new implementation of DAG-based consensus, which intends to create a new platform that improves the scalability and versatility
of existing DAGs. DAG chain technology is intended to create potentially infinite scalability, and process hundreds of thousands of transactions per second even with large numbers of nodes participating in the network. The DAG Chain is intended to solve the scalability limitations of existing blockchain with the Avalanche consensus. This is intended to be achieved by adopting a method where a single event block verifies the previous transaction, and transactions are verified and processed asynchronously without being approved by the miners as in prior blockchains. Thus, increased transactional load will not lead to delayed approval or bottleneck effects. It intends to also manage historical information on its own without being assisted by external databases such as the MySQL Database. Event blocks that store information from transactions that arise include multiple data packages. A data package may include transactions, Smart Contracts file hashs, historical information, reputation management, File storage related data and rewards.

The DAG Chain intends to make the processing infrastructure in our society more transparent and reliable. With fast and safe processing methods based on DAG and independent management of historical information through “Story Data”.

#### DAG Event Block basics

DAG based on the Event Blocks. A set of links between event blocks form a DAG, which is a distributed system that stores arbitrary data that cannot be changed. Event blocks contain information such as transactions, smart contracts hashe, File Hash (so it possible store maintain dictributes file storage), and the values of previous events. An event is connected to the previous event blocks with central authority manipulating the structure. Event blocks from the previous rounds achieve more verifications as future events blocks are added. So it will be fully asynchronous and when two identical transactions are requested (i.e. the double-spending issue), only the earliest transaction is validated.

### Components

In coomon graph consists of Events, the Main Chain.

#### Event Blocks

The Event Block data structure includes the following:
• Stored Data: An Event Block can contain multiple data packages. There are several types of data package, depending on functions such as transaction, SmartContract, File data, Assets data, reputation management, compensation etc.
• Signature: The signature of the user who created the Event Block is included and the user is identified through an account or address. It can based ot multisig approach.
• One or more hash values of the previous event block: This is included to provide links between Event Blocks.

Like other Blockchain technologies, where the new event block verifies all previous event blocks (including the transactions inside them), all new Event Blocks will verify only their parent event blocks. A new event block will be connected to its parent event block through hash and all hashes will be derived from parent event blocks, so that it is impossible to modify or delete the previous event blocks. When an event block is connected, another node will build a new event block on top of that event block.

#### Main Chain

The Main Chain consists of full topologic or related Event Blocks. The Main Chain intends to be used for the validation of event blocks and to maintain the entire network structure.

### DAG flow

DAG Chain intends to achieve high performance and secure data storage. All event blocks can be created asynchronously from nodes and each of these event blocks consists of a set of transactions (payment, assets, files, SmartContract, reputation, rewards etc.). The new event block is connected to the parent event block, which is the most recent previous event block, and the node is intended to generate the block at a high speed through the Avalanche family approach.

#### Most common data structure

When a user wants to add data to the database, he creates a new storage unit and broadcasts it to his peers. The storage unit includes (among other things):

• The data to be stored. A unit may include more than
one data package called a message. There are many different types of messages, each with its own structure. One of the message types is transfer, which is used to send bytes or other assets to peers. Message also represent Transactions Layer data store.
• Signature(s) of one or more users who created the unit. Users are identified by their addresses. Individual users may (and are encouraged to) have multiple addresses. In the simplest case, the address is derived from a public key.
• References to one or more previous units (parents) identified by their hashes.

# FOR DISCUSSION

References to parents is what establishes the order of units and generalizes the blockchain structure. Since we are not confined to one-parent–one-child relationships between consecutive blocks, we do not have to strive for near-synchrony and can safely tolerate large latencies and high throughputs: we’ll just have more parents per unit and more children per unit. If we go forward in history along parent-child links, we’ll observe many forks when the same unit is referenced by multiple later units, and many merges when the same unit references multiple earlier units (developers are already used to seeing this in git). This structure is known in graph theory as directed acyclic graph (DAG). Units are vertices, and parent-child links are the edges of the graph.

Like in blockchains where each new block confirms all previous blocks (and transactions therein), every new child unit in the DAG confirms its parents, all parents of parents, parents of parents of parents, etc. If one tries to edit a unit, he will also have to change its hash. Inevitably, this would break all child units who reference this unit by its hash as both signatures and hashes of children depend on parent hashes. Therefore, it is impossible to revise a unit without cooperating with all its children or stealing their private keys. The children, in turn, cannot revise their units without cooperating with their children (grandchildren of the original unit), and so on. Once a unit is broadcast into the network, and other users start building their units on top of it (referencing it as parent), the number of secondary revisions required to edit this unit hence grows like a snowball.