Hello,
I’m following English-Chinese translation case 546 [1] and I believe
the challenger is likely engaging in jury stacking.
My suspicion comes from the fact that that the English-Chinese subcourt had
not received any new stake for months (as far as I can tell) and suddenly
received 20,000 PNK of stake just one day before dispute 546 was created
(i.e. a day before the translation was challenged, see [7]). My suspicion
was further increased by the fact that the address having added that stake
[2] had not added any stake to Kleros in over 2 months ([3], [4]).
Furthermore, it just so conveniently happens that the amount of stake added
by [2] in [4] is just the right amount to grant them a total of >50% of the
subcourt’s stake (27,264 PNK vs 21,884 PNK; see [5]), or more precisely
55.5%.
All in all, it seems very likely to me this is a blatant case of jury
stacking on behalf of the requester and challenger (same address: [6]) and
the juror with address [2] (who I now believe to be either the same person
or their friend/coconspirator).
Now, all this wouldn’t be quite be so bad if not for one unfortunate fact:
the ‘jurorsForCourtJump’ parameter for subcourt 21 (English-Chinese, and I
believe this is the case for all translation subcourts) is set to 128, which
is to say that there can never realistically be a court jump. If this
parameter were reduced to something reasonable like 3 or 4, I could present
the evidence I have presented above to the higher court(s), and although
they will not be able to judge the quality of the translation, they would at
least be able to see that the court process itself was corrupted.
Now, I know that there is a governance process by which such parameters can
be changed, however I’m not sure what the conventions are regarding its use
and I believe it would take at least one week for the change to be applied.
Not to mention that when I experimented with changing the parameter in
governor.kleros.io, it requested a deposit of over 14ETH, a sum which I am
most definitely not willing to risk.
Of course, there is the possibility that this is all just a coincidence and
that I’m just being paranoid… Let’s hope that’s it but I’m not holding my
breath if the translator goes through with the appeal.
Here are some other issues I noticed while reading the Kleros and Linguo
contracts’ sources:
-
There does not seem to be any limit to the number of appeals. This
seems to me like a pretty big flaw since a rich participant could just
appeal indefinitely until their probably-not-quite-as-rich adversary
gives up or has no money left. I know that crowdfunding is an option but
given a rich enough adversary, even crowdfunders might be too scared to
participate. I therefore believe appeals should be limited in some way. -
Regarding the Linguo contracts, they currently have a governor which can
change the appeal multiplier arbitrarily for any of the participants.
This basically means that the arbitrator can prevent any participant of
his choice from appealing altogether (by setting an absurdly high
multiplier). In its current state these contracts are therefore no better
than a centralized escrow. I would even argue that they are much worse
since they have the complexity of the court system and the
arbitrariness of a centralized escrow. I really think you should remove
this central point of failure.
If anyone here knows how to help, I’d definitely be interested. At any rate,
I hope the Kleros community will at least consider changing the court jump
parameters, and perhaps limiting appeals and fixing the centralization in
the Linguo contracts.
[1] https://court.kleros.io/cases/546
[2] https://etherscan.io/address/0x9b70502efaaf3470f62ca3a27f7eab37942f4e80
[3] https://etherscan.io/tx/0xe6f41720b5b18bfafeb3db8b6bc51fe4425a10b9d8e59e5f2e4a6991f4296122
[4] https://etherscan.io/tx/0xe030fd539e2e929f86abedeae93413257822cce57e054c3bd7cf8d18882b17fe
[5] http://klerosboard.com/court/?id=21
[6] https://etherscan.io/address/0x5dCE0b2F2bc6a806AD1Ee43bCEe0EDd86877025C
[7] https://etherscan.io/tx/0x575a84f7013ec5375c8a4a474c1d30a8e8da9c7dff1e944ca118d6e0f7136f35