DCore Technical Description

In this section we will explain what DCore is, what it consists of, what its fundamental idea is and how it is designed.

DCore Fundamentals

  • Is a stand-alone Type I Decentralized Application (Dapp).
  • Core network components are written in pure C++ using state-of-the-art libraries with open-source licensing.
  • These components further create an entire plug and play system that allows asynchronous interaction via well-known web services:
    • JSON/RPC over Websocket, or
    • fallback interface JSON/RPC over HTTP.
    • API documentation
  • Offers easy interaction via bundled applications or an integration via third-party applications.
  • Is essentially the blockchain layer, responsible for the generation, storage and synchronization of blocks.
  • Its layer consists of DCore Daemon and the Inter Planetary File System (IPFS) integration.
  • Its power lies in the connection between these two protocols, essentially allowing developers to quickly setup a blockchain-based network for data transactions.
  • Uses a Delegated Proof of Stake (DPoS) mechanism, in order to achieve the consensus of various nodes in the network.
  • Deterministic selection of block producers allows DCore to decrease the block production time to 5 seconds.

Image DCore

Miner - To help and be a part of DCore you will be responsible for creating new blocks, validating coming transactions, and being a part of the mining community. To become a miner you need to set up your daemon with specific values of settings parameters.

Seeder - By providing storage to seed a content you can spread the DCore Network. You will need to set up your daemon with spefic values of some settings parameters to become a seeder.

General node - Any node of DCore Network which does not have setting parameters set with specific values (like miner or seeder), mainly used for backup.

Message node - Every node, which will not set other plugins (for example miner plugin).

DCore Daemon

  • Stores network information, such as DCT tokens and encrypted content keys.
  • Provides a secure way to buy and sell content.

IPFS Layer

  • Is responsible for the distribution of content uploads/downloads between seeders and users.
  • We’ve extended the IPFS system and added a mechanism that rewards seeders (the nodes storing content and enabling it to be transferred between creators and users) directly through our DCore functionality.

Application Interface

  • Is the Ecosystem.
  • Includes any of the interfaces which can be built on top of DCore.
  • Allows video streaming, audio streaming, digital content distribution, crowdfunding, advertising, reputation management, miner voting, data management.

Image Ecosystem

DCore Characteristics

  • An all-around, stable, ready-to-use design.
  • Lets the client connect to a server that will handle requests.
  • This proposed design is comprised of cloud of servers that do not require a full mesh of network and do not need low-latency redundant high bandwidth fabric.
  • Is pure open-source, so that it could be auditioned, reviewed and forked.
  • Stability, fairness, spam-freedom and profitability are delivered through tokens that are only present within the network. The token system balances usage and enables processes presented in DCore.
  • Independency and borderless network is provided by the voting community all around the world.
  • Backed by heavy cryptography, in order to deliver a high level of security and anonymity.
  • An anonymity is guaranteed via hashed accounts and nicknames.
  • The majority of communication is done between the participating nodes (except access nodes) of the transaction.
  • These transactions are generated by user interactions with the network and its nodes maintain blockchain database copies.
  • Blockchains grows over time, these nodes handle growth by chaining new blocks on top of the previous ones. Some of these nodes also fulfill a different role, that of a validator.
  • Blockchain technology is immutable by nature so it is a read-multiple, commit-once procedure. Once, there is a commit, someone has to validate the truthfulness of that commit.
  • Validators are independent and community-driven but they must reach a consensus when a new block is committed. The proposed consensus algorithm is written below.
  • The key design feature is a core overlay network built on top of the application server nodes.
  • Such an overlay network is formed by nodes that are hosted by volunteers and it is peer-to-peer by design.
  • An access to this independent network is then provided through access nodes that broker session initialisation, direct and indirect peering, routing, relaying and proxying.
    • Because of insufficient number of IP addresses (v4) in the Internet network, access nodes are only capable of directly connecting peers with dynamic IPs and dynamic DNS, that are also behind NATs. Access node is required to establish a direct connection with the initiator. Other services (e.g. IRC) could be used when a self-hosted static address, reverse DNS record, dynamic DNS or opened destination port in NAT is recommended.
    • The access node works as a communication relay in the event that peers cannot establish a connection directly.
    • As the design is not full-mesh, access nodes are part of the routed network that rebroadcasts traffic.
  • This overlay network implements proposals from RFC5128.

Consensus Algorithm

  • Is Delegated Proof of Stake.
  • To achieve the consensus of various nodes in the network.
  • Decentralized, the fastest, most efficient, and most flexible consensus model available.
  • Leverages the power of stakeholder approval voting to resolve consensus issues in a fair and democratic way.
  • Deterministic selection of block producers allows DCore to decrease the block production time to 5 seconds.
  • Perspective miners present themselves for voting on a forum.
  • The election of miners happens on a daily (24hr) basis.
  • The main delegation of miners is covered by community of voters.
  • In case a miner is untrustworthy, he can be easily demoted.
  • Changing miners too often may undermine trust.
  • DPoS is greener than PoW (Proof of Work) and requires less energy.
  • You have to essentially lock up your tokens to mine or process transactions, in order to confirm your commitment and goodwill.

Differences by Examples

  • PoW requires miners or physical computers to be turned on and processing the transaction.
  • This can be inefficient since better computers are created and optimised for mining which may lead to centralisation, as in the case of bitcoin. Bitcoin may be viewed as being centralised in China due to the fact that a small group of people holding a larger (greater than 51%) share of the mining power.
  • PoW concept proposes high degree of randomness by computation in comparison to DPoS.
  • In contrast, DPoS is backed by democratic voting of the community.
  • Numeric computations, if well designed, are bulletproof in trust.
  • In comparison, democratic voting has accompanied us for many centuries and it is the cognitive behaviour of every one of us to choose between good and bad.
  • DPoS is greener and requires no energy.

DPoS Explained

Let us assume:

  • the_truth = Agreed data structure (Block) containing valid future state of the transactions.
  • rand = 8 byte random number.

I'll bet you that the_truth will be the agreed future block.

DCore Latency

Within 5 second block times, a DPoS miner needs to operate a node with minimal network latency so it can get the new head-block as quickly as possible and then submit its result to the network with enough time to propagate to the next block producer. The introduction of a mining pool would add additional latency that would dramatically reduce the percentage of time available to actually do work.

Competing Chains

Because the vast majority of miners are elected, highly accountable, and granted dedicated time slots to produce blocks, there is rarely any situation where two competing chains can exist. From time to time, network latency will prevent one miner from receiving the prior block in time. If this happens, the next miner will resolve the issue by building on whichever block they received first. After 14 confirmations (about 30 seconds) the transaction has been confirmed by 2/3 of the active miners which means there is no possibility of reversal without manual intervention.

Block Verification

While the system is robust against natural chain reorganization events, there is still some potential for software bugs, network interruptions, or incompetent or malicious miners to create multiple competing histories that are longer by a block or two. The software always selects the blockchain with the highest miner participation rate.

Impossible Attacks

The hard requirement of minimal network latency is also a safety against poisoning attack (when an attacker impersonates the healthy node because of lower latency, which can lead to malicious behavior).

Uniqueness of Block Selection

A miner operating on his own can only produce one block per round and will always have a lower participation rate than the majority. There is nothing that any miner (or minority group of miners) can do to produce a blockchain with a higher participation rate. The participation rate is calculated by comparing the expected number of blocks produced in a given period of time to the actual number of blocks produced.