6.3.1 Network launch preparation

Network deployment is the installation of several nodes interacting with each other. Unlike peer-to-peer network, a DGT network can have a set structure that is thought out and configured in advance. The following items must be considered:

• Setting up the network topology. In DGT, nodes are combined into special groups (clusters) that allow to achieve the F-BFT consensus and a significant scaling effect. Clusters can be hierarchical, allowing for the creation of additional network structures with different levels of trust.

• Segments are another network structure that define the access permissions to the network. Closed (private) segments require access permissions though certificates. Public segments allow free connection. Although several settings allow the network to change dynamically, its initial organization must be well thought out.

• The first nodes entering the network are the so-called seed-configuration (the static core of the network) and must have a certain level of trust that allows them to recognize public keys before making changes in the topology. The initial (seed) topology of the network, including the hierarchy of clusters and segments, can be described by special configuration files (see below).

• DGT allows for flexible management of cryptographic libraries at the network planning stage. However, once the network is launched, the addressing in the distributed (DAG) ledger, transaction signatures, and hidden message encoding must be unified. Therefore, select the correct node assembly parameters before proceeding to launch (see below).

• Connecting to the network and forming closed clusters requires registration and correct processing of certificates in X.509 format (binding a public key to a specific node). See details below.

• The payload within the network is essentially the exchange of transactions. DGT supports different families of transactions, some of which are built-in (such as #topology, handled by the topology processor; #xcert supporting certificate processing; #bgt token testing transactions – see below). Network deployment assumes that all nodes within one cluster support the corresponding family of transactions.

• Connection nodes to the network is carried out through a special type of transactions processed by the topology processor. Like all transactions, they can be rejected and go through a consensus mechanism.

The following options for network deployment and organization of network are available:

#	Network Organization	Description	Section
1	Virtual Clusters	In this configuration, the nodes are deployed on a single physical server using the Docker containerization technology. This schema is convenient for testing purposes or when developing your own applications.	6.3.2
2	Physical Network	In this configuration, nodes are deployed on a separate physical server and communicate using the Internet.	6.3.3
3	Attaching nodes to an existing network	As part of this configuration, the node joins an existing network, virtual or physical, considering various access parameters (private or public segment).	6.3.4

Select the network parameters prior to deployment:

#	Parameters	Description	Options
1	Cryptography	Cryptography is determined by the -CB key when assembling the node and determines the library type, cryptography type (RSA, EDCSA, NTRU), and curve parameters. This influences signatures, verifications, addressing, and other interaction parameters between the nodes. The network must support a single cryptographic system.	-CB openssl (ECDSA over OpenSSL) -CB bitcoin (bitcoin secp256k1 - ECDSA over bitcoin)
2	Physical location of the network	Nodes can be hosted on virtual machines for development or testing purposes. An alternative option is to host servers on different machines on a physical network. The third option is to connect the server to an existing network.	- Virtual Clusters (see 6.3.2) - Physical Network (see 6.3.3) - Attaching Node (see 6.3.4)
3	Number of nodes in a cluster	Although the network configuration can be changed during operation, some parameters, such as the maximum number of nodes per cluster or the depth of the clusters’ hierarchy could be fixed initially.	Setting up the map (see 6.7.1) -- dgt.net.static - dgt.net.map - dgt.net.dyn
4	Access method	Within the same DGT Network, there can be both closed (private) segments that require access approval and open segments, the access to which is limited only by the restrictions on the size of the cluster.	Setting up the map (see 6.7.1) -- dgt.net.static - dgt.net.map - dgt.net.dyn
5	Notation	When forming a network map from many nodes, special attention should be paid to node notation, which allows for the representation of nodes through a mnemonic name. Such named can be redefined through the map.	Setting up through - dgt.netmap (see 3.7.1)
6	Seed Bundle	At network setup, node data can be obtained in a variety of ways, including the dynamic topology processor. At the same time, at the start of the network, some of the nodes can immediately form a circle of trusted validators. The indicators of such nodes are recorded in a special configuration file.	See «static_map» in the configuration file dgt.net.map (see 3.7.1 )