Consensus rewards whitepaper concern - General - Algorand

Some great points here, thanks for sharing your thoughts.

We’re trying to balance the amount of Algo online (and the amount of nodes which we also want increased), with the cost of operating nodes for a large amount of stake.

The paper is exploratory, so these are not hard decisions, but the lower we make the cap, the more expensive we make global staking operations.

Ensuring we don’t have a stall is primary, and thankfully, as per point 4.5.1 in the paper, we have some protection:

The absenteeism mitigation approach effectively provides ”Garbage Collection” for consensus, permitting relatively significant portions of global stake (5% to 10%), within a reasonable rolling time period, to ungracefully exit consensus ad-infinitum without detriment to the network.

post by vidhyanand on Feb 1, 2024

vidhyanand

We are planning to provide a pooling service where communities like (NFT community, meme token communities etc) can run their own pools to which community members can stake their algo to run efficient nodes. The profits they make from these pools can be distributed to their holders thus creating utility for holding tokens.

This will also ensure that retail community is also involved in securing the network.

So we recommend not to have any kind of whitelist for pools.

This will be added to service store of notiboy which already has a web3 notifications and chat feature.

We always welcome your feedback on running such a service.

post by Titi on Feb 1, 2024

Yep I agree, cap at 10 million, minimum also should be lowered, hostile capture of upgrades spot on as well. Ideally, mining percentage should be dynamic wrt some parameters that can fluctuate with the balancing of the operational cost and algos online

post by myshkin on Feb 1, 2024

myshkin

What do you mean by this? It seems an important point.

post by vidhyanand on Feb 2, 2024

vidhyanand

I think there is no plan from foundation to whitelist pools.

post by myshkin on Feb 2, 2024

myshkin

Just to chime in, I was hoping for some of these features years ago – mainly the ability for regular, non-technical Algo holders to participate in consensus. Somehwat old thread below:

Following up on this, I think a lot of Algo holders would be happy to contribute some or all of their balance to participation pools if those pools pledged part of their consensus proceeds for particular projects or infra that those users find important. Maybe we can build a model that facilitates this. Then people could “vote with their participating Algo” to fund initiatives or projects, taking some of the burden (and centralization) off of the Foundation and Xgov.

post by Imod87 on Feb 2, 2024

Imod87

I agree completely with your assessment. A naive solution I thought might be interesting to think about is utilising VRFs to decouple node and stakeholder incentives.

post by oysterpack on Feb 2, 2024

JohnWoods](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

Yes, a larger max lowers the operational expense for the node operator. However, everything comes with a tradeoff. The major tradeoff here is risk to network resilience. I would err on the side of caution. The proposed max limits are too high.

Is the Algorand Foundation reaching out to node operators to run the numbers and also to onboard?

It would also be in Algorand Technologies’ best interest, as a for-profit corporation and as ALGO whales, to provide a staking pool commercial service for Algorand consensus participation.

post by ROAM on Feb 2, 2024

ROAM

I think very large pools are not good thing so max cap is good. BUT how that will actually work, because some MegaWhaleNodePool Corp can create node1, node2, nodex… and so on, and basically have large control via multiple nodes. they can control them all same way than one large one. They can unplug and manage them all. So idea is good, but how the actual execution in reality will work? This is not negativity or fud, but thing that have to be taken into account.

Personally I like that 2^27 cap.

Best regards,

ROAM

post by vidhyanand on Feb 2, 2024

vidhyanand

We have to get community involved and create second layer of pools that will serve as layer of safety

post by ROAM on Feb 2, 2024

ROAM

vidhyanand](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

When you have more details and info, can you contact me on twitter @roamoilanen. I am interested to run COOP Node.

post by JohnWoods on Feb 2, 2024

Of course avoiding a stall is primary, however, the proposed limits are in line with the production mainnet stake topology today, where we would see stake representing ~5% of the active stake on a single node.

This metric isn’t static either of course, as global stake grows so does the ceiling, by definition.

We set the current 5% (~65MM Algo) guidance based on empirical analysis of the chain since launch.

What have you based this assertion on?

post by JohnWoods on Feb 2, 2024

10MM cap significantly reduces yield for any entity with 10’s of MM of stake, including exchanges.

There is a sweet spot, but it’s definitely above 10MM.

As per paper this must align with absenteeism mitigation.

post by oysterpack on Feb 2, 2024

JohnWoods](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

Algorand’s liveness relies upon at least ∼80% of the participating (”online”) stake to actively

and honestly take part in the consensus protocol in order to produce blocks.

Let’s assume the online stake is 7B ALGO.

20% is 1.4B ALGO
If 22 nodes hosting 65M ALGO become compromised, then the Algorand network is effectively down - assuming all other nodes are healthy

Algorand takes pride in zero downtime. Let’s keep it that way. The network will be reliant on these large staking pool providers. Thus, the protocol must be designed to promote enterprise-grade best practices.

Large staking pools should be operated at an enterprise-grade level, which means a distributed deployment architecture spread across multiple data centers across multiple regions for high availability, resilience, and disaster recovery to meet network SLA requirements.

By design, participation nodes are lightweight and cheap to run. The cost to scale out is negligible compared to overall operational costs. The lion’s share of the cost for large staking pool operators will be DevOps required to operate, maintain, and support a secure enterprise-grade deployment.

In the short term, ALGO price and transaction volume do not support enterprise-grade commercial models unless highly subsidized by the Algorand Foundation. The bottom line is we need strong ecosystem growth to drive ALGO price appreciation and transaction volume growth. Real-world commercial adoption at enterprise scale is required to economically sustain the network. Enterprise adoption is very risk-averse and downtime risk is unacceptable. The higher the cap, the higher the risk to the network - period. This is why I also suggested that Algorand Technologies provide an enterprise-grade commercial staking service. If Algorand Technologies provided such a service, then it would be a great show of confidence for Algorand’s long-term success.

post by JohnWoods on Feb 2, 2024

Not in a highly available manner.

Not really, because there is no way to limit multiple low cap accounts being run on the same node, which is incentivised by a lower cap.

post by lobo on Feb 2, 2024

lobo

according to some smart people current node software is not optimized for multiple addresses participating on the same node and apparently after 3-4 doing so the node might run into problems (missing votes/proposals). this would mean the lower the cap the more physical nodes those entities would have to run.

question now is if that’s true at all? and if it’s true can the node software be changed to eliminate those problems?

post by JohnWoods on Feb 2, 2024

The number of simultaneous part keys before significant slow down on well spec’d machines is about 5.

They might run. You will have people who prioritise lower cost of execution over network health, which is another reason why we need a cap ~4-5% of the active staking set.

Yes absolutely, we can thread this part of the critical path better. Again it comes down to limited resources.

post by oysterpack on Feb 2, 2024

The cloud expense will be minor concerning the overall operational expense. A dedicated team will need to be available 24x7 to maintain, support, and secure the entire system. Large staking pools can’t be managed half-assed by a bunch of amateurs. There are hiring and training costs to consider. The system would require a cloud architect and DevOps personnel.

That would simply be dumb for large staking pools.

post by GhostOfMcAfee on Feb 2, 2024

GhostOfMcAfee

But, staking pools will do it if they get so large as to reach whatever the cap is. If they are profitable, and they reach the staking cap, they won’t leave money on the table. They will spin up another node, copy their existing code, and create Pool2.

post by d3ath5t4r on Feb 2, 2024

oysterpack](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

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

post by d3ath5t4r on Feb 2, 2024

High max cap* redundant I meant to say, sorry

post by GhostOfMcAfee on Feb 2, 2024

GhostOfMcAfee

ROAM](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

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.

post by GhostOfMcAfee on Feb 2, 2024

GhostOfMcAfee

I don’t think a 10MM minimum was suggested. The discussion was about a maximum allowed in a node.

post by d3ath5t4r on Feb 2, 2024

Oh shoot my bad lol.

post by oysterpack on Feb 2, 2024

GhostOfMcAfee](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

Like I said, if they do it then it means they don’t understand risk management … and that they are dumb.

post by oysterpack on Feb 2, 2024

GhostOfMcAfee](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

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.

post by Imod87 on Feb 2, 2024

Imod87

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.

post by d3ath5t4r on Feb 2, 2024

oysterpack](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

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.

\ image870×262 21.6 KB](https://us1.discourse-cdn.com/flex016/uploads/algorand/original/2X/5/59d52f85e7b6c3636aac09bf450cfc766e126af7.png "image")

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!

post by Rambutan on Feb 3, 2024

Rambutan

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.

post by oysterpack on Feb 3, 2024

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.

post by SilentRhetoric on Feb 3, 2024

SilentRhetoric

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.

post by d3ath5t4r on Feb 3, 2024

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.

\ image1170×1345 267 KB](https://us1.discourse-cdn.com/flex016/uploads/algorand/original/2X/8/87c048d9372f43dfcffac4564366a665e0fe1220.jpeg "image")

post by oysterpack on Feb 3, 2024

SilentRhetoric](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

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.

post by oysterpack on Feb 3, 2024

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

post by SilentRhetoric on Feb 3, 2024

SilentRhetoric

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.

post by d3ath5t4r on Feb 3, 2024

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.

post by Ravin on Feb 3, 2024

Ravin

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.

post by d3ath5t4r on Feb 3, 2024

Cc @JohnWoods

Nice

post by Ravin on Feb 3, 2024

Ravin

SilentRhetoric](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

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.

post by SilentRhetoric on Feb 3, 2024

SilentRhetoric

I don’t think any technical barriers exist, though. There’s at least two very easy ways to set up a node developed by the community. This is not be a blocker to moving ahead to incentives as Oysterpack delineated as his first phase. Phase 1 is effectively done. Can’t wait for everything to be perfect. We’re ready. Let’s go.

post by funk on Feb 3, 2024

funk

This point deserves more attention. If the cap were at 2^26, each account in a pool would need to have an average stake of 13.4 million to max it out. So unless this limitation of part keys per node changes…

Pooling will not be offered to accounts with less than millions of Algo

Pooled nodes will be operating at way less than the max cap

post by oysterpack on Feb 3, 2024

SilentRhetoric](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

I borrowed the “1-click node” terminology from John Woods, but “1-click nodes” understates the requirements for consensus participation. As I have discussed above, we need robust node management solutions that target different use cases:

retail - single machine solution
large stake pool operators - enterprise-grade node cluster solution

The retail scenarios you described are why we need robust, user-friendly node manager solutions for retail. The path to true decentralization is through retail running their individual nodes, not retail delegating their stake to large stake pool operators.

post by wynn on Feb 3, 2024

wynn

JohnWoods](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

You are mr Algorand - thank you

post by d3ath5t4r on Feb 3, 2024

JohnWoods](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

These are a couple of draft ideas:

A. Fee scaling mechanism:

The shape of the curve aims to increase the fees when Global staking % goes down, incentivizing the firing up of new nodes to capture the higher fees. Also incentivizes risk management from node operators to protect their nodes from attacks of other node operators (pool vs pool).

On the other end of the curve, once you pass the sweet-spot the curve lowers fees de-incentivizing node operators from staking, releasing the Algos into the network to be allocated into the project’s services ecosystem.

The intention of this mechanism is to strike self-regulating fee structures that create incentive vectors that switch around the inflection point of the curve.

B. A centralization mitigation/absenteeism mitigation model that incentivizes node operators (pools or individuals) to keep as much of the registered consensus Algos Online at every round.

The distribution of consensus incentives would be 0 for rounds with less than 80% of online validators in a round. After that threshold is crossed the rewards set for the next block get multiplied according to the curve approved by governance.
Three proposed multiplier shapes, linear, “S” shape, and parabolic. (Note: The “S” and parabolic shapes push the incentives away from the Network failure horizon)

\ image602×994 17.4 KB](https://us1.discourse-cdn.com/flex016/uploads/algorand/original/2X/f/ff1b89164bf97e91e37efde515bdd886d389ea0a.png "image")

PS: Please destroy these models to the ground.

post by Rambutan on Feb 3, 2024

Rambutan

I am not a computer expert and I tried to run an algorand node using the Aust 1 click node, but it could not synced. I tried and tried, asked questions, but was directed to do this and that and this and that, i just gave up.

I then tried to run a voi node, which synced instantly. Tho I did it just to see if my hardware was the problem, it seems that my hardware could run a voi node but not an algo node.

I really tried and tried to run an algo node, but it was too complicated… even with Aust 1 click node. I tried like 2 months ago, not sure if it’s more easy now, but anyways, if any non computer expert were to fall into the same issues I had - then it’s still quite complicated to set up an algo node.

I believe @imshivaprasad_ also developed an easy way to run a node? But I don’t think it supports windows… If it did support windows, I would have tried to run a node using his program too…

post by oysterpack on Feb 4, 2024

This illustrates why we need professionally supported robust node manager solutions.

Regarding the node sync up issues you faced … The voi node would sync up fast because it has very little data. To sync up Algorand mainnet nodes, it is recommended to use the fast catch up mechanism.

Does the Aust 1 click node sync the node use the fast catch up mechanism?

post by lobo on Feb 4, 2024

lobo

yes A1CN uses fast catchup

post by Rambutan on Feb 4, 2024

Rambutan

oysterpack](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

Fair enough.

So you reckon if I buy a new desktop computer with higher power and capacity and latest chips etc, I should be able to sync it easily using Aust 1 click node?

This fast catch up you talking about is a new upgrade or something?

How do I do this. Just install Aust 1 click node again and try to sync it as usual?

post by oysterpack on Feb 4, 2024

The fast catchup sync mechanism has always been there.

According to @lobo, the Austin 1 click does use the fast catchup mechanism.

I haven’t used any community tool to install a local node. I installed it using the Debian distribution package on Ubuntu.

Try submitting an issue on the Github project.

post by JohnWoods on Feb 5, 2024

funk](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

P2P pooling would be executed using a smart contract paired with a managed node operator.

In that mode there would be no “minimum”, as the contract is essentially an aggregate account.

>MaxCeiling accounts will be permitted, but not paid over the threshold.

post by JohnWoods on Feb 5, 2024

A lot of this sounds great, the problem is the practicality. The core team on this is single digit numbers. There is only so much money for engineering. We can do this perfectly but then it won’t release this year.

One has to balance pragmatically.

We’re shooting for, nodes that are easy enough to use, a defi based solution and a P2P pooling option.

post by JohnWoods on Feb 5, 2024

Feel free to make a PR to the paper, then the technical team can review on GH.

This forum isn’t great for technical discussion, and most of the team aren’t watching it.

Thanks for this analysis.

post by oysterpack on Feb 5, 2024

I would like to start by saying thank you for the amazing work your team is doing.

Rome was not built in a day, but they were laying bricks every hour. Laying a brick every day, year after year is how you build an empire. Laying those bricks is how we build Algorand into an empire.

I have a few follow-up questions:

Will these node runner and consensus participation solutions be officially maintained and supported by the Algorand Foundation? AlgoKit is a game changer for the developer experience. I believe the same can and should be done for the consensus participation user and node operator experience.
Are these open-sourced, or will they be open-sourced? These would be ideal to get the Algorand developer community involved and contributing.
Can you please elaborate on the DeFi-based and P2P solutions?

post by JohnWoods on Feb 6, 2024

Thank you my friend! We’re trying!

on 1: It will be a joint effort with Algorand Technologies. I agree, we need a seamless UX. We’ll get there.

on 2: All fully open-source.

on 3: Still being worked on, but it’s likely, alongside the usual “run a node with a partkey” we’ll also have a contract based solution where people can stake simply by sending their funds trustlessly to a contract, where they’ll earn less of course as someone needs to run the node on their behalf, and we’re aiming for one of the major DeFi venues to offer first class staking as a service, liquid staking.

8 days later

post by Titi on Feb 15, 2024

d3ath5t4r](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

I was thinking along approach A but we don’t want to limit how much stake can go online. The network is most secure if all algos are online improbable but possible. If we go the Bitcoin way might lead to centralization if it gets harder to mine. I think we can base the fee adjustment on throughput(more txns in block) since that’s where the fees are coming from. Higher throughput higher fees percentage so validators stay but never , low throughput less percentage but never below 20%. When the block is 100% full you get all the fees and reward

post by mochanerd on Feb 21, 2024

mochanerd

oysterpack](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

Most Node Pool Operators operate across multiple chains and are knowledgeable enough to develop their own solutions…I’m all for open-source, but if there’s a monetary incentive for node-running, companies will fund their own development of such platforms imo…did the Bitcoin Foundation fund development of ASIC miners and the software that runs them?

post by Titi on Feb 23, 2024

A 50m account suspended is a big deal for the network. Paying 2 algos out 50m is peanuts giving the responsibility they have. Charge .0001 of stake. This way we have no problem with funding node runners and people will be incentivized to make up for how much they lost. .0001 is 1 algos for 10k= .0001 *10k is 1 algo, 100 for 10m staked

People can game the initial going online for incentive eligibility by initially paying for small stake say 1 Algo for 10k and topping up later. That’s fine It’s not important in terms of the health of the network, should be 0 really the important thing is the suspension.

For those accounts who are suspended and want to bypass the suspension fee by moving stake to a new account or not coming back online at all you can prevent that by charging the percentage on their next transaction through fees

Some have suggested reducing rewards for suspended accounts by a percentage. Maybe you get a smaller percentage of your actual rewards. Example : If you were to get 500 algos in rewards you get 50 instead.

post by Titi on Feb 23, 2024

JohnWoods](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

I don’t see the need for the minimum we already maintain a map of online accounts currently in memory it didn’t affect anything. people are going to drop off themselves because they aren’t making money and spending too much maintaining a node. As more stake is online the less chance you get, indirectly raising the minimum. Suspension will remove those nodes anyway. Although the minimums as currently suggested apply only to those who want to be rewarded I think we should reward everyone regardless of minimums. As currently suggested the game theory suggests an effective minimum for everyone because by not staking the minimum you’re getting diluted compared to those who have the minimum. why get no rewards when others are making more just by topping up.

I think you said in a tweet that min max are up for discussion leaving it up for discussion is a disaster waiting to happen. These things should be enshrined or algorithmically determined

post by JohnWoods on Feb 23, 2024

I don’t see the need for the minimum we already maintain a map of online accounts currently in memory it didn’t affect anything

Can you point to where in the code this map can be used to non-manually mitigate absenteeism in the critical path?

Have you considered consensus parameters? Do you understand how the distribution of stake across accounts affects the comp and data burden?

people are going to drop off themselves because they aren’t making money and spending too much maintaining a node

What is your assertion?

As more stake is online the less chance you get, indirectly raising the minimum.

No, the more stake online doesn’t change a static floor for CI, minimum changes probability for consensus execution, not for incentives yielded, which directs stake distribution.

I think you don’t understand the technical nuances of that which you are arguing for.

I think we should reward everyone regardless of minimums

OK, I disagree.

As currently suggested the game theory suggests an effective minimum for everyone because by not staking the minimum you’re getting diluted compared to those who have the minimum.

No, this doesn’t make sense.

Can you explain your posit with example?

These things should be enshrined or algorithmically determined

Enshrined by who? isn’t this the point of decentralisation?

How can you algorithmically determine an outcome predicated on a multivariate function dependent on multiple unknowns propagating in a globally distributed system?

post by Titi on Feb 23, 2024

Thanks for replying, my post is a mere suggestion I’m not ripping the incentive paper apart or saying we shouldn’t do incentives at all.

I’ll get back to you on where I saw the map but it’s a suggestion. The idea was that if it’s already in the map it can be used for suspension also

Actually these are sort of questions that should be asked, discussed and written about. It’s a tectonic shift as you’ve and 3 months to deliberate might not be enough. I’m particularly concerned how it might even affect liveness so I’m glad you are asking these questions. Bandwidth cost might increase even more so with p2p.

My assertion is just from observation and a rational actor. A rational actor won’t burn money for nothing, we’ve already posited in the paper that there’s not enough stake because people aren’t incentivized by getting rewarded. So if they aren’t getting rewarded because their stake doesn’t suffice they’ll drop is what I’m thinking. Also they’ll be suspended eventually

Maybe I should have been more clear, I’m not saying it’s going to change the floor what I meant was it’ll decrease their chances of winning a block which determines if you get the reward. So when their chances are decreased to the point of not making enough proposals they might drop off for the same reasons as previously stated. Or they’ll top up their stake which secures the network

Those who don’t meet the minimum currently will top up to meet the minimum because if they don’t they aren’t getting the piece of the pie. It won’t make sense for rational actor because other validators who meet the minimum stake and beyond are getting more of the pie.

By enshrined I meant that the minmax should be algorithmically determined if possible. I didn’t put the keyword possible. If we leave it to the whims of whoever it might be gamed or taken advantaged of. We still don’t know how they are going to be determined though, what ideas are being explored. If I recall correctly you said they can be changed. Changed how? According to what metric?

I don’t know why I’m getting the feeling that you think I’m challenging you or your mad or something. your response is like God from the book of Job. No I’m not challenging you to anything I’m making suggestions and spitting out ideas that’s what I thought the forum was for. A braindead peasant like me may not be technical enough to even make suggestions but every now and they do make good stuff. Far too often those considered to be in the know make irreversible mistakes and take actions that have unforseen repercussions. History is littered with examples.

And as a mere suggestion, what do you think of the post just above this, your humble good citizen and servant

post by Titi on Feb 23, 2024

I was able to find the pieces of code that might be helpful and could be applied for suspended accounts if feasible. In the block there’s a list of proposed updates to expired online accounts as noted on line 139 - 148 in block.go under bookkeeper

Also in ledger/eval.go the function generateExpiredOnlineAccountsList() “creates the list of the expired participation accounts by traversing over the

modified accounts in the state deltas and testing if any of them needs to be reset.”

These were the lines of code i recall and that’s why i said what i said ealier on, i may be wrong. Do you have any idea why it might not similarly work for suspended accounts. of course it’s not going to be a copy paste but i’ll like to know more.

As i was looking for the list i noticed the code for suspended accounts might already be taking this direction. I haven’t looked too much in the absentee code, but a peasant like me can do a tiny little reading into this great body of work to find out. Thanks for all you do and to the entire team

post by Titi on Feb 23, 2024

SilentRhetoric](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

zombie nodes will be suspended

post by JohnWoods on Feb 24, 2024

SilentRhetoric](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

I agree, a floor yields more “committed” actors.

Retail can use liquid consensus or P2P pools.

post by JohnWoods on Feb 24, 2024

You’re very welcome. I value your opinion and the time you’ve taken to give feedback. I didn’t mean for my tone to come across dismissive or impatient.

Potentially it can, the concern is, does incentives cause a Cambrian explosion in node runners yielding a large data set which must be held for precise handling of absenteeism. We can do imprecise handling without holding all accounts in memory. The floor bounds this data set.

I agree, but rather than relying on this presumption a floor is safer.

I agree it would be nice but there is some complexity in doing so, the ceiling being dynamic could cause cascades, as the network removes misbehaving participants.

By governance, guided by ATAC.

That’s why we are in consultation with the community, wrote the paper and encourage PRs.

Thanks, as mentioned above the concern is bounding growth in this set, rather than accessing it.

I greatly appreciate your effort on this.

2 months later

post by algorander on Apr 28, 2024

algorander

Apr 2024

When may the P2P pooling smart contract be ready? Is it one smart contract shared between all pools or one contract deployment per pool?

post by scholtz on Apr 29, 2024

scholtz

Apr 2024

I think much from the algorand side will not change. Algod node can have multiple online accounts, so on one node you can run multiple “aggregated pooling contracts”.

The thing is that it seems that only online accounts with 30k+ algo will receive the reward (as seen in GP10 decision), so more people will aggregate it this way.

And I think the Algorand Technologies, nor AF is not building this “aggregated pooling contract” as they focus on the P2P thing, but i may be wrong.

post by algorander on Apr 29, 2024

algorander

Apr 2024

Great idea! They say after 5 accounts performance may take a hit. John mentioned they may multi-thread that part later so more online accounts can be handled in parallel on a multi-core CPU. Either way it will be really hard to find users who will be willing to sign the registration transaction (and send it via email?). The user experience of pooling will be shitty without the smart contract. Ideally the protocol-core would allow a user to stake under a node without the need of a smart contract. Also, if users stake could be locked this would help push up price and security of the chain.

2 months later

post by PatrickB on Jun 19, 2024

PatrickB xGov Councillor 2025

algorander](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

Jun 2024

Réti Pooling Overview | Réti Open Pooling describes it.

I’m leading a workshop about it at Decipher as well.

1 month later

post by cryptonium on Jul 31, 2024

cryptonium

JohnWoods](https://forum.algorand.co/t/consensus-rewards-whitepaper-concern/11259/3 "Load parent post")

Jul 2024

I fear that the consensus mechanism will fundamentally change the game theory, and over time change Algorand in unpredictable and undesirable ways. Is there a chain with consensus incentives that does not trend toward centralizing? A cap on participation doesn’t change the centralized power of pool operators. As soon as running nodes has a monetary incentive, the monetary incentive will eventually take over the network.

While Algorand currently desires low fees, as soon as nodes are being run primarily for the reward, then node operators will want to increase that reward. The average person will never have the ability or desire to run a node, but they will put their assets to use for yield. All of the incentive will naturally align for pools, provide people with yield, have motive for increased profit, and ultimately have the Algorand development decisions in the hands of the pool owners. They will have motive, and power, to drive development of Algorand to increase their own profits. The profit motive will drive Algorand development in the future, and fees will be raised accordingly.

I still believe in the original game theory of people (businesses) running nodes because they benefit from securing the network for the chain they use for their business. Any business with moderate dependency on the chain will need to have one or more nodes running locally just for reliable and fast transactions. Which on that note, splitting up stake across multiple nodes in an enterprise might not be ideal, perhaps there can be a way to utilize a single participation stake for multiple nodes.

Anyone who needs the chain for their business case, will need a reliable node to transact with. The primary problem is that a transaction node does not need to engage in consensus, so the existing incentives for nodes is there, and people look for things like nodely, or run the node locally to transact. If non-participating nodes were eliminated, the game theory would kick in without the need to alter the fundamental motive of running a node. Perhaps find a way to tie transaction rate to a single node with the participation stake so that the more you need to transact with a node, the more stake you will need for consensus.

post by JohnWoods on Aug 1, 2024