Since hyperchains will largely be free of forks, there is less of a need to use the MARF in its current form. The purpose of the MARF is to allow nodes to quickly validate the value of a particular key in ANY fork. Replacing the MARF with a flat key value store will lead to speedups.
We will replace the MARF with the following:
We will use a flat key value store - implemented with a normal SQLite database.
Store the key/value updates in each block in a database.
When a new block is created, this is what will happen:
If the block builds off of the current chain tip, then the key value updates will be applied as normal.
If the block builds on a fork:
If the fork is shorter than the current tip, the key value updates are stored as a blob but not applied to the flat key value store.
If the fork is longer than the current tip, the blockchain will "undo" the key value updates up until the point of the fork, and then apply the updates in the blocks in the fork.
This change will affect the speed of operations in the SortitionDB and ClarityDB, both of which use the MARF.
Since hyperchains will largely be free of forks, there is less of a need to use the MARF in its current form. The purpose of the MARF is to allow nodes to quickly validate the value of a particular key in ANY fork. Replacing the MARF with a flat key value store will lead to speedups.
We will replace the MARF with the following:
When a new block is created, this is what will happen:
This change will affect the speed of operations in the SortitionDB and ClarityDB, both of which use the MARF.