kleros / kleros-v2 Goto Github PK

Requires the v1Governor to send the ETH to the Foreign Gateway

It would be ideal to have events representing these changes since that would result in a much faster and easier subgraph indexing.

Advisory: GHSA-p9pc-299p-vxgp

$ yarn why -R yargs-parser
├─ @kleros/kleros-v2-contracts@workspace:contracts
│  ├─ ethereum-waffle@npm:3.4.0 (via npm:^3.4.0)
│  │  ├─ @ethereum-waffle/chai@npm:3.4.3 (via npm:^3.4.0)
│  │  │  └─ @ethereum-waffle/provider@npm:3.4.1 (via npm:^3.4.1)
│  │  │     └─ @ethereum-waffle/ens@npm:3.3.1 (via npm:^3.3.1)
│  │  │        └─ @ensdomains/ens@npm:0.4.5 (via npm:^0.4.4)
│  │  │           └─ solc@npm:0.4.26 (via npm:^0.4.20)
│  │  │              └─ yargs@npm:4.8.1 (via npm:^4.7.1)
│  │  │                 └─ yargs-parser@npm:2.4.1 (via npm:^2.4.1)

(just testing the flow of the new Github project beta)

Migration of resolve.kleros.io to be compatible with the v2 DisputeResolver.sol contract.

This ticket tracks the backend part, for the frontend part see #1079.

Service which periodically sends notifications to the jurors and parties in a dispute by email:

• When drawn
• When winning or losing in a case

It creates a lot of unnecessary merge/rebase conflicts and I don't really see any benefit of it when its just a git log

Small functional bug inherited from the KlerosLiquid unstaking logic.

TL;DR

In some cases, an inactive juror will get unstaked in the wrong subcourt if he has staked in several subcourts. The expected behaviour is to unstake from all the subcourts.

Context

I came across this by accident. @unknownunknown1 was able to narrow down the scenario and reproduce it in Remix. The bug doesn’t happen if the phase is not Staking because the DelayedSetStake path relies on a mapping. And it might not happen if a juror was drawn with more than 1 vote in the round.

Advisory: GHSA-93q8-gq69-wqmw

$ yarn why -R ansi-regex
├─ @kleros/kleros-v2-contracts@workspace:contracts
│  ├─ ethereum-waffle@npm:3.4.0 (via npm:^3.4.0)
│  │  ├─ @ethereum-waffle/chai@npm:3.4.3 (via npm:^3.4.0)
│  │  │  └─ @ethereum-waffle/provider@npm:3.4.1 (via npm:^3.4.1)
│  │  │     └─ ganache-core@npm:2.13.2 (via npm:^2.13.2)
│  │  │        ├─ web3-provider-engine@npm:14.2.1 (via npm:14.2.1)
│  │  │        │  ├─ eth-block-tracker@npm:3.0.1 (via npm:^3.0.0)
│  │  │        │  │  ├─ ethereumjs-tx@npm:1.3.7 (via npm:^1.3.3)
│  │  │        │  │  │  └─ ethereumjs-util@npm:5.2.1 (via npm:^5.0.0)
│  │  │        │  │  ├─ ethereumjs-util@npm:5.2.1 (via npm:^5.1.3)
│  │  │        │  │  └─ json-rpc-engine@npm:3.8.0 (via npm:^3.6.0)
│  │  │        │  │     ├─ babel-preset-env@npm:1.7.0 (via npm:^1.7.0)
│  │  │        │  │     │  ├─ babel-plugin-transform-async-to-generator@npm:6.24.1 (via npm:^6.22.0)
│  │  │        │  │     │  │  └─ babel-helper-remap-async-to-generator@npm:6.24.1 (via npm:^6.24.1)
│  │  │        │  │     │  │     ├─ babel-helper-function-name@npm:6.24.1 (via npm:^6.24.1)
│  │  │        │  │     │  │     │  ├─ babel-template@npm:6.26.0 (via npm:^6.24.1)
│  │  │        │  │     │  │     │  │  └─ babel-traverse@npm:6.26.0 (via npm:^6.26.0)
│  │  │        │  │     │  │     │  │     └─ babel-code-frame@npm:6.26.0 (via npm:^6.26.0)
│  │  │        │  │     │  │     │  │        └─ chalk@npm:1.1.3 (via npm:^1.1.3)
│  │  │        │  │     │  │     │  │           ├─ has-ansi@npm:2.0.0 (via npm:^2.0.0)
│  │  │        │  │     │  │     │  │           │  └─ ansi-regex@npm:2.1.1 (via npm:^2.0.0)
│  │  │        │  │     │  │     │  │           └─ strip-ansi@npm:3.0.1 (via npm:^3.0.0)

Avoid a salt on the commit preserving the security properties. This will require jurors to only remember the choice when calling castVote without the additional random salt, highly improving the UX.

This is achieved by using EIP-712 signatures, I realized this and developed this commitment-scheme for my master thesis' protocol, which was a decentralized news platforms that uses dispute resolutions. Here you can see the commit and reveal implementations of my thesis proof of concept. I will provide more details later as I need to translate that section of the technical paper, and will come up also with the PR.

Note: If you check the PoC code I pointed to, the nonce is not a salt, is just a sequential number used to prevent commits being the same when using the same choice. So jurors can override the commit multiple times and each commit will look different, to avoid external observers to find patterns.

Responsible for initiating the following actions:

• Passing Core and DisputeKit phases
• Passing dispute periods
• Executing delayed stakes
• Drawing jurors
• Executing the token and ETH redistribution between jurors
• Executing the ruling

Motivation

There may be many reason for disabling a Dispute Kits: out-dated functionalities, discovery of a vulnerability etc.

Operation considerations

Ensure that every subcourts will be compatible with at least another Dispute Kit after disabling. Otherwise the first step must be to either

• Enable an existing DK for those courts, or
• Deploy and enable a new DK for those courts.
• Disable the subcourts with no other DK. --> requires #97

getDisputeKit(disputeID) returns(address)

A test is failing right after cloning the repository, installing dependencies and running tests.

  16 passing (7s)
  1 failing

  1) Draw Benchmark
       Draw Benchmark:
     Error: VM Exception while processing transaction: reverted with reason string 'Staking failed'
    at KlerosCore.onlyByGovernor (src/arbitration/KlerosCore.sol:179)
    at KlerosCore.setStake (src/arbitration/KlerosCore.sol:494)
    at async HardhatNode._mineBlockWithPendingTxs (/home/donosonaumczuk/Projects/Kleros/kleros-v2/node_modules/hardhat/src/internal/hardhat-network/provider/node.ts:1773:23)
    at async HardhatNode.mineBlock (/home/donosonaumczuk/Projects/Kleros/kleros-v2/node_modules/hardhat/src/internal/hardhat-network/provider/node.ts:466:16)
    at async EthModule._sendTransactionAndReturnHash (/home/donosonaumczuk/Projects/Kleros/kleros-v2/node_modules/hardhat/src/internal/hardhat-network/provider/modules/eth.ts:1504:18)
    at async HardhatNetworkProvider.request (/home/donosonaumczuk/Projects/Kleros/kleros-v2/node_modules/hardhat/src/internal/hardhat-network/provider/provider.ts:118:18)
    at async EthersProviderWrapper.send (/home/donosonaumczuk/Projects/Kleros/kleros-v2/node_modules/hardhat-deploy-ethers/src/internal/ethers-provider-wrapper.ts:13:20)

This was a known issue, the test has a comment in the failing line:

      await core.connect(wallet).setStake(0, ONE_THOUSAND_PNK.mul(10), { gasLimit: 5000000 }); // Github Action fails here, no idea why.

I'm running Ubuntu 22.04, node v16, probably similar environment as GitHub Actions.

Basically allow DisputeKit's castCommit function to be called multiple times during the commit period, each call overrides the commits of the previous one. This allows a juror to change its mind during the commit phase.

Goal

1. To demonstrate the functioning of the v2 court for the resolution of a dispute originating from a new Tag Registry on Arbitrum, and the associated cost savings.
2. To demonstrate the new user experience offered by the new front-end.

Scenario

• John, Joe and Jimmy stake some PNK, hoping to be drawn as jurors.
• Tom wants to tag some contracts, he uses the Tags Registry on Arbitrum to submit several tags.
• Charles disagrees with a tag and challenges it.
• A dispute is created: John, Joe and Jimmy are likely drawn
• Tom and Charles submit evidence to support their claims.
• The dispute resolves (keep the appeal period short for the demo).
• John, Joe and Jimmy get rewarded or penalized for their voting.
• The tag registry enforces the court decision

Scope

Arbitrator

PNK staking ✅

• Smart contracts
• #84
• #256
• #247 (delayed stakes)

Dispute creation ✅

• Smart contracts
• #84

Dispute appeal ❓

⚠️ Arbitrable frontend needs changes.

• Smart contracts
• #84

Juror drawing ✅

• Smart contracts
• #84
• #256
• #247
• #248 "you have been drawn"

Evidence submission ✅

• Smart contracts
• #84
• #259
• #248 "New evidence submitted for a dispute"
• #254

Juror voting ✅

• Smart contracts
• #84
• #260
• #274
• #275
• #247
• #248 "time to vote"

Juror commit/reveal voting ❌

• Smart contracts
• #84
• #250
• #247
• #248 "time to commit (or reveal) your vote"

Phases automation ✅

• Smart contracts
• #84
• #247

Dispute periods automation ✅

• Smart contracts
• #84
• #247
• #248 "dispute has entered phase X"

Token and ETH redistribution ✅

• Smart contracts
• #84
• #263
• #264
• #247
• #248 "you have won/lost some PNK and ETH"

Ruling execution ✅

• Smart contracts
• #84
• #247

Others

• #283
• #290
• #294

Arbitrable

Curate Tag Registry (plan A) ✅

• kleros/tcr#62
• kleros/gtcr-subgraph#16
• kleros/gtcr-injected-uis#6
• kleros/gtcr#255
• kleros/gtcr#256
• kleros/gtcr-action-bot#19

Features:

• Submission of a new tag ✅
• Challenge of a pending tag ✅
• Execution of the arbitrator's ruling ✅
• Appeal ❌

Dispute Resolver (plan B) ✅

• #96
• kleros/dispute-resolver#125

Fast Bridge❓

⚠️ Likely not enough time to bot it, demo it later.

• Smart contracts
• #219
• kleros/vea#35

Fast Bridge Automation

Either one of these:

• kleros/vea#41
• Simple Fast Bridge Frontend

Features

• Dispute creation from L1
• Ruling execution to L1

The RNG doesn't have to be as good as a VRF, but just unpredictable enough for some serious testing in the medium term.

Remove the justification from the commit, as the valuable thing for the stake slash/reward is the choice.

This will make the UX better, as after avoiding the salt (see #184), the only requirement is to remember the choice. Justification can be just emitted in the reveal phase without being part of the commit.

Relates to kleros/vea#35

Pages

• #82
  • #273
• #83
• #257
  • #258
  • #259
  • #260
  • #261
  • #1058
  • #274
  • #275
  • #324
• #255
  • #256
• #225
  • #263
  • #264
  • #265
• #266
  • #267
  • #268
  • #269
  • #270
  • #271
• #272

Features

• #301
• #320
• #321
• #322
• #323
• #276

Implemented on the home chain-side with rates updated via governance for limited number of accepted tokens.

To prevent potentially undesirable arbitrage, the Home Gateway will only accept for fee payment the currency, for example DAI for a HG connecting to a FG on Gnosis Chain. So the jurors for such dispute would receive DAI instead of ETH.

No more fragile deploy scripts with nonce arithmetics.

Resource: https://github.com/wighawag/hardhat-deploy#4-deterministicdeployment-ability-to-specify-a-deployment-factory

Watch out not to break #99

At this stage it's okay to require a separate tx to unstake the locked tokens once they become unlocked (when the dispute is closed) - as in v1.

Previously in v1, the state machine would go through: Staking->Generating->Drawing->Staking.

In v2 things are different because:

• Staking is the Core's responsibility
• Generating and Drawing is the DisputeKit's responsibility

Future dispute kits may even have totally different state machines, but they will always including some form of drawing stage.

In addition different DisputeKit implementations may use totally different RNGs with longer or shorter durations in Generating phase. Therefore different DisputeKits can proceed from Generating to Drawing phases in parallel as long as they all join at the end of their Drawing phase.

Some kind of coordination is needed:

1. For Core to notify a particular DisputeKit that a dispute is in need of jurors
2. For Core to notify all the DisputeKits that the maxDrawingTime has passed
3. For a DisputeKit to notify Core that it has completed its drawing of jurors for the disputes notified by 1.

Possible state machines for v2

• KlerosCore: Staking->Freezing->Staking
• DisputeKitClassic: Generating->Drawing->Resolving->Generating

Exclude functions for voting and appeal funding which take implementation-specific parameters.

There is a good amount of functions shared by DisputeKitClassic and DisputeKitSybilResistant, that might be also shared by future dispute kits. Would be nice to move them to a base contract. I saw there is already a BaseDisputeKit, maybe should be one that inherit from that.

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:

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.

#35

Because Rinkeby will be retired soon.

• Add the Arbitrum Goerli network configuration
• Bridge Goerly PNK to Arbitrum Goerli
• Update the address of the Goerli Inbox/Outbox contracts and PNK address.

Nitro Goerli Rollup Testnet: This testnet (421613) uses the Nitro rollup tech stack; it is expected to be the primary, stable Arbitrum testnet moving forward.

Sources:

• https://developer.offchainlabs.com/docs/public_chains
• https://developer.offchainlabs.com/docs/useful_addresses

Out of scope:

• Arbitrable side on the foreign chains
• Bridging

A participant makes a claim(hash) about a single message hash. Another participant may challenge(hash) which requires falling back to the Safe Bridge and waiting a number of days to resolve.

No extra hop for this iteration: we focus on the Safe Bridge from Home chain to Ethereum mainnet where a native bridge is available. Safe Bridging to other foreign chains can be added afterwards, for example Home chain -> Ethereum -> Gnosis chain afterwards.

Only 1 claim per hash is allowed at the moment, regardless of challenge status, further claims for the same hash are ignored.

Bounties can be added later.

The full specs are not public yet.

The proposal made by @shotaronowhere is gathering feedback.

I have a proposal for a design choice to increase the modularity and flexibility of Kleros v2. The support of modularity would be compatible with a variety of sortition mechanisms which can be determined by the dispute kits and approved through governance. So sortition trees can be supported, sortition data structures we don't foresee could be supported, and a sortition mechanism i'm calling "sortition mining" would also be supported. I am working on a sample 'sortition mining' contract. Please comment on the proposal when you have time.

@unknownunknown1 is testing the feasibility of making the arbitrator compatible with the proposal here:
master...unknownunknown1:feat/sortition-modularity

Problem

In KlerosLiquid there is no way to force jurors to unstake even for the Governor. This is problematic in 2 cases:

• When a subcourt becomes obsolete, such as the Onboarding subcourt.
• When there is a major migration of the Arbitrator contract, such as the upcoming migration to v2.

In both cases, it is likely that some users will never unstake. Therefore some PNK will remain staked, which may hinder some operations.

Solution

• Create a disableSubcourt() function restricted to the Governor only which unstakes any user from the court.
• Respect the phases of the court as usual: use DelayedStakes if not in Staking phase.

Operational considerations

When using this function, the governor should have previously changed the subcourt parameters to make it impossible to create new disputes in the subcourt to disable. Wait for the on-going disputes to resolve. Then let the Governor execute disableSubcourt(). Otherwise some locked tokens may remain, that would require calling disableSubcourt() again at a later time.

Message batching by making a claim(hash) about a Merkle tree root hash of messages instead of the hash of a single message.

verifyAndRelay() on the foreign chain must verify the hash given the Merkle tree branch and data for a specific message.

Any challenge(hash) requires falling back to the Safe Bridge and waiting a number of days to resolve.

Only 1 claim per hash is allowed at the moment, regardless of challenge status, further claims for the same hash are ignored.

Bounties can be added later.

The full specs are not public yet.