3.5.3 Transaction and block signing

DGT employs a robust transaction and block validation process to ensure the integrity and consistency of data within the network. The following describes the transaction and block validation mechanism in DGT:

• Transactions in DGT are received from clients as a batch list. A batch can contain one or more transactions that are processed as a single atomic unit. To prevent unauthorized modification of transaction payload data, the client computes the SHA-512 digest and includes it in the transaction header. This digest acts as a cryptographic checksum, ensuring the integrity of the payload data. Each transaction header also contains a unique nonce value generated by the client, preventing the reproduction of the transaction.

• The client signs the transaction header and includes the public signing key in the header. Additionally, each package within the transaction is signed, and the public key of the package signer is included in the package header. The signer of the batch service and the signer of the transaction may or may not be the same person. Including the package signer's public key in the transaction, header prevents the transaction from being repackaged into another package. The transaction signing key and batch signature public key in the transaction and batch headers, respectively, allow users to identify signers and verify signatures.

• The DGT validator node takes the received transactions and creates proposed blocks. These proposed blocks are signed by the validator node using the ECDSA secp256k1 curve, the same algorithm used for signing transactions and packages. The validator node then transmits these blocks to peers within the DGT network.

• Peers in the DGT network, specifically the validator peers, verify the candidate blocks proposed by the validator node. This verification process includes validating the signatures of the block, packets, and transactions. The presence of digests and signatures ensures the immutability of payload data and prevents unauthorized deletion, reordering, or duplication of transactions within a block or on the blockchain.

Step	Description
Key Generation	Generate a private key and corresponding public key for cryptographic operations.
Calculate Address	Calculate a unique address for each transaction family based on relevant parameters.
Creating a Transaction	Create the payload for the transaction. Serialize the transaction using Protocol Buffers. Calculate the digest of the serialized payload. Generate a nonce for uniqueness. Sign the transaction header with the private key and include the public key.
Creating a Transaction Batch	Add the transaction to a batch. Create a batch header with metadata and a list of transaction IDs. Sign the batch header with the private key and include the public key.
Sending the Batch	Send the prepared batch, including the batch header, signatures, and transactions, via the REST API.
Form Block Proposal	Collect a set of valid transactions for the proposed block. Aggregate the transactions, including headers and payloads, to form the block proposal.
Sign Block Proposal	Sign the block header with the private key. Include the block signature, along with the public key, in the block proposal.

By employing these transaction and block validation mechanisms, as well as the block-based and DAG-based storage approaches, DGT ensures the integrity, consistency, and efficiency of its data processing and storage within the network.

Figure 39 Transaction Path