Draft
Conversation
Signed-off-by: barrystyle <baz@tiltpool.com>
Cache powhashes in a persistent database. Test purposes.
Rationel: Convience libraries built by bitcoin contain logically separated code, which allows for modularity. Introducing powcache -> dbwrapper dependecy breaks this modularity by making consensus dependant on server/wallet functionality. Apart from that it breaks builds for libconsesnsus shared library, and bruteforce fixing by satisfying every symbol is incorrect. It is designed to be stand-alone and lightweight for a reason. Thus this commit relinks powcache.* files to server library, and implements cache lookup outside of primitives.
1. Adds a wrapper around PoW cache database, which allows for easy substitution of any heavy block.GetHash() encounter. 2. Removes redundant calls. Consideration: Performing a database lookup with 160 bit long buffer instead of 256 bit blob. Due to the fact that SHA1 output is 160 bits long 256 - 160 = 96 bits are zeros simply taking up space. It is not a big issue, but may result in extra 1 MB of data every week.
Heavy hash persistent cache
This takes into account regtest and testnet3 sub directories
GetCacheHash() uses SHA1 for a unique key. Its output size is 20 bytes -> 160 bits, however initial implementation uses 256 bit key, thus 96 bits are simply 0, which uses up extra memory.
Collaborator
Author
|
Potential addition that may done to this PR is command line argument that controls a couple of parameters related to
But this optional, and imho shall not be the reason to postpone the merge. |
Collaborator
Author
|
All issues resolved in #17 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements a database that stores Heavy Hash of blocks, making node performance better compromising memory.
Yet memory should not be an issue, as entry related to one block would take up 160 bits (key) + 256 bits (value) = 416 bits.
At the current chain state of 70_000 blocks this gives only 3.64 MB.
Heavy Hash is a resource intensive hashing algorithm, and at a current state block indexation and blockchain rescaning takes up to 6-8 minutes. This strongly impedes the performance of a serving node, and makes deployment with volumes really unpleasant. This issue also causes using wallets a very worrying experience.
A simple lookup table however solves both the problems.
Links:
Discord announcement
Note:
Data base is a bitcoin leveldb database, that works in the same way as
block/indexorchainstate.