6.1.2 Platform sourcing

The DGT platform is designed to bolster its network, comprising individual nodes. Each node operates as a full-fledged server solution, replete with numerous services and software components. Even a standalone node presents a complete solution, capable of supporting application solutions and deployable by a single organization. Although the DGT framework can be implemented across various environments compatible with its technology stack, this section simplifies the deployment process by focusing on Ubuntu OS within a Docker virtualization context.

6.1.2.1 Directory and Package Structure

DGTs are software that is distributed as source files. Единственная точка распространения представляет собой репозиторий GitHub. Inside the repository, you have to choose the right version for your needs. The versions have individual designations, now the most recent versions are Matagami (stable) and Athabasca. In the case of building from source code using Docker Compose, the installation of the platform version is carried out by cloning to the home (or other selected) directory:

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

Within the directory of the corresponding version, you can find subdirectories corresponding to the individual packages of the system:

#	Folder	Sub Folder	Description
1	CORE	..	A subversion distributed under the APACHE 2.0 license and implying basic functionality. In fact, it is an improved version of Sawtooth
1.1		bin	Top-level classes and packages that make the system work as a whole.
1.2		clusters	Network configuration files and topology files.
1.3		consensus	The code behind the consensus mechanism
…		…
1.7		families	Code That Implements a Transaction Processor.
…		…
1.10		rest-api	Code that implements the Node API.
1.11		validator	The code that keeps the validator running.
2	GARANASKA_BETA	..	A subversion distributed under the LGPL 3.0 license, containing the Garanaska financial subsystem (tokenization) and other advanced features
2.1		bin	Top-level classes and packages that make the system work as a whole.
2.2		cli	Support for Console Version Commands
2.3		clusters	Network configuration files and topology files.
2.4		docker	Docker Configuration
2.5		notaries	Code that supports the work of notary nodes
…
2.14		sdk	Library modules that support basic cryptography and networking functions
2.15		validator	The code that keeps the validator running
2.16		Seth	Smart Contract Processor.
3	CLIENTS	..	Example of client-side code that works with remote hosts.
4	DOCS	..	System Documentation.

Thus, the version is represented by two basic branches (packages), which differ in functionality: Garanaska, in addition to the basic functionality of CORE to support general transactions and the test family of transactions bgt, is equipped with additional functionality that works with financial transactions, notary nodes, and support for virtual machines for smart contracts.

6.1.2.2 Shell scripts

Since DGT comes as source code, to run and manage the platform, you will need to run a few additional commands that support building, configuring parameters, and running server components. Within the Linux system, you can use the standard Bash shell for standard node manipulations.

Bash, short for Bourne Again SHell, is a Unix shell and command language written by Brian Fox for the GNU Project as a free software replacement for the Bourne shell. It has been widely adopted as the default command-line interpreter on most Linux distributions, as well as on macOS until Catalina version, and it's available for use on various other operating systems. As a shell, Bash is both a command language and a scripting language. It provides an interface for users to interact with the operating system by typing commands into a console or terminal window. Users can launch programs, manage files and directories, and perform other system tasks by entering commands that Bash executes.

The deployed version of the source code comes with standard Bash scripts responsible for preparing, building, and running the nodes, as well as accessing their commands. There are two versions of such files: single scripts (separate script files, each of which is responsible for one command), and macro (an interpreter of sub-commands), which is responsible for executing different commands.

In the next steps to deploy the nodes and configure them, we'll use commands based on Bash command scripts.

Single Scripts are scripts that are responsible for configuring and using the main functionality, they can be run from the main directory where the DGT code is located (obtained, for example, using the git clone command). The main command scripts are shown in the table below.

#	Command/Script File	Propose
1	control.sh	A super-script designed to run internal commands that control platform components replaces and complements the individual scripts listed below. The parameters for this script are below
2	upDecCluster.sh	A generic script that is responsible for building, running a single node, cluster, or entire network. Accepts cluster number and node number as parameters
3	upDgtDashboard.sh	Script responsible for launching DGT Dashboard (web-client)
4	upDgtGrafana.sh	The script responsible for starting the Grafana server, the component that is responsible for collecting statistics inside the solution
5	upDgtNotary.sh	A script that is responsible for running notary nodes (performing off-chain calculations)
6	downDGTCluster.sh	A script that stops a node or cluster takes the coordinates of a node as input
7	downDgtDashboard.sh	Script that stops Dashboard
8	downDgtGrafana.sh	A script that stops the Grafana server
9	downDgtNotary.sh	Script that stops the Notary's node

All scripts are designed to run in a Linux environment and only apply to nodes running within the home operating system (internal or virtual hosts): many virtual nodes and even clusters can be running on one physical host platform.

The superscript in the table above does control.sh accept the commands listed below.

#	Sub command	Description	Example
1	show	Show peer param	bash control.sh c1_2 show
2	run	Call run command inside of Node Environment	bash control.sh c1_1 run bgt list
3	up	Create and start DGT containers	bash control.sh c1_1 up [-d]
4	mode	Change peer mode	bash control.sh c1_1 <mode name>
5	ps	List all run containers	bash control.sh c1_1 ps [-q/--services]
6	restart	Restarting DGT services	bash control.sh c1_1 restart
7	build	Build or rebuild services	bash control.sh c1_1 build validator-dgt
8	copy	Make peer copy	bash control.sh c1_1 copy <new peer name>
9	list	Print DGT peer's params	bash control.sh dgt list [-v]
10	stop	Stop DGT services	bash control.sh c1_1 stop
11	del	Drop peer declaration	bash control.sh c4_1 del
12	shell	Enter into peer shell	bash control.sh c1_1 shell
13	edit	Edit DGT peer params	bash control.sh c1_1 edit [<param name>]
14	down	Stop and remove DGT containers, networks, images, and volumes	bash control.sh c1_1 down
15	dec	Run dec commands	bash control.sh c1_1 dec list
16	start	Start DGT services	bash control.sh c1_1 start
17	token	Generate API access token	bash control.sh c1_1 token
18	add	Add new DGT peer	bash control.sh c4_1 add

If you use scripts frequently, you can make their invocation smoother (without prefixes and extensions), for example, by configuring the environment through the following steps:

• Make the file executable. You have to make sure that the file has execute permissions. This can be done with the chmod command: chmod +x control.sh

• Remove the .sh extension (if you want to call it without specifying an extension). Simply rename the file: mv control.sh control

• Add the directory path to the PATH environment variable (if this directory is not already part of the PATH). Let's say your script is in the /home/username/scripts directory.

  o Then add this directory to the PATH by editing the «.bashrc» or «.profile» file in your home directory. Open the «.bashrc file» in a text editor: nano ~/.bashrc.

  o Add the following line to the end of the file: export PATH=$PATH:/home/username/scripts.

  o Save the file and close the editor. For the changes to take effect, run the following steps: source ~/.bashrc.

• Specify the interpreter at the beginning of the script. Make sure the first line of your script points to the interpreter, for example: source ~/.bashrc.

Using the scripts described, the following are the step-by-step procedures for configuring and starting DGT nodes.

Using Docker to launch virtual nodes leads to the creation of "servers within a server," or containers, which have their own execution environment. Most node commands will be applied inside such a container. To enter the console within a node, a special command is used. For example, for node c1-1, the command is:

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

This command temporarily moves the user into the node's execution shell (the guest system). Exiting this shell and returning to the host system is done with the exit command.

6.1.2.3 Deployment Process Overview

The deployment involves several key steps:

• Acquisition: Obtain the relevant version of the DGT repository.

• Configuration: Adjust the node’s basic settings.

• Containerization: Utilize Docker Compose to build a container.

• Connection: Link the node to the network.

• Health Check: Run basic commands that allow you to perform a basic check of the functionality of a node or network segment.

Below is a schematic diagram of the process:

Figure 110 General Steps for Deployment with Docker

6.1.2.4 Deployment Scenarios

The deployment scenarios are broken down into individual nodes, virtual networks, and physical networks. Key preliminary notes include:

• Integration and Connection: The deployment and network integration are managed through the "magical" command up.DgtCluster.sh. The DGT Network is segmented into node groups (clusters), with each node fulfilling a specific role.

• Parameter Configuration: Basic parameters, like certificate settings and transaction processing times, are derived from a standard configuration (found in the "DGT-Matagami\CORE\etc." directory) for each node image. Post-creation and connection, a node’s main parameters are stored in the “DGT-Matagami\dgt_clust” directory.

• Service Ports: Nodes consist of multiple services, each requiring configured network access parameters.

• Cryptographic System: The entire network adheres to a unified cryptographic framework, detailing signature methods, address systems, and transaction encryption.

• Transaction Families: The DGT network accommodates various transaction types, known as "transaction families." Basic network configuration includes:

o dgt-set: Essential for network operation, managing settings, and topology.

o xcert: Necessary for deploying closed/private segments, managing certificates.

o bgt: A test family for token management transactions, testing network functionality.

6.1.2.5 System Accessibility

The functionality can be accessed through multiple avenues:

• CLI console/command line. In this case, you log in to the console of the running container and execute the commands directly.

• Dashboard component/service (initiated from a client computer browser). In this case, commands are submitted using a web client (chain explorer).

• API (detailed in Developer Guide section). To check this way, you must use tools such as Postman or curl. Almost all commands in DGT have their counterpart as Rest API endpoints.

These methods facilitate functional assessments.

6.1.2.6 Pre-built Configurations

Depending on solution requirements, you can deploy one of the predefined configurations or devise a custom setup:

• SMALL: Features one DGT network node for basic core function verification under hardware constraints, alongside two notary nodes (key keeper and regular notary).

• MEDIUM: Comprises 2 DGT clusters (3+2) with two notaries on a single virtual machine, focusing on notary functions and node interactions.

• HIGH: Involves the deployment of at least 16 DGT nodes across various cluster configurations, along with 2-4 notaries, primarily utilizing minting functionality.

Additionally, the basic configuration (DGT CORE) offers essential commands and a test transaction family, while the extended system (GARANASKA) facilitates financial transactions with DEC, notary and certificate management (decentralized identification), arbitrary smart contracts, and Ethereum network interactions.