Net plugin improvements

Problem

Opportunity: What are the needs of our target user groups?

Better management of state for net plugin: presently net-plugin will throw away any data that isn't exactly what it needs next and will blindly circulate round-round robin requesting the data from peers that may have already failed to deliver on the same previous request
Better management controls around how a node manages peers and data exchange with the network: presently, there is no way to evaluate the quality of peer connections or explicitly manage bandwidth usage or total peer connection count.
Better management of problematic peers: there are known issues for peer nodes such as unreachable peers or those sending invalid transactions or unlinkable blocks that there is no easy way to identify and eliminate from peer list.

Target audience: Who is the target audience and why?

Block Producers
Developers

Strategic alignment: How does this problem align with our core strategic pillars?

Blockchain made easy - better stability and configurability around P2P syncing processes makes connecting to the network easier and allows users to shift their focus towards the purpose of why they are engaged with the network in the first place.

Context

Competitors: Who are our top competitors (up to 5) and why? How do they solve this problem today?

Product differentiation: what would make our solution different?

Audience definition

Solution

Solution name: How should we refer to this product opportunity?

Net Plugin Incremental Improvements

Purpose: Define the product’s purpose briefly

Although the P2P improvements RFP didn't move forward, there is valuable work there to still be done. The peer discovery portion will be come it's own RFP, but many of the net plugin improvements can be done iteratively within the team's sprints.

Net Plugin Stability and user experience improvements

Block buffer / fork cache

Ability to limit maintain a "block buffer" that allows the node to maintain a locus of recent state
Ability to prevent re-requesting of blocks from peer nodes when microforks are occurring

Connection count and bandwidth usage management

Ability for individual nodes to configure a connection count limit
Ability for individual nodes to configure a bandwidth usage limit
Ability to manage peer connection count within the limits of available bandwidth by default
Ability to gracefully handle scenarios where a node operator has set their bandwidth limit higher than the natural limit of their connection

Management for undesirable peer behavior

Ability to automatically remove unreachable peers from the list used by an individual node
Ability to disconnect from persistently desynchronized peers
Ability to disconnect from peers that persistently send unlinkable blocks
Ability to disconnect from peers that do not honor the “no transactions” flag
Ability to disconnect from peers that have unreliable connections
Ability to disconnect from peers that persistently send invalid transactions

Success definition: What are the top metrics for the product (up to 5) to define success?

Assumptions

A full rewrite of P2P protocol is out of scope for the short term future.

Risks: What risks should be considered? https://www.svpg.com/four-big-risks/

Business Objectives/Functionality

Features/Epics

User stories

Additional tasks

[x] https://github.com/AntelopeIO/leap/issues/452
[ ]

Timeline

Cost

Open questions

If we do introduce a net plugin block buffer, where in the architecture should it live?
If we are to design peer node ratings, what additional data would we like to capture to establish a baseline rating for peer ranking and management?
What about IPv6 compatibility?

eosnetworkfoundation / product