Manipulable inflation
vaultec81 opened this issue · comments
Avalon calculates inflation based off the number of total accounts in existence. A potential attacker could burn/create a number of accounts inorder to artificially increase inflation. That then said attacker could use each of those accounts to vote specific content that has a high likely hood of getting upvotes. (For example a popular, well know content creator). That then creates an artifical popularity of content that is being boted (an entire separate issue). Bots have the ability to vote on content way before a lot of people have seen it. (Thus making it potentially profitable)
Overall if this issue becomes wide spread it will make the chain worthless.
Okay so we are clearly talking about avalon economics here. So let's not be too quick to consider it a bug. First let me state that I clearly want all the economics part of avalon to be entirely customizable by the leaders, and I'm totally open to changing the way it works as long as it serves the goal of empowering humans in the dtube game.
Right now the way the inflation is calculed is pretty simple. https://github.com/dtube/avalon/blob/master/src/economics.js#L16 Here it calculates how many 'active' (defined by at least 0.01 DTC in their account) users are in the chain, and uses that as the base number. Then it gets multiplied by the rewardPoolMult (reward pool multiplier), and it adds rewardPoolMin. Both those variables are already controllable by leaders in the hardforks, and could potentially be used to quickly counter an abuse. Imagine we wake up one day and we realize that 1/2 of the accounts are all fake, then we could easily divide rewardPoolMult by 2 and reach a normal distribution.
Maybe the '0.01' part needs to be a config for leaders too, so that if someone wants to attempt such an attack, there would be a higher lower cap to be considered active.
If you have any other suggestion on how to count number of active users in a deterministic way (i.e. in the chain directly), I would be happy to hear suggestions. The only property that I need to enforce in the chain is that the inflation stays more or less proportional to the number of active users, which in turn creates a stability in the 'hardship' of earning DTC.
@vaultec81 I have started a new branch alt_eco. https://github.com/dtube/avalon/tree/alt_eco/wip
You can see the code that increased the reward pool based on the number of users has been removed, and users do not have a way to manipulate the inflation by creating accounts and loading it with stake anymore.
Instead the rewardPoolMin controls the base reward pool per economic cycle. On top of it this branch re-injects the burnt tokens into the reward pool.
This way, the total supply increases by the base reward pool every economic cycle on average. It can print slightly more or slightly less, but it is computable.
In theory, it also fits my vision of having a scalable reward pool based on user activity. It seems plausible that the more real human using the site, the more total DTC value will be burnt for video promotion / account creation / future burning mechanisms.
Leaders will still be able to somehow control the inflation by modifying the rewardPoolMin. Setting it to 0 is a bad idea, as it would lead to having an empty reward pool in certain situations (api / chain issues) and could lead to bad user experience (votes generating 0.00 DTC). However it would be better if the large majority of the reward pool came from the 'burnt' tokens.
Another strong argument for not having a manipulable inflation, is simply markets / investors. Having a non-deterministic supply is very scary as it basically enables leaders/supernodes to collude against non-majority stake holders.
The mainnet does not include this feature. The inflation is controlled by the blockchain settings that leaders control (2/3 majority required else chain halts).