Last week I began writing a series that explains in simpler language of a layman what DxchainNetwork is up to. First series is available here .
It is important for anyone reading to stay up-to-date by not missing out on any of the series. In continuation, I will focus briefly on the architectural design of Dxchain Network. To remind us of what Dxchain is:<cente/r>
Dxchain as the world's first decentralized big data and machine learning network powered by computing-centric blockchain, has all modules from planning stage to implementation contained in her whitepaper here
The idea -DxchainNetwork was coined from the perspective of enabling miners (connected computers) monetize the idle storage space (s) on their computer through the initiated principle of incentivisation with the sole aim of facilitating decentralized big data computations at a considerably lower costs with conveniences. The underlying architecture is employed from IPFS, Hadoop HDFS, FileCoin, IOTA, IoTeX, Plasma, and others as contained in the whitepaper here.
As Dxchain's target is to provide decentralized big data and machine learning computation, there is need for availability of decentralized data storage to make this spring to reality. This compels Dxchain to designing a specific chains-on-chain structure which oversees the master chain, computation chain and storage chain to achieve consensus and to provide the incentive mechanism in a Byzantine environment.
Note at Byzantine:
The storage data model serves as the bed on which the storage chain is built and uses an algorithm called proof of space time (PoST) to confirm the existence of files on a storage provider. This tends to serve as proof against any dishonest act that may be initiated from the part of the storage provider. The network uses Hadoop as its computational engine wherefore its running elements communicate with one another using a computational chain to synchronize running jobs. Such elements includes task tracker, worker and job tracker.
On DxchainNetwork, there are three chain structural designs containing two unique properties. The three chain structures are thus:
The master chain is responsible for recording small transactions that occur on the network because of its immutability function similar to that of Bitcoin and Ethereum. It keeps the ledger and asset information such as state, transaction and receipt, as well as the smart contracts. In order to support the complex data structure and computing information, there is need for two side chains which are: Data Side Chain (DSC) - built upon a peer to peer distributed file storage system and stores the non-assets information. And Computing Side Chain (CSC) - designed for useful work to solve real business problems and supports the specific computing task on the DxChain Virtual Machine (DVM).
The master chain uses an Ethereum-compatible data structure which comprised of hash-linked blocks. Only valid transactions are recorded in the master chain to facilitates transfer of assets between the master chain and side chains. The side chains use the same token from the master
chain or each can define its own secondary token with the network-defined rate> This indicates that the side chains can be independence of master chain token.
The is built on a peer-to-peer storage network, such as the Inter Planetary File System ( IPFS) or
Swarm. It is does not sever the use for data storage but as an incentive layer. It also serves as the foundation layer for the decentralized storage network. It uses Proof of Spacetime (PoSt) as the consensus method for the micro transactions. It is effective in faster setting times, lower transaction fees, faster transaction speed, higher privacy
and the ability for transparency. The Team designs a virtual logical layer called Dxchain Storage layer which comprises the storage task giver, the miners for importing and exporting files and the verifier.
Just like the DSC, the Computing Side Chain (CSC) is hash-linked and contains the header, transaction sets, contracts of the DxChain Network and data allocation.
When a client sends a computation request, the request propagates through the network, each miner uses the computational side chain to obtain tasks. When a task finishes, the working miner sends the confirmation to the computing side chain to update the task status and obtain incentives.
This reflects the overview of how overall interactions and transactions among individual objects and across the whole network. That is, the transaction flow among the Master Chain, Data Side Chain and Computational Side Chain.
Upon a request, the task giver ("U") submits a task in the master chain where the miner in the MC chain checks for the some parameters such as: the block in valid format, including states, transactions, receivers, and contracts; if the orders are valid; if the pieces of proof are valid; etc
Then, the solver and verifier in the Computing Side Chain load the code and data into the DxChain
Virtual Machine (DVM) for execution inclusive of the parallel computation and verification tasks. Again, the miner in the Computing Side Chain checks: the block format, if the credit and deposit are valid, if the task related-data and code are valid and others. The miner then summarizes the translations and load them back to the master chain.
The miner in the Data Side Chain provides the fundamental data storage and data transfer across the peer to peer network. Miner in the Data Side Chain checks: the block format, conduct maintenance on the health of the data as well as ensure its availability, integrity and security; if the credit and deposit are valid; and transfer them to the Computing Side Chain if the asset in the master chain is locked.
The Master Chain the receives all transactions and assets after all of these processes are completed. This explains how balance is maintained in the communication process.
Reference:
