10mm min = 1000 max #of nodes
1000 * x watts = network max energy req
You can start by defining how much max energy is reasonable (compliant) to spend and then get to your min node stake cap.
Lower max cap might become redundant then
High max cap* redundant I meant to say, sorry
Not only can they spin up multiple nodes and control them like they would with just a single node, but all the same concerns about cloud outages would apply. If they have 60MM in one node on AWS, or 60MM spread across 6 nodes on AWS, the result is the same if AWS goes down.
What you hope for is that the mega whales (namely the exchanges) are cognizant of this and are following best practices in concert with AF so that stake is spread around in multiple environments.
I’m not sure if the current cap is too high or not, but I trust that John and his team have much better insight into these things than I do.
1 Like
I don’t think a 10MM minimum was suggested. The discussion was about a maximum allowed in a node.
Oh shoot my bad lol.
Like I said, if they do it then it means they don’t understand risk management … and that they are dumb.
I have 2 words for you … Risk Management
Any staking pool provider that operates like that is reckless and not only puts their business at high risk but also the entire Algorand network.
Do you think Visa / Mastercard (or any large enterprise) operates their production systems in a single data center? It would be foolish.
1 Like
Why not redefining and decoupling staking from node operation? It seems to me all these problems discussed are in nature dependency problems simply because ALGO is overloaded with conflicting functions creating friction between different incentives that don’t play well with each other; like e.g. monetary, utility and ownership functions.
Just talking out of my a** here, but the most friction between the object of node incentivisation and its function is in my unqualified opinion the “side-effects” of Algorand inheriting economic inequality. One ALGO one vote is a fair representative system when locked into a black box, but crumbles when coming in contact with economic realities. So the issue to me is in finding a way to incentivise everyone equally, but without taking away the rights one acquired by power of monetary wealth, that is, without compromising the privileges of ownership - a contradiction. But Ownership could be efficiently shared across the network if incentives are utilised to foster cooperation
So, what about this crazy theoretical assumption: Since PPoS utilises random functions for equality of outcome, and every participating ALGO is sharing the same characteristics in consensus, wouldn’t it theoretically be possible to temporary “fix” inequality (in this case of ownership) simply by reallocating aggregate participating ALGO in such a way to incentivise all participants equally, that is, nodes and all stake sizes, without ultimately changing ownership?
We could maybe do so by means of temporary distributing the weight of stakeholders across the entire network. If we assume that nodes in the network share the same ALGO weight, equalising the probability for selection in dependence on availability; and further assume a verifiable, random distribution of stake across the network on top of PPoS selection and probing, it might incentivise and lead to network-wide equality of opportunity. If so, it appears to me we could get:
- Separation of Concerns: Stakeholders and node runners are significantly less dependant on each other
- Diversity: There would be drastically more space for node runners, because they effectively attract stake from stakeholders and share the rewards proportionally.
- Efficient Probing: The most efficient nodes would acquire more shared stake over time than less efficient ones.
- Minimise Absenteeism: Using PPoS for temporary reallocation would allow for highly decentralised topologies.
- Natural Pooling: All node operators share aggregate stake and reward of the network.
- Equality of Opportunity: All stakeholders and node runners share the exact same opportunities in the network.
It seems to me such an idea would, if I am not totally bonkers, only be applicable on Algorand because of PPoS.
Agreed, but we have to consider the pools as attackers first sadly.
Any staking pool operator controlling more than 20% of global stake puts the network at risk.
Mitigation ideas already in the paper:
1.To make nodes as accessible (low cost) and simple to use for individuals. (one click nodes) (At launch). Mobile OS run node/wallets could be a pretty effective mitigation method.
2.Finding the lowest staking cap (with a reasonable max carbon footprint) that allows maximum individual participation vs pool (At launch).
3.Punishing bad behavior disconnecting offline Algos from staking and making them pay to re-enter.
For your consideration, 4.
Maybe we could limit the activation staking rewards to the range of a healthy Algorand Network:
A block reward multiplier derived from the node successful hit rate of the block round (n) to be applied and paid in block (n+1) where:
80% successful node hit rate, sets the multiplier to 0 and therefore, no fees, no party, bad pools.
100% successful node response, sets the multiplier to 1 and full rewards are distributed to everyone. (plus you can throw some $Oranges in everyone’s bags for kicks and giggles)
In this case is in the best economic incentive of the Pools is not only to concentrate as much control of the stake to increase the size of the rewards received but to always keep the online stake rate at its highest and healthiest to fully materialize those rewards.
All these strategies would never fundamentally defend the network from a non-economical (pure-evil) Attacker, because at large global infestation numbers of cancerous Algos the VRF becomes comfortable and very predictable for the attacker. Maybe introducing oscillation through a feedback loop in the VRF could help but that’s for some other day.
Much 
to all, Algorand!
Hi, the following is just my opinion based on rational logic. Please do correct me if I’m wrong. My understanding (as a non technical/non geek investor), I also have questions:
- The higher the stake amount allowed per node, say 67 million algos per node, the more centralized (securing the network) it CAN become right? assume a whale(s) with 3 billion algos for example, just need around 44 nodes to stake 3 billion algos. 44 nodes is so less.
2). The more nodes means higher security? The less nodes means lesser security right?
3). If we make the maximum amount say 5 million or 10 million per node, then someone with 3 billion algos would need to invest a lot more to run nodes using all their 3 billion algos… which In turn would mean higher security for network overall right since more nodes?
The more investment would also incentivize the whales to take extra care of their nodes I think. Which is good for security?
To add to this, if you can make running a node on all operating systems like windows mac etc super duper duper easy, then ppl with 10,000 algos who know nothing about computers will also run nodes - it comes down to how technical it is to run a node. - I feel this is important, if you can make running a node super easy, it will really help. Node operators will pop up in all corners of the world.
1 Like
Exactly. Let’s not forget why we are here - Decentralization. Decentralization is the foundation.
The bottom line is that the network’s decentralization depends on the node runners participating in consensus. The more centralized the stake is, the less decentralized the network is, and the more vulnerable the network becomes, i.e., the weaker the foundation. The larger the staked ALGO cap per node, the more centralized the stake will be.
The vision was to make it easy for anyone and everyone holding ALGO to participate in securing the network. We do need a reasonable minimum stake requirement, but we also need a reasonable maximum stake requirement without compromising decentralization and network resilience. In addition, the process to run a node and participate in consensus should be as automated as possible, as simple as possible, and as robust as possible.
We need to take a step back and not get ahead of ourselves. I propose consensus incentivization be rolled out in phases:
Phase 1 - Roll out 1-click nodes
- 1-click nodes should be rolled out before incentivized consensus participation. The 1-click node should have built-in automated workflows for:
- consensus participation
- node updates
- telemetry - monitoring and alerting
- fault recovery
- 1-click node software package distributions should be created for all major platforms: Windows, Mac, Linux, and Kubernetes for cloud deployment
- There should be a global consensus participation dashboard to monitor the network’s health.
- 1-click node deployment versions should be identifiable on the dashboard
- Documentation and training materials should be created. A node runner manual is required.
- Define measurable exit criteria to enter the next phase.
- The program should run on testnet before mainnet
Phase 2 - Governance vote on consensus incentivization protocol upgrade
- Upgrading the protocol to support consensus incentivization should first be voted through normal Governance. The success of the 1-click node program (Phase 1) will be a key for the vote.
- The minimum and maximum ALGO stake limits should be voted on. Governors must understand the implications and the impact on overall decentralization and network resiliency.
If the vote does not pass, then we iterate.
Phase 3 - Rollout the consensus incentivization protocol upgrade on mainnet
We talk about how important the developer experience must be for ecosystem growth. The node runner experience trumps everything else by orders of magnitude.
NOTE: the above proposed phased release is at a high level. A more detailed plan will be required. The devil is in the details.
I feel compelled to respond to a few elements of Phase 1 in this proposed plan:
- Easy-install nodes are here already—three different versions, in fact. Two of those, PixelNode and Aust’s node installer, are developed by the members of the community. What more is needed? What are we waiting for?
-The “roll out” directive implies that you want the Foundation to do it, which would run counter to the stated goal of decentralization, to some extent.
I just want to point out that this is not something that should necessarily be automated. Node runners need to be attentive and aware of what’s going on. If they choose to “vote against” a consensus upgrade with which they disagree, their mechanism to do so is not upgrading their node.
1 Like
Easy to install != one-click
Individual participation vs pooled participation should not be a concern if we can align the incentives towards keeping the highest consensus stake online possible.
Here is an idea. Making the pools care about protecting the network, they will be also incentivized to improve risk management constantly.
Those are good points.
Perhaps the “1-click nodes” name is too simplistic. 1-click nodes are more targeted for retail that install and operate a node on a personal computer. Stake pool operators require a node cluster manager solution.
It’s great to see community members stepping up to the plate to build 1-click node solutions. However, support considerations are crucial. Unless these solutions are professionally built and supported, they are risky to use.
Algorand Technologies has a vested interest in Algorand’s long-term success. Yes, it would make business sense for Algorand Technologies to offer supported node manager solutions:
- 1-click node solution targeting retail, i.e., for non-technical users
- Enterprise-grade node cluster manager solution targeting large stake pool providers
- Algorand Technologies should commercially offer a staking pool service
To answer your question regarding “What more is needed?”, the answer is a lot which requires a lot more discussion.
Exactly. We need much more than 1-click nodes that are easy to install. We need robust node manager solutions for consensus participation targeting different use cases:
- single machine solution case for retail consensus participation
- enterprise-grade cluster solution for large stake pool providers
Potentially unpopular opinion: I don’t want my network run by inattentive, fire-and-forget node-runners. I reject the premise that we need to further enable a pattern of node installations that are likely to become zombie nodes.
I don’t have the data handy, but the most recent consensus upgrade from 3.20 to 3.21 showed a large number of nodes who were still on quite old versions of go-algorand, and not just 3.19, either—people who hadn’t upgraded since 3.15. My theory is that a large number of people who were nudged to run a node for the first time by Voi and decided to set up an Algorand node in the back half of 2023 were these inattentive node runners.
Maximizing retail participation is not an automatic recipe for network resilience, and it could instead lead to detrimental outcomes if a consensus upgrade is needed and node runners are not paying attention. Remember that a network halt, for any of various reasons, may require node runners to upgrade or downgrade their nodes to restart the network.
If we want to be collectively prepared to respond to such a network interruption, maximizing unattended, “one-click” node installations is not the way to do it.
2 Likes
Not un popular at all. Agreed individual participants (retail) most likely won’t be upgrading their nodes as much.
And also agreed.
Individual consensus participation friction should be reduced that’s a no brainer.
But
With incentives on pools will become inevitable and they do pose a more serious risk due concentration of the online global stake.
But if the actual vector attack is them taking their stake offline at any given moment, we could just make the block rewards directly related to the node online rate which can be tacked per round and used to derive a multiplier.
I’ve been using these and while they work for basic consensus participation, could use some QOL improvements.
Pretty much lays out what’s missing.
Not at all unpopular. You’re right to be concerned, and there should be mechanisms to discourage this behavior and remove these nodes from consensus. Slashing and increased fees to rejoin consensus after getting das boot would be reasonable and likely effective measures.
Technical barriers to participating fully in the ecosystem shouldn’t exist. This should be simple to deploy and maintain, with explicit warnings of the penalties for failing to maintain your node appropriately.
1 Like