ethereum / portal-network-specs

Official repository for specifications for the Portal Network
286 stars 79 forks source link

Distributed scheme for reputation #279

Closed mynameisdaniil closed 3 weeks ago

mynameisdaniil commented 3 months ago

TL;DR: Let's formulate a list of properties we want our rating system to have. Let's tag each property with: [MUST HAVE], [WOULD BE NICE TO HAVE] and maybe [MUST NOT HAVE], [WOULD BE NICE TO AVOID]


I was thinking about #278 and while I like the idea, I think we can do better. What if we take #278 and make it distributed? General idea is to split responsibilities of: 1) choosing the node to be audited 2) making an audit 3) interpreting the result of audit and storing it into network

Thus making it harder to game the system. Also important properties:

4) Node cannot refuse the duty or else it will be chosen for audit 5) Negative result should prevail over positive i.e. if node fails audit it's rating should be reset to 0. This will protect the system from rating farms i.e. groups of nodes trying to boost each others rating by exploiting weaknesses of the rating system. 6) (maybe) we should also investigate nodes closer to the one that failed audit. 7) nodes should have a way to regain rating back. But the speed at which they can regain rating back should be dependent on how often they failed audit in the past. 8) this should probably be implemented as a separate network. Not all nodes will participate or care about the rating. And it's ok. But then again, we expect most of the nodes to be pragmatic actors. 9) just to make it clear. The result of the audit should be stored on the network, and the rating of the node, should be calculated using this data.

This gives us a lot of knobs to turn and fine-tune, but I imagine this process to be more like trying to balance economy of online RPG rather than some sort of universal algorithm that we will implement once and forget about it forever. This also gives us power to propagate these changes over different clients. Nodes that refuse to update settings will fail audit -> lose rating.

I understand that what I propose is not a solution, more like terms of reference. But i think we should formulate what we want before trying to figure out how we want to do this.