As far as I understand, Relay Nodes are backbone of the Algorand network. Algorand Inc pays some 3rd parties to run these nodes (outside of the consensus algorithm itself, the network itself does not rewards relay nodes).
This looks like a big problem for the Algorand network and prevents it from being self sustainable.
Are there any plans and timeline to solve that?
The documentation states: “Technically both non-relay and relay nodes can participate in consensus, but Algorand recommends only non-relay nodes participate in consensus.”
I agree that a relay node will require more (network, CPU, memory, file handles etc.) resources than a non-relay node, but I don’t understand why they should not be participate in consensus if appropriately motivated/remunerated. System requirements can be appropriately provisioned - especially in a containerised virtual hosting environment. (Look at the resources thrown at Bitcoin nodes just to keep operating. The Algorand consensus mechanism does not create a self-sustaining power-struggle - it just requires sufficient resources to function efficiently.)
Perhaps a relay node participating in consensus could be rewarded a greater amount than a non-relay node. Perhaps the reward could be related to the number of concurrent sessions it is capable of maintaining with peers. The (financial) reward needs to drive behaviour that is beneficial to the overall operation of a distributed network.
My thesis last year was the optimisation of latency in P2P networks and it seems that a 2-tier decentralised approach with no incentive to maintain highly connected, responsive nodes could become the Achilles ankle. As the number of non-relay nodes increases and the rate at which the network needs to process transactions increases, then if the relay network is not incentivised to increase both the individual nodes’ resources and the number of relay nodes, then the network performance will start to suffer.
The operation of relay nodes outside the network incentive mechanism means that each operator becomes susceptible to doing the bidding of the party paying the highest amount. Compromising the relay network (and its interconnectivity) becomes much easier than compromising a more fully connected network.
Also, the approach of having a core network to which other nodes attach doesn’t necessarily lead to improved latency of information traversing the network and certainly increases the likelihood of (temporary) network partitioning.
I really can’t tell what the income sources for the network are going to be in 5, 10 or 20 years from now.
As you’ve both speculated, there are some ongoing operational costs that need to be covered ( the relays are just part of that ).
From what I can see, Algorand currently has at least four different potential streams of revenues -
The fees are being collected, and currently - not used. In the future, Algorand
might make a different decision around these ( i.e. maybe 80% would go to rewards and 20% to maintenance ? )
The rewards on the platform are currently being distributed to everyone, so I’m sure that Algorand gets a fraction of that.
Third parties solution provider.
The Algorand mainnet won’t be able to grow indefinitely, and the need for expanding the network would outgrow the mainnet capabilities. When that happen, other co-chain would be spawned. Algorand set itself up to be in a great position to offer support for these services, don’t you agree ?
Selling some of the stake. ( currently being executed by the foundation )
As the price of Algo increase, the amount of Algos the need to be sold would go down.
I’m sure there are other potential sources of income, but I wouldn’t be worries about the maintenance cost of the relays.
Also regarding @rmb comment about not having a relay participate in the consensus - this was stated just so that it would “remove” the relay from being the target of an attack. If the relay is not the one that it making the proposals/votes, there is no motivation to try and “hack” it. That aligns with the original white paper where “corrupting a voter after the vote was sent would not accomplish anything, since the vote was already sent”; or from more practical view : hacking this relay would not help you to reveal any of the account keys…
Hacking doesn’t always seek to directly steal something of value. Graffiti in the analogue world & perhaps DDoS in the digital world (or an even more subtle disruption that selectively targets the smooth flow of pending transactions across the network). If the disruption of the network can be advantageous to someone then it will become a target and the relays are the potential Achilles heel.
I can see the benefit of keeping keys off nodes that are visible to the whole network. But suggesting that just because a non-relay node is hidden behind a firewall might give some people a false sense of security regarding the keys on their node. There are plenty of ways to infiltrate someone’s network and people should be hardening their nodes to protect keys. If all nodes participating in consensus are appropriately hardened then they might as well open up the TCP ports associated with operating the network and become relays with appropriate remuneration. (This assumes that the algorand code has been peer reviewed and probed from a security perspective.)
As for keeping keys on a node, there are ways to keep a key off-node and establish secure sessions to retrieve them (e.g. to HSM or software equivalent hosted on a different server). I would rather bolt on key management security products than traditional network perimeter security solutions - though security in depth is always to be encouraged and a layered approach for the security of the node, OS, network, key management, logical and physical hosting environment etc. ought to be the norm. (I wonder when next generation firewalls will be doing deep packet inspection to determine the threat level of incoming data for algorand nodes - or perhaps the nodes should implement peer-to-peer session-level encryption making external deep packet inspection pointless.)
Setting up a proof of concept and a low-value application can be achieved relatively quickly and simply. A high-value application, and the use of personally identifiable information, requires additional disciplines that aren’t as easy to source. The Minimum Viable Environment will be dependent on application.
The mainnet’s inclusion of cryptocurrency means that there could be a lot at stake for some people - both now and in the future.
I very much agree and look forward to your thoughts on my other thread about spawning networks.
Actually, all transaction fees are currently sent to the reward sink account.
@aojjazz Where have you seen that ?
on the mainnet genesis.json, the
Y76M3MSY6DKBRHBL7C3NNDXGS5IIMQVQVUAB6MP4XEMMGVF2QWNPL226CA address is the fee sink, where all the fees are being sent to.
The 737777777777777777777777777777777777777777777777777UFEJ2CI address is the reward pool.
I’m unaware of any transition of funds from the fee sink into the rewards pool.
You might be able to build up a private network which has the same account on both… But I haven’t tried that.
// The FeeSink accepts transaction fees. It can only spend to
// the incentive pool.
FeeSink Address `codec:"fees"`
// The RewardsPool accepts periodic injections from the
// FeeSink and continually redistributes them to adresses as
RewardsPool Address `codec:"rwd"`
It’s not literally an on-chain transaction - just like the transaction fees aren’t a transaction for their fees back ‘out’.
It’s a direct account update in the node code. I walked through it one time and I’m pretty certain saw it all there.
Hrm - I don’t see anything obvious in the code. I see where the transaction fees are moved to the FeeSink ‘account’ and I also see that the FeeSink account can ONLY spend to the RewardSink account.
So at this point, without any code changes you can assume the fees are effectively burned.
If/when the foundation (who presumably has signing keys for that account) wants to then they can send the fees ONLY to the reward account - which then pays back out like it does now.
At some point in time once the foundation stops funding the reward account they may choose to make it an automatic process in the code.