Data Structures

Unpublished tips

This page contains references to Tangle Improvement Proposals (TIPs) that are still not published! This includes TIP-0040, TIP-0041,TIP-0042, TIP-0043,TIP-0044, TIP-0045 and TIP-0046. You can check the list of all available TIPs here!

The Tangle

The Tangle is a data structureA data structure is a way of organizing data so that it can be efficiently and effectively used. The Tangle uses a variety of data structures, including blocks, payloads, transactions, and commitments, to store and process data. replicated across a decentralized network of computers, also called "nodes." It is a robust foundation for tracking token ownership and offers several unique features. At its core, the Tangle forms a directed acyclic graph (DAG) of blocks, creating a block-DAG architecture. In this structure, newer blocks are intricately attached to multiple older ones, resulting in a highly interconnected data structure.

Image 1: The Tangle.

One of the key functionalities of the Tangle is to ensure the immutability of the data stored in it. By leveraging its distributed nature, the Tangle provides a resilient and tamper-proof environment for data integrityAssurance that the data stored in the ledger has not been tampered with or altered in any unauthorized way.. This means that once information is added to the Tangle, it becomes nearly impossible to alter or manipulate, enhancing the system's trustworthiness. Given that the Tangle is a replicated or distributed data structure, nodes have to reach a consensus on the content of the Tangle.

The Tangle Versus Blockchains

While the Tangle and blockchains have the same function of maintaining their ledger stateThe collective state of the network"s unspent outputs, maintained by the Application Layer and used for consensus., the Tangle overcomes some of the difficulties blockchains face. Unlike blockchains, where only a single node can append a new block to the ledger at a time, the Tangle allows all participating nodes to write to the ledger in parallel. This is achieved through a DAG structure, which allows transactions to be processed simultaneously and independently of each other.

Blockchains

A traditional blockchain consists of a growing list of records called blocks linked together as a chain using cryptography. Transactions can only become part of the ledger if they are included in a newly issued block. If all new transactions don’t fit into one block, some must be postponed to the following blocks.

Block producers typically favor including transactions from users willing to pay higher fees. Accelerating block creation or increasing block sizes doesn't solve the issues, as it is well known that this would compromise safety. In other words, to guarantee the security of the system, the throughputThe rate or capacity at which transactions or data can be processed or transmitted within a given timeframe by the network. of the system must be artificially suppressed so that each block propagates fully before the next block is created.

Image 2: Overcoming the blockchain bottleneck.

The Tangle

The Tangle is a leaderless, probabilistic consensus protocol that enables parallel validation of transactions without requiring total ordering. It also eliminates the need for intermediary miners or validators in block creation, allowing all participating nodes to write to the ledger. This removes the need for additional mempools, and the Tangle itself is often seen as a distributed mempool. However, consensusAgreement between nodes on the inclusion of blocks in the Tangle and validation of transactions. on the state of the ledger is achieved through a committee-based selection process, which ensures low confirmationThe stages for a block (transaction) to be secured are Pre-Acceptance, Acceptance, Pre-Confirmation, Confirmation, and Slot Finalization. Pre-acceptance (pre-confirmation) requires approval by an online (total) supermajority of the validator committee. Acceptance (confirmation) requires approval by an online (total) supermajority of pre-accepted (pre-confirmed) blocks. Slot Finalization requires Confirmation of a block that includes the corresponding slot commitment. times.

The Blocks

The basic unit of information in the IOTA 2.0 protocol is called a blockData objects processed by nodes: they contain single transactions. A block is composed of 1) block header (auxiliary information to identify the block); 2) transaction/data; 3) signature., which serves as a container for a collection of data stored in the network.

Blocks are gossiped between nodes. They communicate payloads and the nodes' opinions about them. Payloads can be many things, including token transactions, generic data payloads, or other specific data required by various applications.

Since blocks refer to previous blocks through a list of references, the collection of all blocks forms a directed acyclic graph (DAG), which we at the IOTA Foundation call the Tangle. This structure replaces a linear blockchain since contained blocks are not totally ordered.

The issuer is the entity that creates the block and is identified through a public key. Issuers are different from nodes, which form the network. A node supplies the issuer with tips (unreferenced blocks) to attach to their block and submit any issued block to the network. Wallets provide issuers with the means to issue payloads such as transactions.

Nodes, issuers, and wallets are three separate roles. However, they can be run on different or the same machines. For example, a user can have an issuer built into their wallet, communicating with nodes via an API. Alternatively, an issuer could be a plugin into a node.

Block Layout

The block layout in the IOTA protocol consists of a block headerThe block header is all of the fields in the block wrapper except for the block and signature , content, and signature. The block headerThe block header is all of the fields in the block wrapper except for the block and signature contains metadata about the block. The content contains the references, aka parentsA message can directly reference up to 8 preceding messages, known as its parents. In IOTA 2.0, a parent might be either strong or weak (see approval switch)., and the signature is used to verify the authenticity of the block headerThe block header is all of the fields in the block wrapper except for the block and signature and block content.

There are two types of blocks: Basic Blocks and Validation Blocks. A Basic Block can contain different types of payloads, which are processed by all nodes as part of the IOTA protocol. Validation Blocks have additional functionality and different fields, validation rules, and allowed payloads and are only issued by the current validatorA validator is a participant in a Proof of Stake (PoS) network that stake their tokens in order to validate transactions and blocks and maintain the security of the DLT/blockchain. nodes.

Image 3: The anatomy of a block.

Block Header and Block Wrapper

The two block types share certain fields, which are contained in an outer wrapper. This Block WrapperThe block wrapper is additional data around the typical blocks giving important metadata, including the version, time, and block issuer. This metadata allows nodes to follow the right version of the Tangle, to verify the timestamp of blocks, and to identify the creator of each block. is a way to deduplicate the definition of those fields. It is not a standalone block type.

All fields of a Block WrapperThe block wrapper is additional data around the typical blocks giving important metadata, including the version, time, and block issuer. This metadata allows nodes to follow the right version of the Tangle, to verify the timestamp of blocks, and to identify the creator of each block. except for the BlockData objects processed by nodes: they contain single transactions. A block is composed of 1) block header (auxiliary information to identify the block); 2) transaction/data; 3) signature. and Signature constitute the Block HeaderThe block header is all of the fields in the block wrapper except for the block and signature.

The Block WrapperThe block wrapper is additional data around the typical blocks giving important metadata, including the version, time, and block issuer. This metadata allows nodes to follow the right version of the Tangle, to verify the timestamp of blocks, and to identify the creator of each block. is serialized as follows:

Name	Type	Description
Protocol Version	uint8	This field denotes what protocol rules apply to the block.
Network ID	uint64	The network identifier.
Issuing Time	uint64	The time at which the block was issued. It is a Unix timestamp in nanoseconds.
Slot Commitment ID	ByteArray[40]	The identifier of the _slot_ this block commits to.
Latest Finalized Slot	uint64	The of the latest finalized slot.
Issuer ID	ByteArray[32]	The identifier of the account that issued this block.
Block oneOf	Basic Block A Basic Block. More details in the Basic Block section. Validation Block A Validation Block. More details in the Validation Block section.
Signature oneOf	Ed25519 Signature An Ed25519 Signature. More details in the Signature section.

Basic Block

Serialized Layout

The serialized layout of a Basic Block is that of a Block WrapperThe block wrapper is additional data around the typical blocks giving important metadata, including the version, time, and block issuer. This metadata allows nodes to follow the right version of the Tangle, to verify the timestamp of blocks, and to identify the creator of each block. with the BlockData objects processed by nodes: they contain single transactions. A block is composed of 1) block header (auxiliary information to identify the block); 2) transaction/data; 3) signature. field containing the following layout:

Name	Type	Description
Type	uint8	Set to value 0 to denote a Basic Block.
Strong Parents Count	uint8	The number of blocks that are strongly directly approved.
Strong Parents anyOf	Parent References another directly approved block. Name Type Description Block ID ByteArray[40] The Block ID of the strong parent.
Weak Parents Count	uint8	The number of blocks that are weakly directly approved.
Weak Parents optAnyOf	Parent References another directly approved block. Name Type Description Block ID ByteArray[40] The Block ID of the parent.
Shallow Like Parents Count	uint8	The number of blocks that are directly referenced to adjust opinion.
Shallow Like Parents optAnyOf	Parent Name Type Description Block ID ByteArray[40] The Block ID of the parent.
Payload Length	uint32	The length of the following payload in bytes. A length of 0 means no payload will be attached.
Payload optOneOf	Tagged Data Payload With Payload Type 5, more details are described in Tagged Data Payload section. Transaction Payload With Payload Type 6, more details are described in Transaction section.
Burned Mana	uint64	The amount of _Mana_ the Account identified by Issuer ID is at most willing to burn for this block.

Validation Block

A Validation Block is a special block used by validators to secure the network. It is recognized by the Congestion Control of the IOTA 2.0 protocol and can be issued without burning ManaA reward resource generated by holding IOTA tokens. It is utilized for block issuance, access to network throughput, and protecting against Sybil attacks. within the constraints of the allowed validator throughputThe rate or capacity at which transactions or data can be processed or transmitted within a given timeframe by the network.. It is allowed to reference more parent blocksBlocks that a particular block in the Tangle references as its predecessors. than a normal Basic Block.

Serialized Layout

The serialized layout of a Validation Block is that of a Block WrapperThe block wrapper is additional data around the typical blocks giving important metadata, including the version, time, and block issuer. This metadata allows nodes to follow the right version of the Tangle, to verify the timestamp of blocks, and to identify the creator of each block. with the BlockData objects processed by nodes: they contain single transactions. A block is composed of 1) block header (auxiliary information to identify the block); 2) transaction/data; 3) signature. field containing the following layout:

Name	Type	Description
Type	uint8	Set to value 1 to denote a Validation Block.
Strong Parents Count	uint8	The number of blocks that are strongly directly approved.
Strong Parents anyOf	Parent References another directly approved block. Name Type Description Block ID ByteArray[40] The Block ID of the strong parent.
Weak Parents Count	uint8	The number of blocks that are weakly directly approved.
Weak Parents anyOf	Parent References another directly approved block. Name Type Description Block ID ByteArray[40] The Block ID of the parent.
Shallow Like Parents Count	uint8	The number of blocks that are directly referenced to adjust opinion.
Shallow Like Parents anyOf	Parent Name Type Description Block ID ByteArray[40] The Block ID of the parent.
Highest Supported Version	uint8	The highest supported protocol version the issuer of this block supports.
Protocol Parameters Hash	ByteArray[32]	The hash of the protocol parameters for the Highest Supported Version.

Block Content

In this section, you can find a brief overview of the content of the blocks described above.

Strong, Weak, Shallow Like Parents

Each new block references several previous blocks, also called parents of the new block. The IOTA protocol has three references or parent types; they are crucial for the consensus protocol and are described in detail in the section.

Slot Index

The timeline within the system is partitioned into slots, and each slot is associated with a unique slot index. To determine the slot index of a given timestamp, the calculation requires the genesisUnixTime (the starting point of the timeline) as well as the slotDurationSeconds, of each slot: The slot index of timestamp ts is floor((ts - genesisUnixTime)/slotDurationSeconds) + 1.

Slot Commitment

Slot Commitment is an object that commits a summary of a slot, and it is linked to the commitment of the previous slot, which forms a commitment chain. The slot commitment mechanism shows the divergencies between local versions of the Tangle and the ledger of each node by creating forks in the commitment chains. Together with the Chain switching mechanism, it helps in maintaining the common perception among the nodes.

note

Slot Commitment and Commitment may be used interchangeably.

Each block is obliged to include a new Slot Commitment ID that consists of the Slot Commitment that contains the Merkle tree root of Merkle trees created for the following data structures and more information about the committed slot as shown in the following graphic:

Image 5: Slot commitment.

Therefore, each commitment should contain the following:

• Protocol Version: The Version of the used protocol.
• Slot index: The index of the comitted slot.
• Previous Slot Commitment: The previous Slot Commitment ID creating the Slot Commitment Chain.
• Commitment of Slot Content: The Merkle tree root of Merkle trees.
• Cumulative Weight: The Cumulative WeightA system for valuing transactions. The cumulative weight of a transaction increases with each additional transaction that references it. A path through transactions with a higher cumulative weight is preferred when selecting tips. of the Slot Commitment Chain.
• Reference Mana Cost: The reference mana cost of this slot.

The Commitment of Slot Content is divided into:

• Tangle Root: The hash root of a sparse Merkle tree that contains all accepted blocks issued within the slot. This serves as a statement of accepted blocks in the Tangle. It is used to prove the inclusionThe process of adding blocks in the Tangle. It is based on Acceptance. or absence of accepted blocks.
• State Root: The hash root of a sparse Merkle tree containing all Unspent Transaction Outputs (UTXOs) at the slot’s conclusion. It is used for proving the existence or absence of UTXOs.
• State Mutation Root: The hash root of a sparse Merkle tree containing accepted transactions in the current slot and serving as proof of state mutation from the prior slot to the current one. It helps in proving the inclusion or absence of accepted transactions.
• Accounts Root: The hash root of a sparse Merkle tree containing Block Issuer (Block Issuance Credits, Issuer Public Keys, Expiry Slot) and Staking Data (Fixed Cost, Stake End Epoch, Staking Amounts) for accounts that are stakingThe process of holding and locking cryptocurrency in a wallet to support the operations and security of a blockchain network. or are block issuersEntities responsible for creating and issuing new blocks into the network.. It is used to provide the issuance of blocks for a given account ID.
• Committee Root: The hash root of a sparse Merkle tree containing account IDs representing current or upcoming committee members. It is only updated when the committee is successfully rotated. It is used to prove the inclusion or absence of a specific account to the committee.
• Rewards Root: The hash root of a sparse Merkle tree that contains data related to rewards (e.g., pool stake, pool reward, fixed cost) for committee members at the previous epoch’s conclusion. It helps prove the existence or absence of rewards for a given account ID.
• Attestation Root: The hash root of a sparse Merkle tree that contains data related to the attestation of all account IDs at the end of the slot. It is used to prove the attestation of previous commitments by a given account ID.
• Protocol Parameters Hash: This hash value encodes the protocol parameters for all existing protocol versions. It helps to upgrade the protocol.

Payloads

While blocks without a payload, i.e., Payload Length set to zero, are valid, such blocks do not contain any information. As such, blocks usually contain a payload. The detailed specification of each payload type is out of the scope of this article; we only give more detailed information for the important Transaction payloadThe transaction payload is the essence of a transaction that allows to exchange tokens. It is the data that is included in a transaction that specifies the tokens to be exchanged, the parties involved, and the terms of the exchange. type in Section Transactions. The following table lists all currently specified payloads that can be part of a block and links to their specification:

Payload Name	Type Value	TIP
No Payload	-	-
Tagged Data	5	TIP-23
Transaction	6	TIP-45

Transactions

The IOTA 2.0 ledger state relies on the Unspent Transaction Output (UTXO) model. The UTXO model defines a ledger state where balances are not directly associated with addresses but with the outputs of transactions. In this model, transactions reference outputs of previous transactions as inputs, which are consumed (removed) to create new outputs. A transaction must consume all the funds of the referenced inputs.

The following image depicts the exchange of funds using UTXO:

Image 6: Exchange of funds using UTXOs.

Transaction Structure

Layout

A Transaction PayloadThe transaction payload is the essence of a transaction that allows to exchange tokens. It is the data that is included in a transaction that specifies the tokens to be exchanged, the parties involved, and the terms of the exchange. is made up of two parts:

1. The Transaction Essence part which contains the inputs, outputs, and an optional embedded payload.
2. The Unlocks which unlock the inputs of the Transaction Essence.

The Transaction Payload ID is the BLAKE2b-256 hash of the entire serialized payload data, including unlocks.

The following table describes the entirety of a Transaction PayloadThe transaction payload is the essence of a transaction that allows to exchange tokens. It is the data that is included in a transaction that specifies the tokens to be exchanged, the parties involved, and the terms of the exchange. in its serialized form following the notation from TIP-45:

Name	Type	Description
Payload Type	uint32	Set to value 6 to denote a TIP-45 Transaction Payload.
Essence oneOf	Transaction Essence Describes the essence data making up a transaction by defining its inputs, outputs, and an optional payload. Name Type Description Transaction Type uint8 Set to value 2 to denote a TIP-45 Transaction Essence. Network ID uint64 The unique value denotes whether the block was meant for mainnet, shimmer, testnet, or a private network. It consists of the first 8 bytes of the BLAKE2b-256 hash of the network name. Creation Slot uint64 The slot index in which the transaction was created. Context Inputs Count uint16 The number of context input entries. Context Inputs optAnyOf Commitment Input Describes an input that references a commitment to a certain slot. Block Issuance Credit Input Describes an input that resolves to a _BIC_ value of an account. Reward Input References a UTXO input that claims Mana rewards. Inputs Count uint16 The number of input entries. Inputs anyOf UTXO Input Describes an input that references an unspent transaction output to consume. Name Type Description Input Type uint8 Set to value 0 to denote a TIP-20 UTXO Input. Transaction ID ByteArray[32] The BLAKE2b-256 hash of the transaction payload containing the referenced output. Transaction Output Index uint16 The output index of the referenced output. Inputs Commitment ByteArray[32] BLAKE2b-256 hash serving as a commitment to the serialized outputs referenced by Inputs. Outputs Count uint16 The number of output entries. Outputs anyOf Basic Output Describes a deposit to a single address. The output might contain optional features and native tokens. Account Output Describes an account in the ledger. Foundry Output Describes a foundry that controls the supply of native tokens. NFT Output Describes a unique, non-fungible token deposit to a single address. Delegation Output Describes a Delegation Output, which delegates its contained IOTA tokens to a validator. Allotments Count uint16 The number of account allotment entries. Allotments optAnyOf Allotment Allots Mana value to indicated account. Name Type Description Account ID ByteArray[32] The Account ID of the parent. Mana uint64 The amount of Mana to allot to this account. Payload Length uint32 The length in bytes of the optional payload. Payload optOneOf Tagged Data Payload Describes data with an optional tag, defined in TIP-23.
Unlocks Count	uint16	The number of unlock entries. It must match the field Inputs Count.
Unlocks anyOf	Signature Unlock Defines an unlock containing a signature. Reference Unlock References a previous unlock, where the same unlock can be used for multiple inputs. Account Unlock References a previous unlock of a consumed account output. NFT Unlock References a previous unlock of a consumed NFT output.

Essence

The Transaction Essence of a Transaction Payload carries the inputs, outputs, and an optional payload. The Transaction Essence is an explicit type and, therefore, starts with its own Transaction Essence Type byte, which is of value 1 for TIP-20 Transaction Essence.

Network ID

The transaction essence's Network ID field serves as a replay protection mechanism. It is a unique value denoting whether the transaction was meant for the IOTA mainnet, shimmer, testnet-1, or a private network. It consists of the first 8 bytes of the BLAKE2b-256 hash of the Network Name protocol parameter, interpreted as an unsigned integer number.

Network Name	Resulting Network ID	Network Name defined in
iota-mainnet	9374574019616453254	TIP-22
shimmer	14364762045254553490	TIP-32
testnet-1	1856588631910923207	-
example-mynetwork	1967754805504104511	-

Creation Slot

The transaction timestamp is expressed as a Slot Index, as there is no need for finer granularity. The validity of the transaction timestamp is checked in comparison with the Block timestamp. Therefore, it is performed at the level of semantic validation of a block, described in TIP-46.

Context Inputs

The Context Inputs field holds inputs that provide additional contextual information for the execution of a transaction, such as for different functionalities related to accounts, commitments, or Mana rewards. Context inputs do not need to be unlocked. Currently, IOTA supports the following types of context inputs:

• Commitment Input
• Block Issuance Credit Input
• Reward Input

Commitment Input

A Commitment Input allows referencing a commitment to a certain slot. It is used to provide a notion of time for transaction execution that is linked to the containing BlockData objects processed by nodes: they contain single transactions. A block is composed of 1) block header (auxiliary information to identify the block); 2) transaction/data; 3) signature.'s Issuing TimeA field in the block header that denotes the time at which the block was issued.. It proves that the time at the transaction execution is past a certain slot in the past, as the slot has already been committed. The slot reference is the Commitment ID and can be resolved to the Commitment value before executing the transaction. The Commitment provides the Slot Index, which is the time reference. A Block that contains a transaction with a Commitment input has additional validation rules as defined in TIP-46. Only one Commitment Input may be present in a transaction.

It is serialized as follows:

Name	Type	Description
Context Input Type	uint8	Set to value 0 to denote a Commitment Input.
Commitment ID	ByteArray[40]	The commitment identifier to reference to.

Block Issuance Credit Input

A Block Issuance Credit Input provides the VM with context for the value of the BIC vector of a specific slot. It is required for any AccountA component of the system used for economic activity in the protocol, including staking for validation, claiming Mana rewards, and holding credits to issue blocks. transitions and destruction if the account contains a Block Issuer Feature, as any operation on the AccountA component of the system used for economic activity in the protocol, including staking for validation, claiming Mana rewards, and holding credits to issue blocks. can only be allowed if the BIC balance is non-negative at a specific point in time. A Block Issuance Credit Input always requires a Commitment Input. The input will be resolved to the BIC value of the account identified by Account ID at the Slot Index given by the Commitment Input. Multiple Block Issuance Credit Inputs can be present in a single transaction to provide the BIC for different accounts; however, no two Block Issuance Credits Inputs can reference the same account.

It is serialized as follows:

Name	Type	Description
Context Input Type	uint8	Set to value 1 to denote a Block Issuance Credit Input.
Account ID	ByteArray[32]	The ID of the Account for which this input provides the _BIC_.

Reward Input

A Reward Input indicates which transaction Input claims Mana rewards. It can reference an Account Output with a Staking Feature or a Delegation Output. The input is resolved by calculating the total amount of rewards the respective output can claim, which is provided as context for transaction execution. The amount of rewards that can be claimed is added to the total sum of Mana on the input side of the transaction. Multiple such inputs can be present in a single transaction to claim rewards for different outputs; however, no two Reward Inputs can reference the same index.

It is serialized as follows:

Name	Type	Description
Context Input Type	uint8	Set to value 2 to denote a Reward Input.
Index	uint16	The index of the transaction input for which to claim rewards.

Inputs

The Inputs field holds the inputs to consume to fund the Transaction Payload outputs . Currently, there is one type of input:

• UTXO Input (In the future, more types of inputs may be specified as part of protocol upgrades).

Each input must be accompanied by a corresponding Unlock at the same index in the Unlocks part of the Transaction Payload.

UTXO Input

A UTXO Input is an input that references an unspent output of a previous transaction. This UTXO is uniquely identified by its Output ID, defined by the Transaction ID of the creating transaction and the corresponding output index. Each UTXO Input must be accompanied by an Unlock that is allowed to unlock the referenced output.

Inputs Commitment

The Inputs Commitment field of the Transaction Essence is a cryptographic commitment to the content of the consumed outputs (inputs). It consists of the BLAKE2b-256 hash of the concatenated output hashes.

In the Inputs field, they are only referenced by Output ID. While the Output ID technically depends on the actual output's content, a client cannot validate this without access to the original transaction. For the Inputs Commitment, the client must be aware of the outputs’ content to produce a semantically valid transaction. This protects clients against eclipse attacks that would result in loss of funds.

Outputs

The Outputs field holds the outputs that are created by the Transaction Payload. Different output types must all have an Amount field denoting the number of IOTA coins to deposit.

The following table lists all the output types that are currently supported as well as links to the corresponding specification. The SigLockedSingleOutput as well as the SigLockedDustAllowanceOutput introduced in Chrysalis Phase 2 TIP-7 have been removed and are no longer supported.

Output Name	Type Value	TIP
Basic	3	TIP-41
Account	4	TIP-42
Foundry	5	TIP-44
NFT	6	TIP-43
Delegation	7	TIP-40

Allotments

The Allotments field contains the list of all Mana allotments, the Account ID, and corresponding values that convert Mana provided by the inputs in the form of stored Mana in inputs or potential Mana derived from the inputs' IOTA tokens. Mana listed in this field will be added upon the commitment of the slot in which the transaction was issued in the form of Block Issuance Credits to the account's BIC value.

Note that Block Issuance Credits are used to pay for the block issuance. They are burned on the slot commitment of the issuance slot. The good practice would be to always allot enough Mana to cover for the block issuance.

Payload

The Transaction Essence can contain another payload as described in general in TIP-46.

The following table lists all the payload types that can be nested inside a Transaction Essence as well as links to the corresponding specification:

Name	Type Value	TIP
Tagged Data	5	TIP-23

Unlocks

The Unlocks field holds the unlocks unlocking inputs within a Transaction Essence.

The following table lists all the unlock types that are currently supported, as well as links to the corresponding specifications. The Signature Unlock and the Reference Unlock are also specified.

Unlock Name	Type Value	TIP
Signature	0	TIP-45
Reference	1	TIP-45
Account	2	TIP-42
NFT	3	TIP-43

Signature Unlock

The Signature Unlock holds a signature signing the BLAKE2b-256 hash of the Transaction Essence (including the optional payload). It is serialized as follows:

Name	Type	Description
Unlock Type	uint8	Set to value 0 to denote a Signature Unlock.
Signature oneOf	Ed25519 Signature Name Type Description Signature Type uint8 Set to value 0 to denote an Ed25519 Signature. Public Key ByteArray[32] The Ed25519 public key of the signature. Signature ByteArray[64] The Ed25519 signature signing the Blake2b-256 hash of the serialized Transaction Essence.

Unlock syntactic validation

• Signature must contain an Ed25519 Signature.
• The Signature Unlock must be unique, i.e., there must not be any other Signature Unlocks in the Unlocks field of the transaction payload with the same signature.

Reference Unlock

The Reference Unlock references a previous Unlock (which must not be another Reference Unlock). It must be used if multiple inputs can be unlocked via the same Unlock. It is serialized as follows:

Name	Type	Description
Unlock Type	uint8	Set to value 1 to denote a Reference Unlock.
Reference	uint16	Represents the index of a previous unlock.

Signature

The Ed25519 Signature is supported. It is serialized as follows:

Name	Type	Description
Type	uint8	Set to value 0 to denote an Ed25519 Signature.
Public Key	ByteArray[32]	The Ed25519 public key of the signature.
Signature	ByteArray[64]	The Ed25519 signature computed according to Signature Creation.

Signature Creation

The Signature field over the block is computed as follows:

• Let Block Header Hash be the BLAKE2b-256 hash over the serialized block headerThe block header is all of the fields in the block wrapper except for the block and signature .
• Let Block Hash be the BLAKE2b-256 hash over the serialized content of the BlockData objects processed by nodes: they contain single transactions. A block is composed of 1) block header (auxiliary information to identify the block); 2) transaction/data; 3) signature. field.
• Let Signing Input be the concatenation of Block Header Hash and Block Hash.
• Let the resulting signature be the Ed25519 signature of Signing Input.