Merci pour ta proposition !
Je vais essayer de faire un pseudo-code à partir de là, de l’enrichir avec la méthode de Sakia, mais si d’autres contributeur se sentent de travailler sur ce pseudo code, cela permettrait de l’optimiser, puis à tous les langages d’implémenter le p2p dans leurs bibliothèques respectives.
mais la tas des questions à te poser selon ton usage.
Un nœud va plutôt chercher a connaître le maximum de endpoints, mais pour un client, tu veux pas toute la liste et clairement pas les nœuds offline qui vont te faire pleins de timeout et latence dans ton interface. Après, est-ce que t’utilise un pool de connexion? t’essaye les nœuds un par un en mode conservatif, itératif. ou est-ce que tu broadcast une transaction par exemple. ya différents usage en fait donc différente “optimisation”.
Il va t’en falloir plusieurs 
après ya toujours moyen de faire une tite fonction rest / gva coté duniter qui te file une liste des noeuds up dans les dernières 5 min par exemple mais c’est déjà beaucoup car ya des gens qui allument leurs nœuds quelques heures seulement.
mais si tu filtre déjà un peu pour pas spammer et que t’envoie les requête genre 4-5 à la fois. t’augmente les probabilités que ta transaction arrive dans un port
La solution optimal pour le fonctionnement d’un client c’est une liste de nœud “fiable” et up en conf. mais ce qui est bon pour le réseau c’est du p2p, il faut donc faire des choix 
Oui je précise que pour moi le besoin est côté client.
Pour l’instant le seul modèle existant de requêtes p2p côté client est celui de Sakia.
Je vais donc m’en inspirer, faire un pseudo code et le proposer pour améliorations.
Puis le pseudo code sera implémenté par qui veut pour son client.
La nature d’un réseau P2P comme celui de la Ğ1 c’est :
Une solution utilisée dans Sakia est le circuit breaker pattern https://en.m.wikipedia.org/wiki/Circuit_breaker_design_pattern