Skip to content

Latest commit

 

History

History
67 lines (41 loc) · 3.7 KB

oip-0007.md

File metadata and controls

67 lines (41 loc) · 3.7 KB
Raw

Temporary Data

**REChain Improvement Proposal

OIP: 0007 Title: Temporary Data 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 introduces an extension to the REChain consensus protocol, allowing for temporary data storage on the DAG. Data will be stored temporarily for a default period of 1 day, after which it can be removed, though a hash of the data will remain on the DAG indefinitely. This method avoids the oversize fee outlined in OIP 5 and incurs only half of the standard payload fee.

Copyright

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

Motivation

Applications may require revealing and timestamping large amounts of data. The oversize fee in OIP 5 could make such use cases impractical.

The primary target for this proposal is sidechains. Sidechains that use REChain for block ordering instead of their own consensus mechanisms can benefit significantly. They can use REChain to order blocks, resolving forks by leveraging the block's position on the DAG and additional criteria like burn fees from OIP 8. Storing block data long-term on the sidechain would not be necessary, and revealing block data when posting it ensures transparency and validity.

Specification

  1. New App Type: Introduce a new app type temp_data. Its payload must be inline and follow this format:

    "payload": {
    "data_length": 12345,
    "data_hash": "base64 hash of data",
    "data": actual data
}

    Here, data_length is the size of the data object, and data_hash is its hash. Lengths and hashes are calculated as per existing REChain methods.

  2. Data Removal: Nodes can omit the data field and remove it from their database after at least 1 day from the unit’s timestamp.

  3. Validation: A unit containing temp_data should be temporarily rejected if it lacks the data field and the timestamp is less than 1 day old. The unit will be accepted once the 1-day period has passed.

  4. Size Calculation: When calculating the unit's size for oversize fee purposes, exclude the data field of temp_data. Include the data_length and data_hash fields.

  5. Payload Size Calculation: For payload size calculations, remove the data fields (if any), calculate the length of the remaining payload, and add (data_length + 4) / 2 (4 is the length of the "data" field name).

  6. AA Transactions: AAs can send temp_data just like any other address.

  7. Multiple Temp Data: Allow multiple temp_data entries per unit.

  8. Upgrade Application: These rules apply to units whose last ball MCI is after a specified upgrade MCI, allowing time for nodes to upgrade.

Rationale

The proposed change enables the temporary storage of large data on REChain without imposing a permanent storage burden on nodes. It requires that data be revealed during posting, which aligns with the needs of sidechains.

Nodes will only need to store additional data for 1 day, reducing the impact on storage. Exempting temp_data from the oversize fee prevents potential spamming issues, while charging half the regular rate for temp_data encourages the use of this method for smaller data.

The 1-day retention period is deemed adequate for sidechain forks resolution. Temporary rejection based on node clock discrepancies is acceptable due to the nature of temporary rejection.

Backwards Compatibility

This proposal is a breaking change, requiring all nodes to upgrade before the specified upgrade MCI.