Hey, here is an approach for a fair (dis)incentive mechanism for de-MLS based on peer-scoring. I want to discuss this from here before I go with the RFC update.
The current de-MLS design removes members immediately based on the violation list which is not so fair since the issue can be caused not only by malicious activity but also by network issues e.g. steward can actually commit, but the package cannot be delivered.
To make this fairer, a simple peer scoring mechanism that tolerates accidental or network-related faults until they actually harm the protocol.
Each node keeps a local peer score table: member_id and score.
New members start with a default score defined in the config.
When a member is removed, everyone deletes that entry from their table.
This list is updated later through the emergency criteria proposal if needed. (We have an emergency criteria consensus already)
Every time a score changes, stewards check whether any member’s score is below the threshold (for example, below zero).
If a score falls below the threshold for a member, the steward includes a remove operation in the next commit.
A question:
If there is a low peer score member, should the peer score be increased with the honest activity by the time? Looks good, but make the architecture more complex.
Hey, sounds good! We definitely need some mechanism to make group participation fairer.
So I have some questions:
This list is updated later through the emergency criteria proposal if needed. (We have an emergency criteria consensus already)
So idea that we decrease score only if we have some evidence that user is malicious? How we deal with network issue? And still a question, how we determine is it a network or malicicous user
If there is a low peer score member, should the peer score be increased with the honest activity by the time? Looks good, but make the architecture more complex.
I think this part required to sync table in group time to time, so maybe it’s not a big deal in term of implementation
Short answer, yes, we cannot separate the activity is caused by the network or behaviour. But, with peer scoring, we can mitigate the issue.
In the RFC we have a general violation list. This mechanism is agnostic of specific items in the violation list.
I think some items in the list clearly show that the steward is malicious, such as creating an unvoted proposal commit. Maybe better to give more penalty score these kind violations. But some items, we cannot separate them from maliciousness or network, such as inactivity. That’s why we propose the peer scoring, if the steward violates the list due to a network issue still get a low score but continue, but this activity is not expected to be continuous. Overall, we expect that from this mechanism, during a time interval, malicious stewards are eliminated and network-issued stewards continue.
This is very good, if we can have this, the network issued steward can get a higher score with successfully committing, to compensate the low score from the network issue.