2018-02-23 11:00:07 -03:00

3.3 KiB

Raw Blame History

BSIP: 0036
Title: Remove expired feeds
Author: oxarbitrage <https://github.com/oxarbitrage>
Status: Draft
Type: Protocol
Created: 2018-02-22
Discussion: https://github.com/bitshares/bitshares-core/issues/518
Replaces: -
Worker: To be done

Abstract

Currently, expired bitasset feeds remain in the blockchain forever. The only way to get them erased is if operation update_feed_producers is called with new publishers on the asset. At this call, and only at this case, old publisher feeds will be deleted from the blockchain. If this operation never occurs or if it occurs maintaining some or all of the same publishers feeds will not be removed.

Some examples of this are the followings, where we can see feeds from 2015:

http://open-explorer.io/#/objects/2.4.9 - HKD
http://open-explorer.io/#/objects/2.4.21 - USD
http://open-explorer.io/#/objects/2.4.10 - RUB
etc.

This BSIP proposes a protocol change to remove expired feeds at maintenance time.

Motivation

Improve performance of the bitshares-core.

Rationale

This expired feeds are unnecessary, they clutter up the database and cause unnecessary burden on undo_db.

Specifications

As mentioned in the abstract feeds stay in the blockchain forever unless asset_update_feed_producers_evaluator::do_apply is called.

The BSIP proposes to remove expired feeds at maintenance time by adding feed cleanup code at db_main.cpp.

Solution is not that simple, asset_update_bitasset_operation can change feed_expiration_time and minimum_feeds required for the asset.

If a feed is expired and the feed_expiration_time changes, expired feeds may became valid, similar if minimum_feeds (required to calculate the median) is increased, older feeds may became valid and used by the core market engine if available.

This scenario actually happened in the past and that is the reason the change will fail unless a hardfork protection is added.

The proposed solution

Goal is to remove expired feeds in a safe manner. To do this we need to keep current behavior before hardfork date and only remove feeds at maintenance intervals after the hardfork. This will allow the chain to synchronize and start the cleanup at a point where all the feeds are valid, safely being able to remove them an continue clean from that time on.

This a permanent hardfork, code before hardfork date will work one way(current behavior) and after date new code will work different making the feed cleanup at maintenance times.

Feed cleanup code will only be executed after proposed hardfork date, at the first maintenance interval after date old feeds will be removed, node will not be able to use them anymore as they will not be available in the database.

If asset_update_bitasset_operation is called before hardfork operation will be normal as it is currently is now.

If asset_update_bitasset_operation is called after hardfork and increases the minimum_feeds while they are not enough feeds update_median_feeds() will set a null feed. This is current asset_update_bitasset_operation, no need to make any change in the operation.

Discussion

[to be added if any]

Summary for Shareholders