-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Checkpoints + Get snapshot of state for block n #143
Comments
Very nice Dexx. It's something I've wanted to complete for a long time now. Since realizing our consensus testing was slowly going away. But I could never have the time to properly figure out the user side of it.
Thanks for giving it a thought; I consider it quite an important verification step. |
Yes, parsing from zero to the specific point was what I had in mind as well. Performance shouldn't be an issue here, because this is a rather specific action where (potential long) parsing time is acceptable imho, but as you also suggested: dumping every n blocks might be possible as well. Using raw balances is a too crude approach and pending actions such as accepted purchases, ongoing crowdsales etc. must be included as well, but the actual data structure is probably a different topic. That being said, but as a side note nevertheless and what I once mentioned to @zathras: maybe we should start to think with a mindset such as "what if mastercoin were an altcoin with it's own blockchain and blocks". In some cases this might help to come up with an answer and in this particular case: if you come up with an elegant solution how such blocks would look like, you also found an answer to the data format question. I'm very happy to see consensus about this (imho indeed important) topic. :) What do you mean with "figure out the user side of it"? |
Right now I see a few options on different levels how to achive this goal. First it needs to be determined which data is used as basis.
Raw Mastercoin data alone is not sufficient and information about "reference outputs" and other things is relevant, too. A data entry could include:
The "version" of Mastercoin should provide information whether a feature is enabled and anytime a new feature is added, e.g. the traditional DEx, crowdsales, meta DEx, ... there should be a version bump. Checkpoints based on this data would tackle the encoding layer, but not the logical one. The logical layer involves roughly:
|
We have that: MP_txlist, also includes invalid ones.
We have that as well -- using the above MP_txlist + blockchain that's how gettransaction_MP roughly works. |
Yup, I tested dumping the raw transaction data from interpretPacket (started from scratch). I'm not sure, if it would be side effect free to go this route from somewhere else - it looks like there are data manipulations (update_tally_map). Is this the case? |
Actually I sort of missed one other important aspect: basically nothing from mastercore.cpp/.h and the others is testable at the moment due to the heavy cross-dependencies. |
Agree 100% on the need for this. Just thinking off the top of my head here but comment from skype: [8:30:15 AM] zathrasc: everytime UPDATE_TALLY_MAP calls an action |
Just a further note here from the Skype chat, Michael has pointed out we can get something to this effect already - another quick paste eg:
|
[4:56:42 PM] Michael: and they should match up to the the P2SH block and so on forever between Version N & Version N-1 |
Testing based on logs is actually a neat and creative solution. Sounds like a fast and very effective route for comparing builds where log output can be expected to differ only in values - that should be given, if one build is compared against another where a small change was added etc. On the long run:
I started with the first ones which are probably not optimal, but serve as example nevertheless: I really haven't explored what's possible, but this was fairly simple:
Unit tests are rather difficult at this point though, because most functions (and files, headers) appear to be not self-contained and depend on or influence other parts (e.g. parseTransaction that requires LevelDB stored transactions, interpretPackage that can't be used to get results, but also updates state etc.). And an include of solely mastercore.h completely breaks right at the start. As already suggested, I think comparing the content of MP_txlist would actually indeed be a good starting point, too. I think it would also help, if there were a breakout feature as mentioned at the beginning, basically something like mastercored --stop-at-height nnnn. |
I think it would be great to get a representation of global state for a specific block / time / whatever.
While this doesn't replace tests*, checkpoints should be used to compare builds and ensure history remains intact and no side effects were introduced.
This may replace some tests, if edge case transactions are intentionally created. This would actually be nice to have as well and should be documented, if done so.
The text was updated successfully, but these errors were encountered: