We want to reuse the clients libp2p instance for receiving threshold signature shares directly from our users, for key resharing/rotation as validators join/leave the active validator set, broadcasting, and for other various multiparty computations. Tightly coupling this logic with the substrate client and using non-standard libp2p protocols seems the most appropriate way to do this.

It seems the best way to do this might be via forking sc-networking. Since this is not fun to maintian, might it make sense to add a feature to provide additional protocols/handlers via the sc-networking config?

  • 1
    Check out the work we've done with Orchestra in Polkadot, and the network protocol and bridge crates which use it.
    – rob
    Sep 11, 2022 at 1:58
  • 1
    It'd be nice to extract Orchestra to a separate repository or to Substrate for other projects to make use of.
    – rob
    Sep 11, 2022 at 1:59

1 Answer 1


sc-network allows for custom notification protocols and request/response protocols to be registered with the NetworkConfiguration when starting the service.

The extra_sets define peer-sets for notifications protocols, and the request_response_protocols define request/response protocols which the nodes support.

When configuring a request/response protocol, you pass a Sender which the sc-network logic will forward incoming requests through, which allows you to handle them.

You can listen for notifications and peer events on a notifications protocol by invoking NetworkService::event_stream and send notifications with NetworkService::write_notification, or use NetworkService::notification_sender to incorporate backpressure into your code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.