Skip to content

Remove forking completely from IStore #4003

@greymistcube

Description

@greymistcube

Since moving to PBFT, there has been no real need to allow forking of chains. The following methods should be removed:

  • IStore.ForkTxNonces()
  • IStore.ForkBlockIndexes()
  • IStore.DeleteChainId()
  • IStore.PruneOutdatedChains()
  • IStore.ListChainIds()
    These methods may be provided under RocksDBStore temporarily for operational reasons, but should no longer be part of the IStore interface. It may be desirable to remove all in one go. Due to the 9c-network chain database being corrupted internally already, it would be nearly impossible to implement additional migration methods while accommodating existing chains. Additionally, we might want to remove RocksDBStore.MigrateChainDBFromColumnFamilies() as well.

I propose the following migration path:

  • Remove all interface methods suggested above.
  • Implement RocksDBStore.PruneOutdatedChains() as in Fixed PruneOutdatedChains() #3999.
  • Automatically prune RocksDBStore during the instantiation phase.
    • This can be checked by calling ListChainIds() and see if there is more than 1.
    • Pruning can be skipped if the RocksDBStore is already pruned.
  • Fix RocksDBStore.IterateIndexes().
    • As it stands, RocksDBStore.IterateIndexes() is bugged, which I believe is the reason why the current 9c-network chains are corrupted.
    • Once we can assume that a loaded RocksDBStore is always pruned, reimplementing RocksDBStore.IterateIndexes() becomes trivial.
    • A reimplementation of RocksDBStore.IterateIndexes() may require some optimization as pruning will result in significant performance degradation due to an Iterator normally having to iterate from the very beginning even if one is only looking for the last n blocks. Iterator.SeekForPrev() may be used for this purpose.

Once this is done, I presume significant portions of RocksDBStore can be refactored easily after a full release cycle (to make sure that all local chains are pruned) making additional migrations feasible for further optimizations.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions