Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Dispute Kits to unstake ineligible jurors #98

Open
jaybuidl opened this issue Jun 20, 2022 · 4 comments · May be fixed by #1653
Open

Allow Dispute Kits to unstake ineligible jurors #98

jaybuidl opened this issue Jun 20, 2022 · 4 comments · May be fixed by #1653

Comments

@jaybuidl
Copy link
Member

jaybuidl commented Jun 20, 2022

Problem

For the 1 Human 1 Vote Dispute Kit, it is possible that some large staked jurors might not be registered on Proof of Humanity. In such a case, they would end up being drawn often from the sortition tree but later filtered out. It is highly inefficient and costly.

Proposed solution

Some team members have suggested that KlerosCore should allow a DisputeKit to unstake such ineligible jurors as follow:

/** @dev Allows to unstake the juror that obstructs drawing process.
* @param _coreDisputeID The ID of the dispute in Kleros Core which drawing process is obstructed.
* @param _juror The address of the juror to unstake.
*/
function unstakeJuror(uint256 _coreDisputeID, address _juror) external {
require(phase == Phase.drawing, "Should be in drawing phase");
require(!postDrawCheck(_coreDisputeID, _juror), "The juror is eligible to drawing");
core.unstakeByDK(_coreDisputeID, _juror);
}

/** @dev Allows an active dispute kit contract to manually unstake the ineligible juror. The main purpose of this function is to remove
* jurors that might obstruct the drawing process.
* @param _disputeID The ID of the dispute.
* @param _account The address of the juror.
* @return True if unstaking was successful.
*/
function unstakeByDK(uint256 _disputeID, address _account) external returns (bool) {

Analysis

A) If there are 2 Dispute Kits with different eligibility criteria using the same subcourt

Then one Dispute Kit might decide to unstake a juror while this juror is still eligible in the other Dispute Kit. It would be unfair to the juror as he would miss some opportunities. There is no easy way to prevent that.

B) Should unstaking ineligible jurors take place in the usual Staking phase?

  • Yes because that's what phases are made for. But then the juror could re-stake immediately after.
  • No and by-pass the DelayedStakes to prevent the juror from re-staking immediately after, but this might still happen if it takes more than maxDrawingTime to draw and KlerosCore cycles through the phases. In addition it breaks the design of the phases and creates a new path for unstaking.
@jaybuidl jaybuidl changed the title Unstake ineligible jurors Allow Dispute Kits to unstake ineligible jurors Jun 21, 2022
@jaybuidl
Copy link
Member Author

jaybuidl commented Jun 30, 2022

This issue should be viewed as an optimisation which benefits the bot operators. It does not benefit the end users with either better functionality or performance.

For now we are waiting for more clarity on the possibility of making the sortition sum tree more modular #137 + the possibility of simplifying the phases in Kleros Core.

@jaybuidl
Copy link
Member Author

#137 has been implemented so we can revisit this.

Unstake ineligible jurors from court X:

  • only during Staking phase
  • and only if they are ineligible from all the DisputeKits allowed by the court in question.

image

@jaybuidl
Copy link
Member Author

jaybuidl commented May 3, 2023

Currently we cannot iterate through the dispute kits to implement this logic.

Worst case just unstake without checking all the DKs.

@jaybuidl
Copy link
Member Author

Easier to implement now after #1357

@coderabbitai coderabbitai bot linked a pull request Jul 17, 2024 that will close this issue
@jaybuidl jaybuidl linked a pull request Jul 24, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant