Data Structures Explained: The Parts that Make the Tangle

IOTA 2.0 Introduction Part 4

TL;DR:
Blocks and payloads are two of the most important data structures in IOTA. Blocks serve as containers for data in the network and contain various information, including protocol versions, parent block IDs, and issuer ID. Blocks are categorized according to time slots, and slot commitments ensure agreement among nodes. Validation blocks help determine block confirmation and finality. Blocks carry payloads, including transactions and tagged data, allowing for simple-to-implement and expandable applications.

The IOTA protocol is composed of several structures, which we can think of as simple, solid, indivisible structures, just like an atom. In this blog post, we’ll break down the IOTA atoms to see what they look like inside and how they help IOTA operate!

In our previous blog post, Data Flow: How Nodes Process Blocks, we saw how nodes work at processing blocks; now we want to see how the other structures of IOTA 2.0, namely blocks, slot commitments, and payloads, are made and why they’re so relevant! As always, for a more detailed look, we refer you to our Wiki article on Data Structures.

The Anatomy of a Block

The most prominent unit of information in the IOTA 2.0 protocol, the block is a container for a collection of data to be stored in the network. To spread this data among all network participants, blocks are gossiped by nodes, making this data eventually available to every node on the Network Layer.

Aside from the data it contains (which we call “payload”) a block also contains important information that helps keep the protocol functioning. Let’s take a look at the main pieces of information inside a block:

Protocol Version: This allows nodes to apply the correct protocol rules to the blocks, especially after a protocol update is introduced.
Parents: A list of past blocks that are strongly or weakly approved or are directly referenced to adjust opinions (these are called “Shallow Like Parents”).
Issuer ID: The ID of the node that created the block.
Issuing Time: The time the block is issued, commonly referred to as the Timestamp.
Slot Commitment: A slot commitment is a cryptographic summary of a slot (more on slot commitments below).
Signature: The signature of the issuer.

The block ID is then generated by a hashing process involving the data contained in the block.

Slots and Slot Commitments

Slots divide the timeline into segments that categorize blocks. Each slot is uniquely indexed, and since each slot's duration is fixed, it is straightforward to determine which slot a block belongs to based on its timestamp.

Because of filters within the Parser (explained in detail in the previous blog post in this series, Data Flow Explained: How Nodes Process Blocks), blocks can only be added to slots within a specific timeframe. It's important to note that a block's timestamp reflects when it was issued, so even if it arrives later, it can still be added to a slot as long as it's not too delayed. This process ensures that, over time, nodes that receive identical information will share the same understanding of which blocks have been accepted for a particular slot. Reaching a consensus on this list of blocks through comparison is a vital aspect of the consensus process. To facilitate this, nodes create what we refer to as "slot commitments”.

Slot commitments act as cryptographic records of slot contents. Each block includes a commitment to a past slot, so that it is always possible to check which blocks a certain node has knowledge of.

Moreover, each slot commitment carries information about the commitment of the preceding slot, forming a tree of commitments. In cases where commitment chains diverge due to a fork, nodes will follow the chain generated by nodes with the largest voting power. More insight into tracking slot commitment chains and selecting the heaviest one is available in Part 6, A New Consensus Model.

Validation Blocks

Validation blocks determine the confirmation and finality status of other blocks. Because of their importance, they are exempt from the standard congestion control mechanism (you can see more on this in "Understanding Congestion Control", to be published on October 23rd). As a result, any level of congestion will never bring the validation process to a halt.

In terms of structure, validation blocks mirror regular blocks but with a key distinction: they can only contain a minimal amount of data. This ensures they can’t accommodate transactions or other payloads. This limitation also ensures that no committee member can exploit the validation block to gain free throughput. Identifying these blocks is straightforward, as the validator's committee information is publicly available (refer to A New Consensus Model for additional insights).

Payloads: Transactions and Tagged Data

Payloads are data packages contained in all IOTA blocks that aren’t validation blocks. They are used to execute transactions and run applications on the Tangle. IOTA’s simple payload model is designed to be easy for developers to use and adaptable to new technologies. Each payload includes a header specifying its payload type, enabling easy identification through processing. At launch, IOTA 2.0 will support two major kinds of payloads: Transactions and Tagged Data.

Tagged Data is a generic data payload with a customizable tag field that can be used as an identifier for applications or any other use that the issuer requires. Essentially, the tagged data payload is composed of three fields: identifier (header), tag, and data.

Transactions, on the other hand, are payloads used for value transfer, which is the most used and supported application among users. A transaction contains the transaction identifier (header) and the Transaction Essence, which is the main data field for transactions and contains all necessary information for secure writing to the ledger. This information includes:

Network ID: Identifies if the transaction should be used on the mainnet, testnet, Shimmer, or a private network.
Creation Slot Index: The index of the slot at which the transaction is included.
Input List: List of all UTXOs to be consumed by the transaction.
Output List: List of all UTXOs to be generated by the transaction.
Extra Payload: Possibly a tagged data payload that is included in the transaction.

Largely due to its ability to consume and create UTXOs and consequently modify the IOTA Ledger, transactions are the most complex type of payload.

This completes our journey inside the structure of the main elements of the IOTA 2.0 protocol. With this in mind, we can better understand the functionality of other modules of the protocol and grasp why the Tangle is the ideal platform for the future of DLT applications!

Again, a more detailed look at data structures in IOTA 2.0 can be found in the Wiki article. In the next part of this blog post series, we explain accounts, tokens, Mana, and staking.

Join the conversation on X

🌐 Want an even more detailed look into #IOTA 2.0's #DataStructures - their descriptions, attributes and rules? This wiki article has you covered. 🔗https://t.co/qhrGY3yH54
— IOTA (@iota) October 12, 2023