6.6.2 DEC emission
6.6.2.1 Emission configuration
When you install the Garanaska sub-version, you unlock additional functionalities within the DGT framework. This includes financial features and notary operations. It is assumed that you have not only selected the GARANASKA package but also compiled and tested the availability of at least one DGT node. Most functions are available even for a single node, along with two notaries: one acting as a key custodian and the other as a regular notary connected to the network.
To engage with the DEC financial ecosystem, an initial step is required: the emission of native DEC tokens. These tokens are digital entries in a central registry, earmarking specific token amounts to distinct addresses, akin to account numbers. DEC tokens embody the network's value, primarily compensating nodes for transaction processing, application support, and balancing the network's economy.
There are some key points to consider before emission:
Consortium-Based Launch: The network's initiation is planned by a consortium of independent entities. They agree on the maximum DEC token supply, reflecting a mutual understanding of the network's goals, configurations, and revenue opportunities. The total agreed-upon token amount is issued at once but distributed over time based on predetermined parameters.
Token Distribution Mechanism: The distribution model is straightforward. A portion is allocated to the consortium, which manages a public account through a multi-signature mechanism by key consortium members. This wallet faces time-bound and amount-specific restrictions.
Emission Parameters: In addition to distribution speed parameters, the emission includes basic information like the token name (default DEC), granularity (fractional parts, like cents), and the primary keys accessing the corporate wallet. These details, along with the issued amount, are recorded in the registry, becoming immutable parts of the DGT protocol.
Operational Protocol: The emission record features a virtual key, _DEC_EMISSION_KEY (virtual account), with protocol-limited actions. This ensures that, despite a majority consensus potentially rewriting the registry, the original emission record remains unchanged and singular. The network can process commands before this emission; however, subsequent DEC commands rely on the existence of _DEC_EMISSION_KEY.
Network Value Circulation: Most tokens are distributed among nodes in exchange for transaction processing, regulated by network temperature parameters (via the Heartbeat protocol). Network users acquire tokens by purchasing or exchanging them with nodes or the consortium. Except for shielded transactions, all operations are transparent and community-regulated within the DGT platform.
The process of emission requires considerable planning as it is a one-time, irreversible action. Below are the steps to ensure a successful DEC token emission:
6.6.2.1.1 STEP 1: Emission Keys Configuration
The process of emission is a one-time event that requires not just meticulous planning but also a robust level of security. This ensures the immutable emission parameters remain protected under any circumstances, and that all parties involved in the emission have indeed agreed to and are authorized to proceed. In blockchain systems, this security is typically achieved using private and public keys, with a pair for each participant.
KEY CREATION BASICS:
Complexity of Keys: The keys are complex combinations of letters and numbers, making memorization and subsequent use challenging without specialized software, such as wallets or password managers.
Privacy and Transparency: While the private key must remain confidential (known only to the owner), the public key is openly shared and verifies ownership of the corresponding private key. The public key is generated from the private key, making reverse engineering impractically time-consuming.
Standardization within DGT: Assuming the DGT platform is operational and at least one node is accessible, standard node software is used for key generation. This standardization is crucial for maintaining a unified cryptographic system.
Consortium Participants' Independence: It's assumed that consortium participants issuing the emission can independently generate key pairs using tools and instructions provided, securely store the private key, and share the public key within the consortium. Emission setup is a flexible process with many adjustable parameters.
STANDARD PARTICIPANTS:
Emission Keys (eKeys): Directly approve parameters and initiate the emission process. At least three consortium members (directly executing the emission) are chosen, with their keys named eKey1, eKey2, eKey3. These can be stored in text files with extensions ‘.pub’ for the public key and ‘.priv’ for the private key.
Consortium Keys: Authorize transfers from the consortium account. Managing the consortium's fund (distributed at the time of emission, about 10% of the issued token amount) requires at least three representatives, with their keys named CorpKey1, CorpKey2, CorpKey3, also located in text files with .pub and .priv extensions.
Emission Administrator Key: Acts as a third-party observer to the emission process, assisting in modifying certain parameters (among those allowed for changes) such as fees, tips, and token burn rates.
GENERATING YOUR OWN EMISSION KEYS:
To create your emission keys, execute the key generator command for each key type:
dgt keygen --key-dir /project/peer/keys <KEY_NAME>
This command generates a pair of files with ‘.pub’ and ‘.priv’ extensions. For demonstration purposes, we use a single DGT node console. In real business scenarios, keys are created asynchronously by different platform participants. This can be achieved with specified cryptography parameters (e.g., using OpenSSL with agreed-upon cryptographic parameters) or with DGT utilities available for offline use. After generation, the public key values are stored in a configuration file (see below).
DEMONSTRATION SCENARIO:
A typical scenario for demonstrating emission using a single node console is outlined below. In practice, keys are created asynchronously by various platform participants, potentially using specified cryptographic parameters or DGT utilities for offline use. After key generation, public key values are stored in a configuration file for further use.
#
Command
Comments
1.
dgt keygen --key-dir /project/peer/keys ekey1
Creating a Key Pair 1 for Emission
2.
dgt keygen --key-dir /project/peer/keys ekey2
Creating a Key Pair 2 for Emission
3.
dgt keygen --key-dir /project/peer/keys ekey3
Creating a Key Pair 3 for Issuance
4.
dgt keygen --key-dir /project/peer/keys FUND
Creating a Consortium Account
5.
dgt keygen --key-dir /project/peer/keys CorpKey1
Pair 1 for key1 consortium
6.
dgt keygen --key-dir /project/peer/keys CorpKey2
Pair 2 for key2 consortium
7.
dgt keygen --key-dir /project/peer/keys CorpKey3
Pair 3 for key3 consortium
8.
dgt keygen --key-dir /project/peer/keys admin
Pairing an Administrative Key
For each command listed in the table above, a pair of keys is created – files with priv and pub extensions. Inside such files are the keys themselves, which can be viewed by commands, for example:
6.6.2.1.2 STEP 2: Consortium Agreement
Finalize the maximum token supply and distribution parameters with the consortium. You must agree with the consortium (if you are not experimenting alone) on the main parameters of the emission. It's a good idea to create a contract with key parameters, which can be attached with a list of parameters, as defined in the system:
#
Parameter
Default Value
Description
1.
Name
DEC
Name of the Currency/Token
2.
Symbol
"Đ" ([Unicode: U+0110])
Currency Symbol
3.
supply_total
Total Amount of
4.
admin_pub_key
123456
Admin key for initial operations (if no signing keys are specified in the multi-sign part)
5.
wait_to_date
123456
Date from which funds can be distributed
6.
Granularity
0.0001
Minimum fractional part in calculations
7.
Passkey
7
Paraphrase to access modifiable parameters (which include the number of burns – reduction of the amount, commission, and default value of tips).
8.
Link
Link to the tokenomics model (please use you own)
9.
Nominal
0.8
The ratio of the issued token to the base currency (e.g., USD)
10.
nominal_name
USD
Name of the base currency
11.
corporate_account
0xcfa9fe46e0873050b6819651d6cf6fd5b57e6db4965b
Address or public key of the account of the consortium that receives a share of tokens in the common pool for the development of the network (corporate_share parameter)
12.
corporate_share
20%
Number of tokens distributed for the purpose of direct support of the network (consortium)
13.
minting_share
80%
A parameter that determines the share of tokens that are used to support the network through nodes (minting)
14.
mint_param
"Umax" : 10, "B2" : 1, "T1" : 1
Minting Parameters That Define the Finance Distribution Model: Umax, 𝛽2, 𝜏1
15.
nBurn
3
Number of Possible Token Burns (Limited Use)
16.
Fee
1%
Commission for DEC transfer operations (fixed in the network). Subject to change at a later date
17.
Tips
0.01
Additional fee for "expensive" transactions, subject to change later
18.
Account
{"limit" : 10010, "spend_period": 2
Account limits (e.g. amount of one-time spend, minimum period between transactions 2 minutes) – applied in default accounts (can be changed for linked accounts with a notary)
19.
Emission
{"sign_min" : 2,"signers_pub_key" : […]
The minimum number of signatures to be issued, as well as the public keys involved in the signature (the minimum number of keys from the specified number of keys)
Main features of the parameters:
Not only the numerical parameters of the issue have been determined, but also the public keys that will participate in the issuance and subsequent management of the parameters. These keys will be flashed at the time of issuance to the registry and cannot be changed later. However, there is a threshold multi-signature mechanism, where a transaction is signed by all participants, but by a certain minimum number.
The basic parameters are not changeable, while several parameters are changeable (such as commission and reward tips). For this purpose, it is possible to set a special access code (
admin_pub_key), if the field is left blank, these values cannot be changed.
Some parameters may overlap during the release, so the new parameter values are set as keys on the command line, so we skip the step of updating the configuration file to demonstrate.
6.6.2.1.3 STEP 3: Crafting Technical Specifications
After the development of the tokenomics model (there is a standard tokenomics model, see DGT's Tokenomic Model), these parameters are recorded in the technical specification, which is presented in the system in the form of a j-son file: etc/dec/emission.json.
The current emission configuration parameters can be viewed with the standard Linux command:
6.6.2.1.4 STEP 4. Emission Configuration Review and Certification
Once the parameters are saved, the existing configuration and parameters can be checked and certified before the emission is initiated. Viewing is done by the command in the host environment:
For subsequent certification, it is necessary to make sure that there is no already emission in the system. To do this, run the command:
If there is no emission event, the command must return an error (the _DEC_EMISSION_KEY key is missing:
To consolidate the configuration, it is recommended that you certify the existing settings. To do this, you need to use one of the previously created keys, for example, the eKey1 key. The process of certifying, or digitally signing, the emission parameters defined in etc/dec/emission.json involves several steps, utilizing asymmetric keys based on the secp256k1 elliptic curve algorithm. This certification ensures the integrity and authenticity of the emission configuration, making it possible to verify that the file has not been altered since its signing. Here’s how to accomplish this using OpenSSL and keys, such as eKey1, which you've previously generated.
Generating PEM Files from Text Files. First, you need to convert your existing public and private key text files (with ‘.pub’ and ‘.priv’ extensions) into the PEM format recognized by OpenSSL. Assuming you have eKey1.pub and eKey1.priv as your key files:
These commands generate eKey1_private.pem for the private key and eKey1_public.pem for the public key, both in PEM format.
Creating a Digital Signature for emission.json. Using the private PEM file (eKey1_private.pem), you can now create a digital signature for your emission.json file. This signature will later be used to verify the file's integrity and authenticity:
This command employs the SHA-256 algorithm to sign the emission.json file, producing a digital signature in emission.json.sig. The -passin option is used to provide the passphrase for accessing the encrypted private key.
Verifying the Signature. The signature of the emission.json file can be verified using the public PEM file (eKey1_public.pem). This verification process can be executed by anyone possessing the public key to confirm the file's unchanged status post-signature:
A successful verification will prompt OpenSSL to output "Verified OK" signifying the emission.json file's integrity is intact, and it has indeed been signed with the corresponding private key.
6.6.2.2 The Emission Event
6.6.2.2.1 Emission Command
The execution of the emission in distributed ledger technologies, specifically within the Digital Emission Control (DEC) framework, hinges on the deployment of a singular command. This command is replicated asynchronously by multiple participants, each acting independently based on a set of pre-defined parameters. The essence of the emission process is encapsulated in the execution of a specialized command, which looks as follows:
This command is comprehensive, incorporating a substantial array of parameters to fine-tune the emission details precisely. The full command structure, inclusive of all possible parameters, is presented as:
A detailed explanation of each parameter is provided in the subsequent table, ensuring clarity and ease of understanding for all participants involved in the emission process. This structured approach allows for a flexible yet secure method to manage and execute the emission of DEC tokens, making it an integral part of the broader DGT ecosystem:
#
Parameter
Description
1
-h, --help
Display the help message and exit.
2
-v, --verbose
Enable detailed output for additional information.
3
-y, --yaml
Produce the output in YAML format.
4
--check
Preview all parameters for the operation without executing.
5
-cb {openssl,bitcoin}, --crypto_back {openssl,bitcoin}
Choose the cryptographic backend between OpenSSL and Bitcoin.
6
-U URL, --url URL
Specify the URL of the REST API.
7
--wait [WAIT]
Set a duration, in seconds, to wait for the transaction to be confirmed.
8
--tips TIPS
Assign a tip amount for the transaction (incentive for the accepting peer).
9
--access_token ACCESS_TOKEN, -atok ACCESS_TOKEN
Provide an access token for authentication.
10
-V, --version
Show version information of the command or tool.
11
--proto PROTO
Specify a proto file with emission parameters or input JSON directly.
12
--name NAME
Define the name of the token.
13
--total_sum TOTAL_SUM, -ts TOTAL_SUM
Set the total amount of DEC tokens to be emitted.
14
--granularity GRANULARITY, -gran GRANULARITY
Define the granularity of the DEC token.
15
--admin_pub_key ADMIN_PUB_KEY, -apk ADMIN_PUB_KEY
Provide the public key of the admin.
16
--passkey PASSKEY, -pk PASSKEY
Specify a passkey for special operations.
17
--link LINK
Provide a URL for further description.
18
--nominal NOMINAL, -nom NOMINAL
Set the nominal value of the DEC token.
19
--nominal-name NOMINAL_NAME, -nnm NOMINAL_NAME
Specify the nominal name of the DEC token.
20
--corporate_share CORPORATE_SHARE, -cs CORPORATE_SHARE
Determine the share of tokens allocated to the DGT corporation.
21
--minting_share MINTING_SHARE, -ms MINTING_SHARE
Set the share of tokens allocated for node minting.
22
--mint MINT, -m MINT
Configure minting parameters.
23
--mint-umax MINT_UMAX, -mmax MINT_UMAX
Specify the maximum utility parameter for minting.
24
--mint-t1 MINT_T1, -mt1 MINT_T1
Define the T1 parameter for minting.
25
--mint-b2 MINT_B2, -mb2 MINT_B2
Set the B2 parameter for minting.
26
--num_burn NUM_BURN, -nb NUM_BURN
Specify the total number of tokens to be burned.
27
--fee FEE
Set the transaction fee.
28
--corporate_account CORPORATE_ACCOUNT, -ca CORPORATE_ACCOUNT
Specify the DGT corporate account.
29
--corporate_pub_key CORPORATE_PUB_KEY [CORPORATE_PUB_KEY ...], -ck CORPORATE_PUB_KEY [CORPORATE_PUB_KEY ...]
Provide public keys for managing the corporate account.
30
--emiss_signers EMISS_SIGNERS [EMISS_SIGNERS ...], -ems EMISS_SIGNERS [EMISS_SIGNERS ...]
List public keys authorized for emission operations.
31
--emiss_sign_min EMISS_SIGN_MIN, -esm EMISS_SIGN_MIN
Set the minimum number of signers required for emission.
32
--wait_to_date WAIT_TO_DATE, -wtd WAIT_TO_DATE
Schedule a date for the command to become active: birth, mint, change mint.
33
--keyfile KEYFILE
Identify the file containing the user's private key.
34
--info
Display the current status of the emission.
35
--did DID, -d DID
Specify the DID.
36
-tp TYPE, --type TYPE
Define the type of operation or data.
Most of the command parameters are optional. For demonstration purposes, we will issue it based on the previously prepared json parameters, overloading only the keys and the most important parameters.
The issuance of native tokens in DGT is a multi-step procedure using multi-signature, which implies the asynchronous execution of steps by the participants of the process to complete the issue
6.6.2.2.2 Demonstration
The emission process in the DGT system is a structured, multi-step procedure that involves the sequential signing of a transaction by all designated keys. This process is performed asynchronously and distributed, with each participant executing the emission command on their side. An emission is only carried out once the predefined threshold (emission parameters) is met, with the parameters being recorded at the first instance of emission initiation by the first participant.
For demonstration purposes, we assume the following:
· The node is set up, and the DGT service is operational.
· Keys have been generated according to the guidelines described in "Emission Generation."
Note. Emission commands can accept either the direct values of keys or relative paths to the key files, making the commands more concise.
After confirming the presence of keys eKey1, eKey2, eKey3, FUND, CorpKey1, CorpKey2, and CorpKey3, we proceed with the emission, assuming an issuance amount of 10,000,000 DEC tokens.
PARTICIPANT 1: INITIATING THE PROCESS AND SIGNING
The first participant initiates the process and signs with eKey1:).
-apk <ADMIN PRIVATE KEY FILE>
Pointer to the administrative key for executing critical operations
-ca <CORP PUBLIC KEY FILE>
Pointer to the public key for the corporate account (FUND).
-ck <CORP PUB KEY 1> <CORP PUB KEY 2> <CORP PUB KEY 3> …
Pointers to the public key files of the corporation (FOUNDATION): CorpKey1, CorpKey2, CorpKey3.
-ems <EMS PUB KEY 1> <EMS PUB KEY 2> <EMS PUB KEY 3> …
Public keys for multi-signature execution of the emission: eKey1, eKey2, eKey3.
--keyfile <FIRST SIGNER>
The first signer (eKey1); this parameter changes depending on the signer.
--total_sum TOTAL_SUM
Specification of the total amount of issued tokens.
The result of the command execution is shown in the figure below.
Despite the command given, the emission itself was not made, which can be verified by the command:
After the first start, the network generates a special DEC_EMISSION_SIG object, the presence of which can be checked using the:
VERIFICATION AND CONFIRMATION BY PARTICIPANT 2
The second participant (in a real scenario, asymmetrically and independently) repeats the command but signs it with their signature:
Re-verify the emission execution:
The result shows the emission has been executed (reaching the two-signature threshold set in the initial emission example above), with 10,000,000 DEC tokens issued and ready for distribution through other DGT commands and services.
This structured approach ensures transparency and consensus among participants, securing the emission process against unauthorized changes and confirming the collective agreement on the emission parameters.
6.6.2.3 Getting information about emission
Immediately following the emission process, consortium participants and other network observers (all users with access to the commands) can verify the emission data. This includes details such as when the emission took place, the parameters used, and the terms under which it was conducted. The public nature of this information is fundamental and contributes to building trust in the system.
Below are the primary commands for such verification:
Checking the Emitted Amount. To view the total supply of tokens that have been emitted into the system, use:
Verifying All Applied Parameters. For a comprehensive view of the emission parameters that were applied during the emission process, execute:
This command displays all the parameters associated with the specific emission event.
Checking Emission Distribution. To understand how the emitted tokens have been distributed across the system, you can run:
This provides insights into the allocation of the emitted tokens.
Token Information. While the system may host multiple tokens, only one is designated as the native (primary) token. Basic information about this token, as well as others, can be obtained through:
This command fetches and displays basic details about the specified token, including its name and other relevant data.
The availability of these commands ensures transparency and accountability, allowing all network participants to access detailed information about the emission process. This openness is crucial for maintaining the integrity of the system and fostering trust among its users.
Last updated
