Skip to content
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

tests(parachain/collator): black box tests for collator protocol #3759

Draft
wants to merge 139 commits into
base: feat/parachain
Choose a base branch
from

Conversation

kishansagathiya
Copy link
Contributor

@kishansagathiya kishansagathiya commented Feb 15, 2024

starting with collator protocol

Changes

Tests

go test -tags integration github.com/ChainSafe/gossamer

Issues

Fixes #3745

Primary Reviewer

@

kanishkatn and others added 30 commits September 14, 2023 17:38
Co-authored-by: Kishan 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.
…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]>
Use wazero runtime instance instead of wasmer runtime instance
…sons (#3498)

Also, added enums for common reputation values
kishansagathiya and others added 18 commits January 24, 2024 20:57
…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.
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants