-
Notifications
You must be signed in to change notification settings - Fork 176
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
[BFT] model.Proposal
refactoring
#6526
base: master
Are you sure you want to change the base?
Conversation
…otstuff proposal. Updated SafetyRules interface and implementation
…/6517-proposal-refactoring
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6526 +/- ##
==========================================
- Coverage 41.27% 41.15% -0.13%
==========================================
Files 2030 2031 +1
Lines 145822 179602 +33780
==========================================
+ Hits 60186 73912 +13726
- Misses 79419 99491 +20072
+ Partials 6217 6199 -18
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Co-authored-by: Jordan Schalm <jordan.schalm@flowfoundation.org>
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.
very cool. Thanks for the cleanup. Mostly minor comments regarding documentation.
// This codifies the important aspect that a proposer's signature for their own block | ||
// is conceptually also just a vote (we explicitly use that for aggregating votes, including the | ||
// proposer's own vote to a QC). In order to express this conceptual equivalence in code, the | ||
// voting logic in Safety Rules must also operate on an unsigned Proposal. | ||
type Proposal struct { |
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.
type Proposal struct { | |
// | |
// NOTE: LastViewTC is auxiliary data that must accompany a pending proposal until it is | |
// certified. Atm, we include LastViewTC in the `flow.Header` but that is not strictly needed. | |
// Conceptually, LastViewTC is only needed to prove that the proposer entered the block's view | |
// according to protocol rules. Thereby we protect the consensus process from malicious leaders | |
// attempting to skip views that haven't concluded yet (a form of front-running attack). | |
// However, the LastViewTC is only relevant until a proposed block has been certified. | |
// Thereafter, the QC attests that honest consensus participants have inspected the LastViewTC | |
// and found it to be valid. At that point, the LastViewTC is no longer needed. Therefore, | |
// the LastViewTC is auxiliary data that must accompany a pending proposal until it is | |
// certified but LastViewTC does not need to be part of the block itself. | |
// | |
// TODO: atm, the flow.Header embeds the LastViewTC and also includes it when computing the | |
// block's ID. This is simpler from an implementation perspective, but the LastViewTC wastes | |
// some communication bandwidth when relaying certified blocks to the consensus followers. | |
type Proposal struct { |
consensus/hotstuff/votecollector/combined_vote_processor_v3_test.go
Outdated
Show resolved
Hide resolved
Co-authored-by: Alexander Hentschel <alex.hentschel@flowfoundation.org>
Co-authored-by: Alexander Hentschel <alex.hentschel@flowfoundation.org>
…st.go Co-authored-by: Alexander Hentschel <alex.hentschel@flowfoundation.org>
…onflow/flow-go into yurii/6517-proposal-refactoring
#6517
Context
This PR implements refactoring of
model.Proposal
, all details are in attached issue. This PR very closes follows proposed solution.