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

Handle empty notarizations #97

Merged
merged 3 commits into from
Feb 25, 2025
Merged

Handle empty notarizations #97

merged 3 commits into from
Feb 25, 2025

Conversation

yacovm
Copy link
Collaborator

@yacovm yacovm commented Feb 21, 2025

No description provided.

@yacovm yacovm marked this pull request as draft February 21, 2025 01:47
@yacovm yacovm force-pushed the handleEmptyNot branch 3 times, most recently from 65b2e16 to 3354ca8 Compare February 21, 2025 20:57
@yacovm yacovm marked this pull request as ready for review February 21, 2025 21:04
@@ -918,7 +902,8 @@ func (e *Epoch) maybeAssembleEmptyNotarization() error {

emptyNotarization := &EmptyNotarization{QC: qc, Vote: popularEmptyVote}

return e.persistEmptyNotarization(emptyNotarization)
// Persist the empty notarization and also broadcast it to everyone
return e.persistEmptyNotarization(emptyNotarization, true)
Copy link
Collaborator

Choose a reason for hiding this comment

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

i think we should avoid adding the shouldBroadcast flag to the function and just broadcast it after calling persist

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's not possible. Inside persistEmptyNotarization we increment the round and call errors.Join(e.startRound(), e.maybeLoadFutureMessages()), so if we do it outside we'll advance to the next round without broadcasting it. While it's possible that we stop at some layer of the recursion and fold it back and then broadcast, I don't like this because we would be sending messages for higher rounds before this round, and I think we should finish doing everything regarding this round before we proceed to the next one.

}

// Ignore votes for rounds too far ahead
if vote.Round-e.round > e.maxRoundWindow {
Copy link
Collaborator

Choose a reason for hiding this comment

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

not for this pr, but we have a lot of checks for messages that are too far ahead in other handle functions. Maybe its worth creating a helper e.isMessageTooFarAhead(round) ? i don't mind making this pr

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

makes sense, feel free to go for it.

epoch.go Outdated
@@ -962,11 +947,12 @@ func (e *Epoch) persistEmptyNotarization(emptyNotarization *EmptyNotarization) e

e.emptyVotes[emptyNotarization.Vote.Round].emptyNotarization = emptyNotarization
Copy link
Collaborator

Choose a reason for hiding this comment

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

why do we set the empty notarization here? Since we are increasing the round, shouldn't we delete the round from emptyVotes? If not here, i think we should be deleting somewhere

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

good catch, fixed!

This commit adds handling for empty notarizations received from other nodes.
It prevents re-broadcasting when persisting such empty notarizations.

We can only handle an empty notarization if we have not notarized the round.

Signed-off-by: Yacov Manevich <[email protected]>
@yacovm yacovm merged commit b8fec1e into main Feb 25, 2025
4 checks passed
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.

2 participants