2.4 DGT Transactions

2.4.1 Transaction Overview

Transactions, i.e., messages of a certain type form the basis of the DGT platform. Key capabilities in working with transactions include:

  • The platform simultaneously supports several different types of transactions (also called transaction families), each of which has its own content and may have different interpretations.

  • All cluster nodes represent a homogenous space in terms of transaction families (that is, they “can” understand each other).

  • Each transaction has a certain structure, primarily consisting of a header and its signatures, as well as binary payload (the content part of the transaction). The payload is represented by a set of bytes and can only be decrypted by the appropriate transaction processor.

  • The transaction header is a general description of the transaction itself, the address (from and to whom it was sent), etc.

  • During processing, transactions are combined into batches. Handlers are attached to batches to speed up their processing and optimize forwarding under heavy load.

  • Transactions can be correct or incorrect (tampered with by accident or intentionally). To ensure a single version of the “truth”, transactions are verified (via checklist) and validated (checked for inconsistencies in terms of data within the ledger, including the correctness of the signature). The verification process is essentially “voting” for a transaction.

  • Transactions may depend on other transactions, that is, a dependent transaction cannot be applied before the transaction on which it depends.

  • Transaction input and output fields contain state addresses. The scheduler determines implicit dependencies between transactions based on interaction with a state. Addresses may be fully qualified end node addresses or partial prefix addresses.

  • Input addresses are read from the state, while output addresses are written into the state. Even though they are specified by the client, the input and output declarations of a transaction are applied during its execution. Partial addresses work like wildcards and allow transactions to specify parts of the tree, not just end nodes.

  • To optimize transaction processing, the headers also contain a Nonce field - with a random string generated by the client. When given a nonce, if two transactions otherwise contain the same fields, the nonce ensures that they will generate different header signatures.

../_images/figure_46.png

The image below presents a transaction of the BGT family (see 3.6) in JSON format:

../_images/figure_47.png

2.4.2 Transaction Process

The basic version of DGT (DGT.CORE) supports only the basic transactions, the functionality of which is carried out in the so-called transaction processor. Initial transactions are reduced to the formation and recording of transactions in the ledger, processing their signatures, and basic voting on them. The central component of the system is the Journal module, which is responsible for managing transactions at the node level.

../_images/figure_48.png

When receiving transactions, the validator (the main node component responsible for inserting and storing transactions, as well as communicating with other nodes) interacts with the dedicated Transaction Processor component, which is a service for processing distinct transaction families.

../_images/figure_49.png

When calling the transaction processor, the validator (node core) uses the following standard methods:

  • Register - processor registration.

  • Apply - transaction execution method.

  • Get/Set - getting the transaction result.

2.4.3 Transaction Families

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 DGTKey)

  • A set of bytes to execute smart contracts

../_images/figure_50.png

DGT Core (the basic version of the platform) supports basic transactions: DGTSettings, XCert, BGT. See detailed description of transactions in 3.6. The DGT Garanaska version is an extended version of the platform and includes the transactions described in the table below:

../_images/table_9_04.PNG

2.4.4 Transaction Receipts

Transaction receipts are transaction information that is not directly stored in state, but aggregates the data generated by transaction processing events:

  • Was the transaction accepted by the network, i.e., is it valid?

  • How did the transaction change the ledger?

  • Additional events that occurred during the execution of the transaction.

  • Other transaction execution information related to the transaction family.

This information is provided in protobuf format and contains a list of messages set by the transaction family. Receipts are stored in the TransactionReceiptStore storage, interaction with which is provided by the validator mechanisms (Node Validator). Receiving a receipt is possible through the API using a 128-character transaction ID.