Block rewards including transaction fees

[ch1bo]

One of our key motivations for Leios is to address the declining contribution of reserves to block rewards and that Cardano needs to have enough capacity for transaction fees to pay for the operation of the network.

I'm by no means an expert on the Cardano ledger rules, but I could not find where fees of transactions in a block would be accumulated and paid out to stake pools that produced those blocks.

The latest formal ledger specification contains in Sections 18.1:

Rewards are collective, but depend on performance: after every epoch, a fraction of the
available reserve and the transaction fees accumulated during that epoch are added together.
This sum is paid out to the block producers proportionally to how many blocks they have created
each. In order to avoid perverse incentives, block producers do not receive individual rewards
that depend on the content of their blocks.

This document about Delegation and Incentives seems to discuss pool performance in Section 5.5.2, but that does not include a notion of how many transactions were included.

Neither document discusses why block producers should not be rewarded for including transactions in the blocks they produce and why just counting blocks is fine.

This issue would be amplified in Leios where the work an SPO has to do is strictly higher when they contribute to the increased throughput capacity. For example, they would have more network egress, in order to participate in producing EBs and votes.

Does this mean that our motivation is not attainable without changing the reward scheme of Cardano? Can SPOs opt-out of processing Leios induced data (additional costs for them) by producing empty ranking blocks while getting the same proportional rewards?

[pagio]

A general first game-theory inspired answer here is that by including txs in blocks, voting, etc as they should, SPOs increase their rewards ( as the pot that is to be shared increases).

The main costs of the protocol seem to be the following:

• mempool maintenance (mainly CPU)
• data diffusion (bandwidth and CPU)
• voting (mainly CPU)
• storing txs (storage)

The cost of producing a ranking block is not necessarily high, .e.g, if I have obtained the relevant certificate.

Hence, I suppose the real question here is whether they would be incentivized to diffuse and process data.

In the bad case, a node does not upgrade its hardware and only receives and includes EB certs in the RBs it produces, while also producing empty IBs, and no EBs ( as they require processing of the IBs, checking correctness, etc. ).

Upvoted EBs produced by a party may be a descent performance metric here, since at least in schemes having both IBs and EBs, it requires receiving IBs and processing them. Now, if you are doing this anyway, why not also vote?

[ch1bo]

Okay so you are saying it is enough that if it benefits everyone it will be done and we don't need any Leios-specific incentivization?

Do we need to incentivize IB, EB and vote production then? i.e. should we count those activities into the blocksMade for a given stake pool and increase their share in the whole rewardPot?

In any case it seems we have quite limited possibilities of what we can incentivize easily.

[pagio]

No, I'm saying we need to think about this (we haven't yet and is probably going to be variant specific). E.g., the certified EBs produced may be a nice option for some variants.

[WhatisRT]

This is where rewards are calculated: https://intersectmbo.github.io/formal-ledger-specifications/site/Ledger.Conway.Epoch.html#6863

Basically, we accumulate the transaction fees (which are collected here) together with some payout from the reserves (Δr₁) into rewardPot which is then distributed (after taking some taxes) according to the stake distribution and the block creation history (BlocksMade) using the reward function.

This means that the incentive to include transactions in your block is to grow the rewardPot of which you'll get a more or less fixed percentage. I don't claim to fully understand all the incentives of this reward sharing scheme, but to some degree it discourages height battles. If there's a transaction with a very high fee, with this scheme you don't care in which block it goes in. Whereas if you'd directly gain the rewards if it goes into your block, you might be incentivized to try some shenanigans to make sure it doesn't get in a different block.

[ch1bo]

Thanks for clarifying things.

Whereas if you'd directly gain the rewards if it goes into your block, you might be incentivized to try some shenanigans to make sure it doesn't get in a different block.

This is an interesting take and expands on the why this is maybe a good idea.

Would you say we don't need any Leios specific incentives because of this and can just throw all the transaction fees into rewardPot?

[WhatisRT]

A block producer should optimize their expected returns on a block. Including transactions increases that as long as the likelihood that the block isn't included because of delays caused by that transaction is sufficiently small. The issue is that this probability is really hard to quantify, but I think in Leios it'll probably be less of a problem than in Praos since you have much more time to settle the data availability issue.

That makes me think that incentives for transaction inclusion work better in Leios than they do today without having to change anything.

[ch1bo]

An alternative to incentivizing Leios block (IB, EB, vote) production could be to punish non-honest behavior on the network level: A node would need to churn upstream peers (the ~10 active from whom we download blocks) based on obvious misconduct like not including an EB cert that we saw certified (this is easier said than done). This would make the "free loading" block producer have less good connections for its own block diffusion later on.

[WhatisRT]

The 'easy way' to incentivize the non-tx block production would be to simply include them in the BlocksMade map. This should probably be weighted though. Otherwise most of the rewards would be gained by voting which doesn't sound right. But I don't know if that scheme incentivizes the kind of good behaviour we want.

[ch1bo]

If there are no game-theoretic gaps to this, this sounds like the easiest approach.

• Votes don't strike me as equally important and could be unpredictable enough to not matter.
• Producing EBs sounds equally important as producing RBs. Bonus: for Linear Leios it's the same opportunity and literally no change needed.
• For IBs, I'm not sure. Counting them equally is a slippery slope of incentivizing lots of overhead in low demand situations?