3.5.4 Transaction Families
Last updated
Last updated
Transaction Families allow for processing various information flows within the DGT Network using an extensible system by connecting transaction processors that play the role of smart contracts.
The family of transactions is implemented by connecting special services (via INTERCONNECT) called Transaction Processors. Transaction processors encapsulate the business-logic embedded within the transactions. Some examples of transactions include:
Storage of settings and topology support (the DGTSettings family)
Token management (e-transfers of money from account to account)
Certificate management (XCert)
Test transactions (BGT)
Key-value storage management (see DKey)
A set of bytes to execute smart contracts.
Processing transactions, as well as packing them into blocks, requires the coordinated operation of several components, the central of which is the Journal Engine:
DGT Core (the basic version of the platform) supports basic transactions: DGTSettings, XCert, and BGT. See the detailed description of transactions in Chapter 4. The DGT Garanaska version is an extended version of the platform and includes the transactions described in the table below:
#
Family
Description
Functional
1
DEC (ĐT)
This family is the main one and is responsible for the circulation of the native currency, including the emission, the minting mechanism, the transfer of tokens, and the exchange of secondary tokens and digital objects for the native tokens.
Other families are implemented only to support this family.
The system needs its own addressing system based on the {priv_key, pub_key}. The corresponding account address is calculated using the public key (the algorithm must be agreed upon).
The system will allow for two versions of the ledger: the real one and a test one (like TESTNET Ropsten for Ethereum).
Within this family, other information written by other families into the ledger may be read.
EMISSION – a group of commands that supports the issuance of tokens (one-time action), as well as the issuance of information about the current state of DEC, and one-time transactions (such as the distribution of the amount between participants, except for minting)
MINTING – a group of commands related to the receipt of tokens by nodes in exchange for their support for transactions and other SLAs.
BANK – a group of commands that support transactions for sending tokens between accounts, displaying a receipt for the finished transactions (status), and receiving a balance for one account or a group of accounts.
ORGANIZATION – issuance of secondary tokens.
2
DID
A family of transactions (possibly a subsystem that contains additional services) that provide the role model of the end user – registering his ID, saving, and checking VC (Verifiable Credentials), and issuing flags that will determine the user type.
Creation and revocation of decentralized DID identifiers and DID documents.
Creation (writing) of the corresponding DID artifact – VC (lies outside of the family of transactions itself, listed here only for completeness).
Mapping for a role and capability checks for a given DID.
3
DKEY
A family of transactions that allows you to store key-value properties for some object (associated with an identifier)
Key-value entry for a given object (identifier).
Finding all key-value pairs for a given ID.
Revoking (invalidating) a given key-value pair.
Selection for a given object and a given key of its value.
4
XCERT
Family for working with certificates (currently it already supports some commands but needs to be extended).
General XCERT capabilities, as well as:
The ability to save a certificate in the notary’s storage.
Checking the certificate with a notary.
Certificate revocation.