-
Notifications
You must be signed in to change notification settings - Fork 152
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
Refactor/header caching #1347
Refactor/header caching #1347
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1347 +/- ##
===========================================
- Coverage 86.03% 73.72% -12.31%
===========================================
Files 361 253 -108
Lines 32457 17095 -15362
===========================================
- Hits 27925 12604 -15321
- Misses 2747 3931 +1184
+ Partials 1785 560 -1225
|
3439240
to
114265a
Compare
47df0aa
to
85cd2e4
Compare
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
not stale |
Minor comment
85cd2e4
to
fe88cd9
Compare
This PR caches
BlockHeader
when creating aBlock<T>
instance. This is in preparation for dealing with #1164, like #1326 and #1341. Other than caching, this includes the following changes:BlockHeader
instead ofBlock<T>
.PreEvaluationHash
validation moved toBlockHeader
.Block<T>
constructor.Several new constructors for
BlockHeader
have been introduced to convert some implicit logic more explicit. The main issue remains where there is still too much implicit logic embedded in the "manual" constructor forBlock<T>
. As left in theFIXME
comments, this should be resolved on further refactoring. The firstBlock<T>
constructor in the code should be separated into at least two, one where the constructor is purely used for manual creation of aBlock<T>
instance (possibly intended for testing) and another intended for block generation through mining.