Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TIP-47: Storage Deposit Dust Protection (IOTA 2.0) #150

Draft
wants to merge 9 commits into
base: main
Choose a base branch
from
123 changes: 123 additions & 0 deletions tips/TIP-0047/tip-0047.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,123 @@
---
tip: 47
title: Storage Deposit Dust Protection (IOTA 2.0)
description: Prevent bloating the ledger size with dust outputs
author:
Max Hase (@muXxer) <[email protected]>, Philipp Gackstatter (@PhilippGackstatter)
<[email protected]>, Andrew Cullen (@cyberphysic4l) <[email protected]>
discussions-to: TODO
status: Draft
type: Standards
layer: Core
created: 2023-10-17
requires: TIP-38
replaces: 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](../TIP-0049/tip-0049.md):

- 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](#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)](../TIP-0019/tip-0019.md#microtransactions) still apply in the same way with
this TIP.

# Copyright

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