Author: Benjamin Van Renterghem @ construct0 FV
Date: 05/12/2024
Last updated: 05/12/2024
Nyzo version 649 (commits on construct0's GitHub at HEAD ab8ed53) changes the default cycle digest consolidation mode, adjusts the BlockManager write method to function as intended, adjusts the read call & resolving of consolidated cycle digest file heights, and adds minimally required preservation of file(s) by the CycleDigestFileConsolidator.
Changes have been released on construct0's nyzoVerifier repository.
This version affects the Client, Sentinel & Verifier.
Subversion 3 is the final subversion and concludes the release of this major version release.
The default CycleDigestFileConsolidator run option is changed to "delete" for all run modes.
Storing a consolidated cycle digest file, or a set of individual cycle digest files, requires an non-negligible amount of disk space due to each CycleDigest containing the entire list of identifiers accompanied by index references for repeat occurrences.
Changing the default to "delete" prevents an unintended and exuberant amount of disk-space of being occupied by default due to the aforementioned verbosity and collective bloat.
Opt-ing in to consolidating holds value for niche edge cases (e.g. quickly serving a CycleDigest for a particular block height - without requiring additional logic and compute, at the cost of requiring more disk space).
The writeBlocksToFile method of the BlockManager class has been modified to function as intended.
As is the case with other write methods within the repository; a file write is performed to a temporary path, and the file is only moved to its final path if the write to the temporary path was successful.
None of the locations where the method are called from check whether the "successful" boolean value being returned actually equals to "true", which it never is due to the move from temporary path to final path resulting in a "false" value every time, as the purported file on the temporary path does not exist, resulting in an exception.
The following edit serves as a redundancy, despite this method having facilitated the writing of blocks for years without known issues.
The method responsible for returning a CycleDigest instance with the highest block height originating from a consolidated file now uses the frozen edge height instead of an unnecessarily large figure.
In accordance the maximum amount of files is now incremented by 1 (one).
In addition to that, the method no longer prematurely returns if the consolidated cycle digest file containing the first 1000 blocks of the blockchain (first iteration) does not exist. The method returns the consolidated cycle digest file heights starting from the earliest available up until the occurrence of an incremental gap (indicating a missing file / incorrect file name) or when the provided block height has been reached.
In the event that the CycleDigestFileConsolidator's run option is set to "delete" & no consolidated cycle digest file is present on the system, the CycleDigestManager would recreate the same batch of cycle digests ad infinitum due to the CycleDigestFileConsolidator overzealously deleting existing individual cycle digest files, leaving no available cycle digest to base a new batch off off.
This bug is corrected by adding the minimally required amount of preservation to the CycleDigestFileConsolidator.
Shown below, the largest consolidated file height up for processing in order to create and store a consolidated cycle digest file is determined.
An attempt is made to determine the associated individual cycle digest file with the largest file height.
If the individual cycle digest file could be determined, it is removed from the list, excluding it from consolidation and/or deletion.
Acting as a redundancy: if the individual file could not be determined, the consolidated file height and any individual cycle digest files accompanying it are removed from the fileMap, effectively excluding it from further processing.
