Runtime restriction of peers

[gavofyork]

Right now, managing (reserved) peers is entiely client-side with no input/integration from within the runtime. However there are usecases where we might want to allow the runtime to state which node IDs should be connected to (e.g. with a secure private network).

This could be done in one of two ways:

• A well-known storage item that dictates to nodes (at least those that do not opt-out) about which other node IDs they are allowed to peer with. This lets the runtime command the participants of the network very easily, but cannot do anything "adaptive" where its logic changes depending on those participants.

• Two additional OCW APIs, one to get the current set of peers, and another to set the reserved nodes. The chain spec should provide defaults (bootnodes already exists but we probably want a "bootnodes-only" flag). They should persist across restarts for that chain so that at the initial startup (before the OCW runs) the node doesn't try to connect to nodes that it shouldn't. This allows on-chain logic to get exposure to potentially every node's peer connectivity and to manage their peering individually, potentially openning the door to some quite interesting things.

[g2udevelopment]

@gavofyork I was thinking about this issues but with the tools already available this should already be possible. it is a bit cumbersome but using OCW http calls to rpc endpoints peers / addReservedPeer , it is already possible to use the OCW infrastructure to make this kind of calls.

[kaichaosun]

TODOs:

• Persist the reserved nodes configure properly
• Tutorial / guidance on how to use this feature

[g2udevelopment]

TODOs:

• Persist the reserved nodes configure properly
• Tutorial / guidance on how to use this feature

Thanks was really waiting on this feature. Hope to use it soon.

[kaichaosun]

The tutorial is ready. I'd like hear how you feel about this feature. @g2udevelopment @mattdean-digicatapult

[g2udevelopment]

@kaichaosun very nice I will follow the tutorial this will certainly help permissioned chain usecases. Combining this with this like rbac and on-chain governance opens up alot of possibilities thank you.