* primitives/runtime: initial changes on supporting multiple Justifications
* primitives/runtime: make Justifications strongly typed
* Encode/decode Justifications
* primitives/runtime: add Justification type
* backend: apply_finality and finalize_block takes a single Justification
* manual-seal: create engine id and let rpc take encoded justification
* backend: skeleton functions for appending justifications
* backend: initial implementation append_justification
Initial implementation of append_justification on the Backend trait, and also remove unused skeleton
functions for append_justificaton on Finaziler trait.
k
* backend: guard against duplicate consensus engine id
* client/db: add check for block finality
* client/api: add append_justification to in_mem db
* client/light: add no-op append_justification
* network: fix decode call for Justification
* network: only send a single Justification in BlockData
* network: minor comment update
* protocol: update field names to distinguish single justification
* client: further field renames to plural
* client: update function names to plural justifications
* client/db: upgrade existing database for new format
* network: remove dependency on grandpa crate
* db: fix check for finalized block
* grandpa: check for multiple grandpa justifications hwne importing
* backend: update Finalizer trait to take multiple Justifications
* db: remove debugging statements in migration code
* manual-seal: update note about engine id
* db: fix check for finalized block
* client: update variable name to reflect it is now plural
* grandpa: fix incorrect empty Justications in test
* primitives: make Justifications opaque to avoid being empty
* network: fix detecting empty Justification
* runtime: doc strings for Justifications functions
* runtime: add into_justifications
* primitives: check for duplicates in when adding to Justifications
* network/test: use real grandpa engine id in test
* client: fix reviewer comments
* primitives: rename Justifications::push to append
* backend: revert changes to Finalizer trait
* backend: revert mark_finalized
* backend: revert changes to finalize_block
* backend: revert finalized_blocks
* db: add a quick early return for performance
* client: minor reviewer comments
* service/test: use local ConsensusEngineId
* network: add link to issue for sending multiple Justifications
* Apply suggestions from code review
Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
* Apply suggestions from code review
Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
* network: tweaks to review suggestions
* network: revert change to BlockData for backwards compatibility
* Apply suggestion from code review
Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
* Apply suggestions from code review
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
* primitives: update doc comment for Justifications
* client/db/upgrade: avoid grandpa crate dependency
* consensus: revert to single Justification for import_justification
* primitives: improve justifications docs
* style cleanups
* use and_then
* client: rename JUSTIFICATIONS db column
* network: revert to using FRNK in network-test
Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
Co-authored-by: André Silva <123550+andresilva@users.noreply.github.com>
Co-authored-by: André Silva <andrerfosilva@gmail.com>
We introduced banning of peers who spam us with the same request (more
than 2 times). However, we missed that it is completely legal to send
the same request multiple times as long as we did not provide any
answer. An example for that is the justification request. This request
is send multiple times until we could fetch the justification from one
of our peers. So, the solution to this problem is to tag requests as
fulfilled and to start counting these fulfilled requests. If the number
is higher than what we allow, the peer should be banned.
* Decrease the peer reputation on invalid block requests
This pr changes the block request handler to decrease the reputation of
peers when they send the same request multiple times or they send us an
invalid block request.
* Review feedback
* Change log target
* Remove unused code
* Add a `send_request` to `NetworkService`.
This function delivers responses via a provided sender and also allows
for sending requests to currently not connected peers.
* Document caveats of send_request better.
* Fix compilation in certain cases.
* Update docs + introduce IfDisconnected enum
for more readable function calls.
* Doc fix.
* Rename send_request to detached_request.
* Whitespace fix - arrrgh
* Update client/network/src/service.rs
spaces/tabs
Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
* Update client/network/src/request_responses.rs
Documentation fix
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* Update client/network/src/service.rs
Typo.
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* Update client/network/src/service.rs
Better docs.
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* Update client/network/src/service.rs
Typo.
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* Update client/network/src/service.rs
Doc improvements.
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* Remove error in logs on dialing a peer.
This is now valid behaviour.
* Rename detached_request to start_request.
As suggested by @romanb.
* Fix merged master.
* Fix too long lines.
Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* client/network: Re-enable light_client_handler.rs unit tests
* client/network: Add scaffolding for light client using req-resp
* client/network: Make it compile
* client/network: Rename OutEvent SendRequest
* client/network: Restructure light client request client and handler
* client/network: Rename light client request client to sender
* client/network: Remove light client prepare_request
* client/network/src/light: Rework configuration
* client/network: Formatting
* client/network/light: Remove RequestId
* client/network/light: Make request functions methods
* client/network/light: Refactor request wrapping
* client/network/light: Fix warnings
* client/network/light: Serialize request in method
* client/network/light: Make returning response a method
* client/network/light: Depend on request response to timeout requests
* client/network: Fix test compilation
* client/network/light: Re-enable connection test
* client/network/light: Re-enable timeout test
* client/network/light: Re-enable incorrect_response test
* client/network/light: Re-enable wrong_response_type test
* client/network/light: Re-enable retry_count_failures test
* client/network/light: Re-enable issue_request tests
* client/network/light: Re-enable send_receive tests
* client/network/light: Deduplicate test logic
* client/network/light: Remove unused imports
* client/network/light: Handle request failure
* client/network/light: Move generate_protocol_config
* client/network: Fix test compilation
* client/network: Rename light client request client to sender
* client/network: Handle too-many-requests error
* client/network: Update outdated comments
* client/network/light: Choose any peer if none has best block defined
* .maintain: Replace sentry-node with local-docker-test-network
Sentry nodes are deprecated. Thus there is no need for
`.maintain/sentry-node` to spin up a sentry node test environment.
Instead this commit rewrites the setup to contain two full-connected
validators and one light client.
With the steps below one can now spin up a local test network with
two validators, one light-client, Prometheus and Grafana.
- cargo build --release
- sudo docker-compose -f .maintain/local-docker-test-network/docker-compose.yml up
* client/network/light: Handle oneshot cancellation
* client/network/light: Do not reduce retry count on missing peer
* client/network/request-response: Assert in debug request id to be unique
* client/network/light: Choose same limit as block request protocol
* client/network: Report reputation changes via response
Allow request response protocol handlers to issue reputation changes, by
sending them back along with the response payload.
* client/network: Remove resolved TODOs
* Sync: Fix issue of not freeing a block announcement slot
There was a bug that when the block announcement validation returned an
error, the slot reserved for this validation wasn't freed. This could
lead to a situation where we rejected any block announcement from such a
peer for that the block announcement returned an error multiple times.
* Better logging
* Fuck I'm dumb
* 🤦
* client/network: Report reputation changes via response
When handling a request by a remote peer in a request response handler,
one might want to in- or de-crease the reputation of the peer. E.g. one
might want to decrease the reputation slightly for each request, given
that it forces the local node to do work, or one might want to issue a
larger reputation change due to a malformed request by the remote peer.
Instead of having to pass a peerset handle to each request response
handler, this commit suggests to allow handlers to isssue reputation
changes via the provided `pending_response` `oneshot` channel.
A reputation change issued by a request response handler via the
`pending_response` channel is received by the
`RequestResponsesBehaviour` which passes the reputation change up as an
event to eventually be send to a peerset via a peerset handle.
* client/network/req-resp: Use Vec::new instead of None::<Vec<_>>
* client/network: Rename Response to OutgoingResponse
Given that a request-response request is not called `Request` but
`InomingRequest`, rename a request-response response to
`OutgoingResponse`.
* client/finality-grandpa-warp: Send empty rep change via response
* client/network/req-resp: Add unit test for request id collision
* client/network/req-resp: Prevent request id collision
`RequestId` is a monotonically increasing integer, starting at
`1`. A `RequestId` is unique for a single `RequestResponse`
behaviour, but not across multiple `RequestResponse` behaviours. Thus
when handling `RequestId` in the context of multiple
`RequestResponse` behaviours, one needs to couple the protocol name
with the `RequestId` to get a unique request identifier.
This commit ensures that pending requests (`pending_requests`) and
pending responses (`pending_response_arrival_time`) are tracked both by
their protocol name and `RequestId`.
* client/network/req-resp: Remove unused import
* client/network/req-resp: Introduce ProtocolRequestId struct
* client/network/req-resp: Update test doc comment
Treat `RequestId` as an opaque type.
* client/network/req-resp: Improve expect proof
* Sync: Propagate block announcement data
This pr adds a feature to the sync protocol to propagate the data that
we received alongside a block announcement. This is done by adding a
cache that caches the last X block announcement data where X is set to
the number of `in_peers` (giving every peer the chance to send us a
different block). This will be required by parachains to ensure that
even peers who are not connected to a collator receive the data
alongside the block announcement to properly validate it and request the
block.
* Review comment
* Bring back the code and add new variant to ensure we don't insert block
announce data when something wasn't checked
* Also use out_peers
Pierre Krieger