Incentives: Implements "Mining" - diverting a portion of fees to proposers

[jannotti]

This is only a draft, in the sense of code that isn't ready for merge AND an idea that isn't ready for merge. There is no release timeline for it.

I’m using the word “mining” to mean the portion of incentives for proposing a block that comes from fees. Today’s fees are tiny, but we should introduce this mechanism now, to show how incentives will need to work eventually. The mining mechanism must be built into the L1 protocol, because it diverts funds from the FeeSink. The following should be sufficient to support paying out these incentives, but it lacks the absenteeism protections that are needed because of "Bonus" payouts - the extra incentives that will be paid by the Foundation that do not come from fees.

• If proto.EnableMining, add the current Proposer and the FeesCollected to the block header.
• Choose proto.MiningPercent which is the percentage of algos paid in fees that should go to the proposer of the block from the FeeSink.
• At the start of block n+1, move MiningPercent * block[n].FeesCollected from the FeeSink to block[n].Proposer.
• Outlaw any other payments from FeeSink to ensure the funds to be moved must be present.

The movement is done at the start of block n+1 instead of during block n because a multi-participant node builds a block before it knows which account might actually be the proposer. The actual proposer is determined later, in the agreement code. It is possible we could perform the movement at the end of block n instead, by going back into the block and modifying the state delta of the ValidatedBlock when agreement calls WithSeed. However, in the current code, agreement does not have access to the ValidatedBlock‘s state delta. The choice of n+1 seems simpler, and funds are never invisible in this design. They sit in the FeeSink “between” rounds.

[joe-p]

One thing that should be considered is if and how the protocol determines if the proposer is acting honestly. By simply moving MiningPercent * block[n].FeesCollected to the proposer, it incentives people to create 0-transaction blocks. My understanding is that the committees do not check whether the block has transactions or not, but rather if the transaction it does have are valid or not. Of course, right now there probably isn't much cost to be saved by doing so for an individual, but it it could be problematic at scale. For example, if a delegation service proposes empty blocks, they might have a x% reduction in the cost of running their nodes, meaning they can offer the delegators more of a return. x% becomes larger and larger as the network scales and validating blocks involve more computation. An end-user that doesn't care about the network and just wants to earn more ALGO will be more incentivized to go with this 0-txn delegation services, rather than a legitimate one that offers less in rewards.

[jannotti]

By simply moving MiningPercent * block[n].FeesCollected to the proposer, it incentives people to create 0-transaction blocks.

If you create a 0 txn block, the block's FeesCollected will be zero. You will make no money.

[joe-p]

If you create a 0 txn block, the block's FeesCollected will be zero. You will make no money.

🤦 Yes I was still thinking in the mindset of non-fee-based incentives.

[pao-beep]

Doesn't this centralize block production, the wealthy proposers get even richer.

[MochaN3rd]

Doesn't this centralize block production, the wealthy proposers get even richer.

What if the fee was split between the voters and the block proposers? I run a node and vote on significantly more blocks than I propose

[jannotti]

Doesn't this centralize block production, the wealthy proposers get even richer.

Does it centralize block production? I don't see how. If this offers meaningful returns, it helps any potential participant defray the costs of participating. Today, these costs are born by the proposer, so surely the current policy leads to more centralization, as only the rich would be willing to pay those costs for fun.

Will wealthy proposers get even richer? At the current rates, this will only defray infrastructure costs. They will get poor more slowly. But jokes aside, it seems proper that the people running nodes are compensated by the money being paid for the work being done by those nodes.

[pao-beep]

Doesn't this centralize block production, the wealthy proposers get even richer.

Does it centralize block production? I don't see how. If this offers meaningful returns, it helps any potential participant defray the costs of participating. Today, these costs are born by the proposer, so surely the current policy leads to more centralization, as only the rich would be willing to pay those costs for fun.

Will wealthy proposers get even richer? At the current rates, this will only defray infrastructure costs. They will get poor more slowly. But jokes aside, it seems proper that the people running nodes are compensated by the money being paid for the work being done by those nodes.

Okay this doesn't make any distinction between amounts staked does it. Meaning if I stake 1k algos and produce a big block with more fees and say another proposer stakes 1million algos and produces a small block with small fees it's fair game. I get to keep the fees regardless of my stake?

[jannotti]

Doesn't this centralize block production, the wealthy proposers get even richer.

What if the fee was split between the voters and the block proposers? I run a node and vote on significantly more blocks than I propose

In the end, it will all come out the same. When you participate, you represent the same fraction of voters as you represent among proposers. You do vote much more often than you propose, since the cert committee has something like 1500 voters. But the incentive would have to be split among those 1500! So over enough blocks, your payout will be the same.

This payout scheme is a bit "lumpier", but there are technical challenges to the scheme you propose that make me very willing to accept the lumpiness. In particular, the network reaches consensus about blocks, but not about the voters on each block. Two different nodes might see a different set of votes --- they just each have to see enough. To perform payouts to voters, we would need to consume block space to write down and reach consensus about the voters.

[jannotti]

Okay this doesn't make any distinction between amounts staked does it. Meaning if I stake 1k algos and produce a big block with more fees and say another proposer stakes 1million algos and produces a small block with small fees it's fair game. I get to keep the fees regardless of my stake?

Correct. By having less stake you will propose less often (just as today), but when you do, you get all of the incentive paid here.

[cswenor]

This is great. A couple things that would be nice is the ability to set a configuration at what portion of the fees get given to the block producer and how much go to a treasury. Also it would be nice to allow for nodes to opt out of the reward so that the foundation could run nodes without taking the rewards.

[jannotti]

This is great. A couple things that would be nice is the ability to set a configuration at what portion of the fees get given to the block producer and how much go to a treasury.

The consensus parameter MiningPercent decides how much of the fee goes to the proposer.

Also it would be nice to allow for nodes to opt out of the reward so that the foundation could run nodes without taking the rewards.

That's a good idea. Perhaps a proposer can write any address they'd like into the block's Proposer field. They could write the FeeSink's address to leave the funds alone.

[ctibo]

Okay this doesn't make any distinction between amounts staked does it. Meaning if I stake 1k algos and produce a big block with more fees and say another proposer stakes 1million algos and produces a small block with small fees it's fair game. I get to keep the fees regardless of my stake?

Correct. By having less stake you will propose less often (just as today), but when you do, you get all of the incentive paid here.

Does this mean smaller participants would benefit of pooling their stake together to propose more blocks?

They could do it using a smart contract, to make sure their stake is safe. The pool contract would still participate from a single machine though. So we'd eventually centralize consensus.

It seems we're trying to get rid of relays to better decentralize the protocol, but we'll incentivize people to create the biggest pools and win the most blocks.

I might be overthinking it...

[jannotti]

Okay this doesn't make any distinction between amounts staked does it. Meaning if I stake 1k algos and produce a big block with more fees and say another proposer stakes 1million algos and produces a small block with small fees it's fair game. I get to keep the fees regardless of my stake?

Correct. By having less stake you will propose less often (just as today), but when you do, you get all of the incentive paid here.

Does this mean smaller participants would benefit of pooling their stake together to propose more blocks?

They could do it using a smart contract, to make sure their stake is safe. The pool contract would still participate from a single machine though. So we'd eventually centralize consensus.

It seems we're trying to get rid of relays to better decentralize the protocol, but we'll incentivize people to create the biggest pools and win the most blocks.

I might be overthinking it...

Two people pooling their algos will get the same total rewards as if they operated separately. So in that sense, there's no benefit.

On the other hand, there would be some cost savings from running fewer nodes.

I can see some benefit to pooling, to save costs and perhaps have the nodes that do run be run more professionally. I can also see downsides, as large nodes would be a bigger impact to consensus if they go down.

[HashMapsData2Value]

Given the high performant nature of the PPoS protocol the cost of running a node does not scale with stake, right? It's a "single coin toss" to get the result of the VRF? And since we have a fixed max opcode budget, we have a minimum level of compute hardware the average node needs to maintain, but there's no point in running a super strong computer since everyone else will be too slow?

E.g., if Bob has 10k Algo and Eve has 1m Algo, they can both go and buy the same computer to run an Algorand node on it. They will suffer the same costs But since Eve has 1m Algo she will propose blocks more often than Bob. If we incentivize node running by rewarding block proposals, Eve will be rewarded more often. Since Algo is a limited resource, over time, Eve will accumulate more of an ultimately finite resource, compounding and potentially snowballing over time.

I'm all for rewarding people for their contribution to maintaining the integrity of Algorand, but it'll definitely be tricky setting the %. The higher it is the more we incentivize node runners, but the faster we could get to a "snowballing" scenario. And if it's too low we might not be able to smaller holders to go through the effort of running a node. (And while individually a smaller holder might not be impactful, as a large group they would be essential in decentralizing the network.)

On the other hand, there is another resource that is incredibly important to Algorand and whose cost does scale with usage - networking. Since PPoS is so efficient and we have a fixed opcode budget setting the standard on compute, the bottle neck lies in networking. The more you contribute positively (i.e., helping to connect to many peers, not acting like a bottleneck, etc) the higher the performance of Algorand, but also the higher your cost also ought to be.

Since we are switching over to P2P gossip structure anyway, everyone will be contributing to Algorand's networking and be able to get funds. But the limited resource providing sybil-resistance should not be Algo, but rather networking. The big Algo holders are already getting some incentives to engage in consensus with their nodes and protect their bag.

I dont have any good suggestions here for how to create an incentive structure for networking. A pitfall would be rewarding node runners in developing countries at the risk of punishing those in networking-challenged ones. We'd need to have a way to take into consideration that somehow.

Finally, another thing to consider is archive nodes. Maintaining full or partial archive of Algorand might also be a way to get rewarded from the fees. Storage is another resource where the more you contribute, the more you get rewarded, but the higher your costs will be as well.

TL;DR: From a compute PoV cost of consensus does not scale with Algo bag. Perhaps we should reward in a different way, like networking or storage.

[pbennett]

That's a good idea. Perhaps a proposer can write any address they'd like into the block's Proposer field. They could write the FeeSink's address to leave the funds alone.

Makes sense for payout but if it replaced the on-chain proposer, this would be for unfortunate for the things that track the proposer of each block for consensus participation metrics.

[pao-beep]

@HashMapsData2Value the network incentivization is going to be in place for relay nodes. This rewarding for participating nodes is merely to get more people involved. It could be that a lower stake node gets more fees if during the time it was chosen there was a bigger block

[pkariz]

Perhaps a proposer can write any address they'd like into the block's Proposer field

I don't know the details of how things currently work, but i don't think the proposer should have the power to send me the fees (eg. evil proposer wants to get me in trouble with regulations - it's true that transactions are non-interactive so anyone can send coins to me at any time, but maybe "mining" coins will be looked at differently). To counter that maybe just "donate fees to feesink" option should be allowed (like a binary config option).

I can see some benefit to pooling, to save costs and perhaps have the nodes that do run be run more professionally

One other benefit is also more frequent and therefore more consistent payouts, especially for smaller participants.

Perhaps we should reward in a different way, like networking or storage.

My guess is that it would be hard to evaluate and prove how much someone is contributing to networking or storage.

[jannotti]

That's a good idea. Perhaps a proposer can write any address they'd like into the block's Proposer field. They could write the FeeSink's address to leave the funds alone.

Makes sense for payout but if it replaced the on-chain proposer, this would be for unfortunate for the things that track the proposer of each block for consensus participation metrics.

Currently, the proposer is not in the block, per se. All nodes do agree on the proposer (they must, so they can check the proposed BlockSeed is correct), but they have that information "on the side" in the messages they collect while confirming a block. This PR adds an explicit field, called Proposer to the BlockHeader, and that is the address that gets paid. If we wanted the proposer to be able to decline the incentive, it would be that field that they'd change. The network would still know who the real proposer was.

If this is deemed desirable, I suppose I'd want to rename the field Miner or MinerRewards. And, at the protocol level we're talking about the names of msgpack fields. So it would be mnr instead of prp, or something like that.

[jannotti]

Perhaps a proposer can write any address they'd like into the block's Proposer field

I don't know the details of how things currently work, but i don't think the proposer should have the power to send me the fees (eg. evil proposer wants to get me in trouble with regulations - it's true that transactions are non-interactive so anyone can send coins to me at any time, but maybe "mining" coins will be looked at differently). To counter that maybe just "donate fees to feesink" option should be allowed (like a binary config option).

Since the "real" proposer is always going to be known (see my last comment), I don't see how this could possibly be interpreted any differently that a normal pay transaction. Someone else wrote your address down and so you got algos.

Perhaps we should reward in a different way, like networking or storage.

My guess is that it would be hard to evaluate and prove how much someone is contributing to networking or storage.

That's exactly right. The protocol can't reward anything that's invisible to the protocol. Networking and storage (beyond that needed to evaluate transactions) are both invisible. And the storage that is needed to evaluate transactions is the same size for everyone. An off-chain system could perhaps monitor some of these things and hand out money, but I don't think it could be made part of the protocol without massive changes (things like Filecoin's Proof of Storage).

[HashMapsData2Value]

@HashMapsData2Value the network incentivization is going to be in place for relay nodes. This rewarding for participating nodes is merely to get more people involved. It could be that a lower stake node gets more fees if during the time it was chosen there was a bigger block

I'm not sure I understand this argument since this should average out across many blocks over time, and those with more Algo would simply propose more blocks?

That's exactly right. The protocol can't reward anything that's invisible to the protocol. Networking and storage (beyond that needed to evaluate transactions) are both invisible. And the storage that is needed to evaluate transactions is the same size for everyone. An off-chain system could perhaps monitor some of these things and hand out money, but I don't think it could be made part of the protocol without massive changes (things like Filecoin's Proof of Storage).

What about inflation? If we could inflate the Algo supply in such a way that the stake proportions/distributions between participation nodes are maintained (and preventing the snowballing of a whale vs other node runners), it would incentivize running a node to avoid your holdings losing value to inflation.

Off the top of my head the problems I see are:

• 1. dealing with fixed minimum balance requirements in an inflationary environment
• 2. confirming that a node is non-maliciously engaged in consensus (i.e. their account is activated but they're not actually helping out).

[joe-p]

One thing that I think should be mentioned is this fundamentally changes how fee under congestion will play out in the network. Rational miners will treat fees as a first-price auction which means users will not have a known dominant strategy and will need to outbid each other. I think it's worth considering a mechanism similar to EIP1559, where MiningPercent decreases as the network gets congested, thus more of the fees are sent to the FeeSink under congestion.

[jannotti]

One thing that I think should be mentioned is this fundamentally changes how fee under congestion will play out in the network. Rational miners will treat fees as a first-price auction...

Not just under congestion.

I think it's worth considering a mechanism similar to EIP1559, where MiningPercent decreases as the network gets congested, thus more of the fees are sent to the FeeSink under congestion.

Since your concern is true at all times, I don't see the value in doing that. It would also be very difficult. The level of congestion is not something that the protocol reaches consensus on. So it would be hard to validate the choice of MiningPercent if it changes with congestion.

[pao-beep]

@HashMapsData2Value yes but not the fees, that's unpredictable. The busyness of the network is unpredictable. Over a long enough period yeah but it's not straightforward. Besides like jannoti said It's meant to defray cost but if there is enough fees to be collected you might end up making just a little bit more. Looking forward to knowing how that percentage to proposers is determined to gauge the " just enough to defray cost" and not introduce some zero sum profit games

[pkariz]

Someone else wrote your address down and so you got algos

Miners could stay anonymous, put their other non-mining account as the receiver and pretend it's not them. To avoid such tricks the tax company would need to tax those algos as mining algos imo, so i guess it could create some problems for the receiver.

[jannotti]

This is great. A couple things that would be nice is the ability to set a configuration at what portion of the fees get given to the block producer and how much go to a treasury.

The consensus parameter MiningPercent decides how much of the fee goes to the proposer.

Also it would be nice to allow for nodes to opt out of the reward so that the foundation could run nodes without taking the rewards.

That's a good idea. Perhaps a proposer can write any address they'd like into the block's Proposer field. They could write the FeeSink's address to leave the funds alone.

To follow this up - There are going to be a couple rules that participants will have to follow in order to receive incentives. There will be a minimum account size, maximum account size, and a little extra fee that will be paid when going online from an offline state (whether it's your first keyreg, or because you were suspended). This means that a participant who does not want to receive rewards can easily avoid them by ignoring one of those rules (the last one is probably the easiest).

[jannotti]

Closing this just to get out of the way. Intent is to get #5757 in, which has these changes as well.