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

tips/TIP-0047/tip-0047.md

@@ -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) <maximilian.hase@iota.org>, Philipp Gackstatter (@PhilippGackstatter)
+  <philipp.gackstatter@iota.org>, Andrew Cullen (@cyberphysic4l) <andrew.cullen@iota.org>
+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/).