-
Notifications
You must be signed in to change notification settings - Fork 217
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
Fix synchrony constraint calculation when latest block is older than approved #3269
Fix synchrony constraint calculation when latest block is older than approved #3269
Conversation
approvedBlockNumber = ProtoUtil.blockNumber(approvedBlock) | ||
latestBlockBehindApproved = approvedBlockNumber > lastProposedBlockMeta.blockNum | ||
|
||
allowedToPropose <- if (latestBlockBehindApproved) true.pure[F] else checkConstraint |
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 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.
@tgrospic I feel that using lastProposedTuplespace for fetching active validators is not correct - you have to use state that you are trying to propose on top of, so, basically, state of the main parent. Wdy think?
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.
@nzpr makes sense to use main parent. Do you know why is state from latest block used now?
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.
@tgrospic not really, I don't see why its more preferable then main parent.
@@ -17,8 +17,8 @@ | |||
</appender> | |||
|
|||
<logger name="coop.rchain.shared.EventLogger" level="OFF" /> | |||
<logger name="coop.rchain.rspace" level="info" /> |
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.
Enable info messages from RSpace.
8640117
to
6be0f82
Compare
6be0f82
to
c7df1e9
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.
LGTM
activeValidators <- runtimeManager.getActiveValidators(mainParentStateHash) | ||
|
||
// Validators weight map filtered by active validators only. | ||
validatorWeightMap = lastProposedBlockMeta.weightMap.filter { |
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 overlooked this, but I think this also should be main parent weight map. Not sure if this is crucial though.
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.
Yes, we are using active validators from main parent and use in filter from the latest block. I'll create a fix.
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.
Fix in PR #3274.
} | ||
// Guaranteed to be present since last proposed block was present | ||
seenSenders <- calculateSeenSendersSince(lastProposedBlockMeta, dag) | ||
sendersWeight = seenSenders.toList.flatMap(validatorWeightMap.get).sum |
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.
@nzpr I'm not sure is it possible here that validatorWeightMap
doesn't have validator calculated as seen sender?
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.
@nzpr nvm, this is already handled.
Overview
When validator propose a block it must satisfy synchrony constraint which depends on reading active validators from tuple space. When LFS state is downloaded and validator latest block is older then approved block, we don't have tuple state for that block. This PR adds this detection and allow validator to propose.
Another small fix to Engine initialization. The bug manifested when LFS node received the state, LFS exporter was not enabled although the flag was set.
Please make sure that this PR:
Bors cheat-sheet:
bors r+
runs integration tests and merges the PR (if it's approved),bors try
runs integration tests for the PR,bors delegate+
enables non-maintainer PR authors to run the above.