DACS Node Architecture and Sustainable Generation Manager
Last updated
Last updated
This chapter introduces the proposal of DACS and Sustainable Generation Manager (SGM) to maintain storage availability on Xenea. Also presented is the system architecture and its implementation along with its parameters.
Inside the payload of Xenea, a hash value of the stored data is input. Therefore, the Layer 1 blockchain with the capability to store the hash value along with the NFT contents is required. The proposed system architecture allows for long-term and secure storage of large amounts of NFT content.
Decentralized Autonomous Contents Storage (DACS)
Decentralized Autonomous Contents Storage (DACS) is an architecture for integrating distributed file systems into blockchains. DACS enables sustainable content storage by linking IPFS and other hash-based file systems across multiple nodes on the network. Each DACS node can input a user's NFT content or its payload as transactions onto blocks of Xenea multiply. Users store their NFT content in these nodes without losing their NFT data.
Network design and conditions for DACS nodes
DACS nodes connect storage devices to Xenea and contribute to maintaining the Xenea network; DACS nodes are designed to add only the necessary storage space on Xenea and not increase the unnecessary on the Xenea network, thereby stabilizing the mining process. DACS nodes can acquire storage operating rights and accept additional XENE staking. The amount of staking is proportional to the amount of physical storage in the DACS node.
DACS node operating conditions:
The storage features of the DACS node will be operated under the responsibility of its owner, however, in Phase 1, until the Xenea network is stable and sufficiently decentralized, Xenea will operate the Decentralized Autonomous Contents Storage (DACS) mining pool in the form of cloud mining, as well as the maintenance of the physical storage space of the DACS nodes.
When the number of DACS nodes is sufficiently decentralized to enter Phase 2 or beyond, each DACS node can operate and manage its own physical storage by satisfying the DACS node's operational requirements.
To become a DACS node owner, one must have storage and a collateral XENE. XENE held in collateral will be deducted in the event of a failure of the DACS node's network, depending on the severity of the failure.
The XENE collateral will be returned to the DACS node at the end of the contract term, but may remain as collateral if the DACS node is to continue to operate.
The DACS node owner will receive a daily reward based on the ratio of their storage space to the gross storage space available per day multiplied by the degree of difficulty. The formula is as follows:
Figure 3 shows how the rewards are distributed.
Sustainable Generation Manager (SGM)
Sustainable Generation Manager (SGM) is a technology developed to ensure that data stored on Xenea lasts perpetually, preventing data loss over the lifetime of the storage device and other risks. SGM also eliminates the excessive decentralization of data, avoiding the increase in data volume caused by unnecessary encrypted and decentralized data.
DACS alone cannot guarantee the sustainability of each storage device to store data permanently for 100 or 200 years on its own. Therefore, it must be maintained at the system level.
SGM keeps and references the timestamp of each storage, then replicates the data or NFT with its contents to other DACS nodes. The default storage expiration date is every 180 days from the end of the day on which the data was stored. When the storage lifetime expires, the DACS node is replicated and restored to a new DACS node.
The 1st generation node then expires and all the data on it is deleted. After the deletion, the node may be reused as storage space for new content; SGM replicates the data of the 1st generation DACS node to the free space of the 2nd generation. Once the replication is complete, the 1st generation storage space is freed up as storage space for new content.
SGM Parameters
First, data is stored on the storage node, then the date of the last updated storage is stored on the mainnet; if more than 180 days have passed, SGM searches for a new storage node at the closest network distance (number of node hops), and selects the target storage node. The target node will store the data of the storage node that is over 180 days old with a P2P connection. The main parameters include:
Last modified date of the storage node
Timestamp measurement of each storage node's update date and time
Search for new storage node candidates by nearest pops
Data replication by copy command.
The table below shows the list of conditional parameters:
Figure 4 shows the data replication process flow chart of SGM: SGM agent continuously observes all storage nodes and selects the next candidate storage node for the new region of NFT data.
Old storage after 180 days (default value) moves its data to the new storage and will be used for new data. Storage that has lost capacity due to physical damage can also be utilized on a per-size basis.
Thus, eventually, these older storages can also be maintained as active nodes, with the storage node owners keeping their mining rewards for the storage space held by the DACS node.
Fast Track Contents Delivery Manager (FASTD)
FAST Track Contents Delivery Manager is a system that can preferentially cache content on DACS nodes, allowing content to be managed in a designated cache area and accessible with low latency.
For example, some financial NFT content requires low-latency time access; using FASTD, content organizers can select these content as FAST Tracks. In addition, the use of Data Transmission System (DTS) can greatly expand CPU cache storage space.
Function
Parameters
Date of the last update of the storage node.
Year
Month
Date
Measure of each storage node date with timestamp.
Year
Month
Date
Search the new candidate of the new storage node by nearest pops.
1 hop
2 hops
3 hops
Duplication date parameters are set from 1 day to 365 days.
1 day
1 week
1 month
3 months
6 months
12 months
Storage Size
Minimum 200TB
XENE Collateral
Minimum 100,000 XENE, additional 50,000 XENE for every 100T thereafter