PUP-4: Adjust DAOAllocation to Limit Service Node Counts

I’ve opened up this proposal for discussion again, although the proposal has passed per my above message, to allow for more discussion to take place in the same thread.

If someone wants to propose a new parameter change (e.g. to adopt a different strategy or revert this decision), they should publish it separately in the PUP category and link to this thread.

Hello there,

What are the exact parameters that were voted by the proposal ? Is it the parameters that were initially described by @Andrew ?
I’m struggling to synthesize the complete thread. Would it be possible to clarify that so we could communicate on it clearly to our clients and community ?

Thanks :slight_smile:

cc @tdephuoc @Laszlo_Szabo @Gregoire_SkillZ @JackALaing

No. I edited the original proposal with the new parameters as well as synthesizing the complete thread so that you don’t have to.

Here is the comment where I announced that I was doing this

And here is where I left a note that the original proposal had been edited with Andrew’s consent

Your single source of truth is the latest version of the proposal at the top of this thread. It defines the parameters that were approved by the DAO for modification and synthesizes all of the arguments for/against the proposal.

1 Like

Thanks @JackALaing, very clear :pray:

2 Likes

I think we should discuss delaying and/or modifying the actions approved by this proposal.
TLDR:
1.) Shift the curve out by 1,000 (so that reductions begin at 4,000 not 3,000) and…
2.) Modify the MaxValidators param to 4,000 rather than 5000 ( so that nodes become service nodes sooner rather than later.

Reasons why we should consider this change:
1.) Recent changes in the P2P configurations associated with the RC-0.6.0 release have already caused a very noticeable improvement in block propagation and achievement of consensus. In fact, blocks are actually arriving early in many cases rather than late.

2.) The split between validator and service nodes (after 0.6.0 activation block) will -in itself- reduce the overhead associated with additional nodes.

3.) By my estimation based on conversations with persons who have coins that unlock on 5/15. We can reasonably expect 1,000+ nodes to attempt to join the network on or shortly after that date. As things stand right now… we could be in for a really ugly PR issue if 1 or 2 thousand nodes join at approximately the same time that the rewards go to near zero.

2 Likes

Agree with the fact that we should reevaluate this proposal with a new one. We’re currently drafting a position on the subject and will take part in the discussion shortly.

Thanks @BenVan for the initiative!

cc @tdephuoc @Laszlo_Szabo @Gregoire_SkillZ

@BenVan, thanks for opening the debate on updating PUP4

  • understanding your update suggestion, you propose a maximum of 4k validators earning 100% rewards.
  • passing the 4k validators limit; all nodes will be service nodes
  • reaching 5000 nodes (4000 validators + 1000 service nodes) => 49% of rewards

Is it what you had in mind?

@JackALaing, what doesn’t seem clear to me is when and according to which criteria the PUP4 voted will be implemented by the DAO?

1 Like

@Laszlo_Szabo I’m saying shift the curve in the top post out by 1,000 so that the “wall” is at 6,000 not 5,000 .
At that point … yes… there would be 4,000 validators and 2,000 service nodes running.
Hopefully, prior to that point we will have good data on how the growth from current to 5,000 has effected the network and what effect service nodes are having on overall operations. We may be able to abandon or further postpone this process if we are still good @5,000

1 Like

@Laszlo_Szabo see below

We are inside the activation window and the Foundation has already been authorized/instructed to act.
If I am the only one here that wishes to stop this process, that is fine, I will shut up. But I’d like to know that other people besides myself have actually read this and understand what is about to happen.

3 Likes

My vote was not active in time to vote on PUP-4 but I agree. I would’ve voted against it.

  • I don’t believe it will dissuade any node runners from coming online in the short term. If they purchased and are waiting on vested pocket, I believe they will spin up the nodes regardless of PUP-4.

  • Peering towers, the split of validators and service nodes, and other improvements have likely made PUP-4 unnecessary

  • At the extreme ends of the curve, this proposal will unreasonably penalize node runners that have supported the network with good service since it’s inception

If you wrote a counter proposal to negate PUP-4, you would have my support.

3 Likes

Given the newfound P2P stability through config changes and community level peering efforts (like towers and sentries), it seems that the reward decrease schedule can be (at the very least) pushed later. I worry about unintended consequences of these param changes if it’s not mission critical (the latest observations at 3.5K Validators seem to suggest little P2P stress at this time).

If the three of you are in favor of negating this proposal, or at least swapping it for a less extreme solution, then I’m also in favor.

@BenVan to officially negate this proposal, we should publish a separate PUP and vote on that. If you’re happy to take the lead on authoring that proposal, I’d be happy to help you with any formatting questions you have.

1 Like

Thanks Jack. Yes. Let’s move this to a vote. I’ll write a pup.

3 Likes

Thank you @BenVan for moving the conversation forward, we will contribute to the discussion following your proposal.

Thanks, @BenVan, for this explanation.

  • I agree with you; the current PUP4 doesn’t seem to go in the protocol scaling interest. How can the community find a solution overpassing the 5k node limit while preventing node runners from reaching the limit?
  • It seemed more accurate to push nodes barriers up, testing if the 5k limit could be contoured with 4k validators and 1k service nodes or more.
  • It’s also explicit that the May 15th unlocking period will push some of our genesis clients to launch more nodes. It gives them more liberty to do so without impacting on the rest of node runners rewards.

Ben, we will support you on this new proposal and vote to pass it to the DAO.@jack, thanks for this information! If I understood it well you are afraid of node providers launching as many nodes as they can, while giving a public date announcing when PUP4 will be effective right? Then why not giving a node number hard cap where PUP4 will be effective?

Sorry guys for the late answer, the last few days have been hectic.

2 Likes

This proposal has now been rescinded as a result of PUP-6 passing with 8 yes votes and 0 no votes. Voting results here.

I’ll now close this thread.