Attributes
- Author(s): @shane
- Implementer(s): PR submitted by @h5law
- Category: Protocol Upgrade
- GitHub: feat: enforce max chains during new session by h5law · Pull Request #1582 · pokt-network/pocket-core · GitHub
Summary
When POKT launched, mainnet had a parameter called “MaxChains”. This parameter was designed so the network could have power over deciding how many chains Servicers could serve.
However, unbeknownst to the designers, it had a flaw, where any changes to MaxChains would only effect new node, and not effect existing stakes. This means that this parameter can not be changed without created two classes of nodes within POKT (new nodes and old nodes), each with different reward possibilities depending on their MaxChains.
This proposal (and the attached code) is simply a fix to the MaxChains Parameter so that it operates as intended for the POKT DAO.
Motivation
This is about fixing MaxChains so POKT isn’t perpetually locked with the current setting. The motive is to allow the parameter to be what it was intended to be.
Specification
MaxChains is fixed by adding a MaxChains check at the beginning of a node’s session. This is when the protocol checks to make sure a node qualifies to be sent relays and generate reward.
These are some of the checks POKT already does before each session to see if a node qualifies for a session:
- Does this node have at least 15k POKT staked?
- Is the node currently jailed?
To fix MaxChains, this proposal adds one more:
- Does this node’s MaxChains equal to or less than protocol parameter?
With this check, only nodes who are in compliance with the MaxChains parameter (equal to or less than the MaxChains) will be able to be a part of sessions to serve relays. Any that are not in compliance will not be given new sessions.
There is no other negative effect (like a slash) if a node has more chains than the MaxChain parameter… they just simply won’t be given sessions to generate reward.
@h5law is a protocol developer and has submitted a PR to pocketcore. It’s ready for review and testing by the protocol team and others participating in the next hard fork release. @bulutcambazi currently has two proposals being considered by the DAO to initiate a hard fork upgrade, and the MaxChains fix would simply be included in the next release.
Rationale
MaxChains should work the way MaxChains was intended to work. This is a matter of patching an existing bug in its implementation.
No parameter changes are being proposed in this proposal, this is simply a fix to the protocol.
Dissenting Opinions
MaxChains shouldn’t be fixed because I don’t want MaxChains to ever be changed
This isn’t about deciding on what the MaxChains parameter should be, it’s about fixing the protocol so that MaxChains works how it was intended to work. This is a simple protocol fix.
If the POKT network is to have a MaxChains parameter, it should be in a workable condition. This proposal is not setting MaxChains to a new value, it is simply fixing the protocol to make that parameter usable.
Any parameter value changes to MaxChains must go through a PUP, and this is not a PUP.
Adding the MaxChains check will require a fork, which it so much work.
Two other PIPs are currently up to vote which are consensus breaking changes, requiring a fork. The MaxChains fix would simply be added to the next release with the other features, whenever that may be.
Is this the GANDALF proposal?
No. The GANDALF proposal is economic research proposal on the potential benefits of different MaxChain settings, but this proposal is simply about fixing MaxChains. In the GANDALF discussion, we all realized that the MaxChains parameter doesn’t work as expected, therefore this proposal is about providing a solution.
Any parameter value changes to MaxChains (like GANDALF) must go through a PUP, and this is not a PUP.
Viability
This PR was submitted by @h5law who is a protocol developer. After seeing a discussion in Telegram about MaxChains, he jumped into the code, saw it was a quick fix, and submitted a PR in a matter of minutes. It is a very simple PR, that can be easily tested with the other coming upgrades.
Implementation/Audit
Once approved by the DAO the PR will be allowed to be included in the next RC release for testnet testing. It will be a part of the standard process for testing/auditing a new RC release.
Copyright
Copyright and related rights waived via CC0.