AIP:21 - Discussion

[Jarunik]

My Concerns:

Unclear how master node rounds would integrate into delegate rounds

• Distribution of ARK to master nodes would happen when forging a block. How do we do that without negatively impacting forging?

Measuring Performance

• How can we easily measure performance without negatively impacting the network?

Suggestion to solve the problem differently: Random Delegate Spot

• Change the spot 51 into a random delegate instead
• Each delegate voted with at least X amount gets a chance to forge
• Additional voted ARK will increase the chance to be chose as forger
  Benefits:
• Not much new concepts needed (other then picking a random standby)
• Smoother entry for delegates and option to attract "Mini-Delegates"
• Rewards for standby delegates
• Automatic health check through forging
• Already proven to work in other blockchains

[cambo]

I like the master node proposal for the following reasons:

• It will definitely draw more people to Ark. People see an opportunity to make money and they'll come running.
• Requiring the deposit of 2k Ark will increase demand.
• Network stability, Currently, unless you're forging, there is no reason to run a reliable node, as we all know, unless you just love Ark that much and want to throw money at it to support it. With even a little financial incentive this can be resolved.
• As mentioned above, there is financial gain here and technological gain.

What I don't like about the master node proposal:

• Would this discourage forging delegates? If the 1.8 Ark per block avenue is pursued I imagine it could. I would like to see more delegates weigh in on this.
• We've seen a couple network issues recently. Will these problems even be present in V2? I am concerned this solution could just be a knee jerk reaction. Are tests underway to see if these issues will be present in V2?
• There would be financial gain here and technological gain with this solution, but, what is the driving/deciding factor? If financial holds more weight then maybe that isn't such a bad thing to help prop up Ark. If it is driven primarily by technological gain, again, I'd ask if these network issues will even be prevalent in V2.

[roks0n]

I like the proposals, here are some reasons for it:

• gives incentive to run a node as a community member and not only as a delegate
• enables community to be more involved with the developments
• currently if community member runs a node they run it because they want to support Ark, but usually they set it up and forget about it which can causes issues (especially with v1) if their node goes out of sync and stay like that for days. If relay runners would be compensated when they node is in sync I think this will motivate more people to set up proper monitoring

My thoughts on some of the existing comments

How can we easily measure performance without negatively impacting the network?

What kind of performance would you measure and why? I'd go with the same approach as with other masternodes where every block a % is rewarded to the address specified with the masternode. The more masternodes there are, less frequently MN would get rewarded. And if masternode is out of sync, it wouldn't be rewarded at all which gives additional incentive to MN operator to keep them in sync and running.

Suggestion to solve the problem differently: Random Delegate Spot

This makes me feel weird. Personally I wouldn't mess with the delegate slots and would prefer going the with the path where we'd decide how big of a % do we share with one of the masternodes in the network on every forged block. However I'm not aware how this would impact forging itself. Also, I'm curious @Jarunik, which other blockchains use this approach at the moment?

Would this discourage forging delegates? If the 1.8 Ark per block avenue is pursued I imagine it could. I would like to see more delegates weigh in on this.

Based on my observation it seems that majority of active delegates are OK with "loosing" 10%. Strangely it seems that more are inclined towards the 10% than increasing inflation for additional 0.2 ARK. Please note that this is just based on my personal observation from the chats.

There would be financial gain here and technological gain with this solution, but, what is the driving/deciding factor? If financial holds more weight then maybe that isn't such a bad thing to help prop up Ark. If it is driven primarily by technological gain, again, I'd ask if these network issues will even be prevalent in V2.

Great question, from what I understand the issues that we are seeing now (with nodes rolling back and unable to go in sync) should not be present in v2. I think the major deciding factor is to make it more expensive for any malicious individual or a group to handicap the network.

Questions/concerns/thoughts

1. We need to test how out of sync relays impact v2 at the moment
2. Is 2000 ARK the right number, why this number?
3. How would MN operators impact governance?

Other

I found this to be a good read on masternodes, eg. global list (for payment), what happens if masternode is offline, what if MN operator spends the collateral etc: https://docs.dash.org/en/latest/masternodes/understanding.html

[outboard-arkoar]

I generally view this change as a bad idea. I'm not opposed to the concept of masternodes, but I think adding complexity to the reward system at this stage will create confusion, inefficiency (polling the masternodes) and potentially introduce new attack vectors. 2000 ARK is simultaneously too small to prevent a malicious actor from purchasing a large number of 'trusted' masternodes and too much to encourage everyday people from doing so. At this moment in time, it takes $956,301.36 to purchase the lowest delegate spot. The same money could 'buy' 692 masternodes. If ARK were more valuable this would be less of a concern, but at this stage it is not.

I much prefer a flexible approach managed by the community as a whole that rewards positive relay nodes. If or when the price of ARK exceeds $50, I would reconsider, but at that point, I think the community driven approach will have created enough relay nodes as to prevent the underlying issue.

[github-actions]

Stale issue message