chrome app will be a bit later, I still want to get the realtime handling much more solid. Achieving instant-on has its own challenges, even with 95% of the data being permanent read only.
there are about 5 different states:
initially, there are no spendvectors or balance files, so this is the incomplete state
iguana detects if things are incomplete and then generates the utxo that is needed and ALL balances (any change could affect any balance file)
assuming things generate properly, then we get to the initial state. basically have all spendvectors and all account files as of a certain bundle. The spendvectors are permanent, but the account files are subject to change
immediately after achieving initial state (or on the next start if it is still in the initial state), all the accounts files are verified via SHA256. this does take a while. it also creates a crc32 in parallel and puts these into a file, along with SHA256 of all blockhashes
let's call this the havecrc state
on startup, if the crc file is found, then only the crc32 is calculated, this goes a LOT faster, so in 10 to 15 seconds vs minute or two. and since only the local node is creating the crc file, if it exists, we can assume that the dataset has been validated
there is even an additional state! the readonly state
if all the files are from DB/ro/..., and all files must be from there, then even the crc step is skipped and just the contents of the crc file is assumed to be valid and compared to the SHA256 inside the files.
the DB/ro/BTC dir is meant for a squashfs volume to be mounted, but the way it is done, if the files are there it is assumed to be read-only and allows uncompressed files to be put there (for faster performance).
James
there are about 5 different states:
initially, there are no spendvectors or balance files, so this is the incomplete state
iguana detects if things are incomplete and then generates the utxo that is needed and ALL balances (any change could affect any balance file)
assuming things generate properly, then we get to the initial state. basically have all spendvectors and all account files as of a certain bundle. The spendvectors are permanent, but the account files are subject to change
immediately after achieving initial state (or on the next start if it is still in the initial state), all the accounts files are verified via SHA256. this does take a while. it also creates a crc32 in parallel and puts these into a file, along with SHA256 of all blockhashes
let's call this the havecrc state
on startup, if the crc file is found, then only the crc32 is calculated, this goes a LOT faster, so in 10 to 15 seconds vs minute or two. and since only the local node is creating the crc file, if it exists, we can assume that the dataset has been validated
there is even an additional state! the readonly state
if all the files are from DB/ro/..., and all files must be from there, then even the crc step is skipped and just the contents of the crc file is assumed to be valid and compared to the SHA256 inside the files.
the DB/ro/BTC dir is meant for a squashfs volume to be mounted, but the way it is done, if the files are there it is assumed to be read-only and allows uncompressed files to be put there (for faster performance).
James
