Tracking: inbound message handling.

[hdevalence]

The zebra-network API is designed so that on init, the user passes in a Service whose job it is to respond to network requests from other peers. Currently, the only existing implementation of this is the SeedService, which responds to address requests from peers.

This code should be refactored into a general-purpose Inbound service that handles all requests from peers.

• Refactor Zebrad functionality into logical components #1030 for restructuring; the part needed here was done in Create an inbound network service component #1071.

We need to implement an inbound network service with the following behaviors:

• Request::Peers by returning sanitized peer addresses;
• Request::BlocksByHash by querying the state service for those blocks;
• Request::TransactionsByHash (Send inbound TransactionsById requests to the mempool storage service #1077)
• Request::FindBlocks (Handle FindBlocks in the Inbound service #1078)
• Request::FindHeaders (Handle FindHeaders in the Inbound service #1079)
• Request::PushTransaction (Send inbound PushTransactions broadcasts to the mempool download and verify stream #1080)
• Request::AdvertiseTransactions (Send inbound AdvertiseTransactionIds broadcasts to the mempool download & verify stream #1081)
• Request::AdvertiseBlock (Handle AdvertiseBlock in Inbound service #1082)
• Request::MempoolTransactions (Send inbound MempoolTransactionIds requests to the mempool storage service #1083)

Other work:

• use exhaustive match statement in peer/connection.rs (use exhaustive match statement in peer/connection.rs #1027)

[teor2345]

• observing new transaction advertisements, downloading those transactions if unknown, and adding them to the mempool;

Should we perform transaction verification before adding to the mempool?

[hdevalence]

Yes, there are different transaction verification rules for mempool transactions, I'll clarify the line to reflect that.

[hdevalence]

#878 is unmergeable (the way it used Abscissa components didn't work out) but it has some code that could be extracted to implement the inbound network service. One thing we need to decide (cc @ZcashFoundation/zebra-team) is whether we want to continue to provide a special-case seed command, or drop it and power the DNS seeders from full nodes that validate the chain.

My position is that we should drop it, since eliminating that distinction will simplify the implementation. We will want to run full nodes anyways (in order to be able to supply blocks to other peers), so I don't think that there's much benefit to making a special seed mode.

[teor2345]

Is writing a full node a post-alpha task?
Or is it important to do it before the alpha?

[hdevalence]

Yes, we need to do this before, because it's part of what's required to participate in the network (altruistically, if we don't do this, we'll be draining bandwidth from the network and providing none, selfishly, we need to do this to learn about gossiped blocks).

That said, the work here mostly consists of wiring things together, rather than implementing a ton of new functionality, the bulk of the work left to do remains in implementing all the validation and state handling.

[hdevalence]

#960 is a prerequisite to this issue. Linking it here in a comment in advance of restructuring the list above as a list of sub-issues, which I'd like to do after resolving #878 .

[mpguerra]

Adding #1027 to this Epic

[teor2345]

Adding #1027 to this Epic

We usually edit the description and add a checkbox for new tasks.

Is there an automatic way to see when tickets are completed?

[mpguerra]

We usually edit the description and add a checkbox for new tasks.

Will do that

Is there an automatic way to see when tickets are completed?

We can also just do this in Zenhub in addition to or instead of the checkbox. This is some extra info you can see if you are using Zenhub:

[mpguerra]

I think we're almost done here!

[mpguerra]

All done with this Epic