github.com/koko1123/flow-go-1@v0.29.6/module/hotstuff.go (about)

     1  package module
     2  
     3  import (
     4  	"github.com/koko1123/flow-go-1/model/flow"
     5  )
     6  
     7  // HotStuff defines the interface to the core HotStuff algorithm. It includes
     8  // a method to start the event loop, and utilities to submit block proposals
     9  // received from other replicas.
    10  type HotStuff interface {
    11  	ReadyDoneAware
    12  	Startable
    13  
    14  	// SubmitProposal submits a new block proposal to the HotStuff event loop.
    15  	// This method blocks until the proposal is accepted to the event queue.
    16  	//
    17  	// Block proposals must be submitted in order and only if they extend a
    18  	// block already known to HotStuff core.
    19  	SubmitProposal(proposal *flow.Header, parentView uint64) (done <-chan struct{})
    20  }
    21  
    22  // HotStuffFollower is run by non-consensus nodes to observe the block chain
    23  // and make local determination about block finalization. While the process of
    24  // reaching consensus (while guaranteeing its safety and liveness) is very intricate,
    25  // the criteria to confirm that consensus has been reached are relatively straight
    26  // forward. Each non-consensus node can simply observe the blockchain and determine
    27  // locally which blocks have been finalized without requiring additional information
    28  // from the consensus nodes.
    29  //
    30  // Specifically, the HotStuffFollower informs other components within the node
    31  // about finalization of blocks. It consumes block proposals broadcasted
    32  // by the consensus node, verifies the block header and locally evaluates
    33  // the finalization rules.
    34  //
    35  // Notes:
    36  //   - HotStuffFollower does not handle disconnected blocks. Each block's parent must
    37  //     have been previously processed by the HotStuffFollower.
    38  //   - HotStuffFollower internally prunes blocks below the last finalized view.
    39  //     When receiving a block proposal, it might not have the proposal's parent anymore.
    40  //     Nevertheless, HotStuffFollower needs the parent's view, which must be supplied
    41  //     in addition to the proposal.
    42  type HotStuffFollower interface {
    43  	ReadyDoneAware
    44  
    45  	// SubmitProposal feeds a new block proposal into the HotStuffFollower.
    46  	// This method blocks until the proposal is accepted to the event queue.
    47  	//
    48  	// Block proposals must be submitted in order, i.e. a proposal's parent must
    49  	// have been previously processed by the HotStuffFollower.
    50  	SubmitProposal(proposal *flow.Header, parentView uint64) (done <-chan struct{})
    51  }