Skip to content
This repository has been archived by the owner on Feb 18, 2025. It is now read-only.

TIP-22 IOTA Protocol Parameters #43

Merged
merged 20 commits into from
Jul 13, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions tips/TIP-0022/tip-0022.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
---
tip: 22
title: IOTA Protocol Parameters
description: Describes the global protocol parameters for the IOTA protocol
author: Wolfgang Welz (@Wollac) <wolfgang.welz@iota.org>
discussions-to: https://github.com/iotaledger/tips/pull/43
status: Draft
type: Standards
layer: Core
created: 2021-11-29
---

# Summary

This TIP describes the global protocol parameters for the IOTA protocol.

# Motivation

Various other protocol TIPs rely on certain constants that need to be defined for an actual implementations of nodes or other applications using the protocol. This TIP serves as a single document to provide these parameters. It also serves as a historical record of protocol parameter changes.

# Detailed design

| Name | Value | Description |
|---------------------------------------|------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Network Name | "iota-mainnet" | Identifier string of the network. Its hash it used for the `Network ID` field in transactions. |
| Protocol Version | 2 | Protocol version currently used by the network |
| Max Block Length | 32768 | Maximum length of a block in bytes. Limits Tangle storage size and communication costs. |
| Max Parents Count | 8 | Maximum number of parents of a block. |
| Min PoW Score | 4000.0 | Minimum PoW score for blocks to pass syntactic validation. |
| First Milestone Index | 1 | First valid milestone index. |
| | | |
| Max IOTA Supply | 2779530283277761 | Total amount of IOTA coins in circulation. |
| Max Inputs Count | 128 | Maximum number of inputs in a transaction payload. |
| Max Outputs Count | 128 | Maximum number of outputs in a transaction payload. |
| Max Native Token Count | 64 | Maximum number of different native tokens that can be referenced in one transaction. |
| | | |
| Max Tag Length | 64 | Maximum length of a `Tag` field in bytes. |
| Max Metadata Length | 8192 | Maximum length of a `Metadata` field in bytes. |
| | | |
| VByte Cost | 500 | Minimum amount of IOTA that need to be deposited per vbyte of an output. |
| | | |
| SLIP-44 Coin Type (decimal) | 4218 | Registered coin type (decimal) for usage in level 2 of [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) described in chapter "Coin type". |
| SLIP-44 Path Component (`coin_type'`) | 0x8000107a | Registered path component for usage in level 2 of [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) described in chapter "Coin type". |
| | | |
| Bech32 Human-Readable Part | `iota` | HRP prefix to use for Bech32 encoded IOTA addresses. (e.g. `iota1zzy3drvj6zugek60srqwhqctkjldx3qle5yuvapj`) |
| Bech32 Human-Readable Part (Test) | `atoi` | HRP prefix to use for Bech32 encoded IOTA addresses on test- or development networks. (e.g. `atoi1zzy3drvj6zugek60srqwhqctkjldx3qle5fhvhm6`) |

# Rationale for parameter choices

## Proof-of-work

The `Min PoW Score` has been chosen to roughly match the difficulty of a data transaction in the legacy IOTA protocol:
- The payload length (`signatureMessageFragment`) of a legacy transaction is 2187 trytes or 1100 - 1300 bytes depending on the encoding.
- With a minimum weight magnitude (trailing zero trits) of 14, this corresponds to a PoW score of about 4000.

## Transaction and block limits

The block parameter `Max Block Length` and `Max Parent Count`, as well as the transaction parameters `Max Inputs Count`, `Max Outputs Count`, `Max Native Token Count`, `Max Tag Length` and `Max Metadata Length` govern the block and transaction validity. Their values have been chosen to ensure functionality of the protocol within constrained resource restrictions. Furthermore, choosing more conservatives values here is preferable as increasing such limits can always been done preserving backward compatibility.

## Dust protection

The `VByte Cost` is the core parameter of the dust protection. The reasoning behind its value is explained in [draft TIP-19 Dust Protection](https://github.com/iotaledger/protocol-rfcs/pull/39).

# Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).