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
  • 6.3.2.1 Setup Virtual Nodes
  • 6.3.2.2 Virtual Cluster Evaluation
  1. 6. ADMINISTRATOR GUIDE
  2. 6.3 DGT CORE: Setup Private/Public Network

6.3.2 A Virtual Cluster

Previous6.3.1 Network launch preparationNext6.3.3 A Physical Network

Last updated 1 year ago

6.3.2.1 Setup Virtual Nodes

Deploying a virtual cluster is the easiest way to run multiple nodes within a single virtual server (using Docker technology):

  • Deployment of a small network of several nodes for test purposes.

  • Designing your own subnet, which is expected to include nodes of different types.

  • Development and testing of applied solutions based on the DGT platform.

  • The basic steps to initializing a virtual cluster are as follows:

  • Prepare the server in accordance with the requirements listed in (including setting up the operational system, Docker, Docker Compose, and the necessary instruments). Verify the correctness of the configuration.

  • Download the latest version of dgt through the “git clone” command:

git clone https://github.com/DGT-Network/DGT-Matagami

As a result of execution, the DGT-Matagami/CORE directory is formed in the home folder of the user (HOME/DGT), from which the image of the cluster’s servers is built.

  • Go to the relevant folder and make sure the files are present:

cd DGT-Matagami
cd CORE

  • Go to the CORE/etc directory to set up settings. First, you need to edit the template for creating certificates: etc/certificate.json, by specifying the relevant parameters, including country, region, administrator e-mail and others:

nano certificate.json

  • Set up the topology (see ):

nano dgt.net.map

  • Use the «bash upDgtCluster.sh N M» command to sequentially build each of the nodes included in the Seed bundle (if necessary, install the Dashboard for a given node):

bash upDgtCluster.sh -G -SC -CB openssl NumCluster NumNode

Here:

- -G – flag indicates the necessity of creating a genesis-block

- -SC – flag indicates the requirement of having nodes sign transactions

- -CB openssl – indicates the selectable type of cryptography (must be consistent with the network to which the node belongs). Options include openssl or bitcoin

- NumCluster NumNode – cluster number and the node number in the cluster. For the first node, we set “1 1”. The mapping of the number to a notation variant using segments and clusters is reflected in the dgt.net.map file.

For example, to bring up four nodes located in two clusters, we use the following set of commands:

bash upDgtCluster.sh -G -SC -CB openssl 1 1
bash upDgtDashboard.sh -CB openssl
bash upDgtCluster.sh -G -SC -CB openssl 1 2
bash upDgtCluster.sh -G -SC -CB openssl 1 3
bash upDgtCluster.sh -G -SC -CB openssl 2 1

6.3.2.2 Virtual Cluster Evaluation

After deploying a cluster, you need to perform the initial health check.

  • Using the API, we poll the available nodes:

curl -v http://[SERVER_IP] :8108/peers

Where SERVER_IP is the address of the virtual machine hosting the nodes. The typical output of the command is shown in the figure below:

Note that the nodes have received different ports and URLs:

- tcp://validator-dgt-c1-1:8101

- tcp://validator-dgt-c1-2:8102

- tcp://validator-dgt-c1-3:8103

- tcp://validator-dgt-c2-1:8201

- is not displayed, since the request was made to this node

  • Let’s display the complete network topology, indicating the status of each of the nodes:

curl -v “http://[SERVER_IP]:8108/topology

A typical output contains a complete network map, for which the active nodes receive the «node_state: active» status, as well as an indication of the corresponding roles: plink, leader, etc.

  • Verifying the interaction via console

Each of the running nodes has its own console. This allows for the testing of a scenario where one of the nodes executes commands and then the results are checked through another node.

- Log in to the console of the first node and create some bgt-wallets. Then exit the console:

docker exec -it shell-dgt-c1-1 bash
bgt set wallet_1 1000
bgt set wallet_2 700
exit

- Through the console of another node, we display a list of bgt-wallets:

docker exec -it shell-dgt-c1-3 bash
bgt list

The output should confirm data synchronization between nodes. The output contains commands that display a list of wallets created through the console of another node.

  • Checking node status via Dashboard

If the Dashboard component is installed, checking the status of the nodes can be performed using the browser of the client computer:

🌐 http://[SERVER_IP]:8003/ -> Nodes

  • Querying the API of each of the nodes allows for finer testing of transaction execution.

By default, each of the nodes is associated with its own API service that executes the appropriate commands (endpoints). If a virtual cluster is launched, the corresponding IP servers have the same [SERVER_IP], however, they use different ports, the correspondence of which to a given node is determined by the file. The default ports ([API] parameter) are as follows:

- Cluster 1 Node 1: 8108

- Cluster 1 Node 2: 8109

- Cluster 1 Node 3: 8110

- Cluster 2 Node 1: 8208

To check using the API, execute the command to display a list of bgt- wallets for the first node, change the amount on the first one by using the “inc” increasing command, then check the balance through an API of another node. We call the API from the client system using the curl utility.

We display the status of bgt-wallets on the first node and make an increase (we use the previously created test wallets wallet_1 and wallet_2; if they are not available, you must also execute the commands to create them (see 7.1.9.2):

curl "[SERVER_IP]:8108/run?family=bgt&url=tcp%3A%2F%2Fvalidator-dgt-c1-1%3A8101&cmd=list"
curl "[SERVER_IP]:8108/run?family=bgt&url=tcp%3A%2F%2Fvalidator-dgt-c1-1%3A8101&cmd=inc&wallet=wallet_1&amount=100"

We check the received amount through another node:

curl "[SERVER_IP]:8208/run?family=bgt&url=tcp%3A%2F%2Fvalidator-dgt-c2-1%3A8201&cmd=list"

Expected result: even though the command was sent to the node in the second cluster, the data is synchronized, and the correct amount was displayed for the first wallet.

You need to pay attention to the lists of nodes within each cluster, as well as the «static_map» parameter, which will define the Seed Bundle (the static core of the network); see :

As a result of this set of commands, two clusters with four nodes will be created. To create another configuration, see .

6.1
6.7.1
6.7.1
6.7.1
Figure 121 Net Settings in CORE/etc/dgt.net/map[1]
Figure 122 Peer List for Virtual Cluster
Figure 123 Output for topology API endpoint
Figure 124 CLI Transaction synchronization test
Figure 125. Active nodes are reflected in the Nodes tab of the Dashboard