Algorand Consensus Rewards program through Folks Finance

[Filo_Mora]

Hey everyone!

Folks Finance is planning to continue its Consensus Reward program through Governance Period 9, beginning October 1st, 2023, with an allocation of 70,000 ALGO in rewards.

Feedback on the method of distribution for these rewards is requested. Gov8 was the first time Folks Finance had allocated rewards for those participating in Consensus, and the method of distribution was determined to be an airdrop of a flat amount to all wallets participating in consensus (where online accounts are actually participating in consensus and not harming the network) through Folks.

If you have any ideas for a better distribution method, please leave a comment below. We will use this forum post to gather feedback from the community.

[Governor_Hat]

I believe the distribution should be weighted by stake, and have a factor built in to incentivize good node health/behavior. To make this easier to calculate, governors wishing to participate in the node running program should signify such when signing up through Folks Liquid Governance.

I also think this should generally be based on expected versus actual committee votes. However, a portion could also be allocated to those that also proposed blocks. The model I propose below would take any amount forfeited via poor node health and distribute it to block proposers.

I put this out as a concept/framework for how something like this could work, not necessarily a hard and fast rule. Of course, different models might be better. This is just one idea. I will use the following abbreviations/concepts:

“Pv” = a given node’s probability of being selected in a given round to vote on a committee. This is based on the math underlying the protocol for selecting committees and the node’s stake compared to the total online stake. Metrika does something similar, but uses a range instead of a specific probability. Since the percentage likelihood of a node being selected to vote can change from round to round (since total online stake can fluctuate), calculating the true “Pv” might be a heavy lift. Instead, Folks may wish to do this via snapshots (eg every X number of blocks).

“#R” = the number of Rounds in the Relevant Period (presumably, starting from when the Governance sign up period closes and ending when that that Governance period ends).

“Ve” = A given node’s expected total number of committee votes during the Relevant Period. This is a function of “Pv” x “#R”. Again, because Pv can change from round to round, it may make sense to do this in snapshots. Thus Ve would be the sum of expected votes for all snapshots.

“Va” = A given node’s actual total number of committee votes during the Relevant Period.

“TVa” = the sum of all actual total votes (Va) through the Relevant Period for every node that has signed up for the node program.

Under this proposed model, we first calculate a Base Reward Rate for each participant. This where stake is factored in and is a function of how many actual votes each node had as compared to everyone else in the program. Base Reward Rate = Va / TVa.

Next, we calculate a Node Health Factor for each participant. This is where poorly run nodes get docked. Node Health Factor = Va / Ve. Because probability makes it such that you could have a higher Va than Ve, my proposal would be to cap it at a max factor of 1, such that over performance does not get a boost, but underperformance gets a penalty. Thus, we never have a situation where the Final Rewards Rate (below) sums to greater than 100%.

Now we calculate the Final Rewards Rate for each participant. This takes into account both their stake and their node health and represents the percentage of the total rewards pool they will get. Final Rewards Rate = Base Rewards Rate X Node Health Factor.

If all nodes meet or exceed expected performance then, the Final Rewards Rate for all participants should always sum to 100%. However, because some nodes will not do so (either because of poor health or just as a matter of probability) there is likely to be rewards left over.

One option would be to simply not allocate these leftovers. Instead, they could be rolled over into the next period’s distribution. Alternatively, they could be split pro rata among participants who were also Proposers based on their number of Proposals as compared to the number of proposals by all participants.

[edits: typos]

[Governor_Hat]

A third option for dealing with leftover rewards could be to split them equally among all participants. On one hand, I like that it means small players can still feel like it is worthwhile. On the other, I don’t like that it could mean that small but very poorly performing nodes could actually come out better than if there were no Node Health Factor at all.

[lobo]

in theory i like the idea of comparing expected performance vs actual performance. the thing is this might not work with nodes that have rather low stake because what you are estimating are rare events probabilisticly speaking. thats hard to estimate unfortunately and might lead to frustration among node runners if they dont know why they have a bad node

forgot a part: you might have to set rather wide ranges because of this. so if someone has a score of 0.8 this might not be bad because they lost to math

[Governor_Hat]

Over the 3 month period, wouldn’t you expect it to pretty much all average out? Sometimes they would be under performing, sometimes over performing. But, we are talking about 1.7M+ blocks (even if you factor out the 2 week window for sign ups). That’s a large sample size.

[Garywontwin]

I think putting this much effort to develop a system without a commitment from governance for ongoing support for DeFi consensus rewards could end up being wasted effort.

[lobo]

this branch is not my expertise but i did some quick maths:

for example my probability to propose a block is 6.7* 10^{-6} (12k stake) and to estimate this probability close to an error of around 1* 10^{-6} a data set would have to be roughly 2.7* 10^23 points big… might have made a mistake but even if a few 0s are wrong its still hard i think

[TheWiz]

Hello Everyone at Algorand and Folks Finance!

I’m really excited to talk about this reward program, and I think it’s super important that we make it fair and inviting for everyone.

Let’s Share Fairly:

I really love the idea of this Consensus Reward program. But, I think it should be a chance for all of us to learn and get involved, not just a way for the already wealthy and tech-savvy, or “The Rich Men North of Richmond,” to make more money. I believe that sharing the rewards equally among everyone who takes part properly is the fairest way to do it.

Let’s Learn Together:

By sharing rewards equally, we’re giving everyone a reason to get to know Algorand better. It doesn’t matter how much techy knowledge or money you have; everyone’s involvement is important. This approach can get more people interested in Algorand and help everyone understand blockchain better, which is a win-win for all of us!

My Suggestion:

So, my idea is to keep doing what was done in Gov8 – give an equal share to everyone who is really taking part and helping the network. This way, more and more people will feel welcomed to join and explore the amazing world of Algorand without feeling overshadowed by the tech giants.

Wrapping Up:

Let’s make Algorand a place where everyone’s voice is heard, where learning is for everyone, and where every helping hand is valued. Let’s not make this just another chance for “The Rich Men North of Richmond” to get richer.

I think it’s about bringing everyone to the table and making sure everyone gets a slice of the pie. Let’s keep the conversation going and make Algorand a place for all of us! Thanks for listening, and I’m looking forward to hearing what everyone thinks!

[Governor_Hat]

probability to propose a block

My method focuses principally upon votes, not block proposals. Each voting committee is made of multiple members. Because of this, people with small stakes participate with on a more regular basis. I chose votes over proposals specifically because it would provide a larger sample size and make the estimates vs actuals more accurate.

[Governor_Hat]

I’m not opposed to having a portion of total rewards go to an equal split. In fact, I think that may be a decent idea. But, it should still be moderated by a “Node Health Factor”. And, I do think that the majority of rewards should be weighted by stake. People with more stake are putting more at risk, especially given the possibility of smart contract risk.

Also, while more nodes (in raw count) is a good thing, we need to be cognizant that the size of that stake does matter. The goal (IMO) is to bring more otherwise idle stake online. Under a completely even split, a person with a large stake might see such a minuscule bump that they just don’t bother, which is not good for decentralization.

Also, this can be gamed. Right now, I delegate processing space on my machines to others. If a completely even split is what is chosen, I could just stop delegating to get rid of processing space taken up by others that I delegate for. I could then just make new wallets, add new partkeys for those wallets, and collect multiple “even splits”. This does nothing for decentralization, and actually lowers it since it means I’m just splitting my wallets and abandoning the delegation that I otherwise would do. Any economically rational actor would do the same.

So, we while an even split could play a role, we definitely should not prioritize that.

[Rambutan]

Hello guys, I would love to participate in consensus as well, but I have some questions.

I believe I have to run a node first before I can participate in consensus.

Possible to participate in consensus without running a node?

Running a node means your computer has to be online 24/7 right?

If you get disconnected from internet, then it would mean you are not running a node anymore right?

So if this happens and you get disconnected for even 5 mins, does it still mean you are participating in consensus?

How will the rewards be distributed in this case? Do you become ineligible for rewards if you’re internet gets disconnected for even 5 mins?

[lobo]

oh true my bad. not an expert on consensus: according to https://algorand.com/technology/protocol-overview accounts are randomly chosen instead of ALGOs like with block proposers right? so it depends on numbers of nodes that are online instead of your stake? voting power in still determined by the ALGOs you stake ofc

[Governor_Hat]

Both block proposal and committees selection odds are weighted by stake. The larger your stake, the more likely you are to be chosen. It’s just that the committees involve multiple accounts. So, while a person with only 1 Algo is very, very unlikely to propose a block, they will make it into committees much more frequently. Of course, someone with a large stake will be chosen even more often.

I proposed using committee votes instead of block proposals because even though committee votes do weigh by stake, it also enlarges the sample size so that a “node health factor” can more accurately be measured. While it’s hard to know if a node isn’t proposing as expected (unless it’s a very large stake) it is much easier to know if it is not voting as expected.

[TheWiz]

Totally get the need for a Node Health Factor – it’s crucial for keeping the network in tip-top shape. But I have to say, I’m not on board with handing out rewards based on stake unless we have something in place to stop the “Rich Men North of Richmond” situation that’s cropping up all over Algorand and the wider DeFi scene.

To me, DeFi is about shaking up the system, not just swapping out the old bosses for a new set of gatekeepers. We shouldn’t be setting up another system where the rich get richer, while everyone else is left on the outside looking in.

And about the “perceived risk,” let’s be real. The folks with big wallets are gonna have their money there anyway. Being part of the consensus doesn’t realistically add more risk to their plate. So, I’m not buying the idea that more at stake equals more risk.

It’s the everyday people who need a fair shot and an equal chance—a real opportunity, not just scraps from the table. The wealthy already have the tools and know-how to make the system work for them.

So let’s focus on creating a system that’s fair, inclusive, and gives everyone a real chance to succeed. That means finding a balance that rewards everyone involved without tipping the scales in favor of those who already have plenty.

Let’s build a DeFi space that’s all about spreading the wealth and opportunity—that’s the real spirit of DeFi!

[jasonl99]

I started digging into this because I was curious - I knew that soft and certification votes were not stored on-chain, but I didn’t realize that each node doesn’t necessarily use the same online accounts to reach certification. So there’s literally no way, when running a node, to be sure someone voted.

My node will see my online accounts voting, because it doesn’t have to leave the network. But if Folk’s node is, for example, in Europe (I’m in the US) it might not see any of my votes 'because there are enough nodes running closer by to reach consensus.

The proposer, however, is obviously stored on chain. It’s the only definitive way to unambiguously determine which nodes actually was participating.

That said, I would think there would still be enough voting to capture each account’s vote at least once per day, and just see if it has voted for a percentage of days. If you don’t vote for 60+ days, you don’t qualify.

And as others have suggested, I think it should be split somehow - the act of setting up and running a node is some work. Maybe half of the rewards are split by everyone who actually qualified (60+ days of at least one vote) and the other half prorated by the number of proposals generated.

Keeping in mind this is the same problem as it is with governance in general - what’s to stop a whale from splitting his 100,000 algos into 100 accounts and getting rewarded for all of them?

Here’s the article I came across that explains how nodes see different voters for certification:

https://medium.com/@ppierscionek/to-vrf-or-not-aabccbe3bd25

[makman]

In my opinion the overriding goal here should be to make the network more secure, full stop. The wealth distribution issue may be something worthy of discussion in general, but I don’t think it should be influencing the decisions regarding the consensus program. And after all, governance itself is based on stake.

I do think it might be a good idea to have an incentive component that is stake-neutral because the more people that learn about and particpate in consensus, the better. But overall, a reward mechanism based on stake will lead to larger algo participation and thus greater security, assuming healthy nodes.

[ShaperOfEntropy]

Let me preface my comment by saying that I am against a direct monetary incentivization of participation nodes.
As Prof. Silvio Micali argued multiple times, it leads to a further centralization of power, and thus goes against one of the core principles of a blockchain.
Nevertheless, I do agree that it is crucial to get more stake to participate in consensus.

But for any kind of additional* incentives, it is necessary to first have robust, fair, objective, network-wide metrics of “good” node behavior.
If poor metrics are pursued, it can even hurt the system.
For as complex system as Algorand, it is anything but a simple task to come with good metrics.
It needs to consider that the problem is stochastic, that not all nodes get the same messages, and that even not all valid proposed blocks are equally “good” (e.g. empty blocks). Moreover, solutions that rely on telemetry should not be pursued due to privacy concerns.
The problem is so complex, that even Algorand Inc. - the core developers of the protocol that now best all its intricacies, have not yet come up with a solution and are expected to require quite some more time to do so.
That is why I think we could either 1) wait for Inc., or 2) fund another team to come up with a solution.

A third option, however, would be to just work on existing incentives. These do not require ecosystem-wide metrics of “good” node behavior as they use the inherent motivation of users to do good. Each individual can judge quite easily if they are doing good by simply checking their own node (e.g. if device is powered on, connected to the network, if SW and keys are up-to-date, and if messages are being sent and received).

The existing incentives could prove to be sufficient if users were aware of them, as can be seen from examples of similar systems - e.g. p2p file sharing and even Bitcoin full nodes.
But work should be invested into spreading these and helping to overcome the existing barriers (e.g. lack of hardware or technical knowledge).
For example, Folks Finance could organize (in-person/local) events for their community (e.g. who minted more than X gALGO) to come and learn what are the benefits of running a node, how to install and run one, and/or have follow-up events as checkups to remind users to check if they are correctly running the nodes, or to help with any difficulties they might have.
There could even be rewards in terms of dedicated HW (e.g. a SFF PC) or paid subscription/discounts for a VPS.
I think this would be the best use of the Target DeFi rewards for the Algorand ecosystem.

However, if Folks Finance really believes that (more-)direct monetary incentives are needed, then I would suggest to simply have a policy to waive the recently-introduced gALGO fee for node runners, who fulfill whatever best-effort metrics Folks Finance decides on.

To end the comment, I would point out that during the previous Consensus Rewards program of G8, I have been non-exhaustively monitoring via Metrika a list of 50 top accounts by stake participating in consensus through Folks Finance. They have generated over 400 alerts for not voting as expected. The vast majority of the alerts were triggered by 5 accounts. These still ended up being rewarded. While 5 accounts represent “only” 10% of monitored accounts, it is to be noted that Algorand network would halt in case 20% of stake registered as online would actually not be voting.

*There are already now plenty of incentives to run a node and participate in consensus. They just are not direct monetary incentives and thus little known. Some examples are:

1. One gets to issue their own transactions and blocks to the network, reducing the reliance on third-parties. This mitigates the risk of one’s transactions being censored and/or front run.
2. The node can act as a wallet, thus one does not have to rely on third-party wallet providers for key management and transaction signing.
3. Protecting the network by voting on the proposed blocks as well as on protocol changes. By protecting the network, one protects the value one has on it. The higher the stake that participates, the higher the cost of attacking the network and stealing one’s funds.

[D13]

I think the rewards should have 2 different criteria, one for eligibility and another to determine the % of rewards each participating address should receive.

Eligibility

Why not reward everyone?

Because someone registered online and not participating is harming the network. If enough stake does this, the network will stall.

In my opinion, the best way to ascertain proper participation is through voting.

I knew that soft and certification votes were not stored on-chain, but I didn’t realize that each node doesn’t necessarily use the same online accounts to reach certification.

This is correct. A node in the US may have recorded different cert votes than one in the EU, or one in Asia, because they will each record votes up to the required threshold to certify a block (70% iirc)

So there’s literally no way, when running a node, to be sure someone voted.

From a single node, you may indeed get skewed results, but I think I figured out a way around this:

You can query multiple relay nodes to get their recorded cert votes and build a set of voters based on their collective view of the network.

While not part of the blockchain, cert votes are recorded locally by each node - including relay nodes, which are regular algod nodes on top of being relays.

Querying a few relays in a few corners of the world should give you an excellent view of how participating nodes are voting system-wde. If you collected a superset of votes from, say: US West, US East, 2x EU and 2x Asia, then over time you should have a very decent view of how everyone is voting world-wide.

If we accepted this view as a reliable voting metric, the issue would then “simply” be figuring out the ever-changing voting rate expectation. Folks escrow accounts do not change balance much, but if the overall online stake number changes significantly, then the period cannot be considered as a static one and just take an average, but you have to slice time periods according to their total online stake. Still, this should be doable with math and a bit of elbow grease.

“wtf is this even legal?”

One of relay nodes’ function is that they serve blocks to nodes catching up, so retrieving blocks from them should not be a concern if done at the same rate as a syncing node (or slower, even.)

Voting is the vulnerable part

An extra reason to look at voting as an eligibility criterion is: voting is what would stall the network if 28% of the online stake stopped participating. Block proposers missing their turn is not the big problem - their turn would time out, and another would take their place. Even with 50% of the stake offline, block proposals would eventually take place. But if the critical threshold of voters is not voting, no proposed block would be certified, which would lead to a stalled network.

Voting also happens a lot more frequently than block proposals, so there is a lot more data to sample - whereas looking at block proposals would not be granular enough to determine if an address with ~ 1000 ALGO is doing a proper job of participating.

Rewards Distribution

First, my view about a flat-rate incentive is strictly negative. Anything other than a linear relationship between stake and rewards leaves the system open to a sybil attack: If I know that each participating address will get its equal share of the rewards, I can just spin up 20, 100, 200, 1000 addresses and do a half-assed job of participating (or not at all). This kind of sybil attack hasn’t been properly solved in blockchain aside from requiring KYC or centralizing the decision in some other fashion. If someone is dedicated enough and has a bit of scripting skill, gALGO commitment can be automated, so we aren’t even necessarily talking about someone clicking through the folks website a thousand times.

For similar reasons, voting is not a great metric to use for splitting the rewards. The relationship between stake and expected voting rate is roughly logarithmic.

This chart is from the article “To VRF or not to Vote?”:

As you can see the relationship has a roughly log shape. Again, as a participator you would be incentivized to split up your stake into smaller accounts in order to reap more rewards (by voting more frequently)

(continued)

[D13]

(continued)

This one is about block proposals:

This is the shape you want when deciding rewards on a permissionless system: linear. Splitting up your stake between multiple accounts has no effect on rewards.

---

So I would recommend that rewards are filtered for eligibility via voting as described at the top, and participators’ rewards be decided by block production, to make the rewards system sibyl-resistant.

If a node is only registered for part of the observed period, that should be fine so long as they were voting properly for their online period.

PS: I had to split up my post in order to be able to post 2 images.