tests(parachain/collator): black box tests for collator protocol #3759
Conversation
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
…3281) Co-authored-by: Eclésio Junior <[email protected]> Co-authored-by: Edward Mack <[email protected]>
Co-authored-by: Kishan Sagathiya <[email protected]>
Co-authored-by: Kishan Mohanbhai Sagathiya <[email protected]>
…ement/1 protocol (#3354) - Added `StatementFetchingRequest` and `StatementFetchingResponse` varying data types. - implemented 'network.Message` interface in `StatementFetchingRequest` and 'network.ResponseMessage` interface in `StatementFetchingResponse` as they will be passed into `func (rrp *RequestResponseProtocol) Do(to peer.ID, req Message, res ResponseMessage) error` function as `req` and `res`. - I didn't want to create a new YAML file here. so I decided to rename the YAML file name and variable(in which data of the YAML file getting unmarshalled) name so that I can use them in this PR.
…collation/1 protocol (#3356)
…chunk/1 protocol (#3362) - Added `ChunkFetchingRequest` and `ChunkFetchingResponse` types. - implemented network.Message interface in `ChunkFetchingRequest` and 'network.ResponseMessage' interface in `ChunkFetchingResponse`
…available_data/1 protocol (#3368) - Added AvailableDataFetchingRequest and AvailableDataFetchingResponse types. - Implemented 'network.Message' interface in AvailableDataFetchingRequest and 'network.ResponseMessage' interface in AvailableDataFetchingResponse as they will be passed into this function as req and res.
…g statement and collation (#3374) added New() method and decode test for below varying data types. - statement - statement distribution message - collation protocol - collator protocol message
…pov/1 protocol (#3365) - Added PoVFetchingRequest and PoVFetchingResponse types. - Implemented 'network.Message' interface in PoVFetchingRequest and 'network.ResponseMessage' interface in PoVFetchingResponse as they will be passed into this function as req and res.
#3277) - Added parachain service - Registered collation and validation protocol - Confirmed that we can communicate with collators by talking to them in `run()` function
Implemented following parachain host runtime calls - ParachainHost_persisted_validation_data - ParachainHost_validation_code
This commit adds all the functions required for parachain candidate validations. With this commit, we are able to take candidate receipts and - get validation data for it, - perform basic checks on it, - run respective parachain's validate_block on parachain's runtime, - get validate results from parachain's runtime and verify those validation results again relaychain runtime, - and declare candidate as valid or invalid in the end. This commit also includes tests for candidate validation.
…3382) Co-authored-by: Kanishka <[email protected]> Co-authored-by: Kishan Mohanbhai Sagathiya <[email protected]> Co-authored-by: Axay Sagathiya <[email protected]>
#3427) Co-authored-by: Kishan Sagathiya <[email protected]>
Use wazero runtime instance instead of wasmer runtime instance
Co-authored-by: Kishan Mohanbhai Sagathiya <[email protected]>
…sons (#3498) Also, added enums for common reputation values
…or (#3529) - Verify the collator by its signature and - Save its collator id, peer id and Para id that it collates for in our memory
- Made changes to overseer to support processing messages coming from subsystems - Added logic to process those messages
`Seconded` is a type of statement for a candidate. Seconded implies `Valid` (also a type of statement). Collator protocol could receive `Seconded` message from backing subsystem for a particular candidate. On receiving this message we would - stop tracking its candidate for backing - reward the collator that sent us this collation - sent out a gossip message in the collator protocol peerset that this candidate was seconded
- Added ActiveLeavesUpdate and BlockFinalized overseer signals. - Connected parachain service with a block state. Using this block state parachain service would be notified when a new relay chain block gets imported or finalized. - On receiving these signals overseer would update its active leaves and broadcast an ActiveLeavesUpdate or/and BlockFinalized signal to all subsystems - Added `ProcessActiveLeavesUpdateSignal` and `ProcessBlockFinalizedSignal` method to the subsystem interface, all subsystems will have to implement this method based on their requirements to react to these signals
…verseer (#3532) - Implemented functionality to handle a statement message coming to the candidate backing subsystem - StatementMessage represents a validator's assessment of a specific candidate. - on receiving a statement message, we import a statement into the statement table and dispatch `Backed` notifications and misbehaviours as a result of importing a statement. - if the statement is seconded, the committed candidate receipt will be fetched from the statement table. Attesting data will be generated and stored to retry validation with other backing validators if a validator does not provide a PoV. - if the statement is valid, the validator index will be stored in existing attesting data. It will be checked whether the backing job is already running with the current validator. If not, the backing job will be started. - and then validation work will be kicked off. - added some overseer messages for other subsystems as well, such as provisioner, candidate validation, and statement distribution in `dot/parachain/types/overseer_messages.go` - implemented `Misbehaviour` enum using the interface (#3601) - removed duplicate parachain types from `lib/babe/inherents` (#3668) - implemented ExecutorParams varying datatype slice (partially implements #3544)
…ge (#3600) - implements logic in the Candidate Backing Subsystem to handle canSecond message. - The subsystem checks if it's allowed to second a candidate based on specific rules: - collations must be built on the root of a fragment tree or have a parent node representing a backed candidate. - If async backing is disabled for the candidate's relay parent, the response is always false.
…s for availability store subsystem (#3640) Co-authored-by: Kishan Sagathiya <[email protected]>
#3682) The `Second` message is a message received from the overseer. Candidate Backing subsystem should second the given candidate in the context of the given relay parent. This candidate must be validated. Sign and dispatch a `Seconded` statement only if we have not signed a Valid statement for the requested candidate.
…ming overseer message (#3704) GetBackedCandidatesMessage is a message from an overseer requesting a set of backable candidates that could be backed in a child of the given relay parent.
starting with collator protocol
Base automatically changed from
kishan/feat/parachain/collation-backed
to
feat/parachain
February 22, 2024 15:16
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
starting with collator protocol
Changes
Tests
go test -tags integration github.com/ChainSafe/gossamerIssues
Fixes #3745
Primary Reviewer
@