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

feat: improvements for v19, v20 and dip3 - fire up test chains by first block 5/n #6269

Merged
merged 9 commits into from
Sep 27, 2024

Conversation

knst
Copy link
Collaborator

@knst knst commented Sep 13, 2024

Issue being fixed or feature implemented

This PR is 5th in the achieving ultimate goal to activate old forks from block 1.
It helps to run unit and functional tests faster; it helps for platform's dev-environment to start faster.

What was done?

  • v20 on RegTest is activated from same block as v19 (height 1200 changed to 900)
  • relaxed condition for special transactions Asset Lock (can be mined any block so far as v20 is activated long time ago).
  • unify code for regtest, mainnet, testnet for Asset Unlock validation
  • removed 2 checkpoints: TestChainDIP3Setup and TestChainV19Setup from unit tests which make further changes for forks easier
  • enforced flag fast_dip3_enforcement=True from functional tests which is always true

How Has This Been Tested?

Run unit and functional tests

tsan job runs 500 seconds faster of real time and 2000seconds faster for "accumulated time"
https://gitlab.com/dashpay/dash/-/jobs/7817453421 - this PR
https://gitlab.com/dashpay/dash/-/jobs/7805625816 - some old PR for reference

No breakdown per tests here, because they affect each other and runs in parallel.

Breaking Changes

Regtest has v20 activated on same block as v19 if otherwise is not specified with -testactivationheight=v20@1200

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 this to the 21.2 milestone Sep 13, 2024
@knst knst changed the title feat: improvements for v19, v20 and dip3 - fire up test chains by first block 5/n feat: improvements for v19, v20 and dip3 - fire up test chains by first block 5/n Sep 13, 2024
@@ -53,18 +53,11 @@ static bool CheckSpecialTxInner(CDeterministicMNManager& dmnman, const Chainstat
}
return CheckMNHFTx(chainman, qman, tx, pindexPrev, state);
case TRANSACTION_ASSET_LOCK:
if (!DeploymentActiveAfter(pindexPrev, consensusParams, Consensus::DEPLOYMENT_V20)) {
Copy link

Choose a reason for hiding this comment

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

why keeping similar checks for "unlock" and "mnhf" if we drop this one?

Copy link
Member

Choose a reason for hiding this comment

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

@UdjinM6 don't we normally keep checks like this? for stuff like new devnets, or in case someone is sending us a bad fork I guess?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

what will happen if someone will send us a bad fork for devnet? If fork will be accepted - that's fine, whatever it has asset-unlock/mnehf/etc transaction or not. we have chainlocks also.

That's important to keep conditions like that if they change behavior incompatible way. For example DIP0001 has not only introduced a bigger blocks size, but also introduced a limit for size of transaction and some old blocks do not satisfy that requirement. So, for that type of consensus condition we should keep it, otherwise mainnet/testnet can't re-sync properly for old blocks. But there's completely fine.

Can you show in our code base any condition like that which we keep intentionally over-versions?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

also, we have all soft-forks on all devnets activated from blocks 300 (soon from block 2), so, it should not be a problem also
https://github.com/dashpay/dash/pull/6187/files#diff-ff53e63501a5e89fd650b378c9708274df8ad5d38fcffa6c64be417c4d438b6dL568-L573

Copy link

@UdjinM6 UdjinM6 Sep 23, 2024

Choose a reason for hiding this comment

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

with headers-first sync and assumevalid in place these checks do not matter that much anymore and we can drop them safely imo

@knst knst requested a review from UdjinM6 September 14, 2024 05:35
UdjinM6
UdjinM6 previously approved these changes Sep 14, 2024
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 4950be0

UdjinM6
UdjinM6 previously approved these changes Sep 14, 2024
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 07c510f

Copy link

This pull request has conflicts, please rebase.

@knst
Copy link
Collaborator Author

knst commented Sep 17, 2024

@knst knst force-pushed the forks-speedup-p4 branch from 07c510f to c422e37

rebased due to conflict with #6271

UdjinM6
UdjinM6 previously approved these changes Sep 17, 2024
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.

rebase looks clean

re-utACK c422e37

Comment on lines -62 to -67
if (Params().NetworkIDString() != CBaseChainParams::REGTEST && !DeploymentActiveAfter(pindexPrev, consensusParams, Consensus::DEPLOYMENT_MN_RR)) {
return state.Invalid(TxValidationResult::TX_CONSENSUS, "assetunlocks-before-mn_rr");
}
Copy link
Member

Choose a reason for hiding this comment

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

same as before comment, re: devnets bad chain etc?

Comment on lines -51 to -53
if (!DeploymentActiveAfter(pindexPrev, consensusParams, Consensus::DEPLOYMENT_V20)) {
return state.Invalid(TxValidationResult::TX_CONSENSUS, "mnhf-before-v20");
}
Copy link
Member

Choose a reason for hiding this comment

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

same

Copy link

This pull request has conflicts, please rebase.

UdjinM6
UdjinM6 previously approved these changes Sep 24, 2024
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 cad8aff

@knst
Copy link
Collaborator Author

knst commented Sep 25, 2024

@knst knst force-pushed the forks-speedup-p4 branch from cad8aff to cd037ad

Force pushed due to CI failure after rebase. There's extra fix now

@knst knst requested a review from UdjinM6 September 25, 2024 13:34
UdjinM6
UdjinM6 previously approved these changes Sep 25, 2024
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 cd037ad

Copy link

This pull request has conflicts, please rebase.

V20 is activated long time on mainnet and testnet, so, it doesn't matter anymore
…works

It simplify implementation and unify RegTest, Mainnet and Testnet
No asset-unlock transaction has actually be mined yet, but v20 and mn_rr are activated long time ago.
So, this changes are not breaking changes
… from unit tests

It takes time to update each checkpoint if any forks changes in unit tests: new height,
new bit, and extra params. Reduced scope of changes for future updates
It also change dip3params default from 30:50 to 2:2
De facto, that always equals True, so, there's no meaning to have it
It is not a breaking changes, because this fork is already happened in past
and no EHF transaction is in blockchain at that moment which requires versioning
This fork already happened and no versioning is required
@knst
Copy link
Collaborator Author

knst commented Sep 26, 2024

@knst knst force-pushed the forks-speedup-p4 branch from 0da73ac to 643f9bc
@knst knst force-pushed the forks-speedup-p4 branch from 643f9bc to 6030611

last 2 force-pushes due to rebase mistakes

@knst
Copy link
Collaborator Author

knst commented Sep 26, 2024

utACK https://github.com/dashpay/dash/commit/4950be0df22b23346004c191787424f899e6819f
utACK https://github.com/dashpay/dash/commit/07c510fa08d7ec8335b9bf3090276a5d860dc05b
>  This pull request has conflicts, please rebase.
re-utACK https://github.com/dashpay/dash/commit/c422e37181cb1a3353df9184b39272bfe2429dd5
> This pull request has conflicts, please rebase.
utACK https://github.com/dashpay/dash/commit/cad8aff1fd963bf9cfe2fc9e20289d95f3465f59
> Force pushed due to [CI failure](https://gitlab.com/dashpay/dash/-/jobs/7906337253) after rebase. There's extra fix now
utACK https://github.com/dashpay/dash/commit/cd037ad15bed4431d6bb0088343b444f3f836e1f
> This pull request has conflicts, please rebase.
> @knst knst force-pushed the forks-speedup-p4 branch from 0da73ac to 643f9bc
> @knst knst force-pushed the forks-speedup-p4 branch from 643f9bc to 6030611
...

what a journey! @PastaPastaPasta please, help with this PR finally

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 6030611

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 6030611

@PastaPastaPasta PastaPastaPasta merged commit 9b21aef into dashpay:develop Sep 27, 2024
27 checks passed
@knst knst deleted the forks-speedup-p4 branch September 27, 2024 04:59
PastaPastaPasta added a commit that referenced this pull request Oct 1, 2024
…ck - 6/n

9a9d0d5 feat: drop SPORK 24 (EHF) so far as this feature works on testnet / mainnet (Konstantin Akimov)
da0dc06 perf: optimize feature_mnehf.py by generating less blocks (Konstantin Akimov)
0de3923 feat: bury fork mn_rr (masternode reward reallocation) (Konstantin Akimov)

Pull request description:

  ## Issue being fixed or feature implemented
  MN_RR is activated on mainnet: time to bury it!

  ## What was done?
  Hard-fork mn_rr is buried. Prior fixes are done here: #6270 and #6269

  ## How Has This Been Tested?
  Run unit and functional tests

  ## Breaking Changes
  N/A

  ## Checklist:
  - [x] I have performed a self-review of my own code
  - [x] I have commented my code, particularly in hard-to-understand areas
  - [x] I have added or updated relevant unit/integration/functional/e2e tests
  - [x] I have made corresponding changes to the documentation
  - [x] I have assigned this pull request to a milestone

ACKs for top commit:
  UdjinM6:
    light ACK 9a9d0d5
  PastaPastaPasta:
    utACK 9a9d0d5

Tree-SHA512: 73ea0ca1270f15f6f1193efbaf402d476c84e9a843af85b7eae3e40199f4c943ad40f58e062b8db20e1c5c69c1a85579ebaf0722f1044ee2e1a4e7f96c58e645
@UdjinM6 UdjinM6 modified the milestones: 21.2, 22 Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants