In case of a multi-hash blockchain system, where a pair of a hash-pointer can have different reset time, there might be the possibility to control this reset time based on a common consensus on chain consensus. At a given consensus system, the hash pointers might be stored as:
<p1, reset_time_1, remaining_reset_time_1>
<p2, reset_time_2, remaining_reset_time_2>
The reset algorithm can work as:
if (remaining_reset_time_i <= 0) {
do hash reset;
remaining_reset_time_i = reset_time_i;
}
The reset time is however stored on the blockchain, so there might be a decentralized voting mechanism, controlled either by the miners or by the community that can change the reset time to a new value. This is however not so simple. The problem is that the reset period of p1 hash pointer has to be in the middle of the hash period of the p2, otherwise the system security can be more easily compromised. One algorithm can be the following:
Supposing we have accepted a new future_reset_time, we can do the following modification at the following reset like in this example for 1, supposing that the resets have 50% time delay to each other:
if (remaining_reset_time_1 <= 0) {
do hash reset;
remaining_reset_time_1 = future_reset_time;
remaining_reset_time_2 = future_reset_time / 2;
reset_time_1 = future_reset_time
reset_time_2 = future_reset_time
}
do hash reset;
remaining_reset_time_1 = future_reset_time;
remaining_reset_time_2 = future_reset_time / 2;
reset_time_1 = future_reset_time
reset_time_2 = future_reset_time
}
Certainly, it is an open question how agreement on the new retention time can work in the most efficient way. One idea can be to introduce some special variables in the blockchain that store such a system information and a voting mechanism, like special voting transactions by end-users, or voting by mining power that can make a proposed variable final.
