Kleros 2.0: Scaling from 1,000 to 1 Billion Cases

Where We Are Now

Kleros v1.0 Athena has been live for two and a half years already. When it was launched, in March 2019, DeFi was in its very early days and few people even knew what an NFT was.

In 2021, the Web3 ecosystem is way more mature and the pandemic transformed the way in which we work, trade... and deliver justice.

Kleros itself has also matured: our governance was decentralized, additional primitives for DeFi, governance and insurance have been secured by the court, Proof of Humanity was spun off, extra capabilities for appeals as well as arbitration on xDAI and Polygon have been rolled out.

Last (but not least), a decision made by Kleros was accepted as legally valid by a Mexican court, opening a whole new range of applications beyond the Web3 ecosystem and within traditional legal systems.

For Kleros to fulfill its vision of affordable, fast and secure arbitration, a new and updated version of the court had to be launched.

The first step in this direction was the publication of the Yellow Paper which contains our vision about the new court.

It seeks to address some recurring pain points related to:

1. The high gas costs which prices out a wide range of low-value use cases.
2. The way the mechanisn design works as was discussed recently by Nathan Schneider, Vitalik Buterin, and William George.

Without further ado, let's dig into Kleros 2.0.

Requirements for Kleros 2.0

1. Cross-Chain

The new court Core Contract must live on a “home” chain which provides the adequate trade-off between security guarantees and transaction costs. The exact choice for the home chain is left as a separate discussion. At this stage, it is only assumed to be an EVM-compatible rollup.

The new court will be capable of passing rulings to arbitrable contracts living on other “foreign” chains, starting with Ethereum Mainnet for backward compatibility with the existing integrations.

In the future, we may add support for other foreign chains such as xDAI etc.

2. Modularity

Kleros courts will offer new functionalities as new research (jury selection, vote aggregation, griefing mechanisms, type of answers, appeal fee model and crowdfunding) and new protocols (Proof of Humanity, quadratic voting) become available - without necessarily demanding that changes be made to the main court contract.

Kleros 2.0 will support specific functionalities to become available as a dispute is appealed to another round. For example, cases in the first round in some specific court may use a system of 1 user/1 vote (based on Proof of Humanity), while the next round may use 1 token/1 vote.

3. Fork-Friendly

Kleros 2.0 should make it easy to quickly coordinate and execute a fork to make the payoffs of an attack on a dispute or on the governance process smaller (to paraphrase Vitalik). When a fork takes place, users who choose to follow the secondary chain (the fork) must forfeit their PNK on the primary chain. This PNK will be redistributed among the users on the primary chain.

However, just deploying a new PNK token and a new court contract is not enough to have a useful fork of Kleros. One also needs to build social consensus around using this new version of the court.

Kleros 2.0 addresses the coordination problem of "moving the party to the new court" which would otherwise likely result in a deadlock situation were the token holders are all waiting for each other to make the first move.

In the new version, after a case has been appealed the maximum number of times, an ultimate voting round will take place in the "Forking" court where every PNK holder can participate.

When they vote in the Forking court, PNK holders will be able to express their willingness to join the fork as a threshold. For example: "I will join if 40% of the holders join too".

Also, a PNK holder can express that a given dispute is not worth forking over in her opinion (for example, because she believes that despite being appealed many times, the case simply involves a highly subjective question and is not the result of an attack).

The court can then determine the single largest possible fork using the process described in the section 4.10.1 of the Yellow Paper.

Kleros 2.0 will also offer a front-end taking care of the deployment of the new PNK token allocated in accordance with the choices expressed previously, as well as the new court contract with the appropriate holders staked and court decision fixed.

4. A Lightweight PNK token

Currently, the PNK token existing on mainnet is complex and expensive to transfer because of the reliance on Giveth/Minime (which allows a TokenController to intercept many function calls).

In Kleros 2.0, the version of PNK on the home chain will be simple. We will use the default token created by the bridge of the rollup.

As a result of this change:

• We will lose some convenience functions to know the supply and balance history (but this can be reconstructed via a graph query if needed). Those functions are not relevant anymore for Snapshot.
• The user will have to use the standard ERC-20 approve() function before the Core Contract can manage the user's PNK for staking purposes.
• The staked PNK will effectively be transferred to the Core Contract which will have a PNK balance. Currently there is no PNK transferred during staking.
• The main contract may still contain a balance of untransferable stPNK for display purposes.

5. Juror Fraud Protection

Kleros 2.0 will enable taking action against jurors who are suspected of accepting bribes, cartelling or revealing their votes too early. Anyone who notices that a juror has pre-revealed her vote can challenge it and claim part of her stake. It leads to another dispute not having influence on the votes nor delaying the main dispute.

6. Evidence Spam Protection

The fact that Kleros 2.0 will be built on an inexpensive rollup means that it might become vulnerable to evidence spam attacks. A malicious actor could profit from the low transactions fee to submit a large amount of irrelevant evidence in order to affect the jurors' decision making process.

To avoid this, users will be required to pay a fee or a deposit for submitting evidence (on another chain than mainnet in particular). This deposit could be lost in case it is determined that it was part of a spam attack.

7. A New Beautiful and User Friendly Interface

Here is a sneak peek into our new court interface: the Juror Dashboard, the Court Overview, and the Evidence pages.

The Architecture of Kleros 2.0

Contract Interactions

The actors in the following diagram are just roles. In practice, a user or a contract often plays multiple roles: for example, a party to a dispute may submit evidence, request an appeal, observe and report fraud from a juror.

A New Court for a Multi-Chain Future

This is what a possible multi-chain future may look like based on the new architecture. Ideally, users would interact only with the home chain for nearly everything. For easier integration, it is desirable for the arbitrable applications to be located on the home chain. Otherwise, we would have to rely heavily on the Fast Bridge and the available native bridges.

Key Components

Dispute Kits

• Dispute kits execute a specific set of features involved in the dispute resolution process.
• Each court is compatible with a specific set of dispute kits.
• The features in a dispute kit include typically:
  • A drawing system to select the jurors.
  • A vote aggregation system to determine the winning choice.
  • An incentive system to redistribute ETH fees and staked PNK involved in a dispute according to the jurors coherence.
  • An appeal system to handle subsequent voting rounds.
• When the dispute kit is compatible with the Forking Court:
  • It tells Kleros Core how to redistribute the staked PNK of jurors who decide to join a fork among the other jurors according to the rules in the Yellow Paper section 4.10.1.

• Examples of drawing systems based on the Yellow Paper section 4.5.2

  • PNK drawing
    • Selection odds in proportion of staked PNK amounts.
    • RNG from Chainlink.
  • Proof of Humanity drawing
    • Random selection among staked PNK who are also registered on Proof of Humanity at the drawing time, with a profile drawn at most once.
    • RNG from Chainlink.

• Examples of vote aggregation systems based on the Yellow Paper section 4.7.2.2

  • Plurality (same as Kleros v1).
  • WoodSIRV (aka Condorcet-IRV).

• Examples of incentive systems based on the Yellow Paper section 4.7.3

  • Equal split between coherent votes (same as Kleros v1).
  • Other “weight functions”.

• Examples of appeal systems based on the Yellow Paper section 4.8.2.2

  • Fund 2 only, Vote on Any Option (same as Kleros v1).
  • Fund 2 or more, Vote on Funded Options.
  • Fund 1, Stake on Custom Options Set.

Juror Prosecution

• Enforces standards of jury behaviour as described in the Yellow Paper section 4.7.6.
• Allows anyone to create disputes related to a jury’s behaviour during one or several cases in the Kleros courts.
• Example of suspected pre-reveal fraud:
  • After the vote is cast, users can challenge it if it's considered pre-revealed. It leads to a separate challenge, not interfering with the main challenge.
• Example of suspected cartelling fraud:
  • Users can challenge the jurors involved in a specific case and provide evidence of cartelling (screenshot of online discussion, suspicious transactions between the juror addresses, use of smart contract for carteling, etc).

Dispute Lifecycle

The dispute resolution process should be seamless for the existing arbitrable contracts deployed on Mainnet. Meanwhile our users will interact with the court on layer 2 for voting or requests for appeal.

Sequence Diagram

In this diagram we use our fast bridging mechanism for both the dispute creation and the ruling messages. We don’t use the native bridge during normal operation. This will be used only in case of a claim challenge.

State Management Across Chains

Fast Bridge

Foreign Chain to Home Chain communications should be fast in order to allow for a seamless resolution process. However, in practice, the speed depends on the bridge’s batching parameters. A message is expected to be bridged within 5-10 minutes.

Home Chain to Foreign Chain communications are slow by design to allow time for possible challenges by the native bridge, typically 7 days for the current optimistic rollups.

The Yellow Paper section 4.2 explains how faster communication can be facilitated between Arbitrator and Arbitrable contracts residing on different chains, which is most useful for Home to Foreign communication and communication between different L2s which would otherwise need to use a L1 as an intermediate hop.

The Fast Bridge can transfer messages and value faster than the native bridge during normal operations. It abstracts away the bridging strategy and its implementation from the courts. As a general-purpose bridge it relies on the Kleros Gateways to act as adapters for the purpose of the Kleros protocol.

The Fast Bridge should be extendable to operate across various chains, not just between one rollup and mainnet.

It should be trustless by allowing anyone to participate in the bridging protocol. For example, by running a light client which implements the protocol or by interacting with a web application which interfaces with the Fast Bridge.

At the moment we are exploring different solutions including building our own bridge if necessary.

Dispute Identifier

The Kleros Foreign Gateway creates a unique incremental dispute identifier X for backward compatibility, as well as an identifier X’=hash(chainId, prevBlockhash, “createDispute”, X, jurorFees, extraData) which is maintained by the Kleros Home Gateway. Kleros Core returns a Home dispute ID Y which is returned to the Kleros Home Gateway and associated with X’.

Later to pass the ruling for Y across the bridge, the Kleros Home Gateway matches Y with X’ so that X’ is sent to the Kleros Foreign Gateway which itself matches it with X and gives it to the Arbitrable contract.

As the current blockhash is not accessible and as creating a dispute 1 block in advance is not a security concern (the evidence period always takes more than that), then we must use the previous blockhash to prevent an attacker from creating and resolving a dispute on the Foreign Chain before this dispute is created on the Foreign chain.

The jurorFees and extraData parameters are required to prevent bridgers from mirroring a dispute with the wrong parameters. A malicious bridger could create disputes on the Home Chain which do not exist on the Foreign Chain. But this would only lead to the bridger wasting gas and the dispute being ruled as invalid without any impact on the Foreign Chain.

Evidence Aggregation

Evidence can be created from either the Foreign Chain or the Home Chain. When created on the Foreign Chain, the front-end will look at the Kleros Gateway contracts for associated identifiers. The front-end is responsible for displaying a consolidated view by looking at the event logs from each chain. In order to do that, the Kleros Foreign Gateway will issue a Meta-Evidence informing the front-end to look for evidence on the Foreign Chain.

Migration to Kleros 2.0

The migration process from Kleros 1.0 to Kleros 2.0 will entail an important technical and usability challenge: the state of the courts will have to be moved to the new Home Chain. Specifically, this means moving the staked/locked PNK balances and the active dispute cases.

This problem could be seen as "trying to build a plane while flying". While we want to minimize downtime, we can tolerate that dispute resolution is somewhat delayed as long as new disputes can still be created and queued. The state of the overall system should remain available and consistent at all times.

We are still researching how to make this migration process as smooth and seamless as possible. As always, we will keep the community informed of the upcoming changes and whenever an action is required from their part.

In short, a long time has passed since the launch of the current version of Kleros. That version was good enough to start testing the concept of decentralized justice and to reach our first 1,000 cases (which happened in November 2021).

Now, the challenge is different: scaling Kleros from its first 1,000 to its first billion cases.

Stay tuned!

Big thanks to Fede, Clément and William for their suggestions and review.