Once p2p participation nodes are in place how are they different from relay nodes other than having the participation key and hardware/network requirements? Let’s say we have a participation node that satisfies the hardware/network requirements of a relay node, can it do the job of a relay node as well?
If the answer is yes, doesn’t it make sense to design the incentives for participation nodes in a way that more participation nodes satisfy relaying requirements and therefore drop the relay node concept and therefore the need to keep and maintain a central list of relay nodes?
If the answer is no, any other alternative idea that allows removing relay nodes as a separate concept in the Algorand network?
1 Like
i believe answer is yes. relay nodes can technically serve as participation nodes. however participation nodes takes more cpu i think under heavier load, so it is better for relays just to serve the networking feature…
1 Like
The core issue is that with the current set up relay nodes have to be selected by the foundation. Yes, that’s the default list but practically that’s the list. The incentives are also manually allocated to them. This continue to be a major sustainability and decentralization issue for the network.
2 Likes
But this issue is worked on … The P2P network of participation nodes will be able to work without the relays. The main feature of relays is that when you connect to the network for the first time it serves you the list of ip addresses to connect to. Next feature of relays is that you cannot technically connect two servers behind firewalls together without some internet relayer. It was also the feature of the relay node to archive everything and this has been already solved. The relays are not necessarily the archival nodes now and the point for relays is more the networking then storage.
In the future the AF will opt out from expensive relays and keep only the cheap ones with great networking in my opinion. And when they will see the that network can function efficiently without them (that sufficient people are hosting participation nodes in the clouds with good networking speed) perhaps they will opt out completely and keep rewarding only participation nodes.
1 Like
Next feature of relays is that you cannot technically connect two servers behind firewalls together without some internet relayer.
I don’t quite follow this. Can you clarify what exactly you are referring to?
they will opt out completely and keep rewarding only participation nodes
That would be good if rewarding/incentives are aligned with what network needs which is good connectivity. The current participation nodes incentives proposal doesn’t cover this aspect (at all).
2 Likes
Point of the firewall is to cut all connection from internet to local network.
If you run any application in local network and your friend runs it in other local network and both networks are behind 2 firewalls its not possible to connect these applications. You need some simple relayer to connect to from both firewalled apps and then you can relay the info from one app instance to another.
1 Like
It would be great if someone from AT/AF teams confirms that we can configure a node to be both participation and relay when p2p is enabled. Or if not, why and what needs to be done to make that happen?
@shane-at-algo
@JohnWoods
1 Like
Yes that’s the idea.
If by relay you mean propagate data to other part nodes.
1 Like
Thanks John for the response.
I mean something more specific, which is dropping the relay node concept and therefore the initial relay nodes list (there could be still an initial list of nodes or any other mechanism typically used in p2p networks with uniform nodes) altogether. In other words, dropping any relay-specific logic in Algorand codebase.
Another way to look at this: let’s say participation nodes (or a good subset of them) have the hardware/network spec similar to what’s currently required for relays, then is there still any need for relays. What logic/mechanisms/assumptions in the Algorand code/deisgn depend on having a set of relay nodes?
If dropping relays only boils down to having all (or a subset of) participation nodes with necessary hardware/network spec, then why not just aim to make that happen with the p2p+incentivisation plan? Or, why not include those hardware/network spec factors in the incentivisation now, instead of postponing that to after more experimentation in the hybrid state?
I get that there is some value in experimentation and learning from data, however the key facts are already known:
-
If relays are going to be eventually removed, then participation nodes should be also rewarded for relaying, otherwise that’s unlikely to happen sustainably in the long run. So, some form of direct/indirect incentivisation is necessary.
-
Relaying metrics should be defined, or how a relaying work is measured.
It seems to me that the relay incentivisation shouldn’t be part of core consensus but part of the contract between nodes. Every node in the network can define a cost (per hour for example) for accepting connections from other nodes. For most nodes by default the cost is zero. However, for nodes with higher hardware/network spec it is possible to define a non-zero cost (manually set by the node’s owner in a config file). Whether the payment happens automatically or manually (by the client nodes’ owner) is a less important issue at this point. The key point is that the incentivsation is defined at the protocol level with a decentralized mechanism and the need for having a central/default relay nodes list is removed.
Will try to come back on this later, don’t have time to reply atm.
2 Likes
It would be great if some people from AT could take a look and evaluate the feasibility.
1 Like
In other words, dropping any relay-specific logic in Algorand codebase.
This won’t happen in the short term. We’ll have both options available, with Relays operating in a reduced capacity, until we better understand the network performance after the topological change.
Another way to look at this: let’s say participation nodes (or a good subset of them) have the hardware/network spec similar to what’s currently required for relays, then is there still any need for relays.
Specs for participation nodes won’t change, P2P will likely enjoy 1000s of nodes, we only ever had ~100 Relays.
Or, why not include those hardware/network spec factors in the incentivisation now, instead of postponing that to after more experimentation in the hybrid state?
P2P is a gargantuan shift in terms of network topology & data propagation, it would be hubristic to skip hybrid form.
If relays are going to be eventually removed, then participation nodes should be also rewarded for relaying
Participation nodes won’t be protocol rewarded for propagating data, it’s implicit in operation and required to execute consensus.
Maximal decentralisation comes at the cost of speed. We’re aiming to keep block times sub-3s post-P2P, but we don’t know yet how performance will look outside of synthetic benchmarks.
Optional “fastpath” Relays can be privately operated as a paid service.
Hope this helps, I don’t have a lot of time atm to spend on these forums.
1 Like
Thanks John.
What I suggested does not require changing participation node requirements or any other major change that risks current plans. What I’m suggesting is basically what you wrote:
Optional “fastpath” Relays can be privately operated as a paid service.
Whereas there won’t be any default relay list and therefore the payment (of paid service) is decentralized. In other words, the foundation manual role is removed and it is up to participation nodes to pay a portion of incentives they receive to relay nodes in order to benefit from the relays fastpatth.
I think the part that I suggested “dropping the relay node concept” caused the confusion. Let’s put that aside for the moment because that’s not the key part.
1 Like
Yep - my ideal is that the Foundation runs no infrastructure, neither meaningful staking nor any Relays, need a little transition time though.
2 Likes