Protocol design decision question: why not allow votes before drawing jury?

General
#1

Hello everyone,

I’m working on a proof of concept for a justice protocol similar to Kleros on Solana. I’m doing research and trying to better understand the Kleros protocol.

One thing I was curious about is why is what is the justification for choosing the jury before voting?
To clarify, instead of this order of business:

  1. potential jurors stake to join the jury
  2. jurors are drawn randomly
  3. jurors vote
  4. jurors reveal votes

Why not do it in this order:

  1. potential jurors stake to join the jury
  2. all jurors that staked enough can review the evidence and vote
  3. all jurors that staked can reveal their votes
  4. certain number of jurors are drawn randomly and their votes are counted towards the final result

The benefit of the latter is at least that bribing jurors becomes less viable since nobody knows who the actual deciding jurors are until the very end.

#2

Hello Sal, from my research of Kleros i find that the main focus on Kleros is security.

In my very personal opinion i have this to say about your procedure

  1. everyone should be able to check the evidence (and it should be anonimous), for the sake of transparency
    3-4. the votes should be secret, so there is no way to validate a collusion “if” attempted over time on many cases, also if someone has to have privacy over his decision, he/she should be able.

may i know what is your aim on such endeavor? do you have a team on this? have you estimated the effort/time/cost needed to reach your goal?

#3

Sorry if I wrote confusingly. In my protocol design the evidence is also public and votes remain secret until revealed. What I’m wondering about is why Kleros chooses the jury first and only allows the selected jury to vote. Why not let all juror applicants vote and draw randomly from the votes number of jurors who’s votes count for the final decision?

#4

its okay, it might well be me since im not that sharp (barely sleept in the last 3 nights) now back in track, in that regard… i think is about blockchain efficiency. in your approach when a vote takes place a smart contract is issued, right? computational cost might go sky high. dont evm/signers nodes get involved in that phase?

#5

That’s an interesting point. Solana uses a slightly different model from EVM for on chain computations. In my implementation on-chain computations for my smart contract stay basically constant no matter the number of votes.