…3281)

Co-authored-by: Eclésio Junior <eclesiomelo.1@gmail.com>
Co-authored-by: Edward Mack <emack@pop-os.localdomain>

Co-authored-by: Kishan Sagathiya <kishansagathiya@gmail.com>

Co-authored-by: Kishan Mohanbhai Sagathiya <kishansagathiya@gmail.com>

…ution message (#3355)

…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

…3385)

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 <kanishkatn@gmail.com>
Co-authored-by: Kishan Mohanbhai Sagathiya <kishansagathiya@gmail.com>
Co-authored-by: Axay Sagathiya <axaysagathiya@gmail.com>

#3427)

Co-authored-by: Kishan Sagathiya <kishansagathiya@gmail.com>

…3447)

…#3417)

Use wazero runtime instance instead of wasmer runtime instance

Co-authored-by: Kishan Mohanbhai Sagathiya <kishansagathiya@gmail.com>

…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

… by a collator (#3535)

Fixes #3514

…3560)

`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)

…test (#3707)

…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 <kishansagathiya@gmail.com>

#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.

Co-authored-by: Diego <diego2737@gmail.com>

Collator Protocol Subsystem receives a Backed message from overseer. This message tells collator protocol when a candidate has been backed.
This commit processes that backed message. Unblocks blocked advertisements as per the situation.

- added instance method to call the `ParachainHost_async_backing_params` runtime function
- implemented host API function ext_crypto_ecdsa_generate_version_1

- implemented below mentioned functions in lib/crypto/secp256k1
  - NewKeypairFromMnenomic
  - NewKeypairFromSeed
  - NewPublicKey

- Added support for WESTEND_RUNTIME v1.8.0

…c backing params (#3819)

Added a new Yaml file for test data and used it in a test to call the runtime method to get async backing parameters.

- added support to call runtime method to get minimum backing votes
- as the test was failing, I used runtime version 1.9.0 instead of 1.8.0
- set min memory pages to 2080

This commit introduces collator side of the collator protocol. This is just a skeleton that
- implements the SubSystem interface for the new subsystem
- registers it
- add common methods like processMessage

linked to issue #3824

This commit introduces network bridge skeleton for receiving side subsystem and sending side subsystem of network bridge

Fixes #3860 and #3858

Issue #3859

This commit introduces network bridge skeleton for receiving side subsystem and sending side subsystem of network bridge

Fixes #3860 and #3858

…idator (#3904)

…tor protocol (#3827)

Subsystems needs to know about the peers in collation and validation protocol. This commit
- adds logic to network package for emitting network events when a new peer joins or a peer disconnects.
- introduces a method to get a channel that will give us network events.
- make collator protocol validator side listen to these events and react to it by editing its peer data

Issue #3515

)

Handling active leaves updates are quite important in collator protocol since
- It tells us which relay parents to remove or add
- which candidates to add or remove
- most importantly it leads us to letting us know as a validator which parachain we are assigned to.

This commit add logic to react to active leaves update by
- updating view
- updating active leaves
- updating our parachain assignments

Issue #3515

…g subsystem (#3867)

…utor parameters (#3887)

…tement table for the given candidate hash (#3931)

- This PR implements a method for getting a committed candidate receipt from the statement table for the candidate hash.
- This is an implementation of one of the methods of statement table interface in the candidate backing subsystem.

…ystem (#3837)

Co-authored-by: Axay Sagathiya <axaysagathiya@gmail.com>
Co-authored-by: Kishan Sagathiya <kishansagathiya@gmail.com>

…vailability store subsystem (#3896)

Co-authored-by: Axay Sagathiya <axaysagathiya@gmail.com>
Co-authored-by: Kishan Sagathiya <kishansagathiya@gmail.com>

- handled active leaves update message
- handled block finalized message

…-bridge-rx