3.3.1 Nework Architecture in General
Most blockchain platforms organize interaction between nodes based on the P2P paradigm, a peer-to-peer network in which a node initially gains access to some dedicated nodes and then propagates the network through the GOSSIP protocol (interacting with randomly selected nodes). DGT uses cluster networking, in which individual groups of nodes are connected by permalinks, a dynamic network over the Internet. Specific features of the DGT network organization include:
The network consists of independently functioning nodes, each of which has a full set of functions common to the network (first and foremost, the ability to receive and process transactions, saving them in the local ledger).
The node can differ in terms of roles, additional API capabilities, access to different data sources, and different network environments. Finally, the nodes may belong to different operators (individuals and legal entities) with conflicting interests. If access to the network is controlled by one organization/group of persons, the network is called private. If participants have free access to the network, it is called public. There is an intermediate situation in which access to the network remains free under certain conditions (consortium-based access), or a mixed network is allowed (some remain freely available, and some are regulated by the organization). Such networks are called hybrid networks. DGT supports various networking methods.
As a distributed and decentralized network, DGT must support mechanisms to prevent data conflicts that arise from network failures or intentional distortions (attacks) on data integrity. Some of the possible problems may relate to the irregularity of network objects (for example, node failure, or unexpected loss of connections). Resistance to such problems is called Crash Fault Tolerance – CFT. This problem is most relevant for closed private networks. In open networks, the problems of specific attacks on data integrity are also manifested. The resistance to these is called the Byzantine Fault Tolerance – BFT. Using the F-BFT consensus mechanism (a special set of rules for actions concerning transactions), the nodes can reject wrong transactions and ensure that the correct copy of the ledger is distributed throughout the network. The consensus mechanism is directly related to the network topology.
Nodes are grouped into clusters. Each cluster has a variable leader through which the other nodes of the cluster interact with each other. The cluster communicates with the network through a set of gateways. The current interaction channels that represent the local peer-to-peer network are called permalinks. Thus, DGT offers dynamic links between nodes instead of the dynamics of linking nodes.
The nodes form a network divided into clusters (federations). The topology of such a network is defined by special anchor rules: special transactions with conditions under which a node is allowed to connect to the cluster and transmit messages onto the network. The image above shows a typical network .
Each node keeps a copy of the transaction ledger. Each node can be connected to several clients (or even none) that generate transactions.
Within the given topology (the schematics of organizing a network of nodes), data about servers and their relationships are determined by a special module – the processor of topological transactions. It ledgers links and positions of nodes directly in the distributed ledger. Thus, each node has access to data about the topology of a particular implementation. According to the given rules, nodes perform certain calculations on transactions (“votes”). As shown above, nodes can take the roles of PRIMARY (transmits a transaction received from the client into the network), LEADER (collects the vote and then passes it on), or ARBITRATOR (performs a final check of transactions and inserts them into the ledger) depending on the functions in the context of the consensus.
Last updated
