search

gnolang / gno

Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + Gno.land: a blockchain for timeless code and fair open-source.
https://gno.land/
Other
893 stars 371 forks source link

[chain] Add `unconditional_peer_ids` to gnoland configuration #1923

Open r3v4s opened 6 months ago

r3v4s commented 6 months ago

The less we expose validator node to public, The more safe and sound we can achieve.

Description

Regardless of how many validators we want, its better we hide it from unknown publics and make it does only what validator must do.

One of common ways to do this is using what we called Sentry Node Architecture image

Idea is vey simple, validator only talks to sentry nodes and sentry nodes talks to other public nodes. In this circumstance doesn't matter how we configured system, validator must be able to talk to sentry 24/7. For this we need certain option like "ignore any limits, always establish a connection to given peers"

IMHO, it will be perfect if above configuration happens during chain initialization #1886

moul commented 6 days ago

What are the specific tasks to complete?

zivkovicmilos commented 6 days ago

@moul

We sort of have a variation of this functionality through persistent_peers, where we redial (into oblivion, recursivelly) some peers if we lose connections to them (but only if we were connected to them initially, and the connection broke for whatever reason). https://github.com/gnolang/gno/blob/641d2fd91f03191016f74ea32a0ae9592b884896/tm2/pkg/p2p/switch.go#L311-L319

persistent_peers don't actually account for any kind of "slots" on the p2p switch, they live outside of all limitations (max outbound / inbound peers).

What @r3v4s is suggesting is to have a mechanism where we keep the connections to some peers alive at all costs, if they are not existing, given the limitation of persistent_peers I've mentioned above

It should be easy peasy to do when I wrap up #2852, so I'll keep this issue updated 🙏