Transaction Life Cycle

High-level Overview

Understanding the Transaction Lifecycle in IOTA

The IOTA transaction lifecycle outlines the journey of a transaction from its creation by a user to its final settlement and recording on the ledger. This process involves client applications, full nodes, and validators, ensuring secure and consistent state transitions across the network.

1. Make Transaction

A user or smart contract initiates a transaction through a wallet or application. This transaction can affect objects owned exclusively by the user (owned objects) or objects that multiple users can interact with (shared objects). The transaction typically includes:

• Sender and recipient addresses

• Value or assets to transfer

• Timestamp and nonce

• Digital signature (using the user's private key)

The wallet application signs the transaction with the user's private key, ensuring its authenticity and integrity.

2. Process Transaction

Once created and signed, the transaction is submitted to a full node. The full node performs an initial validation of the transaction structure and checks for sufficient account balance. It then distributes the transaction to validators in the network.

Validators independently verify the transaction's validity. If deemed valid, they sign it and return the signed transaction to the full node.

3. Assemble Certificate

After collecting signed responses from a supermajority of validators, the client assembles these responses into a transaction certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality.. This step is crucial as it ensures that the transaction has been pre-approved by a sufficient number of validators before proceeding to consensus. Unlike traditional consensus-based blockchains, the client or gateway is responsible for propagating signatures and aggregating certificates, reducing the burden on validators.

The client sends the assembled certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality. back to all validators. Upon receipt, validators verify the certificate's integrity and acknowledge its receipt. They then forward the certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality. to the IOTA DAG-based consensus protocol.

If the transaction involves only owned objects, IOTA can process and execute it immediately without waiting for global consensus, leveraging fast path consensus.

4. Sequence

All certificates, regardless of whether they involve owned or shared objects, are forwarded to the IOTA DAG-based consensus protocol. This protocol eventually produces a total order of certificates. Validators then verify and execute transactions that involve shared objects, ensuring deterministic and consistent state transitions across all nodes.

5. Process Certificate

Certified transactions are then sent to validators for execution. Validators verify the certificate signatures to ensure the transaction is valid and not attempting to double-spend.

Depending on whether the transaction uses shared input objects, the validators will either:

• Execute it immediately if no shared objects are involved.
• Submit it to IOTA's consensus layer to order the transaction with others if shared objects are involved, and then execute it.

This ensures that transactions involving shared objects are consistently ordered across validators, preventing conflicts.

6. Assemble Effect Certificate

After the transaction has been executed, clients can gather responses from a supermajority of validators again. These responses are then assembled into an effect certificateA certificate is the mechanism proving a transaction was approved or certified. Validators vote on transactions, and aggregators collect a Byzantine-resistant majority of these votes into a certificate and broadcasts it to all IOTA validators, thereby ensuring finality.. This certificate serves as proof that the transaction has been fully executed, providing evidence of settlement finality and a guarantee that the transaction will be recorded in a checkpoint.

7. Checkpoint Certificate

IOTA periodically creates checkpoints during consensus commits. These checkpoints record the finalized transaction state, providing a stable point of reference. They are also used to drive the validator reconfiguration protocol, supporting epoch transitions and validator set changes.

Epoch Transitions and Their Impact

The IOTA network undergoes epoch transitions, which can affect how transactions are handled. Near epoch boundaries, transactions might occasionally need to be resubmitted. Generally, full nodes handle resubmission, though some client applications may automate this process. As a best practice, it's advisable to avoid submitting time-sensitive transactions immediately before epoch transitions.

Verifying Finality

If your wallet app crashes during a transaction, it stores the signed transaction locally. Upon restarting, it will verify if the transaction was finalized. If finalized, no further steps are required. If not, the app will need to resubmit the transaction.

The wallet app can query the full node with the getTransactionBlock method to check if the transaction is finalized. If the response contains transaction details, it is finalized. If the response is None, the transaction may need to be resubmitted. This ensures that the coffee shop's full node will eventually recognize the transaction once it's included in a checkpoint and update the coffee shop's balance.