Confidential Data and Crowdsourced Dispute Resolution

A fundamental challenge in a crowd-sourced dispute resolution system like Kleros is that, in order for a jury drawn from the crowd to resolve your dispute, they need to see the evidence and arguments presented by the parties. That evidence might be confidential. 

It is for this reason that Kleros has historically concentrated on categories of disputes that only depend on public information, for example, curation disputes about whether public submissions meet the criteria to be added to a curated list. 

In this article, we will overview some of the approaches one can take to try to make crowd-sourced dispute resolution compatible with disputes that involve potentially sensitive information.

Minimizing the amount of information required

In many situations, there is a lot of sensitive information floating around in the records and arguments of the parties that might provide some context for their dispute, but is not really essential to the question that jurors need to answer to provide an appropriate resolution.

So, a first approach to this problem is to just try to reduce the amount of information that the parties to the dispute share with the jurors to the minimum of what the jurors actually need. The jurors should have enough information to provide an appropriate resolution to the case without receiving additional information that could be sensitive. 

Airline insurance example

A toy example we have considered when trying to think about how to handle confidential data in Kleros is the following: imagine that users want to buy insurance against flight delays. However, any given individual does not want the history of his flights to be public for privacy reasons. 

Then, one can have the user include a cryptographic commitment via a hash of their flight plus a secret salt when they purchase the insurance. Flights can be classified as delayed or not delayed by a curated list where disputes are resolved by Kleros. Any third party can submit the status of a given flight with a bond, and if some other party contests this information it leads to a Kleros dispute. Note that whether a given flight is delayed or not is public information. Kleros jurors can have full access to the information required to answer this question without needing to know which users held insurance for this flight.   

Finally, the user issues a zk-proof against her cryptographic commitment that he had insurance for a flight that was ruled to be delayed, and is hence entitled to withdraw funds from the flight insurance contract. In doing so, he does not have to reveal which flight he is being compensated for.

This example fundamentally works because there is a separation between what information the user wants to keep private and what information Kleros jurors need to resolve the case. However, unfortunately, situations where the information separates this cleanly between these two categories are fairly rare. 

zk-Proofs against private documents 

Perhaps the parties have data that is relevant to the case and which is not itself confident. So, they would like to make this data available to the jurors; however, the documents they would normally use to prove this information contain other information that is confidential. For example, they would like to use a credit card statement to prove that they paid for some service (which they did not ultimately receive, so they want a reimbursement). However, they do not want to make the entire credit card statement public.

Tools such as TLSNotary have made it much more viable to provide these sorts of proofs in decentralized and secure ways. TLSNotary allows users to establish to third-parties that selected information that they want to disclose is present in documents obtained from a given website. For example, instead of a user providing their entire credit card statement downloaded from their bank website, the user engages in a multi-party computation version of the TLS protocol (the protocol by which the user would normally use to exchange encrypted information with a secure website like their bank) with a verifier. The verifier can authenticate that the information originated from the bank’s website and can be guaranteed that the specific items the user reveals to them were part of a document from that website. 

Then, Kleros jurors could use these sorts of tools to verify the authenticity of documents provided as evidence and learn essential facts that the parties want to present to them, without having to see other, more sensitive information in those documents. 

AI anonymization

Another, increasingly effective tool is for the parties to the dispute to run the evidence they want to submit to jurors through an AI anonymization tool. A party to the dispute might provide their business records of their interactions with the other party, but before they do so, the records are passed through an AI tool to remove names of individuals and other personally identifiable information. 

This approach has already been used to anonymize evidence in some enterprise and government use cases; notably, it was used to anonymize evidence in Junin cases until case 142. In those cases, the Kleros Cooperative used the AI tool iDox to remove sensitive information, though this process still required manual verification afterwards to check that no sensitive information remained. So, in this setup, the parties to the dispute essentially delegated the role of anonymization to the Kleros Cooperative.  

This approach generally gives parties a lot of autonomy. If they are operating the AI tools they use directly, they can decide what instructions they give their AI tools to determine what types of information they view as confidential and want redacted, while nonetheless saving them the trouble of having to screen potentially long and complicated documents for sensitive information manually. 

If there are likely to be questions about the authenticity of documents submitted by the parties, one could conceivably issue a zk-proof that the anonymized output of an AI corresponds to a private document that is not revealed, and that the hash of that private document matches a value that has been authenticated by some external source of authority, such as a document that has been verified as coming from a bank website via TLSNotary. 

Sending secrets to the crowd

However, this approach has limitations. Sometimes, the critical piece of information that the jurors need to resolve the case is itself fundamentally confidential. 

Encryption

If we want to make some piece of sensitive information available to the jurors in a given case without revealing it to the entire community of Kleros jurors, then that information needs to be encrypted by the parties before it is sent to the jurors. 

This is not intrinsically difficult. Jurors could be required to post a signed message with a PGP public key, for example. Then parties could encrypt the evidence under the public keys of each of the jurors in the case. Such an approach would be very decentralized, though potentially add friction for users. Generally, the exact choice of how the encryption of the evidence is handled can have UX tradeoffs for the parties and the jurors. 

Tresorit is an example of a platform that offers encrypted file-sharing and “encrypted data rooms” services for managing sensitive documents. So, using a tool like Tresorit is an established and practical way for parties to send encrypted evidence to jurors. Tresorit offers end-to-end encryption services, so this can be done without having to reveal the sensitive evidence to the company, Tresorit, itself. The jurors drawn in recent Junin cases, such as case 146, have accessed encrypted evidence through Tresorit. 

Ultimately, what is much more difficult is how to handle situations where jurors might leak the encrypted information they receive. Tresorit offers options that prevent users from downloading the files they receive and to delete the (encrypted) files from the Tresorit services after a period of time, for example, after the Kleros case would be complete. 

Such techniques can make it less likely for leaks to happen by applying good practices around the management of the data. However, blockchain file downloads alone cannot stop a juror who is determined to leak the information. Such approaches are akin to Snapchat’s defenses against saving information within the app. A juror can always take photos of their screen with another device.

Crypto-economic approaches to confidentiality 

Juror Misbehaviour Court

A classic crypto-economic approach to trying to prevent users from taking some action is to require them to stake a deposit, and penalize them by slashing a part of that deposit if they misbehave. So, it makes sense to consider mechanisms that would slash a juror if she leaks some piece of confidential evidence. 

Whether a given juror leaked confidential data is a question about off-chain information, so to bring the answer to this question on-chain, one needs an oracle. As this question can potentially be subjective and requires investigative effort to resolve, Kleros itself is the natural choice for the oracle for this type of situation.

A mechanism that we envision is to have part of a juror’s PNK stake be slashable if the juror generally breaks some aspect of the juror code. A challenger, who might be another juror, a party to the dispute, or a third party, can place a deposit to trigger a secondary Kleros case, judged by a different set of Kleros jurors who are staked in a specialized court that considers cases around juror conduct. If the juror in the original case is found guilty of breaking the juror code, he loses an amount of PNK that is used to compensate the challenger. 

The Juror Misbehaviour Court can potentially also inflict penalties that go beyond just losing an amount of staked PNK. In courts that have an identity layer, such as requiring the juror to be registered on Proof-of-Humanity or requiring the juror to have one or more soulbound tokens (SBTs) in order to be drawn, a conviction in the Juror Misbehaviour Court can result in the juror receiving a “negative soulbound token” that prevents the juror from being drawn in any future cases in those courts. 

Due to the identity features in those courts, it is difficult for the user to get around the penalty by simply creating a new Ethereum wallet and moving their PNK. Even if a user waits a long time between revealing a piece of sensitive information and they have already unstaked all of their PNK so there is no longer a locked amount that can be slashed, if they want to rejoin the court and participate again as a juror in the future, they might be required to reuse the same Proof-of-Humanity profile. In this case, their past misbehaviour will still be tied to their profile, and they can be challenged in the Juror Misbehaviour Court upon their return. 

Whether a negative soulbound token is issued can depend on the type of violation of the juror code that the juror has committed as well as other factors, such as whether the juror has committed other violations in the past. 

The Juror Misbehaviour Court can judge whether confidential information was revealed by a juror. It can also consider various other questions about the juror’s behaviour that require off-chain, and often subjective judgements, such as: 

• Did the juror provide a justification with their vote that meets the standards set out in the court policy?
• Did the juror accept a bribe or otherwise collaborate with an attack?
• For courts that use commit and reveal, did the juror “pre-reveal” their vote by publishing it while the vote was still in the commitment phase? 

This type of mechanism presents risks that parties might try to frame jurors, making it look like they have committed a challengeable offense so that the party themself can challenge the juror and receive the reward. For example, a party might create a fake dispute that includes evidence that appears confidential, but is actually not sensitive. Then they can release the evidence themselves and challenge a juror who they claim is responsible for the leak. If one calibrates the penalties in the Juror Misbehaviour Court appropriately with respect to the dispute fees in the initial case, one can prevent such a strategy from being profitable for the party. Then, this attack would only make sense for parties who want to grief the jurors. 

Watermarking 

Trying to hold individual jurors accountable for revealing confidential information raises further questions. If the information is found to be circulating publicly, how can one establish that it was a specific juror who was responsible for the leak? One possible approach here is to use digital watermarks. 

There are various types of digital watermarks that offer different levels of resistance to various attacks, and as such are used in settings where one’s goals are slightly different. A simple version of this idea is to just add a light text in the background of the document that is visible to a human reader. For example, Tresorit includes options around the addition of watermarks where the watermark shows identifying information about the recipient of the document such as their email address. 

This approach is largely dissuasive as it serves as a visual reminder to the recipient that there is a possibility of the leak being traced to them. However, if the watermark is entirely human visible, an attacker will be able to see what they need to remove from the document.

Other types of watermarks are not human visible, and indeed are designed to be difficult to detect. A classic approach to alter the spacing, fonts, or placement of specific pixels from one version of the document to another. These “structural” or “geometric” watermarks can be designed to still be present even if a user prints and scans the document or takes a photo of their screen. However, this approach can be vulnerable to attackers that reformat the document, or indeed, completely retype the document themselves.

More recent approaches algorithmically replace words in the document with synonyms. A risk of such “lexical” watermarks is that replaced words might have slightly different nuances of meaning compared to the words in the original document, which could negatively affect the ability of a protocol like Kleros to provide good resolutions to disputes involving these documents. These watermarks are resistant to reformatting; however, they can be vulnerable to an adversary that paraphrases or heavily edits the document.   

Note that as the evidence in the Juror Misbehaviour Court will itself be seen by the jurors, at least in those cases, what techniques parties use to watermark their documents runs the risk of eventually becoming public. Thus, one has the particular challenge of operating in an environment where the adversaries know what types of watermarks are used and, consequently, what are the best available techniques to subvert them. However, when applied appropriately, these techniques can offer some chance of catching all but the most sophisticated adversaries. 

Restriction on the pool of who can be a juror

Note that purely crypto-economic approaches to confidentiality in a system like Kleros have fundamental limitations. As is often the case in crypto-economics, the defenses are economic, and if a hostile party pays a large enough price they can overcome those defenses. The loss that a juror who reveals confidential evidence suffers is bounded by how large of a deposit she has locked up in the system that can be slashed by a ruling of the Juror Misbehaviour Court.  

Moreover, if a hostile party anticipated there being confidential evidence they want access to in an upcoming case, she can stake in the court where she expects that case to be considered. Such a hostile party could be a competitor to one of the parties in the dispute, for example. Then, all she needs to do to get access to her competitor’s confidential data is to stake enough in the appropriate court to have a good chance of being drawn as a juror. If she is not drawn in the initial round, she can try to trigger an appeal to give herself another chance of being drawn in the appeal round. 

Ultimately, how much economic security parties can expect to have against their confidential information being revealed will be much lower than the amount of economic security that they can expect Kleros to have against producing incorrect rulings. The exact amount of economic security one has against revelation of confidential information will depend a lot on how much stake is present in the court deciding the case. Thus, a purely cryptoeconomic setup can make sense if the parties are sophisticated enough to understand these varying levels of security, or if their information is not too sensitive. 

However, the idea of an attacker having a fairly straightforward amount of money that they need to pay to see confidential information is unintuitive and seems unnatural, particularly to people from outside the crypto-currency space. 

In order to have a level of security of confidential information that will correspond to what non-crypto people expect based on their experiences in web2, one may need to adapt the Kleros mechanism so that who (or what) can be a juror is less open, and you can have guarantees that the juror is not, in fact, a competitor of one of the parties. 

Vetting of Jurors

In web2 environments, performing checks on people before they are allowed access to confidential information would typically be performed as part of a KYC-type process performed by some centralized entity. These people might also be required to sign a non-disclosure agreement (NDA) as part of this process. As the centralized entity has information about the identities of these individuals, if one of the jurors is ultimately found to have leaked information, they might risk civil or even criminal penalties in the court system of their jurisdiction. These penalties can be much stronger than the crypto-economic penalties through the juror misbehaviour court we discussed above, which are upper bounded to the amount of stake that the juror has deposited. 

To what degree is it possible to achieve this level of juror vetting in a decentralized environment? One can use decentralized tools, such as curated lists, to verify some aspects or the identity of potential jurors. This is the vision of having courts gated by soulbound tokens (SBTs), where in order to be drawn in certain courts, jurors need to obtain an SBT by submitting themselves to some curated list that verifies that they have some kind of specific skill, expertise, or qualification. However, if these users were required to submit enough identifying information about themselves as part of the registration in these decentralized lists so that they could be realistically held accountable for leaks before the court system of their jurisdiction, that would create new problems around the handling of this additional sensitive information. 

One can combine the web2-style vetting with the infrastructure of Kleros. E.g., In order to be drawn in a court that considers certain types of confidential evidence, one can require the jurors to possess an SBT that a given entity issues to jurors who have been through a KYC process and have signed an NDA. Now this entity has enough information about the eventual jurors in the case that those jurors can be held responsible for leaks, without that information having to be public.

However, this adds aspects of centralization to the protocol in these cases. The KYC-issuer has the ability to censor jurors by refusing their KYC process. A possibility to partially decentralize this process would be to allow jurors to perform their KYC process with any one of several KYC-providers. Namely, in order to be drawn in a court that handles private evidence, the juror is required to hold an SBT indicating that she has been through a KYC process and signed an NDA; however, she can get this SBT from any one of several KYC-providers. 

Who might provide these KYC services? Companies that integrate with Kleros Enterprise and want vetted jurors could provide this service themselves. The Kleros Cooperative could also act as a KYC-provider. However, you could have other actors, such as law firms that are particularly crypto-enthusiastic, that could play this role. Then, if any one KYC-provider censors a potential juror, she could get her SBT from some other provider. 

Ultimately, the list of which KYC-providers the Kleros protocol sees as meeting the standards required to issue this SBT could be a curated list. In this model, users would be able to submit a new KYC provider  to the list, and if there are disputes about whether this KYC-provider meets the conditions of the list, those disputes would be resolved by Kleros itself. 

A comparison that we have considered is that the level of decentralization of such a system is similar to that of public key infrastructures. Websites that offer encrypted communication using the SSL protocol (i.e. “https” websites) offer an authentication process so that users can know that they are communicating with the website they think they are communicating with, and not a malicious spoof. 

These websites get a “certificate” from a “certificate authority”. These certificates contain the public key of the website, the website url, as well as other information, and are signed by the public key of the certificate authority. Before issuing a certificate, the certificate authority does some due diligence on whoever is requesting it. 

Then, a browser will typically have a list of certificate authorities that it trusts. If a user tries to interact with a website whose certificate is invalid or is not issued by one of those certificate authorities, they get warning messages. 

Then, in this comparison, one can think of the curated list of KYC-issuers as being equivalent to the browser’s list of accepted certificate authorities. In both cases these lists act as a root of trust  - the juror with the KYC SBT is trusted because they have been approved by the KYC-provider which is trusted because it is on the curated list of KYC-providers, and the website is trusted because it has a certificate which has been issued by the certificate authority which is trusted because it is on the list of certificate authorities trusted by the browser. 

Using specialized AI tools

In the field of confidential computing, one uses Trusted Execution Environments (TEEs), namely hardware components that have material security properties designed to prevent information being extracted from them. Then, one typically incorporates a TEE into some computing process to add security guarantees about how the data in that process is used. 

For example, one application of these principles is the LLM tool Confer. Confer is supposed to be a “confidential” LLM in the sense that the company operating the LLM does not have access to its users’ conversations. Confer achieves this by incorporating TEEs into their hardware - for each conversation, a key is generated in the TEE, the user’s prompt is sent to Confer under that key, and the process of decrypting the prompt, using the LLM model to generate a response, and encrypting that response to be sent to the user happens within the TEE, so that the company operating this hardware should not be able to access any of that information. 

Note that as part of the authentication process, Confer’s servers are able to provide attestations to the user that the key they are using to encrypt was generated by a TEE, and the code operating in that TEE is what the user expects (namely, that the TEE’s code does not tell it to release the confidential information in some way). These attestations are signed by a key that the user can compare to public keys of TEE manufacturers, e.g. Intel or Nvidia. 

This trust model here is dependent on the TEE manufacturer acting appropriately. Also, as the operator of the TEE has physical access to their devices, one is dependent on these devices being resistant to various side-channel attacks. While such assumptions are likely acceptable for many use cases, they may not be acceptable for the most sensitive confidential information.

Then, one might try to use these ideas to create an LLM juror that can rule on cases using private evidence, but is incapable of revealing that evidence. Of course, this LLM juror would ultimately vote on behalf of a human PNK holder. In order to give herself an advantage against other jurors and ensure her profitability, this PNK holder would generally have a strategy based on 1) her choice of which LLM to use and 2) the prompt she provides to the LLM. Together these choices should provide a high enough rate of accuracy for the juror to be profitable, with this profitability threshold corresponding to achieving at least a given minimum rate of coherence that is deemed acceptable when the court is parameterized.  

So the party to the dispute has confidential evidence they don’t want to reveal, but the juror also has private information that she doesn’t want to publish so as to be able to maintain her competitive edge: the prompt she uses. 

In order to be drawn in a court that is designed for confidential AI jurors, a juror might need an SBT establishing that she is using an LLM tool that is accepted onto a curated list that requires that that tool has adequate privacy properties. Similar to the idea of allowing many different KYC-providers to issue SBTs that can be used to establish that a human juror has been through an appropriate KYC process, here there might be many different AI tools, using TEEs from different manufacturers, that would be capable of meeting the requirements of this curated list. 

Once the juror is drawn, she initiates the LLM generating inside the TEE two keys, key1 for the party and key2 for the juror. Then both the party and the juror go through an authentication process, e.g. based on signing a message with the private key of the Ethereum address, to obtain their key and are able to verify the attestations generated by the TEE regarding the code being executed in the TEE matching their expectations. Neither key1 nor key2 is able to decrypt the information provided by the other actor. At the end of the process, the LLM should provide the final vote in clear and encrypt a justification under key1. 

For the moment at least, this approach has some limitations. Confer (nor any other confidential LLM I am aware of) is not currently adapted to the key management in this setup. The two key setup would require a somewhat different, though not fundamentally more difficult setup than what they use.  

Also, in order for the party to trust this process, the parties will need to verify the attestations generated by the juror’s chosen LLM. In order to do this, they need to interact with the jurors after the jurors have been chosen. This requires a level of interactivity that is greater than what is currently required of parties to Kleros disputes, who can typically upload their evidence and arguments during the evidence period and wait for a resolution without having to interact with the process as it is ongoing. So the additional requirements of using such confidential LLMs can degrade the party’s UX. However, this can be a promising approach to research, to try to overcome these issues. 

Conclusions

We have overviewed a wide variety of techniques that can be used to protect confidential information in the setting of crowdsourced dispute resolution.

The only drawbacks of the first five techniques in this table - TLSNotary-type techniques, AI anonymization of documents, penalties in the Juror Misbehaviour Court, and the various types of watermarking - are that they might not be sufficient to adequately protect relevant confidential data. So these techniques can all be applied in all cases without degrading the security and decentralization properties of the Kleros protocol. 

The last two techniques - requiring jurors to have an SBT attesting to having been through a KYC process and using AI jurors based on trusted hardware - make the Kleros protocol less open and introduce centralization risks. In some cases, these techniques may be the only tools available to achieve adequate guarantees on the protection of confidential data. In other use cases, where censorship resistance guarantees and alignment with cypherpunk principles are essential, these tools would not be appropriate. 

Also, while the first five techniques are compatible with either the KYC approach or the AI with trusted hardware approach, these two approaches are not really compatible with each other. Technically, one could require the human PNK holder on whose behalf a trusted hardware equipped AI votes to go through a KYC process. However, as the PNK holder does not, themself, receive the evidence, it is not clear why that would be helpful. 

Ultimately, handling confidential information in crowdsourced settings is a thorny problem. While it is likely there will never be a perfect to this, further research might be able to expand the toolbox of available techniques.