I kinda wonder what the real structure of the blockchain/safebox is.
The documentation is not fully clear about this, and the code is convoluted/confused with all kinds of readings of searching and recovering from possible crashes/corruption... Hmmm.
Would be helpfull to have a test program which reads the blockchain/safebox and displays it on a screen either console app or visual app... just for inspecting the data/file structures.
I did write a test program for this which can just load the "bank" I think this also loads "the blockchain". Loading pending operations is a lot more tricky and was not done/disabled.
If anybody is interested in this contact me =D
Anyway what I have learned from that test program is there are some undocumented fields, for example some files might start with a "magic cookie" which is probably "pascalcoin" or something like that.
There are also some "indexing/offsetting" fields or something like that.
These additional fields make it somewhat confusing.
There are also "length" fields which describe the length of ansistrings, like hashes have a length fields, cause they are stored as ansistrings.
The real file structures are a bit different than the pascal coin (promotion/introductionary) pdf's.
There are some similarities, some things are a bit more vague like how operation block was added to each account block in protocol v2.
Also during code examination the safebox/bank hashing and such works as advertised.
What is yet somewhat unclear to me is structure of operations. These are also stored in the blockchain file. These seem to be streamed to this file. These operations and their fields probably depend on what kind of operation it is.
The most mysterious one so far is "operation resume" not sure what this is. Not even sure if it's stored on disk, I may be confused about that ;)
Why and how operations are hashed is also a bit mysterious, there is some explanation and doc about merkle hash tree hashing, why it is done this way is not really explained as far as I know. Perhaps this hashing structure is not needed and is a "left-over" design from bitcoin analysis/copycatting. In bitcoin the idea was to prune this away later. In pascal coin this is not really necessary and a bit a mute point/unnecessary design/feature (at least as far as I can tell for now).
Furthermore pascalcoin seems to suffer from poor harddisk performance when downloading new blocks from other peers. This may have to do with "snapshot feature" and "checkpointing". It seems to be making a copy of the entire bank per new block, and then deleting older ones or something. Not exactly sure what is going on here. But the harddisk doesn't like it much.
First it performs somewhat fast and after a few seconds it deteriorates, then the same pattern repeats, somewhat fast, and then slower and slower, fast, slower and slower.
I hope that in the future a different storage pattern can be found/applied and used to relief the stress on the harddisk somewhat. I still like harddisks for their proven realibility. Perhaps in the future people will use SSDs only. Though for now that is a too big gamble because those kinds of devices are still very expensive. Also SSDs don't like many re-writes. So even for SSDs a little bit less read/write/create/delete stress would be welcome ! ;) =D
(This performance analysis/observation was done based on the "real" pascal coin and not just the test program, by examining task manager and it's special resource monitor in real time as new blocks were being downloaded from peers.).