Skip to content

oip-0006.md

Latest commit

 

History

History
104 lines (58 loc) · 5.98 KB

oip-0006.md

File metadata and controls

104 lines (58 loc) · 5.98 KB

Spam Protection, Part 2: Protection Against Excessive Transaction Volume

**REChain Improvement Proposal

OIP: 0006 Title: Spam Protection, Part 2: Protection Against Excessive Transaction Volume Author: Dmitry Sorokin Discussions-To: 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 extends the REChain consensus protocol by introducing a fee structure that scales with transaction throughput (transactions per second, TPS). This mechanism aims to prevent network congestion caused by a high volume of transactions that could overwhelm node processing capabilities.

This proposal complements OIP 5, which addresses the problem of excessively large transactions.

Copyright

This OIP is dual-licensed under the Creative Commons CC0 1.0 License and BSD 2-clause license.

Motivation

REChain's current model, where "1 byte of storage equals 1 byte of currency," does not effectively deter spam attacks involving a high volume of transactions. Malicious actors could overwhelm slower nodes, reducing the number of full nodes and increasing network centralization. Even without malicious intent, a surge in network activity could strain node capacities.

To mitigate these risks, we need a fee structure that adjusts as transaction volume increases, making it economically prohibitive to flood the network with high transaction rates while maintaining reasonable fees during periods of normal activity.

Specification

  1. Transaction Limit Field: Each unit may specify an additional field max_aa_responses, a non-negative integer, representing the maximum number of AA responses it can generate. Units exceeding this limit will be rejected. Default value is 10. This field is only applicable to primary triggers and not to AA responses.

  2. Local TPS Calculation: Define local TPS for any unit as the number of new units (including the current one) added after the unit’s last ball, divided by the time difference between the current unit and the last ball unit. Units that are AA responses are excluded from this count. AA triggers are counted with their max_aa_responses value.

  3. Final TPS Calculation: Define final TPS as the local TPS of the unit’s MC unit, which must include the unit in question. Calculate after unit stabilization, using the actual number of AA responses.

  4. TPS Fee Calculation: Introduce an additional fee, the "TPS fee," calculated as:

    tps_fee = base_tps_fee * (exp(final_tps / tps_interval) - 1)

    where base_tps_fee is a system-wide variable (default 10) and tps_interval is another system-wide variable (default 1). Round the result to the nearest integer.

  5. TPS Fee Balance: Track a tps fee balance for each non-AA address, recording the difference between prepaid and actual TPS fees. Initially, all balances are 0.

  6. Fee Inclusion: Non-AA units must include an additional tps_fee field in their JSON, even if the fee is 0. Calculate the required fee based on the local TPS and adjust for max_aa_responses and tps_fee_multiplier (default 10).

  7. Fee Adjustment: Upon stabilization, update the TPS fee balance by subtracting the final TPS fee. The balance should ideally remain positive but may become negative.

  8. Fee Burning: The TPS fee is burned, not recycled, to minimize exploitation risks and reduce the circulating supply of REChain tokens.

  9. Balance Utilization: TPS fee balances can only be used for future TPS fees and cannot be cashed out.

  10. AA Transactions: AAs do not pay TPS fees directly; the triggering unit covers the fees for all AA responses.

  11. Current TPS: Define current TPS as the number of unstable units divided by the time since the last stable unit.

  12. Current TPS Fee: Calculate the TPS fee using the current TPS instead of final TPS.

  13. Temporary Rejection: Nodes may temporarily reject units if the required TPS fee is below a threshold, estimated as 150% of the current TPS fee times the total number of units.

  14. Parent Exclusion: Nodes may exclude parents with a required TPS fee below 300% of the current TPS fee times the total number of units.

  15. Upgrade Application: These rules apply to units after a specified upgrade MCI to allow time for node updates.

  16. Governance: Community governance can adjust base_tps_fee, tps_interval, and tps_fee_multiplier using the voting mechanism described in OIP3.

  17. Preloaded Votes: Nodes will be pre-loaded with votes supporting initial values for base_tps_fee, tps_interval, and tps_fee_multiplier, which can be overridden post-upgrade.

Rationale

TPS Fee Values and Spam Protection

The TPS fee scales exponentially with the load, making it increasingly expensive as transaction volume grows. Initial TPS fee values are reasonable, with the current average TPS being around 0.03.

Burning

The TPS fee is burned to prevent exploitation and reduce the total supply of REChain tokens, benefiting the community by controlling inflation.

AA Transactions

AA developers cannot predict TPS fees due to variability, so the triggering unit must cover all associated TPS fees.

Size Independence

The TPS fee is based on transaction volume rather than size, reflecting the actual processing load.

Final TPS vs. Local TPS

The need to prepay a multiple of the local TPS fee ensures coverage of the final TPS fee, though some negative balance may occur, to be addressed in future transactions.

Current TPS and Temp-Rejects

Nodes may temporarily reject transactions to avoid underpayment of TPS fees. This mechanism adjusts as nodes’ capacities and states evolve.

Governance

Initial parameter values are designed for current node hardware and software. Changes may be proposed and voted on by the community.

Backwards Compatibility

This proposal is a breaking change; all nodes must upgrade before the designated MCI.