PUP - 34: GANDALF 2.0 🧙‍♂️ ("Let’s Go Shannon" Proposal 1)

shane · June 12, 2024, 1:32pm

Author(s): @shane
Parameter: MaximumChains
Current Value: 15
New Value: 1 (progressively)

“Let’s Go Shannon” Initiative Summary

Shannon is a major catalyst for network growth, and we want to set up the ecosystem for success. Two areas within Morse that we can improve through parameter changes is making making it possible for new node specialists to joint the POKT ecosystem and incentivizing Sources to partner with Gateway.

“Let’s Go Shannon” puts these in motion by:

Reducing MaxChains from 15 to 1
Increasing DAO rewards to enable Source rewards

These will not only ease the transition to Shannon but also directly benefit the current Morse phase. Let’s not go with the status quo…“Let’s Go Shannon” and embrace the new strategies it will fully unlock.

GANDALF 2.0 Summary

GANDALF 2.0 is about progressively changing MaxChains from it’s current value of 15 to 1. Between the original GANDALF Pre-Proposal, community discussion, and Shannon economic research, we are at a place where we should begin this transition and open the POKT ecosystem up more node specialists from other communities.

Motives

Allows new nodes to join POKT by only running 1 chain, instead of 15.
Enables POKT to be attractive to node specialists from other chains
Allow Gateways to bootstrap new chains with node runners in those existing communities
Reduce the chain infrastructure cost for small to medium node runners
Allow large providers to work out node distribution system
Allow Gateways to optimize QoS in Sessions from new distribution from Suppliers

Abstract

About MaxChains

MaxChains parameter can be seen as “how many chains a POKT node has to run to generate network average”. With it currently set to 15, it means a single POKT node has to run 15 chains for network average rewards. The result is that the only ones who can generate network average rewards are those with significant infrastructure resources.

This doesn’t have to be the case though. By changing MaxChains to 1, anyone can generate network average rewards with a single chain nodes. This starts making POKT more attractive to node runners from other communities, since they can just focus on the chain they specialize in, instead of also having to pay for and run 14 other chains. MaxChains to 1 enables POKT to be significantly more decentralized.

BenVan explained it best:

The Supplier economics of today vs what we want in Shannon:

To evaluate the impact of different MaxChain parameters, you can check out the GANDALF 2.0 spreadsheet. Click on the GANDALF sheet and change A2 to see how node distribution would look across the network when balanced.

Implementation

To help the network find balance with node distribution, this proposal is about enabling PNF to progressively reduce MaxChains with the final goal being 1. This will allow providers to progressively distribute their nodes across the network in an incremental fashion. The initial target steps are 15 → 8 → 3 → 1.

Process:

PNF will provide a node distribution guide to assist providers in finding efficient balance when distributing large number of nodes to fewer chains.
PNF will announce the first date time of the first target step. This announcement will have at least 14 days of notice to allow providers to prepare.
After enacting the change, PNF will evaluate network health and assess if any other coordination with providers is required.
PNF will then announce next date and time of the next target step. This announcement will always provide at least 2 business days for provider to prepare.
Repeat #3 and #4 until MaxChains is set to 1.

This process will enable PNF to assist the ecosystem in the transition itself. Once this process is complete, POKT’s current providers would have become familiar with balancing large number of nodes across different chains, and POKT’s Supplier ecosystem will have more competitive node economics for new node runners.

Dissenting Opinions

We should wait until Shannon for MaxChains to change.

Waiting does not provide a direct benefit to the POKT ecosystem. Keeping MaxChains at 15 prevents growth in the Supplier ecosystem.

Waiting would also increase migration risks during the Morse to Shannon migration. It would be prudent to allow gateways and providers to work on this transition now.

Jinx · June 12, 2024, 1:38pm

After the previous conversation in our ecosystem call, I am strongly in favor of this.

kDas · June 13, 2024, 6:25pm

Strongly in favor!

Breezytm · June 13, 2024, 9:12pm

Did you check with @BenVan on the wording as Tony suggested on the node runner call?

fredt · June 14, 2024, 1:59pm

Does the update to the parameter for max chains on a node also affect the same limitation on an application? Thinking about gigastakes/app management.

shane · June 14, 2024, 3:10pm

If I’m understanding your question properly, the answer should be no. Changing MaxChains does not effect the amount of nodes in an app session.

After we change the parameter to a new target, we want to evaluate with both Suppliers and Gateways to make sure things are in a good place before moving to the next target. Evaluating session performance will be a metric we will want to keep and eye on.

fredt · June 14, 2024, 4:50pm

The question (better phrased) is:

Right now you can stake an application (currently “gigastake” application) for 15 chains just like a node. Does this change to MaxChains on the node also affect the applications?

RawthiL · June 14, 2024, 5:23pm

There is a single parameter for max chains:

github.com

pokt-network/pocket-core/blob/33b28c1eb14b741d2275f6893bd0174741c2cbb8/x/apps/types/params.go#L21


      
          // POS params default values
          const (
          	// DefaultParamspace for params keeper
          	DefaultParamspace                = ModuleName
          	DefaultUnstakingTime             = time.Hour * 24 * 7 * 3
          	DefaultMaxApplications     int64 = math.MaxInt64
          	DefaultMinStake            int64 = 1000000
          	DefaultBaseRelaysPerPOKT   int64 = 100
          	DefaultStabilityAdjustment int64 = 0
          	DefaultParticipationRateOn bool  = false
          	DefaultMaxChains           int64 = 15
          )
          
          // Keys for parameter access
          var (
          	KeyUnstakingTime       = []byte("AppUnstakingTime")
          	KeyMaxApplications     = []byte("MaxApplications")
          	KeyApplicationMinStake = []byte("ApplicationStakeMinimum")
          	BaseRelaysPerPOKT      = []byte("BaseRelaysPerPOKT")
          	StabilityAdjustment    = []byte("StabilityAdjustment")
          	ParticipationRateOn    = []byte("ParticipationRateOn")

github.com

pokt-network/pocket-core/blob/33b28c1eb14b741d2275f6893bd0174741c2cbb8/x/apps/keeper/params.go#L58


      
          }
          
          // MinimumStake - Retrieve minimum stake
          func (k Keeper) MinimumStake(ctx sdk.Ctx) (res int64) {
          	k.Paramstore.Get(ctx, types.KeyApplicationMinStake, &res)
          	return
          }
          
          // MaxChains - Retrieve maximum chains
          func (k Keeper) MaxChains(ctx sdk.Ctx) (res int64) {
          	k.Paramstore.Get(ctx, types.KeyMaximumChains, &res)
          	return
          }
          
          // Get all parameteras as types.Params
          func (k Keeper) GetParams(ctx sdk.Ctx) types.Params {
          	return types.Params{
          		UnstakingTime:       k.UnStakingTime(ctx),
          		MaxApplications:     k.MaxApplications(ctx),
          		AppStakeMin:         k.MinimumStake(ctx),
          		BaseRelaysPerPOKT:   k.BaselineThroughputStakeRate(ctx),

And I think it will only affect apps when staking or re-staking:

github.com

pokt-network/pocket-core/blob/33b28c1eb14b741d2275f6893bd0174741c2cbb8/x/apps/keeper/appStateChanges.go#L48


      
          		)
          	}
          
          	return nil
          }
          
          // ValidateApplicationStaking - Check application before staking
          func (k Keeper) ValidateApplicationStaking(ctx sdk.Ctx, application types.Application, amount sdk.BigInt) sdk.Error {
          	// convert the amount to sdk.Coin
          	coin := sdk.NewCoins(sdk.NewCoin(k.StakeDenom(ctx), amount))
          	if int64(len(application.Chains)) > k.MaxChains(ctx) {
          		return types.ErrTooManyChains(types.ModuleName)
          	}
          	// attempt to get the application from the world state
          	app, found := k.GetApplication(ctx, application.Address)
          	// if the application exists
          	if found {
          		// edit stake in 6.X upgrade
          		if ctx.IsAfterUpgradeHeight() && app.IsStaked() {
          			return k.ValidateEditStake(ctx, app, amount)
          		}

The hard ban of nodes with more chains is done at session generation, i.e. the nodes with more chains will not be selected to serve a session:

github.com

pokt-network/pocket-core/blob/33b28c1eb14b741d2275f6893bd0174741c2cbb8/x/pocketcore/types/session.go#L155


      
          		if _, ok := m[n.String()]; ok {
          			continue
          		}
          		// add the node address to the map
          		m[n.String()] = struct{}{}
          
          		// cross check the node from the `new` or `end` world state
          		node = keeper.Validator(ctx, n)
          		// if not found or jailed or is overstaked to chains
          		if node == nil ||
          			(isEnforceMaxChains && int64(len(node.GetChains())) > nodeMaxChains) ||
          			node.IsJailed() ||
          			!NodeHasChain(chain, node) ||
          			sessionNodes.Contains(node.GetAddress()) {
          			continue
          		}
          		// else add the node to the session
          		sessionNodes[numOfNodes] = n
          		// increment the number of nodesAddrs in the sessionNodes slice
          		numOfNodes++
          		// if maxing out the session count end loop

fredt · June 14, 2024, 5:44pm

Thank you, @RawthiL . This is helpful.

Depending on the timing of these changes, Gateways may have to coordinate closely with the Foundation to ensure that they have ample stakes, as this effectively increases the number of required stakes by each gateway to ensure node diversity in session.

shane · June 20, 2024, 12:09pm

GANDALF 2.0 is up for voting: Snapshot

Rajeevan_Blockwall · June 20, 2024, 12:51pm

Great initiative Shane!

Do you know by how much it can reduce costs for node runners?
Can this be used to strengthen your DePin narrative? At the moment, infra is capital intensive & not very attractive for small players. Will this allow retailers to plug in their devices or a node instance on cloud to potentially service blockchains that might not be hardware intensive?
Can this increase efficiency by reducing latency for a node that is servicing and optimised to a single blockchain?

Thanks for your feedback.

Qspider · June 20, 2024, 1:54pm

Do you know by how much it can reduce costs for node runners?

#1 is incalculable simply because of the hardware requirements and different types of hardware and services. Another way to look at the cost is you are reducing from 15 to 1. So you can use a 15:1 ratio but that is not even good because each chain has different requirements. If you are spending $150,000 on hardware to service 15 chains you would now be spending $10000 to service one. If you are paying $15,000 to rent hardware for 15 chains then you are now paying $1000. This is not accurate though it’s just an example.

Can this be used to strengthen your DePin narrative? At the moment, infra is capital intensive & not very attractive for small players. Will this allow retailers to plug in their devices or a node instance on cloud to potentially service blockchains that might not be hardware intensive?

#2 I believe it can strengthen the DePin narrative simply because it would probably help with QoS and bring on more individual node runners. However, we will have to wait and see in my opinion as too many node runners and too little chains to serve will make it unattractive to stake already unattractive nodes like BSC.

Can this increase efficiency by reducing latency for a node that is servicing and optimised to a single blockchain?

#3 is somewhat unrelated. That all depends on gateways and the amount of nodes to service a chain along with their healthy status. If this Max Chains parameter brings on a significant amount of new node runners then it could very well benefit. However, for many chains there are already too many node runners so the cost benefit ratio is not that great.

It will be interesting to see how all this works. I was against it before mainly because it was too big of a step from 15 to 1 and punished those already invested in POKT to run 15 chains.

shane · June 20, 2024, 3:33pm

Hey @Rajeevan_Blockwall, thanks for the questions @Qspider provided some good info, and here are my thoughts

It depends how big the node runner is. Large providers will likely need to run the same amount of nodes they currently do. Small to medium node runners can likely cut costs significantly. If someone is running a few dozen POKT suppliers they could focus on just a few chains, instead of 15.

I would suspect the small to medium node runners could theoretically cut their chain node costs between 1/5 to 1/10 of what it is today.

It does improve the DePIN narrative IMO. Someone who is running a blockchain node in EU could likely put it on POKT and generate the same reward as someone who staked with a large provider. Their rewards per node will be less then the provider’s (do to geo-meshing), but they don’t have to pay 30% provider fee… so it could level out in some cases.

So this starts making POKT approachable to most folks running a chain node. POKT could really level up it’s DePIN narrative with Shannon, where regional staking could be introduced. That will mean anyone can generate the same reward per node, not just those with substantial hardware in multiple regions.

Most likely not. The network performance will likely be the same it is today.

With Shannon the QoS could improve with POKT nodes staking to specific regions. This would mean that instead of an app getting a single session with 24 global nodes, which they need to identify which is fast for their location, an app would have regional sessions with nodes already in that area.

Shannon is still being developed though, so we can’t say for sure if region staking will be Shannon at launch, but I hope that is where POKT ends up, literally giving POKT the strongest DePIN narrative within DePIN.

Rajeevan_Blockwall · June 25, 2024, 10:29pm

Thanks @shane and @Qspider for your valuable in puts.

I think this is a good step to attract specialist node runners who has expertise on specific blockchains (e.g., Solana). And not requiring them to service chains that are not profitable, especially chains that do not drive much traffic. It is ridiculous to provide the same level of service to a blockchain that drives little to no traffic, compared to one that drives most of the traffic, at the expense of hardware costs and POKTs needed.

Also, this helps a specialist to run more nodes on a single chain as his costs & breakeven is considerably reduced.

In the end it helps in consolidation. I do not believe all 15 chains that Pocket Service now will be winners. Instead this pushes more nodes and decentralisation to the most relay generating blockchains. Whereas underperforming blockchains will find it hard to attract node runners due to less relays. Then it puts the onus on the community whether they want to keep servicing the blockchains they believe in, and will be a true test to the community strength of that project.

But for this to work there is a need align incentives, I hope the most chunk of the POKT rewards will go to the blockchains that drive most of the traffic and to those node runners who service that blockchain. Please confirm if this is the case!

As it stands, and if incentives are aligned, will be supporting this proposal

shane · June 26, 2024, 8:19pm

To clarify, this proposal doesn’t drive rewards to specific chains directly.

What it does do is make it so nodes runners need to balance their nodes across chains, in accordance to the amount of relays on each chain. With MaxChains at 1, node runners that do not balance their nodes across chains will have significant drop in rewards.

With proper balance on the network, it will be easier to identify if chains should be removed. We’ll be looking to identify if any chains should be removed, but it is too soon to say.

At the end of the day, chains with a lot of traffic have a lot of nodes, while chains will less traffic have less nodes. Here is what good balance would be per chain (the last two columns).

I hope this is helpful context