[BUG] - No officially supported or documented way to have relays discover each other

[PyurOfHeart]

Internal/External External

Area Other

Summary The cardano documentation does a good job of explaining how one should set up a stake pool, starting from building the binaries from source, all the way to meeting the pool pledge.

There is one major missing component here: How is a stake pool supposed to have its relays become a part of others pools' topologies, such that the blocks minted by the pool are acknowledged by the rest of the network?

The tutorial has the following page talking about configuring the topology, but does not mention anything about this problem: https://docs.cardano.org/projects/cardano-node/en/latest/stake-pool-operations/core_relay.html

The stake pool course makes some mention of a centralized place where one can find a list of relays, though it points to a link for the testnet: https://cardano-foundation.gitbook.io/stake-pool-course/stake-pool-guide/stake-pool/core_relay

I've seen mentions of this page by IOHK maintainers, which seems to be a decent source of truth for what relays one might want to add to their topology: https://explorer.cardano.org/relays/topology.json

In absence of official guidance by the cardano maintainers, the community has devised a few solutions. Of those, the currently dominant one is the so-called "topology updater" script: https://github.com/cardano-community/guild-operators/blob/alpha/scripts/cnode-helper-scripts/topologyUpdater.sh

Today, a stake pool operator will find that it's impossible to get incoming connections from other relays without using the topology updater script linked above, so you'll find that most (if not all) pools use this script to call out to a closed-source, opaque API. The script (by default) auto-updates itself, and most likely poses a single point of failure for the cardano network if malicious actors take control of the repo hosting it.

So my questions are:

1. Is there an official way for relays in the network to discover each other?
2. How can a stake pool operator connect with the rest of the network today without using an opaque API as mentioned above?

Steps to reproduce Steps to reproduce the behavior:

1. Follow the stake pool documentation from IOHK

Expected behavior By following official documentation, my pool is able to become a part of the cardano network such that other pools' relays make connections to it via their topologies.

System info (please complete the following information):

• All

Screenshots and attachments

Additional context

[rdlrt]

Small clarification:

The script (by default) auto-updates itself

Not without a prompt, there's a lot of misinformation being shared around in forum and elsewhere about those scripts - they prompt you before updating - and have option to turn off the prompt as well, its a very miniscule bash script with config variables mentioned in documentation, sorry but had to correct ..

While I agree in theory about the rest of the message, I am not sure if github is the place for querying about support. P2P layer not yet enabled - something as a pool operator responsible for making blocks, you'd be expected to know. So while it would be nice to finally have it up atleast for testnet for starters, it's not a bug report/missing doco/hidden.

[gufmar]

Hi @PyurOfHeart As the creator and maintainer of TopologyUpdater (you name it a very opaque API) I want to answer to your issue created by a slightly opaque just created and nowhere else used github account. ;-)

Today, a stake pool operator will find that it's impossible to get incoming connections from other relays without using the topology updater script linked above, so you'll find that most (if not all) pools use this script to call out to a closed-source, opaque API. The script (by default) auto-updates itself, and most likely poses a single point of failure for the cardano network if malicious actors take control of the repo hosting it

let's rewind to 8-9 months ago, when ITN just finished and some of us (today many are open-source contributors at https://github.com/cardano-community/guild-operators ) wasn't that happy about the announced mainnet launch without P2P support. The proposed and still working alternative isto register your relays on-chain. IOG implemented a star-like solution: they continuously parse all on-chain relay registration and publish them as easily digestible JSON dataset at https://explorer.cardano.org/relays/topology.json The official recommended way is to either just use the default relay set in the default topology file from https://hydra.iohk.io/build/4096235/download/1/index.html or alternatively pick some (not more than 20) relays from this published public list.

another alternative is that you use existing tools such as dbsync/smash, to parse the chain data from your own nodes database, and use some of your findings as outgoing connections. if enough others do the same this should allow you some incoming connections, soon after you registered your pools relays on chain.

the official implemented solution from IOG also includes sort of a guarantee that at least one of the IOG main nodes will try establishing a connection to your node. afaik this still works. not nice, not decentralised, not fully transparent but what you describe as "impossible to get incoming connections" seems not true to me.

I personally, in the expectation that the announced short-term p2p availability will take 2-3 weeks longer than expected (shortly after mainnet launch they said), I wanted to provide a little helper service in the quite hectic initial days. operators had a lot of other things to do, instead of initiating and updating manual peering agreements. The goal was and still is to achieve a diverse instead of star-like connection topology. If you are interested to read more about how TopologyUpdater ensures a good selection of globally distributed peers based on some simple formulas and functions, please give a read to https://cardano-community.github.io/guild-operators/#/Scripts/topologyupdater?id=why-does-my-topology-file-only-contain-iog-peers You can use similar logic to pick good peers from your own dbsync parsings.

Since August 2020 month after month passed, and the little intermediate helper service became more and more popular. today close to 2000 active relays use this service, update their subscription every hour and get a fresh topology-set. A lot of time and efforts spent to secure the service from 3th party attackers. Basically, it is the same as what you and everyone else can do for yourselves with dbsync/smash. you (or one) can even develop and publish a copy of the TopologyUpdater concept in order to provide to the wide SPO community what you currently miss. Don't expect any recognition from official side (as long as it is not implemented in pure Haskell). SPOs will like and use it. also don't expect rewards or some other benefits. may some github issues and support requests from time to time. For example to explain how the custom-peer part in your local TU script allows you to still maintain some manually selected peer connections. This way you and other SPOs don't have to fully rely on TU and IOG services only.

The official engineering team had to make decisions about priorities, delivery timelines, milestones... hard-forks, native tokens, metadata, .... P2P so far hadn't the priority, to make central hosted json files or the TopologyUpdater service obsolete.

[ank-everstake]

Don't like to discuss important tech topics on forums/TG chats. They are very hard to track and search. And basically blockchain is about transparency and decentralization.

The first source SPO should study and periodically check is the official doc page. So there must be a note or section that mentions this. And issue page on github is the best way to track and refer things in future.

P.S.: thank for your hard work @gufmar. Outstanding example of how to participate in the community life and to solve problems together.

[karknu]

Your relays are made discoverable by including them in your pool's registration certificate. Some time after that you have submitted the cert they will show up in https://explorer.cardano.org/relays/topology.json and in theory any other SPO could connect to them. As Gufmar mentioned IOHK will connect to your node so you will have at least one downstream peer.

https://docs.cardano.org/projects/cardano-node/en/latest/stake-pool-operations/register_stakepool.html list the option but it does not highlight the importance of registering your relays on chain.

[PyurOfHeart]

@gufmar thank you for your contributions to the community, and thanks for providing more context about the history of the tool. I really appreciate all your work and use the topology updater as an SPO. This issue is not meant to disparage the script/API or any of the other tools contributed by the community, my main goal is to understand what the current “official” solution for this problem is from the POV of IOHK and the cardano maintainers.

Your comment is the first time I’ve ever seen a mention of what IOHK’s preferred relay discovery method is today, and I suspect that I’m not the first SPO to be in this situation. So your summary alone about the star-shaped network topology provides a ton of value, filling in a gap in the documentation.

I do think this is the correct forum to bring up this issue — it is reasonable for an SPO to expect guidance from IOHK and the maintainers about how they should discover other relays. Even if the guidance were “we don’t have a way, just use the default topology file we publish and wait for P2P support” that would be better than what we have now — which is no information or guidance at all.

Your relays are made discoverable by including them in your pool's registration certificate. Some time after that you have submitted the cert they will show up in https://explorer.cardano.org/relays/topology.json and in theory any other SPO could connect to them.

@karknu thanks for highlighting this. I’d be happy to contribute to the docs repo with a summary of this and advocate for the use of the topology file published at the explorer website to find peers. I suspect an SPO can use a few commands to filter that list down to 15-20 peers locally, without using any external sources of truth.

[gufmar]

btw: P2P soon https://iohk.io/en/blog/posts/2021/04/06/boosting-network-decentralization-with-p2p/

[laplasz]

@PyurOfHeart thanks for mentioning this! I am also the guy how prefer following official documentations - and I knew this specific issue with documentation from the beginning but unfortunately forget to contribute and extend the documentation.. now just went through the new version of registration process and I think now it is fixed what was missing before.. thx!

[PyurOfHeart]

I think this is addressed with https://github.com/input-output-hk/cardano-node/pull/2591. Given that P2P seems to be actually arriving soon, I think it's fair to close this out. Thanks @olgahryniuk for updating the official documentation