lwisne
commented
1 year ago Speed of syncing is something we are working very hard to fix. There are a number of things we are working on or planning to work on before mainnet, one of which is better peer management. Thanks for the input!
aminazeb
As a frustrated testnet user who's only 53% sync'd after 3 1/2 days on a dedicated node machine, I would like to be able to "prefer" peers which I have seen before as providing relatively rapid and clean syncing (lots of good uninterrupted runs of block seqs with decent block ingestion times).
The challenge now is, there seems to be a nearly infinite supply of trashy peers that disconnect right away or have other issues, yielding no good long runs of block ingestion during syncing. Can be 15 min to find a peer that will even send you 1 good 20-block-seq!.
Possible solution: "capture" and "pin" names, IDs, IPs, etc., of a few peers as "preferred" peers, so that I can sync faster if those peers are available, and avoid peers who are disconnecting or taking a long time to return blocks.
It's not good enough to save details in the current hosts.json, because the peer you want to pin may have already been booted out. It's "too much" to have to edit full details of a "preferred" peer into hosts.json, because you might not know "all" their details, but you know you saw "something" about them in a log.
Therefore I would like a way to enter some minimal info about a preferred peer, such as peer's "name" (if non-empty) or ID in a "look up or capture" field in some config file, so that either:
A) "direct connection request": The node will send out a "feeler query" to ask if that peer is available and online, and return data on how the node can reach it and select it as a peer
B) "sticky" peers: when I next connect to that peer, they "stay" as long as they are providing good block data efficiently, and are preferred again if they have been banned for a period of time due to a bad or orphan block or chain, etc.
I'm aware that this is not a purely automatic distributed approach and has some downside: A) Brittle B) Anti-random and not fully "flatly" decentralized - less censorship-resistant, etc. C) More subject to surveillance if a connection is frequently used between relatively static IPs, and could become a target of "watchers" of "suspicious or undesirable protocols" D) Like any static configuration, it can block better-performing fully automatic peer identification and selection critieria.
Nevertheless, with the current (v0.1.35) multi-day syncing challenges, nodes need all the help they can get to sync in "only" a few days.
This might be a relatively cheap temporary "hack" until the Dev Team has the time to optimize discovery and connection algs for excellent-performing peers, that's a bit smarter than the current algs. (and thanks for the quick-ban alg - it does get rid of trashy peers well).
Better of course is a "smarter" connection alg that load balances connections to well-connected and well-performing peers (that successfully share many block sequences) without preferring them so much that they get overwhelmed.
See also this Issue about anonymous and censorship-resistance in network startup and peer discovery, including a link to a very interesting research paper: https://github.com/iron-fish/ironfish/issues/1040
Thanks for considering.
ProductGuy