Block Data & Operations
On-chain data stores the network wide state, it must meet two fundamental requirements:
- Blockchain data properties: public verifiability, audit-ability, and incentive-compatibility.
- Domain business logics:
- the balance is the core data for DNetcoin token
- the CryptoID (PubKey) and the Virtual IP address are the core data for ĐNet.
Blockchain Data Requirements
Verifiable: A ĐNet scheme is publicly verifiable since all dnet operations are signed by the creator and no duplications of virtual IP address. In contrast, the operational status of the OVF could not be publicly verifiable, thus not on-chain.
Auditable: A ĐNet scheme is auditable, since it generates a verifiable trace of operations that can be checked in the future to confirm dnet operations was indeed conduct by the dnet creator. In contrast, the highly dynamic operational status of the OVF could not be saved into the network, thus not on-chain.
Incentive Compatible: A ĐNet scheme is incentive-compatible, since miners are rewarded for successfully maintaining the integrity of the ĐNetDB, e.g. preventing duplication of virtual IP address, which is the fundamental requirement for networking and security, similar to prevent double-spending for the Bitcoin.
These properties dictate that the fast-changing dynamic operational data could not be reliably stored on-chain.
Domain Logic Requirements
The Đ.NETWORK protocol has two types of block data stored in the chain. These data are created by consensus engine and immutable once created. The P2P Network maintains a consensus state when the data are logically Created, Read, Updated, Deleted (CRUD).
- Token Transaction Ledger：similar to Bitcoin ledger book, Đ.NETWORK Transaction Ledger stores the Đ.NETWORK transactions including token exchange among D.Network Wallets. Double-spending is prevented with the Practical Byzantine algorithm.
- Overlay Network DB CRUD Operations Log：The network ID, list of end nodes within the private network, OVFs, and access rules are stored into the network database (ĐNetDB). The individual private network is locked with private key by its creator and its entries can only be unlocked for CRUD by appending database operating scripts with signature. Each database operation script is similar to the Transaction in Bitcoin. A difference from the double-spending prevention of the Token Transaction is the prevention of duplicated Virtual IP assignment, which is a fundamental connectivity and security requirement in networking.
The on-chain data meets the three fundamental requirements: security, scalability, and decentralization, which is the trilemma for decentrlized system solved by blockchain technology.
On-Chain Data
Be more specific, the following data meets the decentralization property requirements and store on chain:
- Token: rewards for securing the whole network, the transaction book
- DNet DB
- DNet_ID: unique ID for each DNet
- A list of (Virtual IP, PubKey): for find each other and traffic encryption
- OVC_ID: directive or pointer to the cloud backend for each dnet
Learn more about On-chain data structure
Not On-Chain Data
As important as the on-chain data, the following data are NOT on chain:
- Traffic: the network bandwidth consumption, it could be a desired on-chain variable, especially for quantitatively incentivize the OVC bandwidth contribution. However this oracle variable is highly dynamic and could not be economically and publicly verified and audited.
Block Generation
The mining process is used to secure the block generation, similar to Bitcoin. However, the mining algorithm is based on RandomX, instead of Bitcon's hash.
A DNetDB CRUD Ops Transaction is a Pseudo Token Transaction with a fixed 0.0001 Amount and self PubKey in the Output. However, since the virtual IP addresses are foreign oracles entered into the blockchain, additional block validation algorithms are needed for preventing the Virtual IP address duplication and depletion. A Pseudo Token Transaction allows using the mature blockchain technology, like the consensus algorithms, to prevent unauthorized operations on DNetDB's records.
Token Consumption
The token sent to self address for the DNetDB operations are not consumed and remains to be Unspent Transaction Output (UTXO). However, the token must be reserved to keep the record valid and useable. Once the DNetDB operation UTXO spent, the record is regarded as deleted.
Data Management API
Like managing the wallt, a set of friendly CLI and RPC are avaliable to manage the dnet records. For example, the following command create a dnet:
dnetcoin-cli dnet_create 'hello_dnet0'