The basic unit of information in the IOTA 2.0 protocol is an object called a message which are gossiped through the network containing data and transactions. Together, messages form the tangle, central data structure of the IOTA protocol. Each message has several parts, including a header, payload, and signature.
The header of the message contains the essential information required for a node to process a message. Specifically this includes:
- Version number: the IOTA protocol will be ever evolving and improving, and thus will be subject to a strict versioning system to manage updates.
- Parents: Nodes will contain the hash of several other messages called parents, endowing the tangle with a DAG structure. Each message will have between 2 and 8 parents.
- Timestamp: This field indicates the approximate time that the message was issued, and will be unfalsifiable: see here for more information.
- Issuing node ID: Each message contains the public key of the issuing node, which will allow the congestion control algorithm to determine when it should be gossiped.
- Each message contains a nonce, which is the solution to the cryptographic adaptive PoW puzzle.
The payload is where the message stores the actual content, whether it be a transaction or data. Payloads have types, and different types of payloads are parsed in different ways. For example, transaction is the most important payload type which transfers the IOTA token. Any application can define their own custom data payloads which would allow that application to interact with the tangle.
Each message is concluded with a signature of the node whose ID is listed in the header. The signature signs the entire message, including the payload, which makes the contents of the message unalterable.
We now list the layout of the most important payload type: transactions. Each transaction contains the following fields:
- A list of the UTXO inputs which hold the funds the transaction is spending.
- A list of new UTXO outputs that will be the inputs for future to spend.
- The node IDS which will receive the Access and Consensus mana generated by the transaction
- A payload: this field can also contain data which can be used by various applications. For example, smart contract commands and updates will appear as payloads of transactions.
- The signature from the owners of the funds in the inputs of the transaction.