I saw several critical things to discuss on current cosmos-sdk version.
Some of these might be still in discussion in Cosmos Team.
But I think community also should discuss about it because the logic here will have
large influence on Cosmos validator ecosystem.
Reseting accum to zero when there is a power change of a validator.
Is it an attack vector?
Do we need this in the first place?
Forced withdrawal caused by validator’s power change
Is it an attack vector?
Do we need this in the first place?
Current distribution logic based on current DelAccum
Inflation reward happens once in an hour now.
Inflation reward distribution is based on current DelAccum
So distribution of reward varies depends on each delegator’s withdrawal timing
Is the distribution should be based on current DelAccum?(current sdk logic)
(inflation reward is for the current hour’s contribution)
Is the distribution should be based on last hour’s accumulated DelAccum?
(Inflation reward is for the last hour’s contribution)
Thank you for the links! The process seems clearer now.
I think the issue is about resetting the whole accums of every validator(making the avg of accum to near zero). The topic suggested is about “a” validator’s accum resetting when his power change happens. I am not sure there exists any relevant fix in the linked issue.
There can be other attack vectors such as delegating small amount to cause withdraw when the decimal is high(to cause big proportional loss of reward by decimal donation to community fund)
Yes. blockly minting will eventually get rid of the issue if all the distribution to each validators happens immediately and nothing left in the global pool(global pool should not exist any more)
One thing that I have concern is about the community tax. The truncate to int operation will lead to more community tax as designed. so maybe there should not be a communityFunding part substrated at Endblock?
I also agree on truncate donation issue. I rather think the truncate donation should be removed since it is not very visible and not a transparent tax. It is also bad for small investors since small investors will lose larger fraction of their reward due to truncate donation. Not a fair tax.
This is inaccurate, accums are reset to zero when a validator is bonded (or unbonds and is later re-bonded). After the fix in the PR Zaki linked, they will be reset to a negative value instead to prevent a particular class of attacks on the proposer election algorithm, but that doesn’t change when the reset happens. Power changes to a bonded validator do not cause the validator’s accum to change (other than in the usual way, e.g. if a validator’s power increases they will be more frequently elected proposer).
Re-averaging the accum distribution has nothing to do with the reward accum, they are two different "accum"s with no relation. Probably we should rename the SDK-side accum.
yes i clearly understand there exists two accum, one for proposer choosing(visible from rpc), another one is DelAccum which is invisible at this moment(hidden in reward distribution logic). Both my topic and zaki’s link is talking about the former one. but the zaki’s link is about New validator, not old validator’s New additional delegation.
so, i might not follow accurately about current development version of the github. in the current development version, is the validator’s accum(former one above) not resetted when he gets a new delegation? i saw this happening in 9001 but not sure on current version.
i will add more about 3rd topic in another reply
about topic 3, if the rest of the rewards(ValPool) which are left after immediate distribution(putting it in DelPool) stays in ValPool for some period, the problem of topic 3 arise again.
topic 3 is about the calculation of “entitlement” of a given delegation. i suggested that entitlement should be calculated based on already finished period of time.(period should be defined by time or number of blocks) But current distribution uses current accumulated DelAccum, which is not confirmed yet in a periodic sense.
But, if the period is one block, it means by definition that all distribution is done immediately, meaning there is no left over to put in ValPool.
If it is the case, i think DelAccum also has no reason to exists too because all rewards go to DelPool straight, and the ValPool will be empty at any block. and in this case, now all problem is solved, and withdrawal timing does not cause any unfair distribution!
(happen immediately means all rewards go straightly to DelAccum, without stopping by at ValPool, irrelevant to withdrawal at all)
And one more topic i want to discuss : auto delegation of rewards.
In current design, delegator should withdraw and delegate(2 different tx creating) very frequently to get the maximum inflation rewards. This is very inefficient for individual and also for the whole blockchain since most of delegators will want to reinvest the rewards.
Especially if the gas cost is significantly large enough, tx cost will be quite a lot.
So in design, i think there should be an option for delegator whether he wants to reinvest the rewarss or let it be.
Maybe count the atoms in DelPool as in stake power is a good another option.
No, it is not reset, except in the case where the new delegation causes said validator to switch from unbonding/unbonded to bonded. That shouldn’t have been the case on gaia-9001 either. If you have a testcase which replicates behaviour otherwise, please file an issue on the SDK and we’ll look into it.
Unfortunately, if the period is one block, we lose the primary benefit of lazy reward calculation (not needing to iterate over all validators & delegators). It is true that the distribution is not exactly “fair” in the sense that it does not necessarily correspond to the value we would have calculated if we did so iterate. However, I think that’s only a concern if delegators/validators can predict future fees (information with which they can time their withdrawals or force others to withdraw more effectively). For more discussion, see Interaction between gas / spam prevention and reward distribution · Issue #2764 · cosmos/cosmos-sdk · GitHub. Broadly, I agree, but this seems a relatively low-priority concern (I think we will almost certainly change the fee distribution mechanism as one of the first software upgrades). Do you have a particular situation where you think it would be a high-priority concern?
If the transaction cost is high, validators/delegators will wait and withdraw less frequently - that’s fine, that’s the fee market working as intended, since executing compute and IO costs the node operators physical resources. It may be the case that validators accept zero-fee transactions for their own delegators (or anyone withdrawing rewards then delegating to them), which does seem somewhat concerning. That said, decimal truncation should ensure some minimum frequency of transactions (unless delegators are feeling charitable and want to donate to the community pool!).
First of all, thank you so much for spending time explaining and discussing these issue in forum.
I am little bit worried if I make you spend too much valuable time here.
I will investigate on the blockly provisioning new codes and then submit an issue if I think something crucial attack point(or critically unfair distribution) exists there. Quite difficult to read the changes
I see your point here. If all the delegators are smart enough to get a balance view on tx costs and rewards amount, it is ideally OK. Maybe it is the duty of validator to auto-optimize it. System is OK itself now.
I just want to issue this because in the financial industry, auto delegation is a very low standard. We cannot imagine any bank not providing that. So I just think why new technology doesn’t have it? It looks like finance technology going backwards.
Maybe but this issue is not a priority for the team at the moment. So I don’t want it to issue it if team decide it is not a priority thing.
Again, Thank you so much for clearing these issues. I think most of the community members will share the benefits of developed fee distribution understanding from this issue!!
