-
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/feat: Refactor and add safety belts in llmq utils #5378
Conversation
…to be more precise which block index we actually expect
@@ -65,6 +65,7 @@ void PreComputeQuorumMembers(const CBlockIndex* pindex, bool reset_cache) | |||
|
|||
uint256 GetHashModifier(const Consensus::LLMQParams& llmqParams, const CBlockIndex* pCycleQuorumBaseBlockIndex) | |||
{ | |||
ASSERT_IF_DEBUG(pCycleQuorumBaseBlockIndex->nHeight % llmqParams.dkgInterval == 0); |
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 kinda wonder if we should create an "ASSUME" macro or something similar which if debug is enabled with act as an assert, but if not debug would print to log if the assumption was false? Idk, probably not the most useful
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.
light-utACK for squash merge... I do think it'd be better to have some way to tell which condition failed
it fails like that (I broke
|
void PreComputeQuorumMembers(const CBlockIndex* pQuorumBaseBlockIndex, bool reset_cache = false); | ||
uint256 GetHashModifier(const Consensus::LLMQParams& llmqParams, const CBlockIndex* pQuorumBaseBlockIndex); | ||
void PreComputeQuorumMembers(const CBlockIndex* pindex, bool reset_cache = false); | ||
uint256 GetHashModifier(const Consensus::LLMQParams& llmqParams, const CBlockIndex* pCycleQuorumBaseBlockIndex); |
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.
My only "objection" is here. GetHashModifier
is called for both non-rotated and rotated quorums, hence "cycle" is more adapted to rotation.
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.
for non-rotation quorums pCycleQuorumBaseBlockIndex == pQuorumBaseBlockIndex
and since using pQuorumBaseBlockIndex
for rotation ones is wrong using pCycleQuorumBaseBlockIndex
for both is a good compromise imo
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.
Besides above comment, LGTM
Issue being fixed or feature implemented
We use
pQuorumBaseBlockIndex
name when we shouldn't and we don't check that quorum types and block indexes provided as input params in llmq utils satisfy our requirements. This is kind of ok-ish as long as we use these functions appropriately but it's better to make things clearer and to have actual checks imo.noticed this while reviewing #5366
What was done?
Rename
pQuorumBaseBlockIndex
topCycleQuorumBaseBlockIndex
/pindex
in a few places. Check that quorum types and block indexes have expected values.How Has This Been Tested?
run tests locally
Breaking Changes
n/a
Checklist: