DGT DOCS
  • 1. INTRODUCTION
    • 1.1 Executive Summary
    • 1.2 Why DGT
    • 1.3 Distributed Ledgers Technology
      • 1.3.1 Decentralization approach
      • 1.3.2 Consensus Mechanism
      • 1.3.3 Transactions
      • 1.3.4 Layered Blockchain Architecture
      • 1.3.5 Tokenomics
      • 1.3.6 Web 3 Paradigm
      • 1.3.7 Common Myths about Blockchain
    • 1.4 The DGT Overview
      • 1.4.1 Platform Approach
      • 1.4.2 DGT Functional Architecture
      • 1.4.3 Technology Roadmap
    • 1.5 How to create a Solution with DGT Networks
    • 1.6 Acknowledgments
  • 2. REAL WORLD APPLICATIONS
    • 2.1 Case-Based Approach
      • 2.1.1 DGT Mission
      • 2.1.2 The Methodology
      • 2.1.3 Case Selection
    • 2.2 Supply Chain and Vertical Integration
      • 2.2.1 Logistics Solution for Spare Parts Delivery
      • 2.2.2 DGT Based Solution for Coffee Chain Products
    • 2.3 Innovative Financial Services
      • 2.3.1 Crowdfunding Platform
      • 2.3.2 Real World Assets Tokenization
      • 2.3.3 Virtual Neobank over DGT Network
      • 2.3.4 DGT based NFT Marketplace
    • 2.4 Decentralized Green Energy Market
      • 2.4.1 Peer To Peer Energy Trading
      • 2.4.2 DGT based Carbon Offset Trading
    • 2.5 B2B2C Ecosystems and Horizontal Integration
      • 2.5.1 KYC and User Scoring
      • 2.5.2 Decentralized Marketing Attribution
      • 2.5.3 Case Decentralized Publishing Platform
      • 2.5.4 Value Ecosystem
    • 2.6 More Cases
  • 3. DGT ARCHITECTURE
    • 3.1 Scalable Architecture Design
      • 3.1.1 High Level Architecture
      • 3.1.2 DGT Approach
      • 3.1.3 Unique contribution
      • 3.1.4 Component Based Architecture
    • 3.2 Performance Metrics
    • 3.3 Network Architecture
      • 3.3.1 Nework Architecture in General
      • 3.3.2 Network Identification
      • 3.3.3 H-Net Architecture
      • 3.3.4 Transport Level
      • 3.3.5 Segments
      • 3.3.6 Static and Dynamic Topologies
      • 3.3.7 Cluster Formation
      • 3.3.8 Node Networking
      • 3.3.9 Permalinks Control Protocol
    • 3.4 Fault-Tolerant Architecture
      • 3.4.1 Introduction to Fault Tolerance
      • 3.4.2 F-BFT: The Hierarchical Consensus Mechanism
      • 3.4.3 Cluster Based Algorithms
      • 3.4.4 Arbitrator Security Scheme
      • 3.4.5 Heartbeat Protocol
      • 3.4.6 Oracles and Notaries
      • 3.4.7 DID & KYC
    • 3.5 Transactions and Performance
      • 3.5.1 Transaction Basics
      • 3.5.2 Transaction Processing
      • 3.5.3 Transaction and block signing
      • 3.5.4 Transaction Families
      • 3.5.5 Transaction Receipts
      • 3.5.6 Smart Transactions
      • 3.5.7 Private Transactions
      • 3.5.8 Multi signature
    • 3.6 Data-Centric Model
      • 3.6.1 Data layer overview
      • 3.6.2 Global State
      • 3.6.3 Genesis Record
      • 3.6.4 Sharding
      • 3.6.5 DAG Synchronization
    • 3.7 Cryptography and Security
      • 3.7.1 Security Architecture Approach
      • 3.7.2 Base Cryptography
      • 3.7.3 Permission Design
      • 3.7.4 Key Management
      • 3.7.5 Encryption and Decryption
      • 3.7.6 Secure Multi Party Computation
      • 3.7.7 Cryptographic Agility
      • DGTTECH_3.8.4 Gateway Nodes
    • 3.8 Interoperability
      • 3.8.1 Interoperability Approach
      • 3.8.2 Relay Chain Pattern
      • 3.8.3 Virtual Machine Compatibility
      • 3.8.4 Gateway Nodes
      • 3.8.5 Token Bridge
    • 3.9 DGT API and Consumer Apps
      • 3.9.1 Presentation Layer
      • 3.9.2 Application Architecture
    • 3.10 Technology Stack
    • REFERENCES
  • 4. TOKENIZATION AND PROCESSING
    • 4.1 Introduction to Tokenization
      • 4.1.1 DGT Universe
      • 4.1.2 Driving Digital Transformation with Tokens
      • 4.1.3 Real-World Tokenization
      • 4.1.4 Key Concepts and Definitions
    • 4.2 Foundations of Tokenization
      • 4.2.1 Definition and Evolution of Tokenization
      • 4.2.2 Tokenization in the Blockchain/DLT Space
      • 4.2.3 The Tokenization Process
      • 4.2.4 Tokenization on the DGT Platform
      • 4.2.5 Regulatory and Legal Aspects of Tokenization
      • 4.2.6 Typical Blockchain-Based Business Models
    • 4.3 The DEC Transaction Family
      • 4.3.1 DEC Transaction Family Overview
      • 4.3.2 DEC Token Features
      • 4.3.3 DEC Token Protocol
      • 4.3.4 DEC Account Design
      • 4.3.5 DEC Transaction Family Flow
      • 4.3.6 DEC Commands
      • 4.3.7 DEC Processing
      • 4.3.8 Payment Gateways
    • 4.4 Understanding Secondary Tokens
      • 4.4.1 The different types of tokens supported by DGT
      • 4.4.2 How secondary tokens are produced
  • 5. EXPLORING TOKENOMICS
    • 5.1 Introduction
      • 5.1.1 What does tokenomics mean?
      • 5.1.2 Goals of Building the Model for DGT Network
      • 5.1.3 Tokens vs Digital Money
      • 5.1.4 The Phenomenon of Cryptocurrency
      • 5.1.5 Basic Principles of Tokenomics
      • 5.1.6 AB2023 Model
    • 5.2 Node & User Growth
      • 5.2.1 Node Ecosystem
      • 5.2.2 User Growth and Retention Modeling
    • 5.3 Transactions
      • 5.3.1 Transaction Amount Components
      • 5.3.2 Shaping the Transaction Profile: A Three-pronged Approach
      • 5.3.3 Calculation of Transaction Number
    • 5.4 Network Performance Simulation
      • 5.4.1 Endogenous Model
      • 5.4.2 Network Entropy
      • 5.4.3 Network Utility
    • 5.5 Token Supply Model
      • 5.5.1 Introduction to Supply and Demand Dynamics
      • 5.5.2 Token distribution
      • 5.5.3 Supply Protocol
      • 5.5.4 Token Balance and Cumulative Supply
    • 5.6 Token Demand Model
      • 5.6.1 Node-Base Demand
      • 5.6.2 Transaction-Based Token Demand
      • 5.6.3 Staking Part Modeling
      • 5.6.4 Total Demand
    • 5.7 Token Price Simulation
      • 5.7.1 Nelson-Siegel-Svensson model
      • 5.7.2 The Price Model
    • 5.8 Decentralization Measurement
      • 5.8.1 Active Node Index
      • 5.8.2 Node Diversity in Hybrid Networks
      • 5.8.3 Token distribution
      • 5.8.4 Integral Calculation of Decentralization Metric
    • 5.9 Aggregated Metrics
      • 5.9.1 Transaction Throughput: Evaluating Network Performance and Scalability
      • 5.9.2 Market Capitalization: A Dimension of Valuation in Cryptocurrency
      • 5.9.3 Total Value Locked (TVL): A Spotlight on Network Engagement and Trust
  • 6. ADMINISTRATOR GUIDE
    • 6.1 Introduction
      • 6.1.1 Administrator Role
      • 6.1.2 Platform sourcing
      • 6.1.3 DGT Virtualization
      • 6.1.4 Using Pre-Built Virtual Machine Images
      • 6.1.5 Server Preparation
      • 6.1.6 OS Setup and initialization
    • 6.2 DGT CORE: Single Node Setup
      • 6.2.1 Launch the First DGT Node
      • 6.2.2 Dashboard setup
      • 6.2.3 Nodes Port Configuration
      • 6.2.4 Single Node Check
    • 6.3 DGT CORE: Setup Private/Public Network
      • 6.3.1 Network launch preparation
      • 6.3.2 A Virtual Cluster
      • 6.3.3 A Physical Network
      • 6.3.4 Attach node to Existing Network
    • 6.4 DGT Dashboard
    • 6.5 DGT CLI and base transaction families
    • 6.6 GARANASKA: Financial Processing
      • 6.6.1 Overview of DGT’s financial subsystem
      • 6.6.2 DEC emission
      • 6.6.3 Consortium account
      • 6.6.4 User accounts
      • 6.6.5 Payments
    • 6.7 Adjust DGT settings
      • 6.7.1 DGT Topology
      • 6.7.2 Manage local settings
    • 6.8 DGT Maintenance
      • 6.8.1 Stopping and Restarting the Platform
      • 6.8.2 Backing up Databases
      • 6.8.3 Network Performance
      • 6.8.4 Log & Monitoring
Powered by GitBook
On this page
  1. 3. DGT ARCHITECTURE
  2. 3.1 Scalable Architecture Design

3.1.4 Component Based Architecture

Previous3.1.3 Unique contributionNext3.2 Performance Metrics

Last updated 1 year ago

The basis of the platform is the node software built on top of shared modules, grouped into internal services. The node architecture contains the following features:

  • Network support is conducted with the high-performance asynchronous messaging library. This library allows for the organization of distributed and parallel computing.

  • The node-level consensus mechanism (Pluggable Consensus Algorithms) is implemented as a separate service and allows for the configuration of validation rules and voting mechanisms.

  • Transaction processing is taken out in a separate component called the transaction processor. The network can simultaneously process various types of transactions – the transaction families. Each family of transactions is processed differently, has different data formats, and has its own set of validation rules. Although the rules themselves are tied to the family of transactions (that is, to the transaction processor), the part of the node that implements the general verification procedures and interaction with other nodes is called the Validator.

  • Interaction with clients that allows them to receive information about the state of the network, and the status of transactions, as well as send (“throw in”) new transactions, is carried out through the REST API. This supports the micro-service architecture. Clients include:

– DASHBOARD (Explorer): a specialized web portal that provides information about the state of the node and the network.

– CLI (Command Line Interface): a console that encapsulates individual node management commands.

– Applications that implement the logic of working with the end node (for example, a wallet with tokens, a store of digital assets, an external system – a source of information)

  • Each service inside a node is implemented in a separate container (running ), which allows the node to be represented as a set of connected virtual machines, which collectively form a virtual supercomputer. This allows switching some services from .

  • The ledger shared among all nodes is stored in a separate database, which allows quick access to all records-transactions ( is used in the basic version, it is focused on storing key-value pairs in memory; DAG is implemented over the database). The ledger is the key element of the storage subsystem, while the main efforts of the network are spent on synchronization and collision resolution. The ledger stores not only the data of the transactions themselves but also general settings and topology data.

The figure above shows the main subsystems of the node. They are listed below in the same order:

VALIDATOR

Combining a group of subsystems around the process of obtaining, checking, and selecting data for insertion into the database (ledger)

#
SUBSYSTEM
DESCRIPTION

1

NETWORKING

2

ENCRYPTION

3

STATE

4

JOURNAL

A group of components that work on processing transactions and inserting them into the ledger.

5

CONSENSUS

  • Consensus.BlockPublisher – creates candidate blocks in three steps: initialization, validation, and finalization

  • Consensus.BlockVerifier – helps to check if a block candidate has been published following the agreed rules.

  • Consensus.ForkResolver – selects the side that can be a chain header

The F-BFT consensus has an extended interpretation as the achievement of consensus in the federation and its further distribution to the entire network. The consensus process checks the rules for the selected transaction family and then the vote is conducted.

6

ORACLE

An intelligent component for obtaining additional conditions regarding the transaction. For example, this can be used to detect fraudulent transactions or select the names of organizations with the help of a neural network.

SERVICES

Set of connected components

#
SUBSYSTEM
DESCRIPTION

7

TRANSACTION PROCESSORS

8

REST API

CLIENTS

#
SUBSYSTEM
DESCRIPTION

9

CLI

A command line interface that allows for the processing of information inside a node through a standardized API. It is the primary node administration tool.

10

DASHBOARD

A component is written for specifically DGT, which is a lightweight web portal for visualizing the main network parameters.

11

MOBILE APP

Implements the main business logic. Written by DGT as a digital content management tool (with connection to the Magento platform)

Since many of DGT’s components are run in the Docker environment, interaction occurs through those same network interfaces, which forms a specific inter-connect, as shown in the figure below.

The subsystem is represented by the legacy library and is responsible both for interactions with other nodes (port 8800) and for the interactions with other node components, such as the transaction processor (port 4004), consensus engine (TCP 5050), REST API (TCP 4004), etc.

The library for generating gash-functions and digital signatures. Sawtooth uses the ECDSA (elliptic curve) algorithm with secp256k1 parameters to generate private and public keys. The same library is used for forming the . The cryptography is selected when the node is assembled, and it must be the same for the entire network.

Data warehouse, ledger, DAG. Despite the arbitrary positioning of storage to “hold” the ledger, Sawtooth uses . The - Lightning Memory-Mapped Database (block-00.lmdb file) is used for the ledger (essentially the transaction) by default. The canonical configuration of the Sawtooth kernel also allows to be used for this purpose. Both databases are NoSQL databases and store . DGT also accommodates using graph databases (ex. ).

The platform supports the so-called . For these purposes, an abstract consensus mechanism is implemented. Consensus is accessed as a separate component (port 5050 within INTERCONNECT). Interacting with it is carried out through the Consensus API, an interface that allows the consensus mechanism to interact with the validator to establish consensus functions as a separate process. Three related processes are used in this work:

Using this mechanism, “built-in” Sawtooth consensuses can be connected: (the simplest way to verify transactions), , , , .

A module implemented as a separate service (TCP 4004) that supports various .

In any implementation, there is a settings management family (Settings Transaction Family), which saves configuration settings in the ledger. DGT adds another mandatory family – the topology processor. The transaction processors are responsible for verifying transactions and all actions taken. The BGT family is used as an additional testing component (modification of the ).

A component that allows clients to interact with the host core via HTTP/JSON. Processing is done through ZMQ/. The legacy API is . DGT significantly expands the existing APIs.

ZeroMQ
PyCryptodome
64-bit digital signature in DER encoding
LMDB
Redis
Dynamic Consensus
DevMode
PoET
PoET-SGX
Raft
transaction families
IntegerKey Transaction Family
Protobuff
described here
ZeroMQ
Docker
LMDB
Figure 10 Node Components
Figure 11 Interconnect View of Node Architecture[5]