PIP-34 Fix MaxChains Paramater (FMP)

[RawthiL (Ramiro | POKTscan)]

@shane

@h5law, the DAO voted to fix MaxChains at the protocol level, not hard locked into any specific code to do that. An initial PR was given, but that doesn’t mean code can’t be changed as the the development progresses. The DAO agreed that a fix is desired, so now the protocol and testing teams can implement in the best method. Past proposals have had code changes after a vote was passed, so this is no different.

No, I strongly disagree.
I voted upon an idea and the implementation. The current code does not do what I expect and I would not vote to approve this version.

@h5law

@shane this idea makes sense, instead of enforcing n max chains only consider the first n staked for? At first glance it seems like the current code would be minimal changes to this idea. This check would still be able to go into the validate claims method as well, a claim would only be valid if it was one of the first n chains you are staked for, where n=MaxChains. @msa6867 wdyt?

If we only consider the top N chains then the problem of sessions without nodes can occurs all the same. If a chain is not normally in the top N staked chains it could not have enough nodes all the same.

(This is under the assumption that such thing can happen, something I find unlikely and is easily avoidable with some planning. )

---

• Enforcing at proof or minting level makes no sense.
• Keeping nodes with more than maxChains staked is just bloat.
• We cannot trust lazy node runners to provide high QoS.

I will be as clear as possible here since I feel that we are trying to adapt a simple straightforward change to enable the continuity of a behavior that should not exist after a parameter change.

Keep the protocol simple.

With nodes that can enter sessions that cannot claim-proof:

• We lose visibility of total relays done in the network. Relays go down (apparently).
• We cannot effectively charge the gateways, they get the free relays not the protocol.
• We cannot burn since we cannot prove the relays done.
• We keep lazy node runners on rotations. Lazy node runners are not synonym of good QoS.
• We bloat the sessions with nodes that are staked but are not receiving rewards, why should they keep the staked blockchain alive? The effective number of real nodes by session will go down.
• The number of nodes by chain will not mean anything.
• A bad actor can simply stake 14 chains to small chains just to f**k on the protocol. If these chains are small enough, you will get horrible sessions in all of them. All this because you allow them to stay staked.
• We kick the problem to Shannon upgrade. Wasn’t this all about “slowly update”? are going to code Shannon to allow legacy nodes with 15 chains? To what end?

We must enforce at session level.

The transition period can be handled off-chain, with correct timing. I don’t want to be exotic states just to allow for a one time transition. Exotic states lead to poor understanding of the protocol.

Just some quick ideas:

• Offending nodes can be slashed or force unstaked.
• We can plan the enforcement of the max chain parameter. The same way we do with any other protocol update, we observe the chain data, when we are sure that we have at least 24 nodes on each chain with only one chain staked, we make the change.
• We set the RTTM to zero during the transition period, you will see how fast node runners will get 24 nodes on each chain. Then compensate after the transition by increasing the RTTM.

None of these will have a footprint in the blocks. None of these will require people to be explained how the world was before Shannon and why some nodes have a super power of having 15 chains staked or why we enable them to do relays for free.

[Breezytm]

Seems like a great suggestion @msa6867 . The delivery though, not so much

[msa6867]

yah, I’ll take my lumps

[h5law]

Hey

So the latest commit in the PR has reverted the changes back to enforcing at the session level but not counting the first n chains - if a node is overstaked they cannot join a session.

This is in order to keep the code simple, simple code is clean and easy to understand and we should always push for it.

Given the fact that POKT coordinates all its releases we don’t need to worry so much about the issue of a chain not having any nodes staked for it. If the MaxChains param were to change the DAO can hold off changing the param until enough people have updated their staked chains.

h5law