Skip to content

Improve court documentation #83

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Improve court documentation #83

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 18 additions & 2 deletions docs/learn/court.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -91,7 +91,7 @@ For the `delegate` extrinsic, the function argument `delegations` contains a
list of account ids. The dispatch function ensures that the list of
`delegations` contains actually account ids which are actively participating
jurors. The list needs to contain at least one account and all account ids need
to be unique.
to be unique. Currently the list has a maximum length of five delegations.

### Exiting the Court

Expand Down Expand Up @@ -202,14 +202,30 @@ risks (`slashable` and code reference `SelectionAdd::DelegationStake`) the
`MinJurorStake` associated to the vote weight. If the juror makes bad decisions,
the delegator loses the selected `MinJurorStake`.

### Voting at predefined Time Points
### Vote-, Aggregation-, Appeal-Phases at predefined Time Points

Jurors are requested to vote in a periodic interval (`RequestInterval`) at a
known request block in the future. This ensures that jurors only need to check
at predefined times if they need to take action. If there wasn’t this concept of
predefined requests, the jurors would have needed to check in a much smaller
time interval if they are selected in court cases.

The `RequestInterval` is configured to be seven days currently. So every seven
days the court requests jurors to vote on its cases. If a dispute is made, the
court schedules a vote round at the next request block in the future. The next
request block in the future is the last request block plus the
`RequestInterval`. If there is no last request block, the next request block is
the current block number plus the `RequestInterval`.

The vote phase is configured to be three days currently. The aggregation phase
is three days and the appeal phase is one day. The aggregation phase and appeal
phase is just scheduled right after the vote phase. The appeal phase is
scheduled after the aggregation phase. So it's predictable when to take action
for the jurors.

After an appeal was triggered, the court schedules a new vote round at the next
request block again.

### Commitment Voting

The voting system uses a commit-reveal scheme, which is required to prevent
Expand Down