Skip to content

Latest commit

 

History

History
79 lines (47 loc) · 4.95 KB

oip-0007.md

File metadata and controls

79 lines (47 loc) · 4.95 KB
Raw

Temporary data

Obyte improvement proposal (under the rules of OIP1)

OIP: 0007
Title: Temporary data
Author: Tony Churyumoff @tonych
Discussions-To: discord #tech
Comments-Summary: No comments yet
Comments-URI: https://github.com/byteball/OIPs/issues/10
Status: Active
Type: Standards Track
Created: 2024-08-07
License: BSD-2-Clause and CC0-1.0

Abstract

An extension of Obyte consensus protocol is proposed which allows posting data for temporary storage on the DAG. After some time (1 day by default), nodes are allowed to remove the data, however a hash of the data stays on the DAG forever to enable checking the authenticity of the copies of the data stored off-chain. This data does not pay the oversize fee (OIP 5) and pays half of the regular payload fee.

Copyright

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

Motivation

Some applications may need to reveal and timestamp large chunks of data. However, the oversize fee introduced in OIP 5 would make such applications impractical if they were to use any of the existing ways to post data.

The main type of applications we are targeting is sidechains. For example, sidechains that are blockchains could leverage the ordering capability of Obyte to order their blocks instead of relying on their own consensus mechanisms (which are prone to centralization and vulnerable to censorship, especially when the chains are small). The blockchains can be based on any technology, such as EVM, Solana, etc, but would track Obyte for their consensus. They would post the full content of their blocks to Obyte, and in case of a fork (several competing blocks at the same block height), it can be resolved by a combination of the blocks's relative order on the Obyte DAG and other criteria (such as burn fee introduced in OIP 8). Long term storage of the block data wouldn't be required as the block is already stored by the sidechain. The requirement of revealing the block data when posting the block would make it impossible to hide the block content while posting only its hash, and would also allow verifying that the block is valid.

Specification

  1. Add new app type temp_data. Its payload must be inline and have the following format:
"payload": {
	"data_length": 12345,
	"data_hash": "base64 hash of data",
	"data": actual data
}

where data_length is the length of the data object and data_hash is its hash. We calculate the lengths and hashes of objects in the same way as elsewhere in Obyte.

  1. While forwarding the unit to other nodes at least 1 day later than the unit's timestamp, the node may omit the data field. It may also delete it from its database.

  2. While validating a unit that contains temp_data, temp-reject the unit if it lacks data but 1 day hasn't yet passed since the unit's timestamp. The time measurement is according to the node's clock. The same unit would be accepted after the 1 day passes.

  3. While calculating the unit's size for the purposes of oversize fee calculation, do not include the data field of temp_data (neither the field itself (4 bytes) nor its content). However, do include data_length and data_hash fields.

  4. While calculating the unit's payload size, remove its 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).

  5. AAs can send temp_data like any other address.

  6. Several temp_data per unit are allowed.

  7. The above rules start applying to units whose last ball MCI is after a specific upgrade MCI (which will be set to a value well in the future to give all nodes enough time to upgrade).

Rationale

The proposed change allows putting large data on Obyte without creating a permanent burden on nodes to store the constantly growing data. It demands revealing the data while posting it (otherwise the unit would keep being rejected for 1 day), which makes it fitting to sidechain needs.

While data storage requirements on full nodes still increase, they would need to store only 1 day worth of the additional data.

Temp data is exempt from oversize fee since it doesn't present a lasting spamming opportunity.

The 1 day period chosen for data retention is sufficient for resolution of all reasonable forks in sidechains.

Temp data is charged half the usual rate, i.e. 0.5 Bytes of currency per 1 byte of storage, to encourage applications that post fairly small amounts of data (under 10 kB, which wouldn't trigger the oversize fee) to use temp_data if they don't need to store the data permanently.

While the decision to temp-reject a unit without a data field is based on node's clock, the discrepancy among clocks of different nodes is inconsequential as the rejection is only temporary.

Backwards compatibility

It is a breaking change and all nodes will have to upgrade before the upgrade MCI as indicated in rule 8.