-
Notifications
You must be signed in to change notification settings - Fork 166
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
[Sealing] Validation of multiple receipts in payload #323
Merged
zhangchiqing
merged 7 commits into
leo/validate-multi-receipts
from
yurii/validate-multi-receipts
Jan 25, 2021
Merged
Changes from 6 commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
cbe5f63
Add implementation for looking up receipt in payload
durkmurder 18b29d4
Fix tests to comply to new validator interface
durkmurder 497184d
Added alternative implementation of subgraph validation
durkmurder 1505cd0
Revert "Added alternative implementation of subgraph validation"
durkmurder a15e678
Add comments
durkmurder 100562c
Add lookup cache for execution results
durkmurder 7309dfe
Update module/validation/receipt_validator.go
durkmurder File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -12,6 +12,9 @@ import ( | |
"github.com/onflow/flow-go/storage" | ||
) | ||
|
||
// Functor that is used to retrieve parent of ExecutionResult. | ||
type GetPreviousResult func(*flow.ExecutionResult) (*flow.ExecutionResult, error) | ||
|
||
// receiptValidator holds all needed context for checking | ||
// receipt validity against current protocol state. | ||
type receiptValidator struct { | ||
|
@@ -172,16 +175,38 @@ func (v *receiptValidator) resultChainCheck(result *flow.ExecutionResult, prevRe | |
// * execution result has a valid parent | ||
// Returns nil if all checks passed successfully | ||
func (v *receiptValidator) Validate(receipts []*flow.ExecutionReceipt) error { | ||
// lookup cache to avoid linear search when checking for previous result that is | ||
// part of payload | ||
payloadExecutionResults := make(map[flow.Identifier]*flow.ExecutionResult) | ||
for _, receipt := range receipts { | ||
payloadExecutionResults[receipt.ExecutionResult.ID()] = &receipt.ExecutionResult | ||
} | ||
// Build a functor that performs lookup first in receipts that were passed as payload and only then in | ||
// local storage. This is needed to handle a case when same block payload contains receipts that | ||
// reference each other. | ||
// ATTENTION: Here we assume that ER is valid, this lookup can return a result which is actually invalid. | ||
// Eventually invalid result will be detected and fail the whole validation. | ||
previousResult := func(executionResult *flow.ExecutionResult) (*flow.ExecutionResult, error) { | ||
prevResult, found := payloadExecutionResults[executionResult.PreviousResultID] | ||
if found { | ||
return prevResult, nil | ||
} | ||
|
||
return v.previousResult(executionResult) | ||
} | ||
|
||
for i, r := range receipts { | ||
err := v.validate(r) | ||
err := v.validate(r, previousResult) | ||
if err != nil { | ||
// It's very important that we fail the whole validation if one of the receipts is invalid. | ||
// It allows us to make assumptions as stated in previous comment. | ||
return fmt.Errorf("could not validate receipt %v at index %v: %w", r.ID(), i, err) | ||
} | ||
} | ||
return nil | ||
} | ||
|
||
func (v *receiptValidator) validate(receipt *flow.ExecutionReceipt) error { | ||
func (v *receiptValidator) validate(receipt *flow.ExecutionReceipt, previousResult GetPreviousResult) error { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Did it this way to postpone storage lookup till it's needed and not too put validation in loop body.
durkmurder marked this conversation as resolved.
Show resolved
Hide resolved
|
||
identity, err := identityForNode(v.state, receipt.ExecutionResult.BlockID, receipt.ExecutorID) | ||
if err != nil { | ||
return fmt.Errorf( | ||
|
@@ -206,7 +231,7 @@ func (v *receiptValidator) validate(receipt *flow.ExecutionReceipt) error { | |
return fmt.Errorf("invalid chunks format for result %v: %w", receipt.ExecutionResult.ID(), err) | ||
} | ||
|
||
prevResult, err := v.previousResult(&receipt.ExecutionResult) | ||
prevResult, err := previousResult(&receipt.ExecutionResult) | ||
if err != nil { | ||
return err | ||
} | ||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
when validating a receipt, we assume the previous result from the same payload is "valid", and so that if this assumption fails, eventually the entire validation will fail.
The solution is simple and elegant, however I'm still not feeling very comfortable about it, even though I couldn't think of case that leads to an incorrect behavior yet