3.1.2 DGT Approach
3.1.2.1 Platform Domain View
DGT is positioned as a platform for distributed and decentralized computing:
Distributed computing refers to a computing model where multiple computers or nodes work together to solve a problem or perform a task. In a distributed computing system, these nodes communicate and coordinate with each other by sharing resources, data, and processing capabilities over a network. The goal of distributed computing is to achieve improved performance, reliability, and scalability by distributing the workload across multiple machines.
Decentralized computing refers to a computing model where there is no central authority or single point of control. In a decentralized system, multiple nodes work independently, making decisions collectively through consensus mechanisms. Each node in a decentralized network maintains a copy of the system's data and executes operations based on predefined rules.
Distributed Computing | Decentralized Computing |
|
|
Distribution and decentralization can have different degrees so that the operation of the system is possible in an incompletely decentralized and only partially distributed network (decentralization metrics are discussed below, see 3.1.2.4). Before delving into the intricacies of DGT's architecture, it is essential to understand the fundamental concepts that underpin this platform:
DGT is referred to as a platform because it is capable of processing data for various application tasks. To address a specific task, a set of transactions needs to be configured, along with the addition of an application client.
DGT is built upon the Sawtooth framework, which means it inherits the main technical solutions of Hyperledger Sawtooth. While DGT maintains limited backward compatibility, it organizes node interaction and data processing differently. For further details on the differences, please refer to section 1.4.1.
DGT operates as a network comprising nodes. The DGT software represents the software running on a typical node, facilitating interaction with other nodes, data validation, and insertion of new data into the storage, known as the ledger or DAG (Directed Acyclic Graph).
DGT aims to support consortium-based networks, meaning that connecting a node to the network is subject to certain conditions ("anchor security"). These conditions may involve verifying if the node is whitelisted, checking for enough cryptocurrency, or validating a certificate. The degree of network openness varies based on the implementation of the anchor mechanism, ranging from completely open (public) to entirely closed (private).
Nodes are organized into groups, often referred to as federations or clusters. Initial interaction occurs through connections between the nodes and a dedicated node within the cluster known as the Leader. The Leader collects data from transaction checks performed at each node, referred to as "votes." If the number of affirmative votes surpasses a predefined threshold (such as a simple majority or 2/3 + 1 of the voting nodes for PBFT), the transaction is considered approved within the cluster and awaits further arbitration performed outside the cluster via an additional check.
Within the cluster, nodes communicate with each other through dedicated channels known as permalinks.
The core functionality of the network lies in the exchange of messages between nodes, termed transactions. These transactions undergo verification for accuracy and compliance with specific conditions before being added to the general ledger, also known as the DAG.
The ledger represents a distributed database or storage that exclusively stores verified records linked together via references to previous records. This ledger is immutable, meaning an entry cannot be "pulled out" or altered without modifying the entire ledger.
The complex structure of information exchange in the system is aimed at providing a united information space for different nodes and forming a single reliable copy of the data, free from accidental and deliberate errors. Such objectives arise when the system operates without a single center. The logic of checking each transaction and distributing it to the entire system (ledger synchronization) is described by a system of rules called consensus.
It is assumed that accidental or intentional actions of individual nodes in a heterogenous (uncontrolled) environment may violate the integrity of data in the ledger. Such actions are called Byzantine attacks, according to a well-known mathematical Byzantine generals’ problem. In the general case, the problem of resistance to a wide range of Byzantine attacks is considered unsolvable. But its solution can be obtained in various approximations through private algorithms – consensuses. A large number of such consensuses are known, for example, PoW (Proof Of Work), PoS (Proof Of Stake), etc.
The consensus used in DGT is called F-BFT (Federated Byzantine Fault Tolerance), which is a generalization of the PBFT algorithm (see 3.4).
3.1.2.2 Process Domain
As indicated above, the essence of the platform is to ensure the exchange of messages between nodes and their integration (consolidation) in a single immutable ledger.
For the exchange of such transactions to occur, the following conditions must be met:
A network of nodes has been formed. Each node is defined by its key pair (private and public key). The number of nodes is enough to form a .
There is at least one meaningful family of transactions, for which a transaction structure is defined: its header and description of the transaction body.
Consensus (validation) rules have been defined depending on the transaction .
The transaction storage (DAG, ledger, ledger, State) has been configured properly so that the rules for inserting transactions into the graph have been defined (there is an explicitly stated vertex to which a transaction is added).
Transactions are generated by clients – autonomous agents that interact with nodes through API. Before sending, each client “signs” a transaction with a pair of keys (private and public) based on the elliptic cryptography mechanism (ECDSA). When sending a transaction, the client does not wait for an immediate response, instead the transaction is accepted by the network within a limited time (transactions are sent asynchronously, the client receives the transaction ID and if it has been accepted by the system, he can request its status for a given ID).
If there are multiple nodes, the following roles can be defined in terms of processing a transaction:
INITIATOR/PRIMARY – the node that initiates the transaction (for example, through a client that interacts with it).
LEADER – the node that collects transactions within its cluster (by “counting” the number of votes by the nodes of the cluster).
REPLICA/VALIDATOR – the node that votes on a given transaction within the cluster.
ARBITRATOR – node(s) outside of the cluster that verifies the vote within it and adds the transaction to the .
The general scenario for working with transactions begins with its verification on the client, client signature, and transmission to the PRIMARY node. The PRIMARY node verifies the transaction and submits it for voting to the current leader. The leader sends it within the cluster to other validators. The transaction goes through a cycle typical for PBFT (see section 3.4).
Validators check the transaction according to a stack of rules set by the transaction processor (for example, if a certain number of tokens is transferred from one account to another, then checks may include the validity of the account, sufficient balance, etc.) In case of a positive check, the node votes for the transaction by signing it and returning it to the leader. The leader independently maintains a stack of signatures and rejections from the voting validators.
If the number of votes (signatures) from the nodes exceeds the specified number of such votes (⅔, ⅔ +1, or ), the transaction is considered approved within the cluster and the leader transmits it to the arbitrator. The leader expands the transaction, by including all signatures of the validator nodes that voted for it in its header and then sends it to the arbitrator. This action ends this voting round. Within the framework of the topology, a leader change period (in several rounds) may be defined, after which the leader will change, and another node will be chosen randomly among the validators to act as leader.
The arbitrator is selected from among the nodes outside the cluster according to the algorithm specified by the topology processor (see below). The arbitrator verifies the transaction, including the validity of the signatures of the voting nodes, and inserts the transactions into DAG. The flow of the transaction is shown in the diagram below. In more complex situations, when an ORACLE is present, the transaction may require additional arbitration, in which case the first arbitrator selects a new arbitrator.
If for some reason, the transaction is “frozen” (ex. the initiator temporarily lost connection with the network), then a time-out period is provided, after which the transaction is “removed” from the queue and not sent to the network.
After a transaction is inserted into the ledger, a version of the ledger on the arbitrator node differs from that of the other nodes. The process of synchronization starts immediately: the ledger is distributed along the permalinks either up (to the current leader) or down (from the leader to the validators).
Since the network works asynchronously, the client that initiated the transaction does not receive an immediate response. Instead, they can proactively check on the transaction status by receiving a “check” on its completion.
The diagram below shows the general flow of the transaction:
3.1.2.3 Challenges and Opportunities
The concept of blockchain was introduced by Satoshi Nakamoto in 2009 as a response to the banking crisis, offering the potential for decentralized finance. While the blockchain industry has attracted substantial investment since then, it remains relatively immature and not well-suited to addressing practical business challenges. This section explores the challenges and opportunities faced by blockchain technology, highlighting the need for further development and adaptation to solve real-world business problems.
At DGT, we strive to design solutions that address the challenges and pain points of blockchain technology, leveraging technology to solve these problems. The table below provides an overview of the key challenges and potential solutions:
| # | Challenge | Description | Possible Solution |
|---|---|---|---|
1 | Scalability | One of the primary challenges facing blockchain technology is scalability. As more users and transactions are added to the network, the performance and efficiency of the blockchain can become degraded, leading to slower transaction times and higher costs. | Segmented network in H-NET 2.0 architecture, cluster structure for implementing multi-level F-BFT consensus |
2 | Interoperability | Another challenge is the lack of interoperability between different blockchain networks, which can make it difficult to transfer value or data between them. | Creating bridges to Ethereum, supporting smart contract standards, powerful API layer for hybrid clients across networks |
3 | Security | Although blockchain technology is inherently secure, it is not immune to attack, and vulnerabilities and weaknesses in the system can be exploited by malicious actors. | F-BFT consensus with improved resistance to Byzantine attacks, off-chain layer for confidential data, support for private transactions and multi-signatures at the protocol level |
4 | Regulatory uncertainty | The regulatory landscape surrounding blockchain technology is still evolving, and there is often uncertainty and ambiguity around how different jurisdictions will regulate blockchain-based applications and assets. | Support for parameterizable transaction families, tools for non-custodial solutions that consider regulatory regimes |
5 | Adoption | The high initial entry threshold can be a challenge to broader adoption of blockchain technology, particularly in industries or use cases where there is a lack of technical expertise or understanding of the technology. | Reducing the cost of ownership, simplifying integration with an API layer, private network segments, building standard solution libraries |
6 | Functionality | The functionality of blockchain technology can be a challenge for applications that require more complex or sophisticated features. | Extending out-of-the-box transactional families to support smart contract logic, privacy, and interoperability |
These solutions are aimed at addressing the specific challenges and improving the functionality of blockchain technology for practical business applications. By tackling these areas, we aim to enhance scalability, interoperability, security, regulatory compliance, adoption, and overall functionality within the DGT ecosystem.
3.1.2.4 Decentralization Metrics
Decentralization plays a crucial role in economic systems, particularly regarding the independence of the economic agents involved. While measuring the degree of independence in network systems can be challenging, metrics such as Nakamoto Metrics (e.g., the number of independent nodes) or token distribution among participants can provide some insights (Lin, 2021). In the case of DGT, its hierarchical structure facilitates message segregation between nodes at the cluster level, followed by approval from arbitrators within the ring of arbitrators, comprising top-level nodes. This approach allows for an assessment of DGT's decentralization, although it may be lower compared to true peer-to-peer networks like Ethereum and Bitcoin.
Table 4 Decentralization Metrics Calculation
| # | Metric | Approach | Calculation |
|---|---|---|---|
1 | Nakamoto Metrics | This metric focuses on the number of independent nodes participating in the network. It considers the overall node count and evaluates the level of distribution among various entities | |
2 | Token Distribution | Examining the distribution of native tokens or cryptocurrencies among participants provides insights into the ownership and control within the network. Uneven token distribution may indicate a potential centralization of power | Gini Coefficient: |
3 | Governance Structure | Analyzing the governance structure of the network helps understand how decisions are made. Networks with decentralized governance models, allowing participation and influence from a broad range of stakeholders, often exhibit higher decentralization | |
4 | Node Connectivity | Evaluating the connectivity among nodes can provide insights into the level of decentralization. Networks with diverse and well-connected nodes exhibit a higher degree of decentralization | |
5 | Influence Distribution | Assessing the concentration of influence or decision-making power within the network is crucial. Identifying whether power is concentrated in a few entities or widely distributed among participants helps determine the network's decentralization. | |
6 | Sybil Resistance | Sybil resistance measures the network's resilience against Sybil attacks, where malicious actors create multiple identities to gain control over the system. Networks with robust Sybil resistance mechanisms tend to exhibit higher decentralization. | where: |
8 | Network Openness | The degree to which the network allows new participants to join and contribute to the system affects decentralization. Open networks with low entry barriers tend to be more decentralized. | where: |
Given the status of the DGT, a simulation was carried out showing the comparative value of the metrics for popular systems (Y. Jia, 2022):
| Metric | Ethereum | Algorand | Avalanche | DGT | Comments |
|---|---|---|---|---|---|
Nakamoto Metrics | Medium | High | High | Low | The hierarchy of DGT’s structure affects decentralization |
Token Distribution | Medium | High | Medium | Medium | For DGT it is like Ethereum, with potential concentration among early participants |
Governance Structure | Low | Medium | Medium | Medium | Hierarchical structure affects the decentralization of decision-making |
Node Connectivity | Medium | High | High | Medium | DGT’s permalinks impact connectivity compared to gossip protocols |
Influence Distribution | Low | Medium | Medium | Medium | The hierarchical structure and role of arbitrators affect the distribution |
Sybil Resistance | Medium | High | High | High | POS-based arbitration enhances Sybil's resistance |
DGT strikes a delicate balance between decentralization and scalability while ensuring its compatibility with enterprise-level connections to the Web3 ecosystem. By intentionally reducing the level of decentralization compared to fully decentralized networks, DGT can achieve enhanced scalability and facilitate easier access for enterprises seeking to integrate with blockchain networks.
The hierarchical structure of DGT, with a limited number of arbitrators responsible for transaction approval, allows for efficient and faster processing of transactions. This reduced decentralization ensures that the network can handle a higher volume of transactions and maintain faster transaction speeds, making it suitable for enterprise-scale applications that require high throughput. Moreover, the decreased decentralization in DGT enables seamless integration with existing enterprise systems and protocols. Enterprises often require blockchain networks that can integrate with their existing infrastructure, comply with regulatory requirements, and offer efficient data exchange. The controlled level of decentralization in DGT facilitates easier connectivity and interoperability with enterprise systems, allowing for smoother adoption and integration into existing frameworks.
This strategic balance of reduced decentralization in DGT does not compromise the network's security or trustworthiness. The use of Proof of Stake (PoS) for the arbitrators helps maintain a robust and secure consensus mechanism, mitigating the risks associated with centralization. By combining the advantages of reduced decentralization with the use of PoS, DGT maintains a high level of security while achieving the scalability and enterprise-readiness necessary for practical adoption.
Last updated
