PUP-27: Raise PIP-22 Ceiling (RPC)

Explain? 150ms already is the benchmark used in the cherry picker

Explain. This was lasted adjusted in July and I commented at the time that the topic of proposer allocation may need to be revisited aftr lessons learned from PUP-19 were aborbed.

Yes, everything in proper order, which is why both these proposals have been on back burner

This is going to need research. It’s not so easy as that. I’ll put some time into thinking about this once the dust settles on SER

1 Like

Yes, 30% increase of validator rewards is a rough approximation. Some math could be done to get the more precise number, but I believe it should be somewhere within 20-30% range to raise the validator threshold high enough above the highest servicer node stakes.

1 Like

Once SER is over, I will try to put together a calculator to get ball park estimate of where validator threshold will land for various levels of proposer allocation. that will be a first step

1 Like

Ok, I guess I am wrong on a lot of points here. Sorry guys.

But I still think this is 3-4 months out.

1 Like

Sounds like a good plan. It shouldn’t be complex to get the numbers. SER first, then the rest can be put on the table. I still stand at my point that at the same time proposal should:

  1. increase validator rewards
  2. allow 75k servicer nodes

Changing only one of these 2 is not a wise move. Either both or none.

1 Like

How is our current validator mix not adequately decentralized or secure? https://twitter.com/POKTValidators

How is the current system unfair? Why do validators need more rewards?

Yes, it would be higher than 90k, because servicer and validator rewards would even out at about 280k per validator at 30% validator reward.

You state that validators need to “decentralize” but:

  1. That is not at all the case when you look at https://twitter.com/POKTValidators
  2. Your solutions would only create even more disparity in the validator system. Your solution would make it so fewer and fewer individuals could participate, since the average would be multitudes higher than it is now.

Until an argument is made as to WHY change is absolutely need to be made in the validation space, there is no reason to do any of the actions mentioned above, including PUP-27. Changing economic nobs without a clear goal, is a wasteful burden on the ecosystem.

The only question that need to be asked is:

What amount of POKT is required to be staked in validators to be considered secure? Right now it is 86,364,000… is that not enough to secure the network until v1?

I believe what we currently have now is more than etiquette to secure the network until v1.

3 Likes

Thanks @shane . I don’t think @RayBorg was suggesting ProposerAllocation = 30% but that the allocation be increased 30% from current level - i.e., from 5% to6,5 or 7%

In any case, your point is well taken. As to your question, 86MM is clearly inadequate to secure the network . That’s only ~5% of the circulating tokens and a spend of only ~$3MM to hijack the network.

Running as we have at this level of network security is a calculated risk the DAO has thus far been willing to take after assessing the horizon for potential bad actors and assessing what gain could be obtained by those actors and the probability of them taking negative actions between now and v1.

The calculated risk taking is not unreasonable given the lack of exposure of POKT in the marketplace (little to gain notoriety wise), lack of threat of POKT being feared as a worrisome competitors by the like of Infura at sufficient level between now and v1 to trigger sabotage by a competitor, and unclear path to ill-gotten financial gain resulting from hijacking the network to make the $3MM spend worthwhile. The question comes down to whether this level of risk-taking / playing-the-odds is prudent for the next twelve months or so until v1 when it is at our disposal to fairly easily raise POKT staked in validators through one or other parameter change.

2 Likes

That makes more sense. Thanks for cleaning that up for me.

Today’s liquidity is a safeguard to that kind of attack in all practical terms. That should be take. Into consideration when calculating an attack. For the situation you described, an outsider competitor would be buying POKT to sabotage. That amount of buy pressure would would send the price of POKT to the moon, making an actual attack significant more expensive than $3m. Market conditions should be a factor in the security decisions IMO.

Open to argument about security though. I don’t think there is any level of unfairness or a lack of decentralization, that would warrant a change, unless there is something I’m not seeing.

2 Likes

Yes, liquidity is definitely an important factor in the risk management. I don’t think POKT is as illiquid as people think it is, though. $3MM represents only half the daily volume on BTCEX, and just over the daily volume on Gate. Not to mention OTC solutions that exist. I’m pretty sure enough tokens to do damage could be purchased over a week or two without significantly moving the needle.

I’ll look at the idea of unfairness brought up by @RayBorg next week. I hadn’t myself brought up anything to do with unfairness, but will spend a bit of time to see if if I can understand the sentiment prior to responding.

1 Like

Looking forward to your analysis, msa. I’ll be happy to discuss further once SER gets implemented and when you come out with the data about this topic.

1 Like

@msa6867 can we proceed with this proposal now that SER has passed and put it on a vote?

1 Like