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.2.4.1 BGT-based CLI tests
  • 6.2.4.2 Rest API Test
  • 6.2.4.3 Check the DGT Dashboard
  • 6.2.4.4 Unified single node check
  1. 6. ADMINISTRATOR GUIDE
  2. 6.2 DGT CORE: Single Node Setup

6.2.4 Single Node Check

Previous6.2.3 Nodes Port ConfigurationNext6.3 DGT CORE: Setup Private/Public Network

Last updated 1 year ago

After installing the node, you need to make sure that the services are installed and working correctly. The following are the basic tests to verify that the basic properties of the system are working. Here and below are the tests for the MATAGAMI version, the following versions, such as ATHABASCA. You can use a similar syntax.

6.2.4.1 BGT-based CLI tests

BGT is a test transaction family that supports abstract tokens within the network. Accessing BGT is possible in various ways, including using the command line interface – CLI. To use the CLI, you need to call bash inside the container.

  • We call bash inside the container:

docker exec -it shell-dgt-c1-1 bash

Inside the container, we execute the command to create a bgt-wallet and transfer a sum to it:

bgt set WAL  7777 –url http://api-dgt-c1-1:8108

As a result, a WAL bgt-wallet is created, to which 7777 BGT tokens were credited.

  • Checking the list of enrollments:

bgt list –url http://api-dgt-c1-1:8108

Sample output:

To add funds, conduct transfers, reduce within the bgt family, you can also use the commands (full list bgt -h):

- set – sets the bgt value

- inc – increases bgt value

- dec – reduces dgt value

- trans – transfers tokens from wallet to wallet

- show – shows a specific value for this wallet

- list – a list of all wallets and their amounts

  • For example, increasing wallet values is performed by the command:

bgt inc WAL 102 –url http://api-dgt-c1-1:8108

Sample output:

For more information on using the DGT CLI, see all command list below.

6.2.4.2 Rest API Test

  • Check the passage of transactions through the network.

  • Access network “costs” in terms of performance and scalability.

Each node is equipped with an API server that, in the basic configuration, responds on port (8108 by default). To carry out checks, you must ensure the following conditions are met:

#

Action/Requirements

Complete?

1

▢

2

▢

3

The overall health of the node has been verified internally using the CLI.

▢

4

The node has an IP address accessible from the local/external network. For an Ubuntu system, use the official guide for configuring and checking system network interfaces

▢

5

You have API testing tools installed and prepared. Recommended:

▢

Verification will be carried out by obtaining a list of transactions for a given node. Even in the case of a newly installed node, this list cannot be empty, since the node initialization procedures include settings for its topology performed through a special transaction family. Depending on the tools you use:

  • When using CURL, type the following in the command line interface:

curl -v [NODE_URL]/transactions

Here the [NODE_URL] – is the tcp-address of the node, including port. For example,

curl -v http://192.168.1.53:8108/transactions

As a result of executing such a command, the server will return a list of current transactions in JSON format. A typical output is shown below:

  • When using POSTMAN, load the local version, configure the Environment (see Environments tab) by setting the local variable url = NODE_URL (node’s IP: Port). Select the new GET command and enter the value:

{{url}}/transactions

If successful, the command should return a result similar to the one shown in the figure below.

6.2.4.3 Check the DGT Dashboard

#

Action/Requirements

Complete?

1

▢

2

▢

3

The overall health of the node has been verified internally using the CLI.

▢

4

The node has an IP address accessible from the local/external network. For an Ubuntu system, use the official guide for configuring and checking system network interfaces.

▢

5

On the workstation, you have access to the network and downloaded browsers (we recommend MS Edge, Google Chrome, or Mozilla Firefox of the latest versions)

▢

To conduct the testing itself, open your browser and follow these steps:

  • Go to the Dashboard by typing http://[NODE_IP]:8003/ in the address bar. For instance, http://192.168.1.53:8003/. If the service is operational and the network configuration is correct, the main Dashboard page will load:

  • For further testing, go to the Dev/Batch Creator tab. The presented functionality allows you to create test transactions. Select the following options:

    - Family: bgt

    - Url: tcp://validator-dgt-c1-1:8108

    - Command: set

    - wallet: WALX

    - amount: 1000

    The name of the wallet and the BGT amount can be specified arbitrarily. Execute the transaction (Execute) and if successful, the results of the transaction will be similar to those shown below:

6.2.4.4 Unified single node check

To verify that a single node installation works correctly, please use the following test to verify that the node is available and working:

#

Action

Description

Complete?

1

Check Environment

Make sure the system is deployed and assembled without errors, including the core services and Dashboard.

Use the appropriate procedures (see below)

▢

2

Check CLI with BGT Transaction Family

Navigate to the command line of the deployed node with the

«docker exec -it shell-dgt-c1-1 bash» command.

The command line prompt will change to «root…:/project/dgt».

Run the command for creating the WALLET1 wallet.

(or any other name, if this wallet was created earlier:

«bgt set WALLET1 1000».

If successful, repeat the command for creating a second wallet:

«bgt set WALLET2 1000».

Transfer tokens from the first wallet to the second:

«bgt trans WALLET1 500 WALLET2».

Print a list of wallets for the bgt family using the command: «bgt list».

The output should reflect the list of wallets and the wallet balances that changed due to the transfer:

«WALLET1: BGT_token=500 WALLET2: BGT_token = 1500»

▢

3

Check CLI Command to show all transactions

Without leaving the CLI of the node, enter the command to display the list of transactions:

«dgt transaction list».

The command should display a list of all transactions in the DAG.

▢

4

Check CLI/xcert

To check the processing of certificates, we use the command of their creation based on the key generated earlier:

«xcert set /project/dgt/etc/certificate.json –user /root/.dgt/keys/root.priv».

The successful output of the certificate’s contents guarantees the performance of the corresponding functionality.

The output of “xcert list” certificates should provide for outputting data created on the base of the certificate’s template.

Close the CLI console with the “exit” command.

▢

5

API Quering

To check the functionality of the API, they must be accessed through the appropriate client tool.

On the external machine, open the command line interface (or the POSTMAN toolkit).

Execute the listing of transactions: «curl -v http://[NODE_IP]:8108/transactions».

This command displays a list of transactions based on the network settings.

Additionally, let’s display the information for each separate transaction.

To do this, copy the Transaction_ID

(header_signature – 128-144-digit code in the form of “3046022…d630fd”)

for any transaction randomly selected from the list.

The output of transaction details is given by the command:

«curl -v http://[NODE_IP]:8108/transactions/TRANSACTION_ID».

▢

6

Dashboard Check

Checking the health of the Dashboard component (if it was installed) is carried out through the operations of the bgt family.

Load the Dashboard in the browser of the client computer:

«http://[NODE_IP]:8003/»

Open the «Dev/Batch Creator» tab.

Select the following in the Create Batch section:

Family = bgt; Url = «tcp://validator-dgt-c1-1:8101» , command = «set».

In the additional fields, enter the information about the transaction:

wallet = “DSHBTEST”, amount = “700”

Press execute and you should receive a link to the transaction status:

http://[NODE_IP]/batch_statuses?amount=700&cmd=set...

Press the Refresh button and you should receive the information on the transaction’s status; if successful, it will display: COMMITTED.

Copy the transaction ID:

«“id”: "3046022100…» (just the ID itself)

Head over to the “Transactions” tab, find the transaction of the bgt family among the first lines, highlight it, and in the pop-up window, check the transaction id against the “header_signature” field.

▢

7

Direct BGT API

Check the processing of the bgt transaction (by direct API access) with the endpoint run and curl utility.

Create a new :

curl "http://[NODE_IP]:8108/run?family=bgt&url=tcp%3A%2F%2Fvalidator-dgt-c1-1%3A8101&cmd=set&wallet=TESTWALLET&amount=1000"

In case of success, you should receive a check with a link to success.

The status of the created wallet is checked by the command:

curl "http://192.168.1.166:8108/run?family=bgt&cmd=show&wallet=TESTWALLET"

In case of success, a link to the wallet and its value are returned:

«”value”:1000»

Reduce the number of tokens in the wallet by a sum exceeding the one set before:

curl "http://[NODE_IP]:8108/run?family=bgt&cmd=dec&wallet=TESTWALLET&amount=1200"

This transaction returns a check with a display of the transaction (batch) ID:

“id= 3045022100fcc9cc0e1e5cda651e5b33…”.

Verify the operation’s status:

curl "http://[NODE_IP]:8108/batch_statuses?id=[BATCH_ID]"

With the output ID, the result is provided with the “INVALID” status.

The wallet status is checked with the command:

curl "http://[NODE_IP]:8108/run?family=bgt&cmd=show&wallet=TESTWALLET"

It should display an unchanged balance of 1000 BGT

▢

The health check presented above using the BGT transaction family may not be sufficient for a number of situations: the CLI client (see ) interacts with the node through API like any other client, at the same time, this interaction involves the internal (local) network of the node, which does not allow assessing the impact of network effects that are significant when testing distributed interaction. Using direct API calls allows you to:

The node is deployed in the local network in accordance with the instructions (see )

The node has open ports as per requirements (see )

- is a command-line utility for interacting with URL-based serves available for Linux and Windows operating systems (see )

- is a comprehensive API testing and development solution.

The standard node comes with a built-in dashboard, which can make health checks much easier. This component is optional and must be run separately – see . Make sure that you have completed the necessary preparatory steps.

The node is deployed in the local network in accordance with the instructions (see )

The node has open ports as per requirements (see). The standard port for using the Dashboard is 8003.

Experiment with other DGT commands by creating wallets, transferring tokens to them, and ensuring the operations are correct (for a complete list of DGT operations, see ).

6.5
6.2.2
6.5
6.1
6.2.3
CURL
user guide
POSTMAN
See the official guide for using the system.
6.1
6.2.3
Figure 115 Output for bgt command inside container
Figure 116 Output for bgt command “inc”
Figure 117 Test REST API with curl command line
Figure 118 Test REST API with POSTMAN tool
Figure 119 DGT Dashboard's main tab
Figure 120 Transaction via DGT Dashboard