-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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: make MNActivationHeight in Params() indeed constant #5658
refactor: make MNActivationHeight in Params() indeed constant #5658
Conversation
(also, pls rebase to fix linter/tests) |
2171b01
to
0f20116
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
few more suggestions
also, I'd like to see that in v20 :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, utACK
previous implementation is tested on |
src/evo/mnhftx.cpp
Outdated
// TODO: can it actually happen? Maybe if try to use old version with re-index and update after MN_RR activated | ||
assert(false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why'd we add this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it will happen (this line will be run), it means that instead legit list of signals the node will have an empty list (that is not expected).
probably we can throw some exception out then? not sure what is good enough solution; but current implementation behaviour is not expecting (because it can cause that some hard-fork will be deactivated or something similar)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well; we shouldn't be asserting in paths that are affected by p2p; which this appears to be (as I think this is called on block connect)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@UdjinM6 can you evaluate these asserts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should never reach this point on a potential invalid chain (mined past v20 activation block by some older version) because it's going to fail much earlier due to other changes activated via v20 I think. So this assert
simply ensures that we read signals from evodb for some block only if we wrote them earlier. And if not, there is GetFromCache
somewhere that is called too early which would be a logical error and we shouldn't continue. In fact, I would probably make it even more explicit 7d0cb4a. We could probably also avoid writing useless data to evodb for pre-v20 blocks while we are at it 2ca4aee.
src/versionbits.cpp
Outdated
AbstractEHFManager* AbstractEHFManager::globalInstance{nullptr}; | ||
|
||
AbstractEHFManager* AbstractEHFManager::getInstance() | ||
{ | ||
return globalInstance; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I really like this new "AbstractEHFManager" thing; why not just have a global like we do now in other parts of codebase, or refactor it to not need a global and use member variables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's to avoid circular dependency versionbits -> mnhfmanager -> versionbits
.
This abstract interface is meant to break this circular dependency over a small simple interface AbstractEHFManager
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is a logical dependency; then I think it's best for there to just be a circular dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's nothing like "logical dependency". It just means that there's not enough interfaces between components; components should know public interfaces but not private details of implementatino.
## Issue being fixed or feature implemented There's too much spamming log items related to new v20 features: credit pool, asset locks, EHF manager, EHF Signaling for MN_RR. Some logs are still spamming after this PR but related code is not changed here #5658 ## What was done? - Removed some log items, tidy-up other. - logs that supposed to appear for each block are moved to new categories EHF and CREDITPOOL ## How Has This Been Tested? Run unit/functional tests, reviewed log output ## Breaking Changes N/A ## Checklist: - [x] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone
The helpers and direct calls of UpdateMNParams for each block to update non-constant member in Params() is not needed anymore. Instead CMNHFManager takes cares about status of Signals for each block, update them dynamically and save in evo db.
…o/mnhftx" It appeared in previous commit, but gone now
- updated help for RPC - int64 replaced to bool in chain param nMNActivationHeight -> useEHF - simplified helper in CMNHFManager
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
4cf7447
to
6b7f514
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
It should be initialized before the very first call
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
Co-authored-by: thephez <thephez@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK for squash merge
Issue being fixed or feature implemented
Addressed issues and comments from PR comment and PR comment
Params()
should be const; global variableCMNHFManager
is a better out-come.What was done?
The helpers and direct calls of
UpdateMNParams
for each block to update non-constant member inParams()
is not needed anymore. InsteadCMNHFManager
takes cares about status of Signals for each block, update them dynamically and save in evo db.How Has This Been Tested?
Run unit/functional tests.
Breaking Changes
Changed rpc
getblockchaininfo
.the field
ehf
changed meaning: it's now only a flag -1/0; but it is introduced a new fieldehf_height
now that a height.Checklist: