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.6.4.1 Simple account creation
  • 6.6.4.2 Base Account Management
  • 6.6.4.3 Aliases
  1. 6. ADMINISTRATOR GUIDE
  2. 6.6 GARANASKA: Financial Processing

6.6.4 User accounts

6.6.4.1 Simple account creation

Any user can create an account for transactions with DEC. To do this, you need to have a private key and a public key pair. After generating the keys, the user must keep the private key secret.

By default, accounts are created with default settings. You can check the current settings by contacting the:

cat /project/dgt/etc/dec/wallet_opts.json

Below are the basic steps that follow the steps taken earlier to demonstrate transfers from the consortium account to the regular accounts. To create a new account, the user follows these steps:

  • STEP 1: Create two regular accounts (for more details, see the section on working with regular accounts). First, generate keys for regular accounts C and D:

dgt keygen KEYС --key-dir /project/peer/keys/
dgt keygen KEYD --key-dir /project/peer/keys/
  • STEP 2: Next, using the pair of keys, create the accounts:

dec account --keyfile /project/peer/keys/KEYС.priv
dec account --keyfile /project/peer/keys/KEYD.priv
  • STEP 3: Obtain addresses for accounts C and D:

dec addr /project/peer/keys/KEYC.pub
dec addr /project/peer/keys/KEYD.pub

6.6.4.2 Base Account Management

Detailed information on each account can be obtained in several ways: a list of accounts (limited for a small number of accounts in the system, with the growth of the number of accounts, it is recommended to use external systems for storing transactions, paging and search), account attributes, detailed information on accounts, account balance.

6.6.4.2.1 List DEC Accounts

The DGT is not an accounting system, so it only supports basic node-level commands that allow you to view all transactions that have been performed. A complex system for monitoring accounts, lists of accounts and sorting them can be implemented at the level of an application system (for example, DGT Dashboard), which is equipped with a parallel relational database capable of supporting tens of thousands of transactions.

The current version of the command allows you to output a limited number of transactions for system testing purposes:

dec list -tp accounts -v

You can limit the number of wallets that can be withdrawn by setting the --l or --limit parameter:

dec list -tp accounts -v --l 3
dec list -tp accounts -v --limit 3

Getting Account Address

A user, especially one working with a console, often uses a pair of private and public keys, however, the account number in the system is represented by its address, which carries the payload of compression of information, as well as a checksum, which does not allow you to make a mistake when performing operations with a large alphanumeric expression. These identifiers can be translated from one another in a one-way manner:

Private Key -> Public Key -> Address

Knowing the algorithm, the calculation of the address for the public key can be done without connecting to the system, for example, using the SDK or on your own. In some cases, it is necessary for the system to calculate the address directly on request, for example, in the console. For this purpose, there is a command, which we have already used above:

dec addr <PUBLIC KEY OR FILE>

The command accepts either a public key or a proper reference to the file that contains the public key. For example, for a previously created public key KeyA, the command looks like this:

dec addr /project/peer/keys/KEYA.pub

6.6.4.1.2 Calculate balance of account

Getting a balance refers to the basic information about the account. The balanceof command accepts a public key, a link to a file with a public key, and an account address as parameters. Command format:

dec balanceof <PUBLIC KEY, ADDRESS, FILE>

For example, for a public key wrapped in a KEYD.pub file, the command:

dec balanceof /project/peer/keys/KEYD.pub

6.6.4.1.3 Show Account Details

In some cases, it is necessary to provide detailed information about the account. In this case, the following command is convenient:

dec show -tp accounts <ADDRESS, PUBLIC KEY, FILE>

For example, for the following commands, the following will have the same result:

dec show -tp accounts /project/peer/keys/KEYD.pub
dec show -tp accounts 0xe5e21e493f156531a87dda17916eff6fb70aa39cbe5f

The result:

6.6.4.3 Aliases

6.6.4.3.1 Enhancing Usability with Alias Systems

While managing accounts via private and public keys with computable addresses remains a staple in blockchain operations, connecting to social networks, specific ecosystems, and business transactions can prove cumbersome due to their complexity. To address this challenge, DGT introduces a specialized addressing system that allows setting user-friendly aliases for given addresses, enhancing the system's accessibility and integration with various platforms.

Aliases act as synonyms for addresses and can be utilized in commands such as SHOW and SEND, as well as in operations involving assets. These aliases facilitate a more intuitive and memorable way of conducting transactions and managing assets, especially for users less familiar with the traditional address formats. Below are examples of the types of aliases supported by DGT, along with their requirements and potential applications.

#

Alias Type

Requirements

Comments

1

E-MAIL

Confirmation via E-Mail (requires a service like OneSignal)

Implemented through a notary in the Athabasca stage.

2

PHONE

SMS verification (requires an external service)

Implemented through a notary in the Athabasca stage.

3

FREE ALIAS

Any string that can replace an address

Limited to creation through a consortium mechanism with signature by the issuance participant.

4

WEB PAGE

Notary verification that the domain exists

Offers a direct link between digital identities and web presences.

5

OBJECT ALIASES

Implemented through a notary

Acts as an alias for a DID, facilitating easier reference and management of digital assets.

The alias system introduced by DGT significantly enhances the usability and accessibility of blockchain technology, making it more appealing to a broader audience, including those involved in social networks and business ecosystems. By simplifying the interaction process, aliases enable more intuitive transaction processes, asset management, and network participation. This system is particularly beneficial for the development of DeFi applications, where ease of use and accessibility can drive adoption and user engagement. By reducing the barriers to entry and making transactions more user-friendly, the alias system supports the growth and diversification of the blockchain ecosystem, paving the way for innovative applications and services.

6.6.4.3.2 Create Free Aliases

Free aliases are those that can be registered directly in DGT as any arbitrary string by any party involved in the issuance process, based on verified keys. This capability enhances user experience and integration with external systems without compromising security.

COMMAND STRUCTURE

The general command for creating a free alias is as follows:

dec alias [ALIAS] [ADDRESS] <SIGNATURE>

EXAMPLE

Let's say we've previously created an account associated with key A, whose address can be represented by the command dec addr <PUBLIC KEY A>. For the obtained address 0xb03304f0f1ae66c4252adbfe44c5dd857bbe0f8ebbf4, we create a new alias UserA@gmail.com (here we establish a linkage to the user's email without verification, but sign with the consortium's key) admin.

dec alias UserA@gmail.com -a 0xb03304f0f1ae66c4252adbfe44c5dd857bbe0f8ebbf4 
--keyfile /project/peer/keys/admin.priv

After creating the alias, it can be operated just like an address. For instance, using the command dec balanceof, we can obtain the account balance:

root@d1a7aba624ba:/project/dgt# dec balanceof UserA@gmail.com

The alias mechanism in DGT facilitates a more accessible and user-friendly interface for blockchain operations, especially in DeFi applications. By allowing the association of blockchain addresses with common identifiers such as email addresses, phone numbers, or even web pages, DGT significantly lowers the barrier to blockchain adoption for both users and developers.

6.6.4.3.3 Aliases List and Details

As with accounts, aliases can be viewed with the basic list command in the format (the capabilities of this command are limited when used in the CLI):

dec list -v -tp aliases

To view the details associated with the alias, use the show command:

dec show <ALIAS> -tp aliases

For example, for the UserA@gmail.com alias above, the command looks like this:

dec show UserA@gmail.com -tp aliases
Previous6.6.3 Consortium accountNext6.6.5 Payments

Last updated 1 year ago

Figure 140 Account List
Figure 141 Get address from public key.
Figure 142 Show account details
Figure 143 Alias creating