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:
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:
STEP 2: Next, using the pair of keys, create the accounts:
STEP 3: Obtain addresses for accounts C and D:
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:
You can limit the number of wallets that can be withdrawn by setting the --l or --limit parameter:
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:
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:
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:
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 | 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.
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:
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):
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:
Last updated
