[][src]Crate zebra_network

Networking code for Zebra. 🦓

The Zcash network protocol is inherited from Bitcoin, which uses a stateful network protocol in which messages can arrive in any order (even before a handshake is complete!), and the same message may be a request or a response depending on context.

This crate translates the legacy Bitcoin/Zcash network protocol into a stateless, request-response oriented protocol defined by the Request and Response enums, and completely encapsulates all peer handling code behind a single tower::Service representing "the network" which load-balances outbound Requests over available peers.

Each peer connection is a distinct task, which interprets incoming Bitcoin/Zcash messages either as Responses to pending Requests, or as an inbound Requests to an internal tower::Service representing "this node". All connection state is isolated to the peer in question, so as a side effect the design is structurally immune to the recent ping attack.

Because tower::Services provide backpressure information, we can dynamically manage the size of the connection pool according to inbound and outbound demand. The inbound service can shed load when it is not ready for requests, causing those peer connections to close, and the outbound service can connect to additional peers when it is overloaded.



Types used in the definition of Request and Response messages.



A database of peers, their advertised services, and information on when they were last seen.


A builder for specifying [Codec] options.


Configuration for networking code.


A very basic retry policy that always retries failed requests.


A very basic retry policy with a limited number of retry attempts.



A network request, represented in internal format.


A response to a network request, represented in internal format.



Initialize a peer set with the given config, forwarding peer requests to the inbound_service.

Type Definitions


Type alias to make working with tower traits easier.