PUP-14: Increase MaxValidators to improve economic security

Proposals Parameters
1

Attributes

  • Author(s): @addison @pierre
  • Parameter: MaxValidators
  • Current Value: 1000
  • New Value: 5000 (over a period of 1 month)

Summary

Right now the amount of pocket needed to take over the network is extremely low. The top 1000 validators have 19.8m pokt staked. This means that an attacker would need 13m pocket in order to take complete control of the network. At current prices, this is $2.6m USD, which is a very small amount for a network of this size. We should increase the MaxValidators parameter in order to improve the economic security of the network. I propose we increase the parameter to 5000 over a period of 1 month, which would increase the validator stake total to 81m and amount required to attack the network to 54m POKT/ $10.8m USD.

Abstract

The MaxValidators parameter determines how many of the top nodes by stake are considerd validators. Currently the value is quite low and needs to be increased.

View current validator distribution here:

image
image1061×623 96.1 KB

View desired validator distribution at 5k validators here:

image
image1059×656 127 KB

Motivation

This parameter change would increase the network security from 13m pokt ($2.6m USD) to 54m pokt ($10.8m USD) and further mitigate attackers and malicious actors.

Rationale

We cannot have a $300m protocol that peaked at $2.5b secured by $5m of assets. Here are a few of the many possible threats if someone were to get 66% of the validation power.

  1. Chain halt
    The chain could shut down. Apps would stop receiving service and nobody would be able to transfer POKT
  2. Exchange/OTC reorg
    Someone could deposit pocket onto the exchanges at block N, market sell and take all of the buy liquidity. After this, they could produce another block off of block N-1, orphaning block N and returning all of their funds
  3. Modify consensus
    Someone would be able to modify consensus and pretty much do whatever they wanted.

5k is not a firm selection and can be modified. Please see this sheet for analysis and charts to determine the optimal value for yourself. We should try to determine a value that increases the economic security while reducing overhead on node runners and the state. Core devs can chime in here to provide insight into the implications of increasing the validator count.

We could also consider pursuing an approach where the MaxValidators parameter is continously adjusted so that the validator stake always equals a certain threshold.

Implementation

Per Jack’s insight, we should increase the validator count steadily.

I propose we increase the validator count as Jack said upon the following timeline. The foundation will handle the parameter changes.

Upon Passing: 1500
Week 1: 2250
Week 2: 3375
Week 3: 5000

This will allow us to observe changes and ensure the network remains healthy.

Dissenting Opinions

  1. This will cause too much chain bloat.
    The max blocksize is 4mb. Currently blocks are about 2.6 mb. This change would increase blocksizes by .9mb according to Andrew’s post. This would be approximately 2.5gb a month. This is definitely worth it in order to ensure we have a secure network.

The following is a chart of blocksize in the past 2 days.

image
image1382×355 40 KB

If we increased blocks by .9mb, this would put blocks at around 3.5mb, which allots for some spikes.

  1. Pocket is illiquid. Nobody could acquire this much pocket.

There are individuals with this much pocket and from my experience running the OTC, I have no doubt that someone would be able to acquire 13m POKT with decent slippage.

  1. There is no economic incentive for someone to attack the network.

Regardless of someone’s incentive, we need to ensure that the network is economically secure. A competitor could see this as an opportunity to end pocket, we cannot have this liability. Also, regardless of the risk of an attacker, the validator set needs to be diversified. Liquify currenty has 37.5% of the validator power. What happens if they go offline due to a bug in their infrastructure?

  1. We should instead further incentivize validators instead of changing this parameter.

That would be a more significant change and require greater thought as that would affect everyone in the ecosystem. This is a seemingly easy change that would drastically improve network security.

  1. The DAO, foundation and other whales would be able to step in if an attacker arose.

This is not a suitable defense. There are no alerting systems currently for validator stake. It would also be a massive coordination effort in order for the DAO or other people to combine funds and stake it ont o a validator. They might not be able to react quick enough as the aforementioned threats only require a block or two to occur.

Analyst(s)

See analysis here

@addison

Thank you to poktscan for the raw data.

Copyright

Copyright and related rights waived via CC0.

7 Likes
2

I strongly support this proposal.

3 Likes
3

Amazing proposal, let’s do it.

4

I also strongly support this proposal

The current lack of network security is honestly scary. There are also lots of other more complicated attacks that could be done right now (I can explain once this proposal passes), and this proposal will significantly mitigate the danger of all of them.

1 Like
5

By the time any of us is aware, the chain could already be halted (or corrupted) putting the network in danger. If corrupted, this is a position no network would ever want to be in. Network security should first be proactive followed by reactive measures.

:open_mouth:

I strongly support increasing the number of max validators for the simple reason that it strengthens our network security. The additional block bloat along with increased voting gossip is worth the tradeoff to improve the network security. Later down the road, we will see optimizations (like the one the Core team introduced for V0 @ infracon) that could help alleviate this.

This breakdown of data is amazing, a data driven proposal - love to see it.

If approved, we should compile a list of soon to be validators and give a fair warning to ensure they are properly provisioned to be a validator.

6

The problem here is more to do with the lack of incentive to be a validator, leading to the majority of node runners distributing horizontally to optimize their servicer count and causing a lower average validator stake, than it is to do with the number of validators.

Our validator set has a very long tail. The 12th largest validator has only 62,500 POKT staked, the 22nd largest validator has ~30k POKT staked, and we get into the range of 16k POKT staked at approx 200-300 validators.

It is therefore my view that increasing the validator set from 1k to 5k isn’t going to have as much impact as increasing the average validator stake. We can do this by making a validator more attractive to whales than servicers, by adjusting the ProposerAllocation. This has the bonus of consolidating the total node count, thus reducing the total operating cost of the network. Adam and I are currently drafting a proposal that does this.

I’m not opposed to expanding the validator set, it just shouldn’t be our only solution. I think we should also keep in mind that we may later want to reduce MaxValidators again in light of the light client and the behaviors we observe in how many node runners optimize to be a servicer vs validator.

7 Likes
7

I think it’s a mixture of both. I’m focused mostly on the security aspects right now. In the past, node runners didn’t get choice on whether to be a validator or servicer, everyone was a validator. This change was only proposed and passed to optimize on the efficiency of the network’s consensus and avoid hitting the max block size. I think we should use the reverse logic of turning some nodes into validators forcefully so that our network becomes more secure. At the time, 1K was decided to be the desired amount - but now that amount is far too low economically and puts the network at greater risk.

If the max validators increases, the incentive node runners get is still being a block proposer(which the amount can be adjusted another time) but also as well securing the network which is a good thing if they value their investment.

Why encourage only whales to secure the network? This decreases the diversity of the validator set and makes collusion attacks more likely to occur. I think it should be the opposite where we have a diverse set of validators.

The only “con” to running a validator is that it might take more infra resources (compute, memory?) to run one. Can Core team shed some light on how much of a difference this is, if any? Instead of encouraging whales to up their stakes so that they are block producers with increased BlockProposerAllocations, we could provide a stipend to incentize individual node runners to top up their stakes to be validators if we don’t see an diverse validator set due to validator overhead.

Based off the data provided though, with 5,000 validators - we already see a much larger diverse validator set.

Edit: Diverse validator set in sense of voting power too.

8

I agree that it’s a mixture of both, this was my point.

I’m not suggesting that we encourage only whales. I’m saying that all of our whales are currently optimized horizontally to be servicers. Increasing the ProposerAllocation is an easy way to increase the average validator stake by incentivizing these whales to consolidate instead of distribute. The “con” to running a validator is opportunity cost of not using that stake to run extra servicers, increasing ProposerAllocation would flip that opportunity cost on its head.

As for the stipend idea, it seems needlessly complex to append an incentive when we can tweak the protocol incentives.

3 Likes
9

If increased to 5K, the min stake to be a validator would be 15,375+. It looks like the network already has a handful of servicers who have already staked past the recommended amount of ~15050 to ~15100 to optimize on their rewards. I’m not sure why this is the case, but these servicers already have lost that opportunity cost and have everything to gain by being potential block producers - assuming infra cost to run a validator is not too significant. It’s possible we don’t have provide a stipend or tweak anything to see security benefits.

11

I also strongly agree with this.

Increasing the depth of validator stake is a more urgent priority in my mind than increasing the breadth. I also don’t know if 5K is the magical number for how horizontally spread the validators are.

Getting all validators over 100K stake, then increasing the maxvalidator parameter as a two pronged strategy seems like the most secure option as a whole.

12

What’s the 100K number based on?

13

Based on reaching a 10MM pokt level of security of validation.

14

What’s the optimal threshold?

15

I do not believe this issue should have been handled this way. I heard about this vulnerability at InfraCon and from core-team members directly. This was already on their radar and from my understanding and research was already underway so as to not expose it to the public without a solution in place.

These kinds of sensitive issues should be handled in strategic manner before making them public. While there is a place to have public discussions about issues, it is absolutely in the best interest of the protocol to NOT use public forums to break news about an exploitable vulnerability without an in-place solutions that devs have sanctioned as safe.

As a POKT owner, I would much rather have perceived vulnerability handled in a strategic manner that does not in a public manner that invites attach. I am perfectly fine with not having a vulnerability public if the core-team is on the case and is researching solutions. As a DAO voter, I would easily vote for a community standard that DAO members should first go to the core-team before going to the public. This is a very dangerous precedent to set.

@addison while I believe your motives where genuine, I would ask that in the future that vulnerabilities first be discussed with the core-team. This issue was already being discussed in a tactful ways that would protect the ecosystem, and going public on your own, like this, is dangerous.

As a DAO, I feel we should formalize a process where vulnerabilities are first to be discussed with the core-team before posting to public forum and social media.

P.S. I do want to say that, though I disagree with how this validator attach vector was disclosed, I do appreciate the proposal and research itself. I think the quality of the proposal is top notch and your solution is well thought out. Props for the work you did :+1:

1 Like
16

Since cat is out of the bag now, solution wise, I lean with @JackALaing that increasing the block producer share of the reward would incentivize a more secure network while not adding validation bloat (which is incurred when changing the validation from 1k to 5k).

I feel what is important to understand is that this just a v0 issue so any solution now is really just temporary. From what I see now, increasing the number of validators doesn’t decrease the number nodes on the network or incentive larger amounts of POKT to be locked up.

I’m open to being convinced otherwise, but increasing block rewards consolidates the number of nodes on the network, while creating a race to the top incentive for larger POKT holder, resulting in more POKT being locked up. Node consolidation and more POKT being locked up and both positives for the network as a whole.

1 Like
17

@pierre I appreciate the work you do and the research you are involved with, and I want to encourage you to keep at it. I would ask that you please see my comment above about my concern with discussing vulnerabilities publicly before discussing with the core-team.

If a vulnerability requires DAO involvement, I would ask that public disclosures be done in tandem with the core-team. I believe we need to establish a community culture where we work with the core-team doing the development. I know that for myself, I will share issues directly with them before talking about them publicly.

I feel that is not only safer for the ecosystem, but it also encourage collaboration between the core-team and contributors. Please take into consideration going to the core-team first about exploitable issues.

2 Likes
18

I strongly support this proposal along with increasing the validator rewards to make it happen like @JackALaing is suggesting. I also agree with @shane that a formal process for reporting potential network vulnerabilities needs to be put in place. But regardless, I appreciate @addison taking the initiative here.

5 Likes
19

Ironic, this entire post you just made could’ve been sent to Addison, not here.

The vulnerabilities brought into this proposals are properties of a BFT/Tendermint based blockchain. Getting 1/3’s or 2/3’s power voting power is textbook vulnerabilities that’s been outlined since the dawn of time. Let’s be glad that an involved community member brought up this proposal and potential solutions rather some FUD/shit poster. One of the bigger complaints we have is that there’s too many behind the scenes conversations. We are a decentralized community and have to act as one. Someone has put forth a problem and kickstarted us off, now let’s work together to get it solved.

2 Likes
20

I appreciate where you are coming from @poktblade.

I did message him about why I feel it’s important to talk publicly about how disclosures should be handled. @addison has posted many forum posts and he’s a quality contributor on every level. I’ve been supportive of his initiatives before, so I hope that my criticism here isn’t taken in bad faith.

We haven’t established a community process before for disclosing attach vectors. Community processes are a public matter, so in this case it does feel appropriate to state my concerns here. The proposal itself was great, I’m just concerned with established a disclosure process for the future.

I am glad indeed. I’m just hoping to encourage a process of disclosures that encourages further cooperation with the core-team.

I feel that standardizing a process of first consulting with the core-team about potential vulnerabilities doesn’t mitigate the idea of decentralization. Communities require processes, and I believe it is in the best interest of the community have a defined processes if there is potential exploit. Right now, a simple DM to @JackALaing could be process enough IMO while we are still small.

Agreed. Though I was aware of the mechanics, I personally wasn’t aware of the numbers until InfraCon. I’d still prefer that all perceived vulnerabilities be disclosed in cooperation with the core-team who are closer to the network’s development. I personally feel that it mitigates risk to work with the core-team.

1 Like
21

Having a process is fine, but people have no obligation to follow it. Maybe establishing a bounty program for the disclosure of security vulnerabilities would incentivize reporting of those issues in an organized manner and following an established process.

5 Likes