This issue is based on [this PR comment](noted by Yurii).

Context

Currently, we have a different kinds of blocks in our code base:

• flow.Block

  flow-go/model/flow/block.go

  Lines 29 to 34 in c271a58

  	// Block (currently) includes the header, the payload hashes as well as the
  	// payload contents.
  	type Block struct {
  	Header *Header
  	Payload *Payload
  	}

• Collections, which are conceptually also blocks from the perspective of the cluster consensus:

  flow-go/model/cluster/block.go

  Lines 27 to 32 in c271a58

  	// Block represents a block in collection node cluster consensus. It contains
  	// a standard block header with a payload containing only a single collection.
  	type Block struct {
  	Header *flow.Header
  	Payload *Payload
  	}

• HotStuff's abstract notion of a block

  flow-go/consensus/hotstuff/model/block.go

  Lines 9 to 18 in c271a58

  	// Block is the HotStuff algorithm's concept of a block, which - in the bigger picture - corresponds
  	// to the block header.
  	type Block struct {
  	View uint64
  	BlockID flow.Identifier
  	ProposerID flow.Identifier
  	QC *flow.QuorumCertificate
  	PayloadHash flow.Identifier
  	Timestamp time.Time
  	}

Using a separate block struct for HotStuff introduces code duplication, ambiguity. Furthermore, other components ingesting notifications often lack auxiliary information not contained in the HotStuff block. This leads to ambiguity and conceptual complexity.

When implementing HotStuff, we have emphasized a strong separation from the rest of the protocol, which has two benefits: We can easily isolate HotStuff to run scientific consensus experiments, or use it for other purposes. Second, the remainder of the protocol also becomes relatively agnostic about consensus, which simplifies upgrading and evolving Flow's consensus implementation. This is the reason, why HotStuff has its own high-level notion of blocks, because payload and header contain lots of information that is entirely irrelevant for HotStuff.

Suggestion

In my opinion, it would be best to change HotStuff to work with:

• a Block interface:
  • has getter-methods to expose the information that we currently hold in these fields:

    flow-go/consensus/hotstuff/model/block.go

    Lines 12 to 15 in c271a58

    	View uint64
    	BlockID flow.Identifier
    	ProposerID flow.Identifier
    	QC *flow.QuorumCertificate

  • In my opinion, the following could be dropped from HotStuff's block interface:

    flow-go/consensus/hotstuff/model/block.go

    Lines 16 to 17 in c271a58

    	PayloadHash flow.Identifier
    	Timestamp time.Time

    because they are never used (except for generic logging).
• The notion of QC is foundational to HotStuff.
  • I would suggest to represent QCs in HotStuff via their own interface. The interface enables us to define important structures such as

    flow-go/consensus/hotstuff/model/block.go

    Lines 48 to 55 in b8f54ac

    	// CertifiedBlock holds a certified block, which is a block and a QC that pointing to it.
    	// A QC is the aggregated form of votes from a supermajority of HotStuff participants.
    	// Existence of a QC proves validity of the block. A certified block satisfies:
    	// Block.View == QC.View and Block.BlockID == QC.BlockID
    	type CertifiedBlock struct {
    	Block *Block
    	QC *flow.QuorumCertificate
    	}