Skip to content

oip-0005.md

Latest commit

 

History

History
64 lines (40 loc) · 4.09 KB

oip-0005.md

File metadata and controls

64 lines (40 loc) · 4.09 KB

Spam Protection, Part 1: Protection Against Excessively Large Transactions

Proposal Identifier: REIP-0005
Title: Spam Protection, Part 1: Protection Against Excessively Large Transactions
Author: Dmitry Sorokin Discussion: Matrix - https://matrix.to/#/#chatting:matrix.katya.wtf Comments Summary: No comments yet
Status: Draft
Type: Standards Track
Created: 2024-08-07
License: BSD-2-Clause and CC0-1.0

Abstract

This proposal introduces an extension to the REChain consensus protocol that significantly increases the fee for transactions as their size (in bytes) grows. This measure aims to protect the network from spam attacks that could excessively inflate the database size required to run a full node. This is part of a broader spam protection strategy; a companion proposal, REIP-0006, addresses spamming the network with a large number of small transactions.

Copyright

This proposal is dual-licensed under the Creative Commons CC0 1.0 License and the BSD 2-Clause License.

Motivation

The current model of "1 byte of storage = 1 byte of currency" seems fair but fails to sufficiently deter malicious actors who may attempt to overwhelm the network with large transactions. Such attacks could potentially force full nodes to drop out due to unsustainable storage requirements, thus centralizing the network. Even without malicious intent, using REChain for large data storage could have similar consequences.

To address this, the proposal aims to make excessively large transactions prohibitively expensive while maintaining a straightforward fee structure for normal-sized transactions used for token transfers, dapp interactions, and other standard uses.

Specification

  1. Oversize Fee: Introduce an additional fee, termed "oversize fee," for transactions exceeding a threshold_size. Initially set to 10 kB, this threshold can be adjusted through governance. The oversize fee is calculated as follows:

    oversize_fee = size * (exp(size / threshold_size - 1) - 1)

    where size is the transaction size in bytes. The resulting amount is rounded up to the nearest integer.

  2. Transactions Below Threshold: Transactions smaller than threshold_size are unaffected by this change.

  3. Unit JSON Field: Transactions exceeding the threshold must include an oversize_fee field in their unit JSON:

    "oversize_fee": 12345

    This field is omitted for transactions below the threshold.

  4. Fee Handling: The oversize fee is burned to prevent exploitation.

  5. AA Responses: Automated Agents (AAs) are also required to pay the oversize fee.

  6. Upgrade Timing: The above rules will apply to units whose last ball MCI is after a designated upgrade MCI (set to a future date to allow adequate time for all nodes to upgrade).

  7. Governance Adjustments: The threshold_size can be changed through community governance using the voting mechanism outlined in REIP-0003.

  8. Pre-Upgrade Voting: Prior to the upgrade, nodes will be "pre-loaded" with votes from several high-value addresses in favor of the initial threshold_size. These pre-loaded votes will be recorded even if no actual voting transactions have been cast yet. Nodes can override these votes post-upgrade.

Rationale

The proposed oversize fee increases exponentially with transaction size, making large transactions very costly. For instance, a 100 kB transaction would incur a fee of 810,208,393 Bytes, approximately 8102 times the normal fee, while a 200 kB transaction would cost more than 35% of the total supply of Bytes.

This structure does not significantly impact transactions well below 10 kB, nor does it excessively penalize transactions that are moderately larger, such as those up to 40 kB.

Burning the oversize fee simplifies handling and reduces the risk of exploitation, while also slightly benefiting the community by decreasing the circulating supply of Bytes.

Backwards Compatibility

This proposal introduces breaking changes; all nodes must upgrade before the designated upgrade MCI as outlined in rule 6.