I really don’t think that the relay nodes are indispensable. I’m almost sure that Algorand consensus could be run on a peer-to-peer gossip network very efficiently. Peer to peer networks are really capable networks and they can achieve stunning performance. They just need to be implemented well.
I don’t know what is the reasoning behind using these relay nodes. Maybe the developers were unable to use UDP correctly so they decided to use TCP. But you can’t use TCP in a peer to peer network because routers block TCP connections, so they had to use relay nodes to be able to communicate in a client-server style instead of peer-to-peer style.
In my opinion, existence of relay nodes does not make Algorand a centralized system. Because nodes do not need to trust relay nodes and anyone can theoretically build a relay node. Again I don’t know why there is a permissioned list of relay nodes and they don’t let normal users to make relay nodes.
I totally agree that we should have a peer to peer network instead of this strange client-multipleserver architecture.
Anyone can run a relay now, and any node can specify the peers (relays) it connects to, either via DNS, json phonebook file, or delimited list of peers to -p argument.
Given enough shared stake, people could setup a completely independent relay chain with an agreed upon seed list (via whatever means they want - including their own dns records or just a web page - like cosmos and their seed lists) and everything would work just fine. They could take over the relay network in a sense (but this isn’t possible right now obviously because the stake isn’t there). The key is - it’s all open - and all possible as part of the design.
I think the relay argument is way overblown. There are definitely other chains that quite explicitly don’t allow anything but pre-arranged permission to join, in any form. Algorand is definitely not that, in any form, including relays. Right now, ALGO is centralized, because it’s a proof of stake chain, genesis minted, that still has to be released. This is pretty much a given.
Them, all that’s actually ‘centralized’ right now is control of a default configuration bootstrapping mechanism - a DNS record. That same record, is a configurable option in the node config. It’s just not a big issue IMO.
The argument that relays could censor transactions is legitimate though, so the planned mention of allowing explicit dual lists for the node config is a good start. I’d like to see, as part of a roadmap to decentralization, information about how this could be handled so that relay discovery is baked in. There are a number of approaches that could work here.
Hi @stephenfoundation , curious whether there have been updates on a plan to provide long-term sustainable incentives for relay nodes. Perhaps you could point me to a thread/article.
Separately, if anyone can participate with 1 Algo, why there are just 1,000 - 2,000 participation nodes active? What are the incentives for running a participation node?
If there are no incentives, how might this be kept sustainable and not just altruistic?
If there are incentives, what stops a LIDO type protocol from emerging that would swap your Algo (and use it for a participation node) and give you a liquid pAlgo token (as well as a rewards token) in return?
Also, I found this reference saying that all Algo gets rewards, regardless of whether they are staking or not. Is this true? [Odd this isn’t clear from the official Algorand documentation, or maybe I’m missing it]
Thanks! Keen to learn what long-term incentive structures Algo comes up with for participating and relay nodes to function in a stable and decentralised way.
Thank you for your answers.
So the consensus of the algorand validators (participation nodes) is decentralised and 1/3 of the participants (currently about 136 nodes) are required to block the production of blocks. However, the relay nodes, while not participating in the consensus, are semi-permissioned and managed by the algorand foundation.
What is the minimum number of honest relay nodes for the network to be able to operate even with degraded performance? 2/3, 1/2, 1/3, 1 nodes?
An important first point if that relays are only doing networking. As long as 80% of the stake participating is honest, Algorand will not fork.
If enough relays start misbehaving, they can slow down/stop progress but not fork the network (assuming 80% of the online stake is participating honestly).
But there is an immediate fix to this: just remove the relays from the list.
The Foundation can easily do that.
In case, the Foundation does not do it, anyone running a participation node can actually do it themselves (you can manually specify the relays to which a node connects to).
More generally, any person can publish an alternative list the same way the Foundation does.
It then just needs to convince other nodes to use it.
It is just one configuration line to change to use another list of relays.
Now, to the exact question, I don’t know if anyone did any test of the above.
It also depends on what the non-honest relays do.
If the non-honest relays just stop responding, then you just need enough honest relays to hold the amount of bandwidth of all the other nodes.
My guess (but I did not do experiments) is that you need at the very most 10-20 honest relays.
Maybe 1 or 2 relays are sufficient (if they are very very good honest relays).
If relays start acting maliciously, for example injecting incorrect messages, then things are slightly less clear. But again, the relays can just be removed and the network starts again without at any point being in an insecure state.
It that relay nodes are the same as participating or archival nodes, but relay nodes must listen for other relayers (and for connected participating nodes, I assume). It seems this requires much higher performance/computing power from relay nodes.
The docs say the following, which isn’t a deep explanation of why much more compute is required:
" Relay nodes are where other nodes connect. Therefore, a relay node must be able to support a large number of connections and handle the processing load associated with all the data flowing to and from these connections. Thus, relay nodes require significantly more power than non-relay nodes."
Could you expand on why relays require much higher performance/computing?
i think it say it right there. The bandwidth requirements due to the data flowing through them. Currently there’re fewer relay nodes to participation nodes and they have to handle all these connections. Relays i believe also have to be archival so increased storage requirements. You can think of relays as IXPs on the internet and you can get an idea
Where does the 80% stake come from?
The handling of the relay list should not be manual, but managed by an algorithm based on the reputation of the relays (e.g. past behaviour, SLA, operational efficiency, etc.).
So theoretically, even one relay is sufficient if it is powerful enough and if all participation nodes change their relays list.
In practice things are slightly more complicated and there are several parameters to take into account.
As I wrote above, an algorithm is needed that dynamically changes the relays list according to the network conditions. A sort of routing protocol as in computer networks (OSPF and BGP style :))
