[DO NOT MERGE] Random sampling

[zsculac]

No description provided.

[botnumberseven]

I'm trying to understand the math for score in a submitProof function and failing so far. As the score components values differ by dozens of orders of magnitude. Am I doing it wrong?

I'm using SBB node (identity_id 193) on Neuro as an example.

uint256 nodeStake = stakingStorage.getNodeStake(identityId);
uint256 nodeStakeFactor = (2 * ((nodeStake * SCALING_FACTOR) / 2000000) ** 2) / SCALING_FACTOR;

nodeStake = 2.01965755312963E+24
nodeStakeFactor = 2.04E+54
So nodeStakeFactor is at 10*54 order. Not sure why nodeStake is multiplied by scaling factor as it's already 2M * 10^18.

uint256 nodeAsk = profileStorage.getAsk(identityId);
(uint256 askLowerBound, uint256 askUpperBound) = askStorage.getAskBounds();
uint256 nodeAskFactor = (nodeStake * (((askUpperBound - nodeAsk) * SCALING_FACTOR) / (askUpperBound - askLowerBound)) ** 2) / 2 / SCALING_FACTOR;

nodeAsk = 2.2E+15
askLowerBound = 1.1058E+33
askUpperBound = 3.04353E+33
nodeAskFactor = 2.49E+42
Above does not make much sense, I'd expect nodeAsk and bounds to be at the same order and they differ by 18 orders. Hence the result makes little sense as one is subtracted from the other.
Btw, why nodeStake is included into askFactor calculation? In that case nodeStake would be counted/considered twice in the score.

uint256 nodePubFactor = epochStorage.getNodeCurrentEpochProducedKnowledgeValue(identityId);
uint256 nodePublishingFactor = (nodeStakeFactor * (nodePubFactor * epochStorage.getCurrentEpochNodeMaxProducedKnowledgeValue())) / SCALING_FACTOR;

nodePubFactor = 1.00736E+23
epochStorage.getCurrentEpochNodeMaxProducedKnowledgeValue() = 1.00736E+23
nodePublishingFactor = 2.07E+82
Why nodeStakeFactor is used in pub factor? in this case node stake is used in every component one way or another.
I don't understand the logic behind this formula at all honestly.

And in the end score sums values which are dozens of orders magnitude different.

[zsculac]

Hey @botnumberseven
Thanks for the interest and effort you put into analyzing this PR, we appreciate the feedback. Indeed you are right and it should be fixed now.

Since this is a draft PR, we're working on it daily. Some functions in their current form are more of a skeleton to keep track of key components, and we’ll continue refining them as we go. We do keep these things in mind and will address all issues that arise.

[zsculac]

Closing this because we continued our work in this PR #377