mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-04-26 18:07:58 +00:00

Files

T

Benjamin Kampmann c78c2892a4 Attempting to fix publishing (#9140 )

* mark template and utils as non-publish

* switch to development version for testing

* activate unleash check

* maybe if I disable all rules...

* Fix isolated compilation of `max-encoded-len-derive` with `syn`

error[E0369]: binary operation `==` cannot be applied to type `syn::Path`
  --> src/lib.rs:88:29
   |
88 |             .filter(|attr| attr.path == parse_quote!(max_encoded_len_crate))
   |                            --------- ^^ ----------------------------------- _
   |                            |
   |                            syn::Path

error: aborting due to previous error

For more information about this error, try `rustc --explain E0369`.
Error: could not compile `max-encoded-len-derive`

* WIP: bump changes crates since v3 tag to next breaking

cargo unleash version bump-breaking --changed-since v3.0.0
cargo unleash version set-pre dev --changed-since v3.0.0

FIXME: Don't modify crates that are not yet released, e.g.
`max-encoded-len-derive`

* Update lockfile

* WIP: Bump sp-transaction-pool as well

* WIP: Bump sp-offchain as well

* WIP: Bump frame-system-rpc-runtime-api as well

* WIP: Bump sp-authority-discovery as well

* Manually deactivate dev-deps before `cargo unleash check`

Otherwise we run into `Cycle detected` error.

* Bump sp-consensus-slots

* Add missing Cargo.lock change

* Bump sp-consensus-vrf as well

* Bump sp-keyring as well

* Bump sp-consensus-pow as well

* Try to speed up the `unleash-check` job

Previously, the job took 106 minutes - let's see if explicitly
specifying a `CARGO_TARGET_DIR` will help

* fixup: Ensure the temp target dir exists for unleash check

* Bump pallet-transaction-payment-rpc-runtime-api as well

Needed for Polkadot

* Bump pallet-transaction-payment-rpc as well

Needed for Polkadot

* Try updating crates after patching in the Polkadot CI job

* Use another approach to update patched Substrate crates

* Try to update all sp-core versions in Polkadot CI job

* Simplify sp-core version checking

* Apply another shellcheck lint

* Just do the simplest thing I guess

* Welp don't do --offline then

* Clean up `unleash-check` job triggers

Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>

* Fix a note in unleash-check cache step

* Add a note about temporary optimization in cargo-unleash

* Pin a newer version of cargo-unleash

Co-authored-by: Igor Matuszewski <xanewok@gmail.com>
Co-authored-by: Denis Pisarev <denis.pisarev@parity.io>

2021-07-11 12:17:53 +00:00

src

grandpa: restrict grandpa gossip (#9131 )

2021-06-18 19:31:00 +00:00

Cargo.toml

Attempting to fix publishing (#9140 )

2021-07-11 12:17:53 +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