# 1.3.3 Transactions

Transactions in blockchain networks differ from their counterparts in traditional databases. Rather than representing data operations, transactions serve as messages exchanged between nodes and consist of a header and a body (content). These transactions utilize special addresses derived from public keys and are signed using a public-private key pair, ensuring their authenticity and integrity.

In classical blockchain systems, transactions are typically transparent, revealing information such as the sender, recipient, and transaction amount. However, advancements like Zero-Knowledge Proofs (ZKP) enable the concealment of transaction addresses, enhancing privacy. It is important to note that transactions in blockchain networks are asynchronous, meaning that sending a transaction does not guarantee its immediate acceptance by the network.

The general mechanism of transaction processing within a blockchain involves the following steps:

* **Transaction Creation**: Participants initiate transactions by composing them using the appropriate transaction format for the specific blockchain network. These transactions typically include information such as the sender, recipient, transaction amount, and any additional data required by the network.
* **Transaction Broadcasting**: Once created, transactions are broadcasted to the network. They are propagated across nodes in a peer-to-peer fashion, ensuring widespread dissemination.
* **Transaction Validation**: Each participating node validates the received transactions according to the predefined rules and consensus mechanism of the blockchain network. This validation process ensures that transactions adhere to the network's protocol and criteria for inclusion in a block.
* **Block Formation**: Validated transactions are collected by network participants into blocks. A block is a container that can hold multiple transactions. Blocks also contain a header that includes metadata such as a timestamp, a reference to the previous block, and a unique identifier.
* **Block Validation**: Once a block is formed, it undergoes validation by network nodes. The validation process ensures that the block satisfies the consensus rules, maintains integrity, and adheres to the network's protocol. The consensus mechanism, such as Proof of Work (PoW) or Proof of Stake (PoS), is employed to reach an agreement on the validity of the block.
* **Block Addition**: Upon successful validation, the block is added to the blockchain. It becomes a permanent part of the distributed ledger, creating an immutable record of the included transactions. The new block's reference is stored in the subsequent block's header, forming a chronological chain.

During the transaction processing phase, several important characteristics come into play. The speed of transactions, often measured in _Transactions Per Second_ (TPS), determines the network's throughput. Latency refers to the time it takes for a transaction to be confirmed and added to the blockchain. _Finality_ indicates the irreversibility of a transaction once it is confirmed and included in a block.

_Communication complexity_ refers to the amount of network communication required for reaching a consensus. It is influenced by the consensus mechanism's design and the number of messages exchanged among network participants. Some consensus mechanisms, such as PoW or PoS, require extensive communication between nodes to propagate transactions and reach an agreement on block creation. This can result in higher communication complexity and increased network overhead. In contrast, consensus mechanisms like PBFT or Raft focus on reducing communication complexity by employing a leader-based approach, where a subset of nodes is responsible for proposing and validating blocks. This can result in lower communication overhead, allowing for faster consensus and improved network efficiency.

In the context of _smart transactions_, some blockchain networks allow for the inclusion of additional attributes or metadata in transactions. These smart transactions can have configurable properties, such as setting transaction priority, which affects their preference for inclusion in blocks. By assigning priority to transactions, participants can influence their position in the order of block inclusion, potentially expediting their processing.

Regarding the DGT network, it employs a similar approach to transaction processing as seen in the Sawtooth framework. In this system, separate transaction processors handle specific types of transactions. Each transaction processor specializes in processing a particular transaction type, executing the necessary logic, and updating the state of the blockchain accordingly. This modular architecture allows for efficient and scalable transaction processing in the DGT network, ensuring that different transaction types can be handled by dedicated processors to enhance overall network performance and flexibility.
