Increase MaximumChains to expand node servicing capabilities

Attributes

  • Author(s): @beezy
  • Parameter: Maximum Chains
  • Current Value: 15
  • New Value: 30

Summary

Currently , the maximum amount of chains a node is allowed to stake for servicing is limited to 15. This causes the operator to have to pick and choose the chains they will support usually based upon the ones that have been getting the most relays.

In order to help facilitate the teams goal of 100 chains by the end of 2023, each servicer will need to be able to support new chains as they are onboarded. I propose increasing the MaximumChains parameter to 30 (arbitrary wanted to open to discussion on the optimal setting for this to ensure steady growth and service availability to new chain partnerships). Increasing this will help keep idle nodes busy, move towards the goal of onboarding more chains and allow increased flexibility to node runners.

Abstract

The MaximumChains parameter is pretty straightforward and is defined as The amount of chains a node can be configured for in one stake.

Motivation

While adding backends supporting Moonriver and Moonbeam earlier this week; I also added BSC backends for our nodes. Today when trying to stake BSC; I received the error “Too Many Chains” thus having to remove Goerli from our stake list and adding BSC.

With rewards and relays decreasing due to market conditions, WAGMI and other factors I chose to stake BSC in place of Goerli due to the ever increasing relay count for the chain in comparison to Goerli. Also because I had to in order to support more chains.

Rationale

I chose double the default value as a starting point and to open discussion on what this should be configured to. I think 30 will help give people more options of investigating, deploying and staking new chains on the network for a few months and it can be revisited as Triforce and general demand continue to grow. This proposal will benefit more engaged runners that are looking to diversify their servicing portfolio and aligns the incentive more towards providing diverse relay infrastructure rather than stacking pocket nodes.

There are currently 5941 staked nodes servicing less than 10 chains, 8949 servicing less than 13 chains and 22448 currently at 15 MaximumChains staked.

Dissenting Opinions

1.) We are trying to reduce overall infrastructure costs for node runners now and this is the opposite of our near term goals.

  • Yes. This would increase costs of node runners as they scale into new chains and technologies. It will also give them they ability to directly weigh the cost vs benefit of supporting different chains., Thus replacing other chains they no longer wish to support on existing hardware. While short term it will increase node runners cost(voluntarily by adding more chains) in the long term it aligns with the teams goals.

2.) This proposal exaggerates the economies of scale that larger node providers enjoy.

  • While this could increase cost of larger node providers; it would be their own decision whether it was economically viable to expand their current relay offerings. This could also allow smaller runners a better chance to pick up more relays to stay competitive and diversify. Providers and runners do not have to stake more than 15 chains, this would just give them the option to.

Analyst(s)

N / A

Copyright

Copyright and related rights waived via CC0.

4 Likes

I support this proposal

2 Likes

I’d love to hear @luyzdeleon 's opinion on the additional load per servicer, but I support this proposal in theory.

3 Likes

I support this proposal

1 Like

I support this proposal. Based on the research I’ve done, it seems like 15 is a soft limit rather than a hard one. I also would like to add that if the goal is to have 100 whitelisted chains by year-end and to reduce node counts by implementing either
PUP-17 or PUP-15; one can argue this proposal is essential.

3 Likes

I support this proposal 100%.

2 Likes

I know this idea is very popular among node runners with 100+ nodes and - if put to a vote - will likely pass for exactly that reason. Nonetheless, I’ll take this opportunity to document my opposition and rational.

The example which the OP cites is exactly how the system is supposed to work.

Large providers (like myself) can pay the cost of a single backend server and throw thousands of front end nodes onto these small chains. The cost per node is minimal. Smaller runners who still have plenty of available space in their allocation would be able to make a profit off of those chains if the big boys didn’t crush the returns.

2 Likes

I support this proposal

Thank you putting the time of putting together this proposal.

I would like to start with the fact that my comments are neither in favor or against this proposal, they are merely a recollection of information from my understanding of the current implementation of the network and how if this proposal were to pass, it would impact node runners in their operations. I also would like to clarify that I analyzed this proposal from the standpoint that only the Nodes maximum chains would be increased, not the application’s.

The first observation is that this proposal would increase 28.55133 mb every block to the node’s application state, which sums up to 2.4gb of application state every day if every node in the network (37,322 according to POKTscan) decides to stake for 30 chains at it’s maximum. This would accelerate state growth significantly, which increases costs for node runners. One caveat to this observation would be our upcoming release of Persistence Replacement which would alleviate some of this burden, but we would have to measure again to see the impact.

In addition to that Pocket Core buckets nodes per chain in order to speed up access during session generation, if we were to double the amount of chains, we would be doubling these buckets in memory which would increase the software memory consumption, as well as processing times for session generation, which affects quality of service for apps and block processing for both validator and service nodes.

The team is trying to create mechanisms to educate the community on the broader impact of parameter changes and create tools to gather such information beforehand, I would like to open up the possibility of starting a dialogue in our #core-research channel in Discord to further discuss the impact of this change before making a final decision on this proposal.

5 Likes

@luyzdeleon , wanted to circle back to this. Any more thoughts on supporting more than 15 chains per node ?

I support this proposal. There is currently work being done to decrease maxchains to 1. I can thinmk of a few ways this actually works against individual node runners and service providers and the decentralization of the POKT protocol.

Decreasing max chains to 1:

Removes wealth from the ecosystem. No longer can an individual node runner offer up their chain or chains to the community as all 14 would be removed leaving no need for it. Nobody is going to need to get endpoints from other node runners and service providers in the community removing all that wealth opportunity and if they do then that need is decreased over ~90%. So expect the market for this stuff to crash the day it takes effect.

It is centralization by nature. If the rewards are distributed like they say it would be where all nodes get the same amount of POKT regardless it removes incentives from staking new nodes that just hit the chains list. It also destabilizes the network that provides 50+ chains and it would probably not do anything for the over provision of certain chains. They would still be over provisioned. The market already solves the issue of over provisioned chains by giving incentives to stake higher earning rare chains which we saw in the last few days where a few thousand nodes switched over to Kava archival because it earns more and I’m assuming they left Arbitrum because Arbitrum jumped up in rewards whil Kava Archival decreased.

We should be increasing the max chains limit not decreasing or just leave it at 15. Everyone needs to revisit this because they are implementing the change in the next release. I am just going to say no for the reasons above. I have seen all the reasons people have used to reduce max chains to 1 and I still do not approve of it.

3 Likes

Not sure if I understand this correctly, but the fact that node runners are getting endpoints from other node runners is bad for decentralization. This only artificially grows the number of nodes staked to a chain when in fact there is only a single node runner with the actual blockchain.

This same behavior is expected with max chains = 1. In fact, I expect it to be incentivized, as you will be forced to diversify as a big node runner. Less chains means more pressure to conciliate number of staked nodes in a chain with the total traffic in the chain.

3 Likes

There are a few misconceptions in your comment if I understand it correctly.

Backend infrastructure sharing, while I support it since it could reduce the infrastructure costs of the entire network, as @RawthiL already alluded to, can produce the opposite effect of decentralization. We, the DAO, cannot make decisions for the network depending on what’s best for a single individual’s strategy or a node provider.

With the maxchains parameter set to 1, in theory, it could open the door for existing node runners from other communities to stake POKT and join our community. If that does happen, it would further decentralize the network while keep cost relative low, which is what we want. We need the Pocket Network to be supported by existing node runners whose primary source of income is not POKT. What you are describing does the opposite of that.

Do you happen to have any data to back up this claim?

There currently isn’t a proposal to reduce the maxchains value. However, there is a proposal to merge a PR that would make it possible to enforce the usage of the parameter.

2 Likes