Cosmos-sdk: Peer filtering

[marbar3778]

Summary

Tendermint exposes functionality to prevent peers from joining the network.

https://docs.tendermint.com/master/spec/abci/apps.html#peer-filtering

Problem Definition

While in a public setting networks would like to allow anyone and everyone to join a network, in private environments networks would like to allow only certain peers to join the network.

Proposal

Expose peer filtering to be optionally used by a module.

I believe this is related to baseapp?

---

For Admin Use

• [x] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[alessio]

Thanks Marko! CCing @PaddyMc for visibility

[alexanderbez]

Expose peer filtering to be optionally used by a module.

I don't understand what this means. What do modules that deal with state-transitions have anything to do with peer filtering? Isn't this just a configuration operators can provide which we provide to BaseApp s.t. it can properly implement that ABCI method?

[marbar3778]

I don't understand what this means. What do modules that deal with state-transitions have anything to do with peer filtering? Isn't this just a configuration operators can provide which we provide to BaseApp s.t. it can properly implement that ABCI method?

Maybe not a module, this could be within baseapp, but it would be best set as a store that can be updated. A network may want to grow and having all nodes update their configs is huge ordeal.

[alexanderbez]

What's a store? I don't see a problem with just a config. We can easily support IP ranges/CIDR.

[marbar3778]

What's a store?

Sorry, list of peers should be persisted with the ability to add and remove peers from the list.

I don't see a problem with just a config.

How would you do network wide updates?

[alexanderbez]

How would you do network wide updates?

Update config & restart. We can even have a file watcher so you don't need to restart.

[marbar3778]

Update config & restart. We can even have a file watcher so you don't need to restart.

This is horrible UX and it's easy to get it out of sync. Is there a reason why this couldn't be a feature within the protocol?

One approach is handling it the same way tendermint consensus parameters are currently handled

[alexanderbez]

Out of sync with what? I respectfully disagree. It is a feature in the protocol already (ABCI). This isn't a consensus parameter, it's local to the operator like min fees (which are also in config).

Yes, it is stateful, but not stateful in the blockchain context -- stateful either in-memory or on file. I.e. either by config or hijack the database that we use for blockchain data which is janky IMHO. So hence I propose we use a config file. Not a horrible UX as this is how many cloud-based frameworks operate (e.g. whitelist/blacklist).

[marbar3778]

Yes, it is stateful, but not stateful in the blockchain context -- stateful either in-memory or on file. I.e. either by config or hijack the database that we use for blockchain data which is janky IMHO. So hence I propose we use a config file. Not a horrible UX as this is how many cloud-based frameworks operate (e.g. whitelist/blacklist).

But for the config file updates a team has to send out some information in a newsletter or some other way telling node operators to update their configs, this is the part that can easily get out of sync. Or are you thinking of it coming through the chain.

[alexanderbez]

Ok I'm not following here then. Probably some miscommunication again.

The way I interpret peer filtering, is that a full-node operator may decide to reject connections to/from specific peer(s). Very similar to how that same operator decides on their min fees. Both values are _local_ to that operator. They're not network-wide and have nothing to do with other operators in the network. So why does anything have to be broadcasted or publicized?

Is my understanding in peer filtering completely off then? Is it peer filtering actually a network-wide concept in which _all_ full-nodes accept/return the same peer(s) to filter? If so, then yes, a configuration is the completely wrong approach and I suppose I just completely misunderstood.

If it actually network-wide, then we need to write up an ADR/RFC on how to tackle this. It's not even clear to me how we'd tackle this. I guess they can be parameters voted upon governance like you've suggested.

[alexanderbez]

Ok updates from out-of-band discussions:

Peer filtering is intentionally ambiguous and up to the protocol. Specifically, it can be local and/or consensus-based (maximum flexibility). That being said, we should support configuration-based and consensus-based peer filtering. Where for a given peer P, P will be rejected iff P ∈ configSet U consensusSet. Configuration is obviously trivial. For consensus, we can treat peers as an on-chain parameter which a network can vote upon to update just like consensus params.

/cc @ebuchman