V1 -- How to Enforce Fairness and Decentralization: A first approach

Edits:

  • 2023-03-10 : Grammar and writing corrections by @zaatar (Thanks!!!)
  • 2023-03-17 : Even more grammar and writing corrections by @zaatar (Thanks, again)

Authors:

Introduction

Three topics that have been discussed several times in the Pocket Network ecosystem are the survival of small node-runners, the real decentralization of the Pocket Network and chain-region incentives (to promote the staking of nodes in a given region or chain).

These topics are closely intertwined since small node-runners are one of the major sources of decentralization of the network, and incentives should drive decentralization.

Currently in the V0 version of the Pocket Network, a Pocket Node can be staked for many chains at the same time (up to 15) and can work in any available gateway. In addition, there are no incentives to stake for specific chains or regions.

In V1 the staking of Pocket Nodes will change. Currently it is expected that a Pocket Node will be able to stake for many chains at the same time (as in V0), but recently a change was introduced to V1 specifications whereby a Pocket Node would be restricted to a single region. Also, the incentives for chains and regions are to be controlled by the Application volume on each [chain, region/geozone] pair. This approach is not ideal for several reasons. We want to open up this discussion to the community.

Restriction on staked GeoZones but not on staked Chains

The logic behind the restriction of GeoZones to one was to promote decentralization and encourage node runners to deploy blockchain nodes in each region that they wish to serve, thereby increasing the distribution and resilience of the service. However, this restriction will not produce the desired result. This is because there is no way to audit a node location (nor should there be). Nodes are permissionless; there is no way to know how a node-runner connects their Pocket Nodes to blockchain nodes. The only thing that matters is QoS, which is agnostic of node location. Therefore, one can have a single piece of hardware with many nodes serving more than one location. This is why we think that the current justification for single GeoZone staking is incorrect.

A real effect of single GeoZone staking was pointed out by @shane. He argues that this restriction would help small node-runners who lack the scale to deploy blockchain infrastructure in many locations, which disadvantages them vis-a-vis big node-running companies. This is true: restricting GeoZone staking to one region will dilute the relative power of big node-runners. However, this same argument can - and must - be used against the multi-chain staking that exists today and is expected to continue in V1. A small node-runner cannot compete against a large node-runner who can spread the cost of blockchain nodes by scale of operation. This is something we must consider if we want to capture the decentralization power of many devs who run single blockchain servers for other applications (something mentioned many times by @vitally). Currently, with staked POKT producing higher returns for big node-runners due to economies of scale, there is no reason why anyone would stake POKT for a single chain and region.

The current proposed V1 landscape, with multi-chain and single-GeoZone staking, seems to be arbitrary and should be changed, either to allow multi-chain and multi-GeoZone staking, or single-chain and single-GeoZone staking. The current specification will have the following effects:

  1. Drop of yield per POKT staked: 15 k POKT will produce 70% less rewards than in V0.

  2. Increase in staked nodes. To cover all the main regions, the number of nodes will have to increase by about 5x (or by the number of principal GeoZones implemented). More staked POKT for performing the same amount of work.

  3. Partial improvement of small node-runners’ finances, but not as good as possible. Single-chain node runners will be largely out-performed by multi-chain node runners.

Decentralization Mechanisms for Node-Runners

V1 has no on-chain metric that makes it possible to monitor, and thereby enforce, node-runner decentralization. The only process intended to induce node runner decentralization is the single-GeoZone staking, but as explained above, it’s ineffective. We believe that it is impossible to control centralization of node-runners’ operations using on-chain data on a permissionless network such as Pocket. The only way to produce decentralization is to level the playing field for small node-runners. While economies of scale will always benefit large entities, the Pocket Network should do all it can to reduce the benefits of economies of scale for large node-runners. The limit of single-GeoZone staking is a move in the right direction, but by itself, not enough.

Chain and Region/GeoZones Incentives

In V1 the chains and GeoZone incentives are to be controlled by means of the Application volume in each of the [chain, GeoZone] pairs. As a result, regions generate rewards based on their traffic, which has some drawbacks:

  1. The minting process of the network is more complex. If the minting per block of the network is to be controlled, it would require leveraging all the traffic in all applications, as opposed to the current model where only the Relays-To-Token Multiplier is modified to control the amount of POKT minted per day.

  2. Nothing forces node runners into new zones and out of crowded ones. If one of the goals of the Pocket Network is to be decentralized we should incentivize not only the opening of nodes in new regions, but also the forcing of nodes out of crowded zones. Such a mechanism would encourage a lower total staked POKT (all servicers) per region - which some have said is desirable.

Below we describe two different approaches to this problem, one keeping the multi-chain multi-region nodes and the other going to a single-chain single-region.


Staking Restrictions Effects

Multi-Chain Multi-Region

This is the simplest approach in terms of transition from V0. Nothing changes for the node runner except the need to stake in all the regions that the node runner desires.

Without any further action, the same fairness and decentralization problems from V0 are carried over to V1. Only some unfair rewarding of bad nodes (poor QoS) is eliminated by the new fishermen mechanics.

We are still trying to come up with an on-chain metric that favors nodes staked into single regions and chains over multi-chain and multi-GeoZone nodes. So far we’ve not been able to find a way to do this, and are open to suggestions. What we do know is that a per-node parameter/multiplier should be created since this won’t interfere with GeoZone/chain incentives.

Advantages:

  1. No friction between V0 and V1 for node runners.
  2. Number of nodes in the network should remain constant.

Possible drawbacks:

  1. We would have to come up with a model to penalize nodes in multiple chains and regions and reward single chain/GeoZone nodes.
  2. Modulating per-node rewards can be difficult for the community to accept.

Single-Chain Single-Region

Following the logic of restricting the stake of a Pocket Node to a single region/GeoZone, the only logical path to follow is to also restrict chain staking to a single one. This creates the scenario where a Pocket Node represents a given chain in a given region. This is interesting as it simplifies the tracking of the nodes’ QoS on chain. Currently, in V0, QoS is already measured by chain and gateway; restricting nodes to single chain and region would therefore be natural from a metrics point of view.

On the other hand, restricting nodes from 15 chains to 1 and from 20 gateways to 1 would create significant pressure on node runners, as the expected return of POKT per POKT staked will fall considerably. Each POKT staked will yield less POKT. Just to give some context, in V0 a single Pocket Node staked with GeoMesh and 15 chains receives only around ~10% of its income from a single chain and single location (for top chains and locations). Also ~80% off all income of a high QoS node comes from the top 6 chains, meaning that many other chains are mostly unprofitable. This means that in this case, the minimum staked should be modified greatly to compensate. We can’t give exact numbers here, as this is only a proposal meant to open up debate. But in this scenario we would expect the MinStake to be reduced to ~1000 POKT (only to approximate the reduction impact). Nevertheless, this reduction will benefit the small node-runners who were staking 15K POKT in a single region and chain, now that their relative selection probability is increased with respect to large node-runners who will try to diversify their nodes to reduce income variability.

Advantages:

  1. Small node runners will see a clear improvement in the probability of entering a session compared with large node-runners.
  2. Node metrics are easier to visualize as a node will not have multiple sets of metrics.
  3. Given the same QoS and chain, there will be no difference between small and large node-runners in POKT yield per POKT staked.

Possible drawbacks:

  1. Large friction from V0 to V1.
  2. Base node-stake should be modified to keep POKT returns per POKT invested similar pre- and post V1.
  3. Number of nodes will dramatically increase - can V1 hold a 75x number of nodes? (required to keep status quo).
  4. Support of some chains and GeoZones might be reduced with the result that apps using them would experience poorer quality of service (due to likelihood that the Pocket nodes that continue to service those chains and GeoZones would have lower QoS).

Decentralization and Chain/GeoZone Incentives

Whether we choose to stick to multi-Chain/multi-GeoZone or single-Chain/single-GeoZone staking, it is critical to create incentives for the staking of new Pocket Nodes (and hopefully the underlying blockchain servers) in each location and chain. A mechanism should be created to encourage decentralization. Moreover we should try to set this as an on-chain mechanism to avoid having to discuss how and why we should benefit one region over another. To this end we need to measure and maximize the Pocket Network entropy, which is a fancy way of saying how distributed the nodes are in the network.
In a perfect Pocket Network the amount of Pocket Nodes per Relays (Application volume) would be constant for all chains and regions. We can think of this as a probability distribution; we want it to be as uniform as possible. This means that the p_{g,c} of the distribution of nodes per relay by GeoZone and Chain should be the same for all GeoZones and Chains:

imagen

where N_{g,c} and R_{g,c} are the number of nodes and relays in a given GeoZone “g” and chain “r” respectively. Then the calculation of the maximum system entropy is:

where “G” and “C” are the total number of GeoZones and chains respectively.

Now, using this value as a target, we can obtain an Incentive Multiplier (IM) for each chain following:

imagen

This would provide a way to calculate IM based on on-chain parameters. This is an equalization incentive that is agnostic of the distribution of relays. Further incentives can be applied on top of this if needed (i.e., to incentive archival nodes). Moreover, these IM_{r,c} values can be scaled and multiplied to a global RTTM which controls total emissions. This way we can re-use SER or WAGMI mechanisms after V1 without having to come up with a new inflation control mechanism.

Now with drawings YAY!!!

We created a metric that guides the weighting of chains. Suppose that we have 3 different scenarios:

  1. Overprovisioned: a given [Chain, GeoZone] with too few relays per node (many node runners in the same place)
  2. Balanced: the same number of relays per node (what we want to achieve)
  3. Underprovisioned: too many relays per node (we want more nodes here as we have lower decentralization)

This can be illustrated with the following distributions:

Notice that we only modified a single [Chain, GeoZone] for simplicity; from left to right these are the cases described before. If we apply the equation that we described before we would obtain the following multipliers:

The picture shows several cases, but we added three markers representing the cases of the distribution shown before. The red one is the overprovisioned case, where we apply a <1.0 multiplier to penalize nodes and kick them out. The green one, that is, the uniform distribution, that is above the black line representing the maximum entropy, corresponds to a multiplier of 1.0. This means that if all regions have the same amount of relays per node, no incentive or penalization is applied. Lastly, the yellow marker represents the underprovisioned case. Here we need more nodes to join this [Chain, GeoZone] and we will pay them more using a multiplier of >1.0 until the system reaches equilibrium.

Stake Weighting

It is unclear whether stake weighting will continue to exist in V1. The docs provide as follows:

Each Servicer’s reward is scaled proportionally to both their stake and their ReportCard.

This suggests that stake weighting will exist in V1. However, stake weighting will not serve Pocket Network’s decentralization objectives or reduce the costs of the network:

  1. Pocket V1 should have mechanisms such as LeanPOKT. The cost of the Pocket node should not be important, otherwise V1 would be a step backwards from V0 in terms of network cost. In this scenario stake weighting does not reduce network costs (same as today in V0). If node runners want to earn more with the same infrastructure, they can spin up a new Pocket Node with their existing hardware without additional costs.
  2. The number of nodes should not be a problem in V1 (or so we heard…).
  3. Adds an unnecessary layer of complexity to staking. Without stake weighting, per node earnings should be simpler to calculate, making it easier for new participants to know how much they would earn.
  4. It does not advance decentralization objectives as it does not require node runners to increase their stake before staking a new node. On the other hand, if no stake weighting is allowed, staking additional nodes in the same [chain, GeoZone] will negatively impact rewards, pushing new nodes to other chains/GeoZones. This means that you cannot freely earn more POKT if you don’t at least provide entropy to the system.

Personal Conclusions

In my view (I don’t speak for POKTscan), the best scenario would be:

  1. Single-Chain / Single-GeoZone Staking
  2. On-chain entropy controls to enforce even distribution of Relays per Node on each [Chain, GeoZone] pair.
  3. No stake weighting as it provides no benefit to the V1 Pocket Network.
4 Likes

Man, @RawthiL why you always gotta make my head hurt?

Working on understanding the math here, but would like more clarification on this:

My understanding early on was that reward by relay volume was being replaced by the QoS metric. How does your statement relate to that?

1 Like

Yes, but the mechanism is not clear (to me) are they going to increase the RTTM (or UsageToRewardCoefficient)?
If you serve only a single region today you will work on ~30% of the total traffic, so given the same RTTM after V1 hits, your rewards will drop (outside any QoS measurement changes). It is true that also the number of nodes you are competing with will drop too, but does this compensate? I think not since there is no enforcing of equal node distribution by chain and GeoZone.
Anyway, now I think that maybe 30% is a worst case scenario. Its hard to say how much your rewards will drop but surely they will drop.

2 Likes

Agreed. Last node runners community call discussed multi-region’s negative effect on independent node runners, and in prior node runner calls, the negative effect of multi-chain has been discussed in depth. Credit to @BenVan for originally arguing this point back in the summer (at least that is where I first heard the economics explained).

V1 is supposed to have this feature where multiple “nodes” use the same blockchain storage. Check out: Persistence - Pocket Network

Completely agree. PIP-22 made POKT significantly more complex since each relay on the network is not worth the same amount of POKT… but is valued compared to whoever sent it.

A relay should equal the same POKT regardless of who sent it. That makes the ecosystem easy to understand, easy to develop for, and treats all work the same. Adding undue complexity makes no sense, so I fully agree with @RawthiL’s arguments here that V1 already addresses resource waste of multiple nodes.

By requiring someone to run more nodes vs beef up a single node, then those with more stake end up serving more relays on the network, which is how it should be. The more POKT you stake the more work you have to do. Right now, a node at 15k gets 1/4 the reward for the same work as a node staked at 60k. RPCs will become a commodity in the web3 space, so POKT should lead the industry by making the cost of an RPC measurable, and a weighted stake system make that impossible.

Overall, great work POKTscan for putting all this together in a single place :+1:

3 Likes

Some initial thoughts:

  1. Re Stake-weighted rewards, I empathize with the sentiments expressed above, especially that which @shane mentions re the desire to have all relays be worth the same amount of POKT . Seeing that this concept has been part of v1 spec for longer than I’ve been involved in the project, I strongly suggest that it be coded as its been spec’d and its usage or not be decided by governance action rather than to go in and scrub it from the code.

  2. That being said, I do not fully understand v1 reward structure yet, but as I understand it, the idea of directly coupling the work done by a node to the POKT received by a node the way it is done in v0 is completely thrown out the window in v1 in favor of pooled rewards. Meaning two nodes with identical QoS scores would get equal share of the rewards available in a pool even if one of the two served 2x or 3x or nx as many relays during the pay-out time period as the other node (say as a result of randomness)

  3. Getting rid of stake-weighted rewards, limiting or not limiting regions per node and/or chains-per node does absolutely nothing toward the overall stated goal of decentralization and giving small node runners ability to compete with large node runners so long as there are other mechanisms that remain that allow a chain node backed by deep pockets to gain rewards proportional to POKT staked - whether by persistence, a V1 version of LeanPocket, or something else. If the goal really is to decentralize and prop up small node runners, all such mechanisms will need to be shut down - e.g., enforcing at a protocol level a 1:1 (or 1:n) correspondence between a POKT node and chain node.

  4. Re setting minStake=1000 (as an example) in conjunction with making nodes single-chain/single-region as a method to keep approximate continuity to v0 in reward per POKT stake is entirely doable and a decent idea to be explored further. There is nothing sacrosanct about minStake=15k.

  5. Re chain/Geozone incentives, another dimension that should probably added to the discussion is the cost to service. Some chains or some regions are more expensive to service than others. Or is this automatically accounted for using the “maximize entropy” methodology? (Great methodology idea, by the way!)

  6. I am not sure yet how I feel about the over-arching idea that decentralization and/or equality between small and large node runners should be enforced much less be a top-level consideration. At what cost would these goals be achieved? What good is a perfectly decentralized, small-node-runner-dominated network if the whole project dies because it is not cost-effective compared to the competition. The efficiency and economy of scale that large node-runners bring to the table may be exactly what is needed to make this project successful. Perhaps spreading service among a dozen top providers, a couple dozen niche players and the rise of the class of provider’s mentioned by Vitaly** is all the decentralization that is needed.

  7. I concur with the following quote. For the moment, this would be done off-chain (via instructions given to PNF on parameter settings), but it would be nice to have something like a global RTTM added to the v1 protocol so that this one single parameter could be actively managed with all the per-chain/per-geozone reward settings becoming percentage based to slice up this global reward pie. We can (1) leave v1 spec as is and add this on-chain functionality down the road via a PIP or (2) make a PR to add this to initial release of V1… would love to get input esp from the v1 dev team.

** dAPPs who run a chain anyway for their own purpose and couples it to a POKT node at negligble extra cost for side income stream

1 Like

Re-StakeWieighting, I also do not fully understand the V1 minting mechanism and I don’t know why stake weighting was already there… Maybe someone from PNI can give us some insight later…

I think that matching 1:1 or 1:n Pocket Nodes to Blockchain nodes (real physical independent nodes) is not technically possible in a permissionless network such as Pocket. (I would love to be proved wrong since this will be what we need)

The entropy cannot fix this as this is the effect of off-chain variables (such as real world price of hardware and data). To fix this we would need to add a human (or DAO) in the loop to identify and set incentives for these special cases.
The entropy will only de-couple the incentive of equal servicers distribution from any other kind of incentives, such by-region or by-chain (i.e. archival nodes) specifics.

This is focused for small node runners such as the “dApps” mentioned by vitally. Right now this “dApps” node-runners earn 10% POKT by POKT invested compared to full Pocker node-runners. They have zero costs on hardware as they run their node for other reasons (zero sell pressure). We need to make things easy and appealing for them. In return we will have better decentralization figures at (almost) no added cost.

This will not be that much affected, scale will always be an advantage. I don’t see these changes as deadly wound to large providers.

My hope is that we can change V1 protocol. We are on time to shape it I think. It wont feel clean to be thinking on patches before even V1 is launched… But yes, we need to wait for the team on this, I think they will drop by here after Eth-Denver.

1 Like

This would have been straight forward to do in v0 as it could have been enforced by the portal. Will have to rethink it for the v1 architecture. For v0, enforcement would be at the new stake/change stake level, where each chain association is done not with a chain number (eg “42” but by a unique chain ID (e.g., 42xxxxxxx). A database keeps track of all chain IDs. If an new/change stake command is received with a chainID that is already in the database, the new/change ID fails. When a POKT node unstakes, the associated chain IDs are removed from the database. The question becomes: how would this concept carry forward into v1?

I’m not sure? Is it not possible an entropy metric could catch and incentivize balancing for different costs? Imagine chain A and chain B have same volume of traffic but chain B is twice as expensive to operate. Uniform rewards would lead to natural preference of providers to service chain A over B leading to non-maximized entropy. Without any knowledge of root cause for the mismatch, but only responding to there being a mismatch, rewards for chain B would be boosted to achieve maximum entropy. Am I missing something?

What does “this” refer to in this sentence? The entire research thread? Or narrowly responding something I said in the text you qoute?

I concur with respect to coding a single global reward level with per-chain/zone values that denote a percentage of the global value. I am not sure I concur with resect to making a code-level decision to eliminate stake-weighted rewards without first achieving DAO governance input. Let’s see if we can get dev team input after Eth-Denver

1 Like

There is no way to know if the node runner is actually spinning-up a new chain or s/he is only redirecting traffic to a shared node in the back-end. You will lots of chains codes (42xxxxxxx, 42xxxxxxy, 42xxxxxxz, … 42xxxxxxn) but all will be pointing to the same infrastructure. I don’t see how this solves the problem.

Yes this is possible, but you need the external information that you mentioned, you need to know which one is “twice as expensive to operate” (or any other particularities). Surely this can be added before entropy maximization and optimize the weighted system.

When I was referring to “de-coupling” is that there are two things that must be balanced:

  1. Cost of running a given pair of [chain, location]
  2. Service availability and descentralization, which must be equal for all chains/regions

The first problem is measurable in needed hardware and results in a fixed value. The DAO would be able to discuss this and set the correct incentive.

The second one is more relative and temporary, as setting an incentive changes the network distribution and then the incentive must be adjusted. The entropy avoids this last discussion.

I was referring to the research as a whole plus my personal opinion of setting the staking to single-chain and single-geozone.
This will level the return of POKT per POKT invested (before costs and scale) of “dApp” runners and “pocket only” node runners (who currently stake 15 chains and ~5 regions).

1 Like

You are right. Back to the drawing board.

1 Like

Entering this thread with humility. Not my comfort zone, so please bear with me if I overstep.

How do you empirically arrive at what’s over-provisioned, balanced and under?

I think I have asked you this question on a separate thread.

I know that a Pocket equivalent doesn’t exist yet. Is there anything else in this space or maybe elsewhere that can provide some benchmarks?

I have been thinking about the method to arrive at $POKT’s demand- emissions equilibrium with respect to our working group and my upcoming research blog, and I get stuck at the following to know what demand is-

a) what’s the optimum number of nodes needed to meet the quality and decentralisation standards
b) what are those standards
c) how did we arrive that those standards

I feel finding the number of validators needed is a relatively easier question because there is some benchmarking available for general security standards.

Also, another thought-

Has there been any conversation about the DAO dynamically covering (through funding or subsidies) for the gap in minimum standards of decentralisation (predefined) for the network VS the actual in the network, whenever the actual falls below the minimum standard?

The DAO’s share of emissions could increase under those special conditions.

I have no idea how technically possible or impossible this is to execute but from a network design and efficiency (and therefore quality) perspective, this might make some sense.

Because now we don’t have to put decentralisation/small node runners at the centre stage and inadvertently push other metrics (or priorities) to the backstage, that may be equally or even more important to the end user.

Decentralisation is a metric that we would want to support. It has cost and tradeoffs. First we need to know what decentralisation means to us, the market/end users; which is what I think we are trying to achieve through this research post.

Lastly and related- this place is inundated with node runners (love you all). Therefore it’s natural to have sentiments and opinions sway in one direction.

I would humbly urge us to keep the market realities (or the space), protocol and the enduser in mind in such discussions. Because there could be natural conflicts and tradeoffs.

Sorry for any ignorant comments.

Thanks for reading.

3 Likes

Thanks for joining Caesar,

Here I simply use the ratio of relays to staked nodes: Relays / Nodes.
This is under/over/balanced-provision in terms of traffic only. This is probably the simplest metric that we would want to balance in the network, we want each chain and region to be equally served.

This are open questions I think. As I always say, I think that we cannot control real decentralization, as scale will always favor large node-running entities, the only thing that we can do is remove any extra advantage from the protocol. This is what we are trying to achieve.
Regarding the standards, its an interesting point. We don’t actually know, we have some ideas, like response times below a given threshold, success rates above an other, etc. App user are the ones that could tell us better. Anyway, whatever those standards are, if they can be measured (like QoS), they could be bake in into a metric that reflect how the standards are meet among all chains and normalized afterwards. This would work like compensating the cost of a blockchain/location.

I think not, but also the DAO should not be interfering in the node running IMO, it should only create the conditions to allow fair competition and promote decentralization. Also, the amount of decentralization that the DAO can provide to the network will be really low, as it will only count as a single independent node runner.

I think that this two concepts do not collide. Here we are proposing incentives (sort of) for small node runners to favor decentralization. This also means more nodes in chains that have less traffic (this is actually a problem raised by an app runner @0xMo0nR3kt3r , for polygon archival).
The other metric that we are observing for App service quality is QoS. This wont change regardless on the incentives of staking nodes in a certain chain or region. So, more nodes means higher decentralization (hopefully) but same QoS enforcement.
Regarding other metrics that we are not currently observing, I cannot say. If those metrics are measurable on chain, we can probably optimize for them, but first we need to know them.

I think that this proposal is not very friendly to large node runners, who are the most vocal ones in the forums. I’m kinda surprised that this thread has remained calm so far hahaha

I don’t know why you exactly say this, do you think that this proposal is counter-market for some reason?
Maybe is counter centralization, which can be argued that can bring higher network costs, but is also pro “dApp”-node runners, wich will bring nodes into the system at almost no added costs. I would not say that this will impact the market in any meaningful way.

1 Like

Sorry I missed the following, thanks

I actually didn’t mean DAO running nodes. I meant the DAO subsidising a certain set of small node runners (picked based on some criteria) to keep them afloat (who would otherwise have to shut shop) so that the minimum level of decentralisation (which is yet to be defined) is maintained in the network.

That would allow consolidation (in favour of large node runners) that could also drive efficiencies and at the same time always maintain the minimum level of decentralisation (pre-determined) in the network.

Please ignore if this abstract idea doesn’t make any sense.

Not at all, I am not in an attack mode haha!!

You somewhat answered it yourself here as far as considering the likes/dislikes of end users is concerned-

Not everything is positive-sum. Such as high emissions could work for node runners but is considered “cost to the protocol”. App burn could work for the protocol but could also mean dilution of profit for the gateway.

I am just giving examples to make a point, those may be out of scope on this thread.

I am also sensitive to “over fixation” to decentralisation by decentralisation maxies in this space. Therefore I like to use the word “optimum” or even “minimum” and then hopefully work towards it if that is possible.

1 Like

If it cannot be enforced, it can be disincentivized. Not sure yet how to do this in v1 until I understand the architecture better but in v0 allowing unlimited (or reasonably high) stake-weighted servicer selection (e.g., PIP-23) would have eliminated any need or incentive to develop LP or other n:m architecture since chain node utilization becomes the limiting factor (hence no reason or benefit to front-end a chain node with more than one POKT node). It would have made for a much cleaner architecture and much greater transparency as to the actual state of network provisioning. That ship has sailed for v0, but this ought to be looked into for v1

1 Like

As you say with high enough stake weighting on node selection you could achieve a similar behavior as today without the need of so many Pocket Nodes.
However, without a mechanic that enables stake delegation for servicers, users that want to join a node-runner service must delegate their coins to the node-runners (currently you can use non-custodial staking).
Also, if in the ideal case where each node-runner has only one node, the need to populate sessions will make the node runners split their nodes to occupy more slots in a session. I mean (some random numbers), if a session has at leas 10 nodes but only 6 node-runners exists, then any node runner will split their stake to claim one of the vacant 4 positions. Hence, returning to the original problem, no 1:1 Pocket Node to Blockchain Node.

I think that if V1 protocol can resist the number of nodes, then they would work as a fractional stake weight on selection probability (as they work now).

1 Like

Main post updated. Corrected grammar and writing mistakes. No new content.

Thanks @zaatar !!

1 Like

Now that EthDenver has passed and the writing of the initial post has been improved, it would be great to hear what the V1 devs think of this. @Olshansky @deblasis ?

1 Like

Seconding the desire to get some v1 dev thoughts. I’d hate to see this thread fade into the background. This is an important topic.

1 Like

@RawthiL I apologize for the silence.

I’ve read and thought about your post, but haven’t had a chance to really sit and think deeply about it, modelling out different solutions and alternatives.

In fact, I wanted to point out that we did bring it up and created an issue for it (https://github.com/pokt-network/pocket/issues/557) while talking about it with @bryanchriswhite in one of our PRs.

In order to prioritize other work, I don’t think I will have a good answer to this in Q2, and will revisit in Q3. However, it’s worth noting that we’re building V1 in a way that this change would be “trivial” from a code perspective. I’m also not married to either approach but simply want to model out the economics in both cases (similar to like you have above). I know this is work you’re already thinking about or doing, and I would really appreciate if you could incorporate both approaches

tl;dr It’s on my backlog, will revisit in Q3, would appreciate if you consider both approaches in tokenomic modelling you’re already doing.

2 Likes

Hi @Olshansky thanks for commenting.

This PR is posterior to this post. It addresses some part of the stated problem but from the number of returned IPs by node. I don’t know how much decentralization can be enforced, I only see it as a check to restrict multi-region, but again, that does not mean decentralization.

I know it is trivial to change from multi-region / multi-chain to single-region / single-chain or any combination from a code perspective. In fact you changed from multi-region / multi-chain to single-region / multi-chain without making any in depth study.
If an answer to this will come in Q3, we should at least keep the status quo and stick to multi-region / multi-chain. Under any circumstance is the current single-region / multi-chain logical (as we explain above).

We plan in doing so.


Since the PRs seem to be the way of influencing the V1 development, should I create a PR to change the single-region / multi-chain strategy?
As we are not going to get an answer until Q3 and we still have no justification for the single-region / multi-chain scenario, the most logical course of action would be to set the docs back to multi-region / multi-chain.

1 Like

Sounds good.

Regarding the PR, let’s just leave it until Q3. This is an important decision but a very small technical change in the scope of V1 development and is not impacting implementation that much.

Let’s change everything together at once when resolving is a priority.

2 Likes