Karma Farming Solved?

BACKGROUND:

Every Service Node within the Pocket Network has an economic incentive to become a Federated Node so that the node can earn POKT reward for completing relay validations. To become a Federated Node, a Service Node must complete several admission requirements, one of which is a high Karma score. Karma scoring is the ± system that the Pocket Network uses to rate Service Node performance. Most (if not all) Karma scoring is based on the performance of a SN within each Servicing Session.

ORIGINAL ATTACK VECTOR:

Application Client and Service Node collusion where the AC sends arbitrary requests to the SN in order to boost the SN’s Karma score.

SOLUTION:

This attack vector may have been indirectly fixed by forcing session nodes (now including Service Nodes) to be derived pseudorandomly from the native blockchain data.

TOPIC:

This is a discussion about whether or not the Karma Farming attack vector is remedied.

I am going to go on a different tangent and say/repeat that karma is undesirable, being a requirement to become a federated node, which is undesirable due to requiring a high stake, thus increasing centralization. While it has been said that the stake will be similar to a validator in Ethereum’s PoS (32 ETH), as stated, requiring only 3 validators to be assigned per session is too low. How long will the session be, again? Looks like it’s undecided in the white paper (X seconds, p 13). Eth2 originally aimed for 8 s, but the spec has been revised to 16 s per slot, while at least one contributor (Danny Ryan) is still bullish for 8 s (so am I, ;P), with 128 validators per slot (111 recommended as the minimum for safety, CTRL+F 111). Given that I am repeating myself, I feel like a broken record / flogging a dead horse, so I won’t do it again, but don’t say I didn’t warn you! While I understand that the federated nodes don’t participate in blockchain consensus, 3 still seems like it’s too low for the same reason in the link.

@jray The reason behind the karma scoring system is to avoid collusion between Clients and Service Nodes, by avoiding paying the Service Nodes directly, but incentivizing them to become Relay Validators by accumulating a good karma score, and maintaining that Karma Score over time. The other topic is that we can’t assure that in the network will exist more than a minimal amount of validators for a given network (Eth, Bitcoin, etc.), given the fact that Validators can choose which networks to validate for, and it’s unrealistic to assume that all validators will be able to validate for all networks.

Understood, but I still think it needs thorough scrutiny for security as such a system hasn’t been tested in the wild, AFAIK.

Sure, but I think if there is going to be less than 111 validators for one network at any time then it may be better to wait until there are at least 111 validators. There are 12,600 nodes on Ethereum, so given a sufficiently low minimum stake deposit it shouldn’t be too hard to get enough nodes for any one network, provided that it is sufficiently well used.

PS see here for another example with similar math:

Agreed. Part of our design philosophy is as long there are no protocol breaking issues when live, the system can be fixed in flight.

Yes but how many of these are mining nodes? Is there an idea roughly of how many staking nodes there will be when the switch happens on ETH?

Sure, however I do like to see (at least somewhat) formal arguments for liveness and safety, as has been done with the correct by construction approach in Casper CBC (although it isn’t developed yet but is under development), and also FFG: https://ethresear.ch/t/epoch-less-casper-ffg-liveness-safety-argument/2702.

Not sure how many are mining. Getting GPUs to mine is a hurdle.

I guess that not every node on Ethernodes may be able to afford a 32 ETH stake, but my guess is that it should be nearly certain to be more than 111, maybe between a tenth to half the current number of full nodes.