mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-05-07 08:28:05 +00:00

Files

T

Aaro Altonen 1a7f5be07f Extract syncing protocol from sc-network (#12828 )

* Move import queue out of `sc-network`

Add supplementary asynchronous API for the import queue which means
it can be run as an independent task and communicated with through
the `ImportQueueService`.

This commit removes removes block and justification imports from
`sc-network` and provides `ChainSync` with a handle to import queue so
it can import blocks and justifications. Polling of the import queue is
moved complete out of `sc-network` and `sc_consensus::Link` is
implemented for `ChainSyncInterfaceHandled` so the import queue
can still influence the syncing process.

* Move stuff to SyncingEngine

* Move `ChainSync` instanation to `SyncingEngine`

Some of the tests have to be rewritten

* Move peer hashmap to `SyncingEngine`

* Let `SyncingEngine` to implement `ChainSyncInterface`

* Introduce `SyncStatusProvider`

* Move `sync_peer_(connected|disconnected)` to `SyncingEngine`

* Implement `SyncEventStream`

Remove `SyncConnected`/`SyncDisconnected` events from
`NetworkEvenStream` and provide those events through
`ChainSyncInterface` instead.

Modify BEEFY/GRANDPA/transactions protocol and `NetworkGossip` to take
`SyncEventStream` object which they listen to for incoming sync peer
events.

* Introduce `ChainSyncInterface`

This interface provides a set of miscellaneous functions that other
subsystems can use to query, for example, the syncing status.

* Move event stream polling to `SyncingEngine`

Subscribe to `NetworkStreamEvent` and poll the incoming notifications
and substream events from `SyncingEngine`.

The code needs refactoring.

* Make `SyncingEngine` into an asynchronous runner

This commits removes the last hard dependency of syncing from
`sc-network` meaning the protocol now lives completely outside of
`sc-network`, ignoring the hardcoded peerset entry which will be
addressed in the future.

Code needs a lot of refactoring.

* Fix warnings

* Code refactoring

* Use `SyncingService` for BEEFY

* Use `SyncingService` for GRANDPA

* Remove call delegation from `NetworkService`

* Remove `ChainSyncService`

* Remove `ChainSync` service tests

They were written for the sole purpose of verifying that `NetworWorker`
continues to function while the calls are being dispatched to
`ChainSync`.

* Refactor code

* Refactor code

* Update client/finality-grandpa/src/communication/tests.rs

Co-authored-by: Anton <anton.kalyaev@gmail.com>

* Fix warnings

* Apply review comments

* Fix docs

* Fix test

* cargo-fmt

* Update client/network/sync/src/engine.rs

Co-authored-by: Anton <anton.kalyaev@gmail.com>

* Update client/network/sync/src/engine.rs

Co-authored-by: Anton <anton.kalyaev@gmail.com>

* Add missing docs

* Refactor code

---------

Co-authored-by: Anton <anton.kalyaev@gmail.com>

2023-03-06 16:33:38 +00:00

src

Extract syncing protocol from sc-network (#12828 )

2023-03-06 16:33:38 +00:00

Cargo.toml

Rework the trie cache (#12982 )

2023-01-26 05:38:00 +00:00

README.md

prepping for releasing rc6 (#6922 )

2020-08-20 17:04:42 +02:00

README.md

Polite gossiping.

This crate provides gossiping capabilities on top of a network.

Gossip messages are separated by two categories: "topics" and consensus engine ID. The consensus engine ID is sent over the wire with the message, while the topic is not, with the expectation that the topic can be derived implicitly from the content of the message, assuming it is valid.

Topics are a single 32-byte tag associated with a message, used to group those messages in an opaque way. Consensus code can invoke broadcast_topic to attempt to send all messages under a single topic to all peers who don't have them yet, and send_topic to send all messages under a single topic to a specific peer.

Usage

Implement the Network trait, representing the low-level networking primitives. It is already implemented on sc_network::NetworkService.
Implement the Validator trait. See the section below.
Decide on a ConsensusEngineId. Each gossiping protocol should have a different one.
Build a GossipEngine using these three elements.
Use the methods of the GossipEngine in order to send out messages and receive incoming messages.

What is a validator?

The primary role of a Validator is to process incoming messages from peers, and decide whether to discard them or process them. It also decides whether to re-broadcast the message.

The secondary role of the Validator is to check if a message is allowed to be sent to a given peer. All messages, before being sent, will be checked against this filter. This enables the validator to use information it's aware of about connected peers to decide whether to send messages to them at any given moment in time - In particular, to wait until peers can accept and process the message before sending it.

Lastly, the fact that gossip validators can decide not to rebroadcast messages opens the door for neighbor status packets to be baked into the gossip protocol. These status packets will typically contain light pieces of information used to inform peers of a current view of protocol state.

License: GPL-3.0-or-later WITH Classpath-exception-2.0