3.9.1 Presentation Layer

Following the architecture outlined above, the presentation layer addresses the end users to present transactions and information about the results of storing data in the ledger.

Implementation features of the DGT platform presentation layer:

• Each client interacts with a certain node through an API layer that the node is equipped with (the Primary Node in terms of roles)

• The functionality of the client is the creation and signing of a transaction or receiving data on already executed transactions. The DGT platform works asynchronously, so some time elapses between the information being sent to the node and receiving data about the acceptance of this transaction (insertion into the ledger). The transaction may also be rejected because of consensus and fall into the set of “lost” transactions.

• The clients may contain additional business logic, including back-end support outside of the DGT platform, or even have a server-side for third-party clients.

• The Validator (the actual core of the node) is the node’s main component in the context of service architecture, while such components as REST-API, CLI, and DASHBOARD are clients that coordinate with the Validator in a unified way.

• It is necessary to distinguish between read transactions (lighter transactions, mostly open ones – without authentication requirements, except for certain special transactions associated with notary node services) and write transactions (heavier transactions that require a digital signature and possibly additional links to decentralized identifiers – DID).

• The basic functionality of the platform (mainly represented by the CORE version) consists of storing and processing transactions of a general kind. Specifying transactions and implementing additional business logic falls on transaction processors: families of transactions. Such families may have functionality connected with token processing or saving key-value data (see 3.4.4). Depending on such functionality, the appearance and behavior of clients will differ. For example, a Wallet client for the DEC family might allow you to do the following:

  • Create and manage decentralized identifiers.

  • Create and manage accounts, including public-private key pairs.

  • Receive and transfer DEC tokens between network clients (known account)

  • Register new digital objects onto the network and confirm their attributes through notary node services.

  • Create and exchange secondary tokens for native DEC, as well as buy and sell digital objects previously registered on the network.

• Development and implementation of clients are possible using Sawtooth SDK or without SDK if adhering to the overall application architecture.