feat(dot/parachain): implement validate candidate from exhaustive

[edwardmack]

Changes

This PR introduces code for candidate validation subsystem to validate candidates when all data validation data is provided. As described in Implementation Plan this PR implements:

• Defining structure for ValidateFromExhaustive message
• Implements function performBasicChecks to confirm parameters are present and checks collator signature.
• Instantiates validation host.
• makes call to validate block of validation host to check the validation parameters and returns validation results message to caller.

Create tests to check for candidate validation exceptions based on possible errors generated by validate block function and reviewing code from polkadot test code

Tests

 go test github.com/ChainSafe/gossamer/dot/parachain/candidate-validation -v

Issues

closes: #3547 and #3995

[axaysagathiya]

the function returns the wrong struct.

[axaysagathiya]

We don't need to Encode or decode ValidationResultMessage, so we don't need to create VDT.

I have already commented above on how to use this struct.

Validation results can be either Valid or Invalid.

If the result is Invalid,
    set the IsValid field of ValidationResultMessage to false.
    also store the reason for invalidity in the Err field of ValidationResultMessage.

If the result is Valid,
    set the IsValid field of ValidationResultMessage to true.
    set the values of the CandidateCommitments and PersistedValidationData fields of ValidationResultMessage.

Reference from rust: https://github.com/paritytech/polkadot-sdk/blob/7ca0d65f19497ac1c3c7ad6315f1a0acb2ca32f8/polkadot/node/primitives/src/lib.rs#L346-L353

Let's schedule a meeting and work on this together if you are confused.

[edwardmack]

We don't need to Encode or decode ValidationResultMessage, so we don't need to create VDT.

I've removed the usage VDT for this type (and renamed it back to ValidationResult)

[kishansagathiya]

epic! 🎉

[axaysagathiya]

It seems you have missed implementing this.

[edwardmack]

It seems you have missed implementing this.

Good point, I've implemented this now.

[axaysagathiya]

How do you plan to handle these errors?

You have returned all the errors, but Rust doesn't consider them all errors. Two are considered errors, and others are reasons for invalidity.

[timwu20]

Great work Ed!

[edwardmack]

How do you plan to handle these errors?

You have returned all the errors, but Rust doesn't consider them all errors. Two are considered errors, and others are reasons for invalidity.

The ValidateBlock function that creates these errors will be refactored when the PVF host is implemented, so we can parse the errors that are generated by that when it's implemented.

[axaysagathiya]

How do you plan to handle these errors?
You have returned all the errors, but Rust doesn't consider them all errors. Two are considered errors, and others are reasons for invalidity.

The ValidateBlock function that creates these errors will be refactored when the PVF host is implemented, so we can parse the errors generated by that function when it's implemented.

If we are not checking that the error is an actual error or reason for invalidity, it's not the correct implementation.
Can we add a to-do comment where errors should be filtered out?

Context:
Reason for invalidity: When a candidate is Invalid, we store the reason in the validationResult struct and don't consider it an error.

@kishansagathiya How should we handle errors here?

[kishansagathiya]

If we are not checking that the error is an actual error or reason for invalidity, it's not the correct implementation.
Can we add a to-do comment where errors should be filtered out?

@edwardmack
Me and @axaysagathiya sat down to figure this out how to approach this. @edwardmack I agree with you that we could do this as a separate task.

So, currently (I am including this PR), eventhough we have Reason for Invalidity (

gossamer/dot/parachain/candidate-validation/messages.go

Line 56 in 2afed8b

type ReasonForInvalidity byte

) we never use it.
I would think that ValidateBlock (

gossamer/dot/parachain/runtime/instance.go

Line 69 in 2afed8b

func (in *Instance) ValidateBlock(params ValidationParameters) (

) should return a reason for invalidity in validation result. Right now it doesn't since ValidationResult struct (

gossamer/dot/parachain/runtime/instance.go

Line 25 in 2afed8b

type ValidationResult struct {

) does not have any field in it for reason for invality or any sort of error.

Let's make sure that ValidateBlock is implemented as expected. Let's have a decent number of tests for it. And differentiate between ReasonForInvalidity and errors occurred in executing ValidateBlock or any other internal error.

Have created an issue to track this task