I am trying to decide how many relays to get for the staking pool I am setting up. My understanding is the relays help get the transaction information to my block producing node faster. Is this the only advantage and is the speed really that much faster? Does this equate to more revenue? And if so at what point is their diminishing returns on buying more relays? I assume each relay should be in different areas of the world to maximize getting transaction information faster?
1 Like
Your block rewards do not depend on how many and which transactions are in the produced block. So, getting transactions to your block producer faster does not really have an advantage in that regard.
Relays in different parts of the world do help in propagating your produced block faster after creating it, though. That might reduce the risk of getting it orphaned, of another block producer that did not get your block in time resulting in a longer chain or otherwise winning a fork battle.
But the main reason for relays is to protect your block producer from being known to the world from getting hit by DDOS or hacking attempts directly. (Which is also why putting the BP and one of the relays on the same machine only makes very limited sense.)
The two relays in different data centres in different parts of the world recommended everywhere seem totally fine.
In theory, you wouldn’t need a relay at all and could just run one node, the block producer, but that is not recommended at all. (Given the quality of SPO support questions, I’m not sure if a well-maintained BP exposed directly without relay could not be more secure than the majority of no-clue-relay-setups out there.)
2 Likes
@HeptaSean I have another question, if I use DNS with different A records pointing to different relays, will it always choose the first server IP listed in the A record? Or will it randomly choose between them?
The reason I ask is because if I get two relays in different parts of the world but use DNS to configure it in the P2P if it only ever connects to one because of the DNS, would this defeat the purpose of the two relays?
Maybe if I set the valency correctly it will know automatically to still connect with the other relay described in the A records of the DNS?
For example @Terminada posted a config file like this:
{
"localRoots": [
{ "accessPoints": [
{ "address": "relays.terminada.io", "port": 2700 }
]
, "advertise": false
, "valency": 6
}
]
, "publicRoots" : []
}
Notice the DNS is relays.terminada.io, would this only use the first IP address listed in it’s A Records for the domain name, or because it says valency 6 will it know to use all 6 relays he has? I say this, because if it does not then I would need to write this file differently listing each relay 1 by 1
As far as I understood it, the operating system will already give multiple A records to the application – if it is a browser or cardano-node – in a randomised order.
And, yes, if you give a valency equal to the number of A records, it should connect to all of them.
For what it’s worth, the standard topology.json for a non-P2P node at https://book.world.dev.cardano.org/environments/mainnet/topology.json is:
{
"Producers": [
{
"addr": "relays-new.cardano-mainnet.iohk.io",
"port": 3001,
"valency": 2
}
]
}
So, it will connect to two of the eight relays configured at that DNS name.
2 Likes
Thank you @HeptaSean , sorry to keep asking questions, I have one more though. I noticed that some users use bp.domain.com for the DNS of their block producing node, but is that bad practice? The idea of the block producer node is to make it not guessable by assailants correct? (Since only the relays are supposed to be able to talk to it), Would it be bad to use DNS to resolve the ip address of the block producer node? (This way it would keep the bad actors guessing what the IP Address is?). In short I was thinking of doing bp.domain.com, but would this be a security risk? I noticed others doing this but wasn’t sure.
For the reasons you stated – one of the ideas is that nobody knows where your block producer is – I would not do that.
3 Likes
@HeptaSean Alright thanks, I was wondering about that, it seemed like a security risk to me but wasn’t sure. This means that some other users may be exposing their block producing nodes without realizing it currently.
1 Like
Using domain names in your topology file is really more for convenience. There is no security risk so long as you have properly configured your firewall. Though it is definitely a good idea to only have your block producer IP address known to hosts on your internal network.
For example, you can run your own caching nameserver on your internal network, with specific extra configuration for your own domain names. So long as you firewall this from outside, then only your internal network hosts can access this nameserver. If you want to do this, I would recommend unbound but you will need to ensure this is firewalled correctly.
Although it is more work, I think it is generally a good idea to run your own caching nameserver because then you are not relying on your ISP (or some other namserver you don’t control) to tell you the truth about IP addresses. A caching nameserver does it’s own DNS lookups by starting at the root name servers and working down to the name you seek. It then caches the results so that other machines on your network will get a near instant result if they lookup the same name. This can greatly speed up name resolutions on your internal network and overall reduce network bandwith usage. In other words, running your own caching nameserver can provide security, speed, and bandwith benefits.
If you like the idea of running your own nameserver internally, then there are other useful things you can do with it. For example you can configure your nameserver to return the loopback address for every advertising domain name. This is a great ad blocker feature which causes every host on your network to not even contact advertisers websites because every time they look up their domain names they get 127.0.0.1 returned which causes them to contact themselves resulting in an instant rejection. Thus saving both network traffic and disabling the advertisers ability to track you. For more information about this see: https://pgl.yoyo.org/
If anyone is interested in using the caching nameserver unbound as an ad blocker this way, I can provide more information and some simple scripts on how to do it.
1 Like
This is super interesting, never knew all this about DNS, I’ve been researching a lot into unbound. Do you have any good tutorial videos/sources you recommend?
I don’t know any particular tutorials for Unbound off the top of my head. To be honest it is a while since I have made any significant changes. It is fairly simple to set up though so just reading a few tutorials should get you going. It is worth the effort I reckon for the reasons I stated above. Ensure it is firewalled though so it can’t be accessed from outside your internal network.