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.3 Unique contribution

Previous3.1.2 DGT ApproachNext3.1.4 Component Based Architecture

Last updated 1 year ago

DGT is a distributed ledger technology that allows organizing interactions between organizations (Businesses) within the framework of a consortium-based approach. Several properties derived from the F-BFT consensus make it possible to position DGT as a platform for ecosystems, which can implement complex B2B2C and B2B2B models. , including DGT, are suitable for creating hybrid business communities. Some of DGT’s features include:

  • The storage system is , similar to IOTA, Hedera, Hashgraph, Orumesh, DagCoin, Byteball, and Nano. The DGT approach differs from those systems in that it allows voting in a federated network structure with a customizable topology.

  • The federated approach to voting is actively used by solutions such as Ripple, and . DGT applies this ideology onto a horizontally scalable DAG and, through the rotation of leaders in clusters, provides a dynamic topology. This resolves the problem of the otherwise apparent .

  • The consortium-based consensus system allows to maintain flexibility, without losing speed and interoperability. For example, Hyperledger Fabric is aimed at private peer-to-peer networks and requires the formation of special support structures (sidechains). The ICON solution uses a special Loopchain Fault Tolerance mechanism for interacting with . Unlike these solutions, DGT implements a dynamic topology on top of DAG, allowing for a high degree of asynchrony in the network.

Having some of DGT’s functional properties intersect other existing solutions allows for an edge computing environment to be implemented, particularly through the simultaneous use of several well-known approaches combined within the framework of the platform. The solutions close to DGT in architecture, such as , do not have a clear focus on ecosystem components:

  • The horizontally scalable DAG storage architecture combined with federated networking.

  • Dynamic network organization due to topology processor.

  • A single ontological layer due to the support of several families of transactions.

The implementation of the F-BFT consensus, based on the probabilistic ratio of the time the network takes to vote and the polynomial interpolation of the voting results, allows for an effective and unique technical solution with broad functional properties and exceptional interoperability. This is necessary for constructing business systems that achieve a required level of .

FEATURES
Intel Sawtooth
DGT Network

1. General architecture

2. Low-level protocols

3. Cryptography

DGT redesigned the cryptographic system and can support several alternative systems, including the ECDSA curve secp256k1, as well as OpenSSL.

4. Type of DLT

Private/Public

Consortium-Based/Hybrid

5. Network solution

One-level; the GOSSIP protocol is used for node discovery and transaction propagation

In a federated network; the interaction between nodes is determined by the topology processor (one of the transaction families)

6. Consensus

The F-BFT algorithm is based on reaching consensus in clusters (federation) and then disseminating validated data to the entire network.

7. Data storage

DAG, is a directed acyclic graph, whose vertices contain batches of transactions, and the edges are formed by hash links to previous batch transactions.

8. Transaction management

Like Sawtooth, DGT uses a mechanism for separating transaction families through pluggable transaction processors. This feature makes it possible to use different types of transactions within one stored Ledger mechanism. Additionally, DGT uses a family of topological transactions to form the network topology.

9. Tokenization

Missing.

The tokenization mechanism implies the capabilities of system participants to issue their value equivalents for information exchange.

10. Connecting clients

In both Sawtooth and DGT, the client that defines the application logic (with which the end user is working) connects to the selected node through an API server, that provides all the necessary data. The DGT API server is significantly expanded compared to Sawtooth, which allows for the connection of a system of statistics and general network analysis (Dashboards).

11. Byzantine Fault Tolerance

A distinctive feature of Sawtooth among other Hyperledger projects is the embedded resistance to Byzantine attacks: node spoofing, double spending, and other violations of integrity in a distributed network. An additional feature of DGT is the built-in BFT testing system with an attack emulator.

12. License

CORE edition – Apache 2.0

GARANASKA edition – AGPL 3.0

Backward compatibility with Sawtooth provides the following benefits:

  • Inheritance of significant functionality that has been security audited and verified in terms of performance.

  • The use of a consistent technology stack allows DGT to focus on developing distinctive features that most closely match the target characteristics of application scenarios, such as those primarily necessary for establishing digital ecosystems.

  • Easy integration of such components as Sabre and other modules with high potential.

DGT was initially built on a well-known Hyperledger Sawtooth framework (see DGT. Technology Roadmap, 2021 | ), led by the Intel Corporation. The philosophy, architecture, and implementation of Sawtooth most closely represent the goals and objectives of DGT. DGT inherited some low-level technical features, while also adding several of its own – as presented in the table below:

DGT supports the underlying in terms of modularity, distribution of core data handlers, event streams, and so on.

DGT mainly inherits Sawtooth solutions, including the use of ports, the asynchronous library, virtualization, and flow management.

Even though the framework supports a reloadable consensus mechanism, the leading algorithm is , a consensus based on Intel chips. At the end of 2019, Intel .

In blocks, physical storage is organized in reloadable data stores (LMDB, , and other NoSQL databases). Sawtooth uses a for storing data for transaction .

Available on corporate site
Sawtooth architecture
ZeroMQ
PoET
announced support for the PBFT consensus
OpenTS
Merkle-Radix tree
Apache 2.0
Consortium-based networks
based on DAG
Stellar
compromise of network safety versus liveness
Figure 9 DGT positioning in the blockchain landscape