mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-04-30 01:27:56 +00:00

Files

T

Aaro Altonen e71c484d5b Rework the event system of sc-network (#1370 )

This commit introduces a new concept called `NotificationService` which
allows Polkadot protocols to communicate with the underlying
notification protocol implementation directly, without routing events
through `NetworkWorker`. This implies that each protocol has its own
service which it uses to communicate with remote peers and that each
`NotificationService` is unique with respect to the underlying
notification protocol, meaning `NotificationService` for the transaction
protocol can only be used to send and receive transaction-related
notifications.

The `NotificationService` concept introduces two additional benefits:
  * allow protocols to start using custom handshakes
  * allow protocols to accept/reject inbound peers

Previously the validation of inbound connections was solely the
responsibility of `ProtocolController`. This caused issues with light
peers and `SyncingEngine` as `ProtocolController` would accept more
peers than `SyncingEngine` could accept which caused peers to have
differing views of their own states. `SyncingEngine` would reject excess
peers but these rejections were not properly communicated to those peers
causing them to assume that they were accepted.

With `NotificationService`, the local handshake is not sent to remote
peer if peer is rejected which allows it to detect that it was rejected.

This commit also deprecates the use of `NetworkEventStream` for all
notification-related events and going forward only DHT events are
provided through `NetworkEventStream`. If protocols wish to follow each
other's events, they must introduce additional abtractions, as is done
for GRANDPA and transactions protocols by following the syncing protocol
through `SyncEventStream`.

Fixes https://github.com/paritytech/polkadot-sdk/issues/512
Fixes https://github.com/paritytech/polkadot-sdk/issues/514
Fixes https://github.com/paritytech/polkadot-sdk/issues/515
Fixes https://github.com/paritytech/polkadot-sdk/issues/554
Fixes https://github.com/paritytech/polkadot-sdk/issues/556

---
These changes are transferred from
https://github.com/paritytech/substrate/pull/14197 but there are no
functional changes compared to that PR

---------

Co-authored-by: Dmitry Markin <dmitry@markin.tech>
Co-authored-by: Alexandru Vasile <60601340+lexnv@users.noreply.github.com>

2023-11-28 20:18:52 +02:00

src

Rework the event system of sc-network (#1370 )

2023-11-28 20:18:52 +02:00

Cargo.toml

Rework the event system of sc-network (#1370 )

2023-11-28 20:18:52 +02:00

README.md

Markdown linter (#1309 )

2023-09-04 12:02:32 +03: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