Skip to content
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

Merged
merged 14 commits into from
Nov 10, 2023

Conversation

knst
Copy link
Collaborator

@knst knst commented Oct 30, 2023

Issue being fixed or feature implemented

Addressed issues and comments from PR comment and PR comment

Params() should be const; global variable CMNHFManager is a better out-come.

What was done?

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.

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 field ehf_height now that a height.

Checklist:

  • 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
  • I have assigned this pull request to a milestone

@knst knst added the RPC Some notable changes to RPC params/behaviour/descriptions label Oct 30, 2023
@knst knst added this to the 21 milestone Oct 30, 2023
src/consensus/params.h Outdated Show resolved Hide resolved
src/rpc/blockchain.cpp Outdated Show resolved Hide resolved
test/functional/test_framework/test_framework.py Outdated Show resolved Hide resolved
src/evo/mnhftx.cpp Outdated Show resolved Hide resolved
@UdjinM6
Copy link

UdjinM6 commented Oct 31, 2023

(also, pls rebase to fix linter/tests)

@knst knst force-pushed the refactor-mnehf-manager branch from 2171b01 to 0f20116 Compare October 31, 2023 15:49
Copy link

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

few more suggestions

src/chainparams.cpp Outdated Show resolved Hide resolved
src/chainparams.cpp Outdated Show resolved Hide resolved
src/chainparams.cpp Outdated Show resolved Hide resolved
src/chainparams.cpp Outdated Show resolved Hide resolved
src/chainparams.cpp Outdated Show resolved Hide resolved
src/chainparams.cpp Outdated Show resolved Hide resolved
@UdjinM6
Copy link

UdjinM6 commented Nov 1, 2023

also, I'd like to see that in v20 :)

src/chainparams.cpp Outdated Show resolved Hide resolved
UdjinM6
UdjinM6 previously approved these changes Nov 1, 2023
Copy link

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, utACK

@knst
Copy link
Collaborator Author

knst commented Nov 1, 2023

also, I'd like to see that in v20 :)

previous implementation is tested on devnet-ouzo, this one - only on reg-test. @UdjinM6
If this one will be included in v20, we need to get it in next beta/RC and activate EHF (MN_RR) on testnet with this changes merged.
@PastaPastaPasta

Comment on lines 289 to 290
// TODO: can it actually happen? Maybe if try to use old version with re-index and update after MN_RR activated
assert(false);
Copy link
Member

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?

Copy link
Collaborator Author

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)

Copy link
Member

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)

Copy link
Member

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?

Copy link

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.

Comment on lines 276 to 281
AbstractEHFManager* AbstractEHFManager::globalInstance{nullptr};

AbstractEHFManager* AbstractEHFManager::getInstance()
{
return globalInstance;
}
Copy link
Member

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.

Copy link
Collaborator Author

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.

Copy link
Member

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.

Copy link
Collaborator Author

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.

PastaPastaPasta pushed a commit that referenced this pull request Nov 6, 2023
## 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
@knst knst requested a review from PastaPastaPasta November 6, 2023 16:27
knst and others added 9 commits November 8, 2023 02:12
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>
@knst
Copy link
Collaborator Author

knst commented Nov 7, 2023

@knst knst force-pushed the refactor-mnehf-manager branch from 4cf7447 to 6b7f514

rebased on top of current develop due to conflicts with #5669 and #5668

@knst knst requested a review from UdjinM6 November 7, 2023 19:27
UdjinM6
UdjinM6 previously approved these changes Nov 8, 2023
Copy link

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK

src/versionbits.h Outdated Show resolved Hide resolved
src/versionbits.cpp Outdated Show resolved Hide resolved
knst and others added 3 commits November 8, 2023 23:33
Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
It should be initialized before the very first call
@knst knst requested a review from PastaPastaPasta November 8, 2023 17:26
UdjinM6
UdjinM6 previously approved these changes Nov 8, 2023
Copy link

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK

src/rpc/blockchain.cpp Outdated Show resolved Hide resolved
Co-authored-by: thephez <thephez@users.noreply.github.com>
Copy link

@UdjinM6 UdjinM6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK

Copy link
Member

@PastaPastaPasta PastaPastaPasta left a 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

@PastaPastaPasta PastaPastaPasta merged commit 216a5f7 into dashpay:develop Nov 10, 2023
8 checks passed
@knst knst deleted the refactor-mnehf-manager branch November 10, 2023 14:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RPC Some notable changes to RPC params/behaviour/descriptions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants