diff --git a/tips/TIP-0047/tip-0047.md b/tips/TIP-0047/tip-0047.md new file mode 100644 index 000000000..1fcef89ce --- /dev/null +++ b/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) , Philipp Gackstatter (@PhilippGackstatter) + , Andrew Cullen (@cyberphysic4l) +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/).