Closed dennis-tra closed 9 months ago
Hey @dennis-tra. Thanks again for the integration. That's awesome!
do the following numbers make sense?
I think so. One q: do these numbers show instances running with DHT in Client mode? Those who detected that their reachability is private through AutoNat
By default, peers who identify that they are not publicly reachable won't end up in the DHT, so unless Celestia is using a custom configuration, Nebula wouldn't discover them :/
By default, peers who identify that they are not publicly reachable won't end up in the DHT, so unless Celestia is using a custom configuration, Nebula wouldn't discover them :/
Ahh, I see. Then it might be the case, that a bunch of peers are not represented in the numbers. Is there a simple way to make them advertise for node count purposes that's not cheatable? IIRC, nodes behind the NAT could still advertise their relayv2 addresses. Could this help?
We design our network around the fact that the majority of LNs are behind NATs(that's why we don't pursue DHT-based sampling), and we are quite unsure that HolePunching, together with UPNP, could give us needed reliable connections. As wells as we are also targeting browsers that do not allow inbound connections, but might still connect over DCUtR, I guess?
Hi @Wondertan is there a way I can estimate if the discovered peer is a validator or not? from the Nebula crawl data output
@namn-grg, Unfortunately our validators are not on the libp2p network yet, so its not possible to find them through nebula. For CometBFT p2p there are other crawlers available
Changelog
CELESTIA
network key. A network crawl only takes a few seconds.@wondertan do the following numbers make sense?
It would be great to have proper versioning in the agent version instead of just
celestia-celestia
:+1:Full crawl results:
2023-11-14_neighbors.json 2023-11-14_visits.json 2023-11-14_crawl_properties.json 2023-11-14_crawl.json