Celestia Mainnet Support

[dennis-tra]

Changelog

• This PR adds support for Celestia Mainnet, which was launched ~2w ago by adding the CELESTIA network key. A network crawl only takes a few seconds.
• This PR also updates the Arabica and Mocha network defaults (though I learned that this seems to be a moving target)

@Wondertan do the following numbers make sense?

INFO[0024] Crawl summary:                               
INFO[0024]                                              
INFO[0024] Dial Error                                    count=13 value=connection_refused
INFO[0024] Dial Error                                    count=8 value=connection_reset_by_peer
INFO[0024] Dial Error                                    count=24 value=io_timeout
INFO[0024] Dial Error                                    count=11 value=no_public_ip
INFO[0024]                                              
INFO[0024]                                              
INFO[0024] Agent                                         count=80 value=celestia-celestia
INFO[0024] Agent                                         count=56 value=
INFO[0024]                                              
INFO[0024] Protocol                                      count=61 value=/celestia/shrex/eds/v0.0.1
INFO[0024] Protocol                                      count=80 value=/ipfs/id/push/1.0.0
INFO[0024] Protocol                                      count=80 value=/celestia/header-ex/v0.0.3
INFO[0024] Protocol                                      count=80 value=/celestia/celestia/ipfs/bitswap/1.2.0
INFO[0024] Protocol                                      count=80 value=/celestia/fraud/v0.0.1
INFO[0024] Protocol                                      count=80 value=/celestia/celestia/ipfs/bitswap/1.0.0
INFO[0024] Protocol                                      count=80 value=/celestia/celestia/ipfs/bitswap
INFO[0024] Protocol                                      count=80 value=/ipfs/ping/1.0.0
INFO[0024] Protocol                                      count=80 value=/floodsub/1.0.0
INFO[0024] Protocol                                      count=55 value=/libp2p/autonat/1.0.0
INFO[0024] Protocol                                      count=61 value=/celestia/shrex/nd/v0.0.3
INFO[0024] Protocol                                      count=80 value=/ipfs/id/1.0.0
INFO[0024] Protocol                                      count=80 value=/meshsub/1.1.0
INFO[0024] Protocol                                      count=80 value=/celestia/celestia/ipfs/bitswap/1.1.0
INFO[0024] Protocol                                      count=80 value=/celestia/celestia/kad/1.0.0
INFO[0024]                                              
INFO[0024] Finished crawl                                crawlDuration=24.491062084s crawledPeers=136 dialablePeers=80 undialablePeers=56

It would be great to have proper versioning in the agent version instead of just celestia-celestia 👍

Full crawl results:

2023-11-14_neighbors.json
2023-11-14_visits.json
2023-11-14_crawl_properties.json
2023-11-14_crawl.json

[Wondertan]

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

[dennis-tra]

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 :/

[Wondertan]

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?