ain
ain copied to clipboard
DeFiCh
Increase the maximum TM due to the introduction of the subnodes
What would you like to be added:
Increase the TM from 57 to a bigger Number
Why is this needed:
with the integration of the subnodes and the increasing amount of masternodes there is already a huge amount of subnodes at TM 57 no matter if they found 2 or 3 weeks ago the last block.
Perhaps it would make sense to extend the 14 days to 28 days in order to maintain equal opportunities.
Attached a graph over the targetmultipliers, Somewhat affected by the many frozen nodes at Cake in the front TM areas.
@bernd-mack: Thanks for opening an issue, it is currently awaiting triage.
The triage/accepted label can be added by foundation members by writing /triage accepted in a comment.
Details
I am a bot created to help the DeFiCh developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the DeFiCh/oss-governance-bot repository.
Agree on the proposal. TM 57 is collecting quite a few masternodes. Why is there a limit anyways? We could just have it open ended?
The limit is set for the following reasons:
- Economic fairness. Nodes that are offline should be able to accumulate TM indefinitely. Nodes are encouraged to be online.
- Security. Nodes that collectively accrue too high TMs may run the risk of pulling out a 51% attack on the network. An entity that runs say 30 nodes but collectively having TMs above 51% might be able to pull off a 51% attack without even controlling majority of the nodes. This is an a more important reason.
For this reason TM should not be too high.
Graph posted by @bernd-mack with the distribution is showing that the distribution is actually performing well It is not top heavy, except at the max, which could indicate one of the following reasons:
- The nodes are offline.
- The nodes are mining on an underpowered system that are not able to keep up with the hashrate.
Both cases are bad for the network, and thus should not be rewarded.
I also would like to add that all nodes are currently fair. No nodes are at an advantage over the other.
I would disagree on the 2 mentioned points My 10y locked node has now a subnode with a TM 57. been stuck there for many days and it is the 3rd time jt happens
Target Multiplier: 30, 57, 2, 4
My machine is obviously running as the other subnodes are finding blocks. I have a physical machine with 12 cores and 128 gb ram and ssd. Definitely enough power.
Running fair I am not sure as other nodes started at the same time have found 10 blocks more.
@uzyn there are close to 400 TM57 nodes on Cake. I would assume Cake is not having uptime/hardware issues and the root cause is something else.
@sandrich
I would disagree on the 2 mentioned points My 10y locked node has now a subnode with a TM 57. been stuck there for many days and it is the 3rd time jt happens
Target Multiplier: 30, 57, 2, 4
My machine is obviously running as the other subnodes are finding blocks. I have a physical machine with 12 cores and 128 gb ram and ssd. Definitely enough power.
Running fair I am not sure as other nodes started at the same time have found 10 blocks more.
Fair as in all nodes are facing the same chance of hitting TM 57. Assuming we have no TM, then all nodes have the same likelihood of mining or not mining a block.
As we can see with @RomanShumkov's response as well. Cake nodes have the same likelihood of hitting it.
@uzyn there are close to 400 TM57 nodes on Cake. I would assume Cake is not having uptime/hardware issues and the root cause is something else.
There's no exploits and every node is having the same good/bad luck on this.
One thing that could have been pointed out by @sandrich is that there could be a bug on mining at TM57.
This graph does not disprove the existence of that bug.
Will take a look at that to see if there's a loss in efficiency mining at TMmax.
One thing that could have been pointed out by @sandrich is that there could be a bug on mining at TM57.
This graph does not disprove the existence of that bug.
Will take a look at that to see if there's a loss in efficiency mining at TMmax.
I do find it strange that my TM57 is stuck for a long time (couple of days) while the other subnodes happily find blocks with very low TM.
Will take a look at that to check if there's a loss of mining efficiency at TM57. Will share back on that. Thanks for reporting on the finding @sandrich
Took a look at this and made charts based on the TM of sub-nodes when finding a block, this covers the last 30 days worth of blocks being a time period where coin-age and sub-nodes are fully activate. For all nodes there was 478 exiting at TM 56, others will then stack up on TM 57. You can see where the majority of nodes will exit around TM 23. Checking the code there does not appear to be any loss of mining efficiency at TM 57, it does still offer the easiest staking possible. You can see that some staking nodes will stack up on TM 57 and you will also end up with nodes that are offline, improperly configured or had their staked blocks orphaned by longer chains.
Thanks for the graphs. I still think that TM57 is too low as I would argue that the majority of hosts in TM57 are actually working. I take mine as an example again. It is stuck there for 4 days while the other subnodes work fine. Essentially I have a 5y node locked for 10y which is not optimal.
@uzyn maybe an open ended TM limit is not optimal but certainly higher than now to adapt for the many subnodes that were introduced. A normal node has now 2 subnodes so maybe doubling the max TM might be a good start. I wonder how high the TM should be so that it is very likely to get out of it rather quick for a well working node? This could be maybe calculated and then used as an optimal max TM.
Also I am not entirely sure I understand your argument about the 51% attack. It is more likely that such an attack comes through the Cake nodes since they hold > 83% of all nodes.
I'm having the same issue. The TM is stocked at a very high TM or at 57 and other subnodes are still minting normal.
I would like to point out that it is easy to tell which subnodes at TM 57 belong to offline masternodes. Since the likelihood of all of a masternode's subnodes being at 57 simultaneously is very small, one can remove these masternodes from consideration when using listmasternodes command. Here's the distribution as of a few hours ago with 'offline' masternodes removed. Even with these removed there is a sizable population at 57.
@uzyn Your points are well taken. Does it make sense though to adjust the maximum TM (without getting rid of it) as the online subnode population continues to increase?
Hi, I had 57 for 3 times at 2 MN's one with 5 and one with 10 years freezer. The length of stay at 57 was 1/4/6 days. Together with the 12 days to reach 57 a maximum of 18 days. If you project this to an enhanced TM you need a minimum TM 90 to 100. Thank you.
I have run some simulations of block rewards to help quantify the impact of the current target multipliers. These simulations assume a few things: blocks come every 30s, a subnode's chance of finding a block is proportional to it's target multiplier, population of subnodes is constant, APR only includes block rewards (no tx fees), block emission reduction is taken into account, etc.
I have simulated the APR for a normal masternode over the next year under three different conditions: (1) maximum TM of 1 (essentially no target multiplier system), (2) maximum TM of 57 (current), and (3) maximum TM of 10 000 (essentially no limit on TM). Here are the results:
max of 1: APR = 0.344 +- 0.038 max of 57: APR = 0.344 +- 0.021 max of 10 000: APR = 0.344 +- 0.020
As you can see, the target multiplier system has no impact on the average APR for masternodes. The only impact is on the variance, i.e. how much will the individual masternode's APR fluctuate about the average. A maximum TM of 1 acts as an upper bound on the amount of variance in the block reward distribution. Likewise, an unlimited TM acts as a lower bound on the variance. We can not reduce the variance in the block rewards any more than this lower bound by using the target multiplier system. Both the upper and lower bounds will be dependent on the current subnode population.
The following is a way to measure how close the current maximum target multiplier is to the upper and lower bounds of the variance:
Let, currentTM = variance of current max target multiplier (0.021 in the above case) tm_1 = variance of max target multiplier of 1 (0.038 in the above case) tm_inf = variance of no limit on target multiplier (0.020 in the above case)
Then, factor = (currentTM - tm_inf) / (tm_1 - tm_inf)
The closer 'factor' is to zero, the closer the current TM is to the case of no limit on TM. The closer 'factor' is to one, the closer the current TM is to the case of not using the target multiplier system to reduce the variance at all.
Our current value of 'factor' is 0.04, very close to no limit on TM indeed. This would indicate no need to increase the maximum target multiplier at this time.
Perhaps this would be a useful metric for evaluating when to increase maximum TM?
ps If you're interested in how my simulations work see my reddit post: https://www.reddit.com/r/defiblockchain/comments/qocnd1/simulating_defichain_block_emission_rewards_a/