Martin/5092 mutator seals

[arrivets]

This PR addresses issue 5092

Update Mutator sealExtend

• Check that seals correspond to IncorporatedResults on the current fork

• Create IsValidSeal stub which should check the cryptographic integrity of the
  seal and verify that it has collected enough approval signatures based on
  the chunk assignment derived from the IncorporatedResult

[AlexHentschel]

This is a great PR; thanks Martin.
Very well documented and tested 👏 .

I only have a couple minor stylistic suggestions. It also would be great to add a few more test cases:

• see my suggestion for extending TestExtendSealNoIncorporatedResult
• Mutator rejects duplicated seals:
  • seal was already included in a parent block
  • two seals for the same block are included in the same payload

(In case there are already tests for some of the listed scenarios, my apologies. Feel free to just skip)

[jordanschalm]

Looks good, nice work! 💯

[jordanschalm]

Suggested change

	// for an execution result, we don't need top updated it.
	// for an execution result, we don't need to update it.

[jordanschalm]

Since we have both receipts and blocks here with names first..., I'd suggest including the type in the names for both (eg. firstBlock or block1 and receipt1)

[jordanschalm]

We have variables seal and firstSeal - I'd suggest renaming to seal to rootSeal to disambiguate, especially for the assertions at the end of the test

[zhangchiqing]

This assumes the parent seal must be found. Could we add a comment explaining why?

[AlexHentschel]

Do you mean, why it would be an unexpected internal error if we didn't find the latest seal in the fork?
I think the explanation would be

// Get the latest seal in the fork that ends with block `ParentID`.  The protocol state saves this 
// information for each block that has been successfully added the chain tree. Prior to entering this 
// method, we check in `headerExtend` that the candidate block's header is a valid extension of 
// the chain. Reaching this payload check here implies that `headerExtend` passed successfully, 
// i.e. the parent must already be part of the chain tree. Therefore, _not_ finding the latest sealed block
// in the fork up to the parent constitutes a fatal internal error. 

Does that sound like a convincing argument?

[jordanschalm]

for each block that has been successfully added the chain tree

worth noting that this is true even for blocks that don't themselves contain any seals

[zhangchiqing]

I think the explanation would be

Yeah, thanks for the explanation. I wonder if makes sense to make such dependency more explicit by taking the seal from the input:

lastSealedUpToParentBlock, err := headerExtend(block)
err := sealExtend(block, lastSealedUpToParentBlock)

This way, headerExtend must be called before sealExtend, otherwise there is no lastSealedUpToParentBlock.

[AlexHentschel]

I am a big proponent of making conceptual dependencies explicit in the code. Thanks for the suggestion Leo.
+1

[AlexHentschel]

Thanks for cleaning up sealExtend; the code is much more readable now.
Great work!

[jordanschalm]

for each block that has been successfully added the chain tree

worth noting that this is true even for blocks that don't themselves contain any seals

[jordanschalm]

Suggested change

	// sealExtend checks the compliance of the payload seals and returns the last
	// valid seal on the fork. Payload seals should form a valid chain on top of the
	// last seal, and should only correspond to blocks and execution results
	// incorporated on the current fork.
	// sealExtend checks the compliance of the payload seals and returns the last
	// valid seal on the fork up to and including `candidate`. Payload seals should form a valid chain on top of the
	// last seal as of the parent of `candidate`, and should only correspond to blocks and execution results
	// incorporated on the current fork.

[AlexHentschel]

Thanks. The Mutator is very clean now :-)
From my perspective, the PR is ready to be merged without any further modifications.

[AlexHentschel]

Do we still need the constructor? We now have the

flow-go/state/protocol/badger/state.go

Lines 21 to 25 in 4dd3d6e

	// MutatorFactory is an interface that is used to build Mutator instance
	// it is used to inject different implementations for badger.State.
	type MutatorFactory interface {
	Create(state *State) protocol.Mutator
	}

Suggested change

	func NewMutator(state *State) *Mutator {
	return &Mutator{
	state: state,
	}
	}

I think the implementation is also not setting the required filed validator

flow-go/state/protocol/badger/mutator.go

Lines 20 to 23 in 4dd3d6e

	type Mutator struct {
	state *State
	validator module.ReceiptValidator
	}