Hello ALGO team and all participants!
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?
Thank you!
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.
@krotkiewicz and @rmb,
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 -
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.
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
// rewards.
RewardsPool Address `codec:"rwd"`
@aojjazz - ahhā¦ I see where the confusion comes from.
It said āIt can only spend to the incentive poolā, but there is no process that does that.
In fact, you can look here and see that no transaction have ever been executed that moved Algos from the fee sink to the reward pool.
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.
Actually, Iāll have to check again - Iām probably thinking of the transfers out from the reward account (also no āactualā transactions for those).
Who owns that address?
Doesnt that make the Algorand blockchain rather centralized if there is a single entity collecting the transaction fees?
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.
@petew, I donāt know for sure. I suspect that the Algorand Foundation has it, but I could be wrong. Either way, you can easily see that no one has yet ātakenā any of these fees.