Though this is a bit late, in addition to the JSFiddle @Andy-Liquify provided, I also wanted to share a simple colab I used to verify the updated proposal for those who prefer Python.
reposting from Telegram:
We’ve been evaluating weighted sessions vs rewards through the lens of nodes (the supply-side) but I’d encourage thinking about the implications for the apps (the demand-side). Currently the Portal’s cherrypicker relies on consistently having a pseudorandom set of 24 nodes to choose from - ensuring that even if some nodes are highly latent or out of sync, there are plenty of others to choose from, ensuring quality service for apps. Now imagine instead that a new set of whale servicers get selected for 80% of sessions, but they’re misconfigured, now the Portal is going to have a much harder time ensuring quality service because it has a much smaller pool of alternate servicers to choose from.
PIP-22 is superior on the basis of not disrupting quality assurance on the demand-side. Folks like msa6867 have acknowledged that PIP-22 is less set-and-forget from a governance perspective than PIP-23, when it comes to supply-side parameters, but PIP-22 leaves the demand-side untouched whereas PIP-23 will require Portal enhancements and most likely an increase in the SessionNodeCount to compensate for a reduction in diversity of available servicers.
Regardless of which way this proposal goes, the way in which this was thoroughly discussed, amended via community contributions, criticized for its flaws and praised for its merits, it’s a huge win for the Pocket community. It’s probably going to be close , but I think everyone can be satisfied that every facet of its pros and cons was thoroughly debated(I certainly threw the kitchen sink at it), every vote was cast in full knowledge, and everyone can feel good about moving forward and coalescing around the end result, whether they agree with it or not. There’s tremendous value in that.
This proposal has been approved with 27 yes votes and 6 no votes. Snapshot
The next steps are for the code to be shipped and bundled with the next release (RC-0.9.0) and, in parallel, for the DAO to agree to the initial parameter values, which @msa6867 and @Andy-Liquify have proposed here PUP-21 Setting parameter values for the PIP-22 new parameter set