tip-0047.md

tip	title	description	author	discussions-to	status	type	layer	created	requires	replaces
47	Storage Deposit Dust Protection (IOTA 2.0)	Prevent bloating the ledger size with dust outputs	Max Hase (@muXxer) <maximilian.hase@iota.org>, Philipp Gackstatter (@PhilippGackstatter) <philipp.gackstatter@iota.org>, Andrew Cullen (@cyberphysic4l) <andrew.cullen@iota.org>	TODO	Draft	Standards	Core	2023-10-17	TIP-38	TIP-19

Summary

This document describes a dust protection concept, called Storage Deposit, which was originally introduced in TIP-19. This concept creates a monetary incentive to keep the ledger state small. This is achieved by enforcing a minimum IOTA coin deposit in every output based on the actually used disk space of the output itself.

This TIP simplifies the calculation in TIP-19 by removing the fine-grained weights on each field and instead introduces offsets. The offsets can be defined in other TIPs and this TIP no longer includes the deposit calculation for each individual output. This eases maintainability of this TIP as it only defines the principles of the storage deposit while other TIPs can build on top of these principles.

Motivation

In a distributed ledger network, every participant, a so-called node, needs to keep track of the current ledger state. Since Chrysalis Part 2, the IOTA ledger state is based on the UTXO model, where every node keeps track of all the currently unspent outputs.

Misusage by honest users or intentionally malicious behavior can lead to growing database and snapshot sizes and increasing computational costs (database lookups, balance calculations). Due to these increasing hardware requirements, the entry barrier to participate in the network becomes higher and less nodes would operate the network, hurting decentralization.

Especially in a system like IOTA where token holders can issue blocks without fees, this is a serious issue, since an attacker can create a lot of damage with low effort. Other DLTs do not yet face this problem, as such an attack would be much more expensive due to the high transaction fees. However, in order to solve scalability issues more and more transactions need to be handled. Therefore, other DLT projects will also eventually run into the same dust limitations.

The Storage Deposit addresses this issue by creating an incentive to keep the ledger state small. In simple words: The larger an output's byte size, the more IOTAs need to be deposited in the output. This is however not a fee, because the deposited coins can be reclaimed by consuming the output in a new transaction.

Requirements

• The maximum possible ledger database size must be limited to a reasonable and manageable size.
• The dust protection must not depend on a global shared state of the ledger, so that transaction validation can happen in parallel.
• The dust protection should work for outputs with arbitrary data and size.
• The ledger database size should be fairly allocated to users based on the scarce resource, IOTA coins.

Detailed Design

Blocks including payloads, such as data or transaction payloads, are pruned by nodes after some time, but unspent transaction outputs must be kept until they are spent. Therefore the dust protection rules only apply to unspent outputs.

This TIP specifies the following calculation of the storage deposit to simplify the calculation from TIP-19, using the Storage Score Parameters of the IOTA 2.0 Protocol Parameters:

• Let the Storage Score of an output be the sum of:
  • The Storage Score Offset Output of an output in storage, which is the sum of the Offset Output Overhead and Factor Data * Output Metadata Size, where:
    • Offset Output Overhead accounts for the overhead of storing any output.
    • Output Metadata Size is the size in bytes of the output's metadata and is the sum of:
      • The length of an Output ID: 38.
      • The length of a Block ID: 36.
      • The length of a Slot Index: 4.
  • The Factor Data * Serialized Output Size where Serialized Output Size is the size in bytes of the serialized output.
  • The offsets defined by any subschemas (e.g. features or unlock conditions) of an output. These are defined with the respective subschema. If a subschema does not define a storage score explicitly, it is 0.
• Let the Minimum Storage Deposit be Storage Score * Storage Cost.

Offsets in subschemas or by outputs themselves can be used to increase the storage score of an output additionally if they incur a higher computational cost for the node.

Additional syntactic transaction validation rules

For any created output Output in a transaction it must hold that: Output::Amount >= Minimum Storage Deposit

How does it affect other parts of the protocol?

The dust protection only affects "value transactions". Since blocks containing other payloads are not stored in the ledger state and are subject to pruning, they cannot cause permanent "dust" and do not need to be considered for dust protection. However, all output types like e.g. smart contract requests are affected and must comply with the minimum deposit criteria. Therefore, these requests could become expensive for the user, but the same mechanism introduced for Microtransactions can be utilized for smart contract requests as well.

Storage cost calculations

To limit the maximum database size, the total IOTA supply needs to be divided by the target database size in bytes to get the worst case scenario regarding the storage costs.

However, in this scenario no outputs hold more IOTA coins than required for the dust protection. This does not represent the real distribution of funds over the UTXOs. We could assume that these output amounts follow Zipf's law. Unfortunately, fitting a Zipf distribution to the current ledger state will not match the future distribution of the funds for several reasons:

• There is already another dust protection in place, which distorts the distribution.
• With new use cases enabled by the new dust protection (e.g. tokenization, storing arbitrary data in the ledger), the distribution will dramatically change.
• Fittings for other DLT projects do not match because there are transaction fees in place, which decrease the amount of dust outputs in the distribution.

Another possibility would be to estimate how much percentage of the database will be used for outputs with minimum required deposit (fund sparsity percentage) in the future. The remaining IOTA coins can be ignored in that case to simplify the calculation. Since a fund sparsity percentage of less than 20% would already be bad for other upcoming protocol features like the Mana calculation, we could take this value for our calculation instead of the worst case.

Microtransactions

To enable microtransactions on Layer 1 and 2 while still satisfying the minimum deposit requirement, the mechanisms introduced in TIP-19 (Microtransactions) still apply in the same way with this TIP.

Copyright

Copyright and related rights waived via CC0.