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: deglobalization of bls_legacy_scheme 2/N #5443

Merged
merged 5 commits into from
Jul 1, 2023

Conversation

knst
Copy link
Collaborator

@knst knst commented Jun 19, 2023

Issue being fixed or feature implemented

Many usages of CBLS{Signature,PrivateKey,PublicKey} assume using global variable, even if can be specified explicitly.
Some of these usages have been deglobalized in this PR.

Some prior improvements and fixes are here: #5403

What was done?

  • Refactored the uses of global variable of bls_legacy_scheme from SetHex, SetByteVector, some rpc calls.
  • Removed flag checkMalleable to simplify code because it's always true.
  • Removed dependency from txmempool.h on bls.h to speed up compilation.

How Has This Been Tested?

Run unit/functional tests.

Breaking Changes

No breaking changes assumed. But in theory behaviour of some RPC can be more explicit and predictable.

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 changed the title refactor: deglobalization of bls_legacy_scheme part 2/N refactor: deglobalization of bls_legacy_scheme 2/N Jun 19, 2023
@knst knst added this to the 20 milestone Jun 19, 2023
@knst knst requested review from ogabrielides and UdjinM6 and removed request for ogabrielides June 19, 2023 12:18
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.

Reindexed on testnet with no issues 👍

Pls see some suggestions in rpc code.

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

UdjinM6 commented Jun 20, 2023

Looks good but Check Merge Fast-Forward Only complains... pls rebase on the recent develop nvm, rebased it via GH

ogabrielides
ogabrielides previously approved these changes Jun 20, 2023
Copy link
Collaborator

@ogabrielides ogabrielides left a comment

Choose a reason for hiding this comment

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

LGTM. Let's wait for CI

@UdjinM6
Copy link

UdjinM6 commented Jun 20, 2023

hmm... so one of my suggestions was wrong https://gitlab.com/dashpay/dash/-/jobs/4505250574#L2394 and we need to partially revert 668d00d now (pls see 140c1cb).

EDIT: On the bright side, I reindex both on mainnet and testnet with no issues :)

@knst
Copy link
Collaborator Author

knst commented Jun 20, 2023

EDIT: On the bright side, I reindex both on mainnet and testnet with no issues :)

So far as I understand, the RPC verifychainlock can success (or partially success) even if we don't have this block in chain yet. So, behavior in this case indeed changed (and CI failed), but it is not a regular situation, that can not be reproduced easily without an intention. The test rpc_verifychainlock.py indeed checks this corner case.

UdjinM6
UdjinM6 previously approved these changes Jun 20, 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.

👍

lightly tested ACK (reindexed with no issues)

ogabrielides
ogabrielides previously approved these changes Jun 21, 2023
Copy link
Collaborator

@ogabrielides ogabrielides 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

@UdjinM6 UdjinM6 requested a review from PastaPastaPasta June 21, 2023 09:46
@@ -167,7 +167,7 @@ class CProUpServTx
}
if (!(s.GetType() & SER_GETHASH)) {
READWRITE(
CBLSSignatureVersionWrapper(const_cast<CBLSSignature&>(obj.sig), (obj.nVersion == LEGACY_BLS_VERSION), true)
CBLSSignatureVersionWrapper(const_cast<CBLSSignature&>(obj.sig), (obj.nVersion == LEGACY_BLS_VERSION))
Copy link
Member

Choose a reason for hiding this comment

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

I'd request dropping b2d41f6 (maybe modulo this line's change) as it's not related to the deglobalization and it may be something we SHOULD use when reindexing... I'll have to check perf at some point.

Copy link
Collaborator Author

@knst knst Jun 22, 2023

Choose a reason for hiding this comment

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

There's big dangerous of how it is implemented right now.

Currently, there are 2 methods Unserialize, that has both default arguments:

template
inline void Unserialize(Stream& s, const bool specificLegacyScheme, bool checkMalleable = true);
template
inline void Unserialize(Stream& s, bool checkMalleable = true);

Let's assume that I am calling Unserialize(s, true) - it's very non-obvious which one will be called and not error prune at all.

It should be re-implemented, and there should not be default argument. Let's create an issue "check performance of Unserialize with/without checkMalleable flag" - but I really want to remove this confusing method in this PR

Reverting this change and adding new interface in future won't be difficult task so far as changes are quite trivial.

Comment on lines 152 to 155
if (obj.nVersion != BASIC_BLS_VERSION && obj.nType == MnType::HighPerformance) {
// for HPMN should be only BASIC bls, bail out early
return;
}
Copy link
Member

Choose a reason for hiding this comment

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

5989de8 should probably be it's own PR... maybe even a backport?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

why do backporting only this commit but not other commits in this PR? What's a difference?

@@ -989,14 +989,15 @@ void CDKGSession::SendCommitment(CDKGPendingMessages& pendingMessages)
qc.sig = WITH_LOCK(activeMasternodeInfoCs, return activeMasternodeInfo.blsKeyOperator->Sign(commitmentHash));
qc.quorumSig = skShare.Sign(commitmentHash);

const bool is_bls_legacy = bls::bls_legacy_scheme.load();
Copy link
Member

Choose a reason for hiding this comment

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

please do this at the call site to avoid an atomic read when we basically never lie

Comment on lines +311 to +312
const auto pindex = llmq::utils::V19ActivationIndex(::ChainActive().Tip());
bool is_bls_legacy_scheme = pindex == nullptr || nTime < pindex->pprev->nTime;
Copy link
Member

Choose a reason for hiding this comment

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

this would need cs_main locked?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

should it? if so, probably there's bug also in this commit:

 bool CGovernanceVote::CheckSignature(const CBLSPublicKey& pubKey) const
 {
-    if (!CBLSSignature(vchSig).VerifyInsecure(pubKey, GetSignatureHash())) {
+    CBLSSignature sig;
+    const auto pindex = llmq::utils::V19ActivationIndex(::ChainActive().Tip());
+    bool is_bls_legacy_scheme = pindex == nullptr || nTime < pindex->nTime;
+    sig.SetByteVector(vchSig, is_bls_legacy_scheme);
+    if (!sig.VerifyInsecure(pubKey, GetSignatureHash())) {
         LogPrintf("CGovernanceVote::CheckSignature -- VerifyInsecure() failed\n");
         return false;
     }

Copy link

Choose a reason for hiding this comment

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

::ChainActive() locks it inside

@@ -7,6 +7,7 @@

#include <batchedlogger.h>

#include <bls/bls.h>
Copy link
Member

Choose a reason for hiding this comment

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

why?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Because CDGKContribution has members of type CBLSSignature:

    CBLSSignature quorumSig; // threshold sig share of quorumHash+validMembers+pubKeyHash+vvecHash
    CBLSSignature sig; // single member sig of quorumHash+validMembers+pubKeyHash+vvecHash

This object is declared in bls/bls.h that is missing to be in list of includes.
Code is compilable because bls/bls_ies.h includes recursively bls/bls.h, but better to include it explicitly.

@knst knst dismissed stale reviews from ogabrielides and UdjinM6 via ac5af56 June 22, 2023 19:07
@knst knst requested a review from PastaPastaPasta June 22, 2023 19:07
@UdjinM6
Copy link

UdjinM6 commented Jun 22, 2023

@knst In ac5af56 you did the opposite of what @PastaPastaPasta suggested I think. The idea was to move atomic read inside if/else if to avoid doing that outside of tests.

@knst
Copy link
Collaborator Author

knst commented Jun 24, 2023

@knst In ac5af56 you did the opposite of what @PastaPastaPasta suggested I think. The idea was to move atomic read inside if/else if to avoid doing that outside of tests.

as pasta says:

Atomic reads are slightly intensive so best to avoid when possible.

Updated, thanks for notice.

UdjinM6
UdjinM6 previously approved these changes Jun 27, 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

@PastaPastaPasta
Copy link
Member

PastaPastaPasta commented Jun 28, 2023

Still not super happy here... This PR is just doing too many things imo; options are to split into a few different PRs that only really do 1 thing or get the git log to be clean enough so that it'd make sense to merge via a merge commit. I think preference is multiple PRs. (I think I'm okay with all the actual code changes, just not the PR :) )

ogabrielides
ogabrielides previously approved these changes Jun 28, 2023
Copy link
Collaborator

@ogabrielides ogabrielides left a comment

Choose a reason for hiding this comment

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

re-ACK

knst added 4 commits June 28, 2023 15:26
txmempool.h is widely used header and the dependency bls.h should not be spread
to all usages of mempool.

It also noticeable improve compilation speed of project if bls.h has been changed.
@knst knst dismissed stale reviews from ogabrielides and UdjinM6 via c5b55d3 June 28, 2023 08:27
@knst knst force-pushed the bls-deglobal-v2 branch from 8e6a914 to c5b55d3 Compare June 28, 2023 08:27
@knst
Copy link
Collaborator Author

knst commented Jun 28, 2023

it split to #5462 and #5463

Remaining changes are rebased.

ogabrielides
ogabrielides previously approved these changes Jun 28, 2023
Copy link
Collaborator

@ogabrielides ogabrielides left a comment

Choose a reason for hiding this comment

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

re-ACK

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.

it looks like you (unintentionally?) dropped some related changes on rebase

@knst
Copy link
Collaborator Author

knst commented Jun 28, 2023

Probably lost after rebase. Let me check...

+partiall revert "refactor: simplification of rpc/quorums.cpp bcs pindex can't be nullptr"

in some cases - can!
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
Collaborator

@ogabrielides ogabrielides 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 07fd889 into dashpay:develop Jul 1, 2023
PastaPastaPasta pushed a commit that referenced this pull request Jul 3, 2023
## Issue being fixed or feature implemented
Current implementation of BLS wrapper has an unclear interface related
to `checkMalleable` flag.

There are 2 methods Unserialize, that has both default arguments:

```
template
inline void Unserialize(Stream& s, const bool specificLegacyScheme, bool checkMalleable = true);
template
inline void Unserialize(Stream& s, bool checkMalleable = true);
```

Let's assume that I am calling `Unserialize(s, true)` - it's very
non-obvious which one will be called and not error prune at all.

It should be re-implemented, and there should not be default argument. 

Pasta noticed that this flag can be useful from performance point of
view - let's have better new method such as `UnserializeNoMalleable` or
similar and use it when reindexing/etc. It should be specified explicit.

Reverting this change and adding new interface in future won't be
difficult task so far as changes are quite trivial.


## What was done?
Removed flag checkMalleable to simplify code because it's always true.
It splits from #5443


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

## Breaking Changes
No breaking changes - flag is always true.

## 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
PastaPastaPasta pushed a commit that referenced this pull request Nov 8, 2023
…Evo Nodes (#5463)

## Issue being fixed or feature implemented
#5471


## What was done?
It splits from #5443

Adds extra unit tests for BLS basic scheme; enforces BLS basic for Evo
Nodes in serialization/unserialization of CProRegTx, CProUpServTx.

## How Has This Been Tested?
Run functional/unit tests + added new unit tests.

## Breaking Changes
Serialization slightly changed, but it should be not breaking change

## 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
- [ ] I have made corresponding changes to the documentation
- [x] I have assigned this pull request to a milestone
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.

4 participants