Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type NewestForkChoice ¶
type NewestForkChoice struct {
// contains filtered or unexported fields
}
NewestForkChoice implements HotStuff's original fork choice rule: always use the newest QC (i.e. the QC with highest view number)
func NewNewestForkChoice ¶
func NewNewestForkChoice(finalizer *finalizer.Finalizer, notifier hotstuff.Consumer) (*NewestForkChoice, error)
NewNewestForkChoice creates a new NewNewestForkChoice instance
func (*NewestForkChoice) AddQC ¶
func (fc *NewestForkChoice) AddQC(qc *flow.QuorumCertificate) error
AddQC updates `preferredParent` according to the fork-choice rule. Currently, we implement 'Chained HotStuff Protocol' where the fork-choice rule is: "build on newest QC" It assumes the QC has been validated
func (*NewestForkChoice) MakeForkChoice ¶
func (fc *NewestForkChoice) MakeForkChoice(curView uint64) (*flow.QuorumCertificate, *model.Block, error)
MakeForkChoice prompts the ForkChoice to generate a fork choice for the current view `curView`. NewestForkChoice always returns the qc with the largest view number seen. It returns a qc and the block that the qc is pointing to.
PREREQUISITE: ForkChoice cannot generate ForkChoices retroactively for past views. If used correctly, MakeForkChoice should only ever have processed QCs whose view is smaller than curView, for the following reason: Processing a QC with view v should result in the PaceMaker being in view v+1 or larger. Hence, given that the current View is curView, all QCs should have view < curView. To prevent accidental miss-usage, ForkChoices will error if `curView` is smaller than the view of any qc ForkChoice has seen. Note that tracking the view of the newest qc is for safety purposes and _independent_ of the fork-choice rule.
Source Files