Thank you @iaa12 for your proposal!
I believe from an economic standpoint, this proposal achieves the same goal as PIP-22 - Weighted staking minus the potential for scaled slashing discussed in this reply: PIP-22 - Weighted staking - #16 by luyzdeleon since this proposal focuses on selection rather than rewards.
However my biggest dissenting opinion about this proposal would be it’s surface of impact in the current implementation, opening the surface for potential bugs and unforeseen issues at the technical level. This change would imply the following impact to the current implementation:
-
The first impact is that the whole Dispatch and Relay mechanisms would have to be modified, and the QA regression scenarios would need to be augmented significantly to account for the different categories of node stake distributions and re-benchmarked, introducing potential unknown unknowns to these critical functions of the software.
-
Claim and Proof transaction validation would have to be revised, re-benchmarked (impacting potentially block production times, which impacts session transitions and other block based functionality).
-
A revision of the SessionCache used for performance in both points mentioned before.
I believe PIP-22 to be safer to implement because it only introduces changes to the Service Rewards and Slashing functionalities which are centralized to only 3 functions in the codebase, with no impact to how applications interact with Pocket Core or how transaction validation occurs, while achieving the same economic incentive mechanism.