P2P Transactions based on Trust

Problem Statement and Solution

In existing centralized marketplace solutions (amazon, eBay, ...) the platform providers take the role of all-powerful gatekeepers. This centralized authority can remove certain products due to "moral concerns", block users or vendors or highlight their own products and make competing vendors difficult to reach. In some cases, they can also intervene in the trust-building process itself: Inappropriate reviews are removed on a whim, bad reviews are hidden or are cumbersome to submit or find. Trust relationships built up over a long period of time are always dependent on the goodwill of the platform operator and ultimately also on the lifetime of the technical platform itself.

For many types of transactions, however, there is no central platform with a reliable rating system in the first place and one is at the mercy of one's gut feeling. Even in industrialized countries, this applies not only to transactions in moral gray areas, but to most transactions between two parties who are selling something privately and are not primarily acting as traders. If we go to third world countries, these transactions make up the majority of all transactions and the possibilities to assess the degree of trust of the counterpart are often reduced to knowledge of human nature and hearsay.

Therefore, there are a number of reasons to look for alternative solutions, one of which is presented here in the form of a platform and payment service provider independent decentralized Peer-To-Peer (P2P) solution. This technical solution enables trust-based trading of goods and services between parties based on a history of "certificates of trust" using Atala PRISM. By means of an app (with integrated wallet), two parties can prove their trustworthiness to each other and thus come to a trade agreement. The establishment of trust is completely independent of the marketplace (where the offer is presented) and the method of payment (cash, EC, Ada, ...) and can therefore be used anywhere. 

Concept

Basics

Instead of "certificates", credentials of trust are issued by both parties upon successful transactions. In the following, these credentials will be referred to as "Trust Tokens" to move away from the PRISM/SSI terminology (but technically this is identical). For example: a seller issues a "Trust Token" to the buyer. This "Trust Token" certifies to the buyer, the successful payment. At the same time, the seller receives a "Trust Token" for the successful delivery of a good or service.

The seller-buyer relationship represents the simplest conceivable case. Other scenarios are, for example, the request for services (requester-fulfiller) and the interchange of goods without payment. The procedure is essentially the same and independent of the traded goods/services or the payment for them.

Using PRISM/SSI terminology, each of the two participants in a transaction is always both an "issuer" and a "holder". In the ideal case (happy path), each participant certifies the other to be a good transaction partner. The third party in the trust triangle, the "verifier", using this terminology, represents e.g. another potential buyer who asks the seller to show "trust tokens" of past transactions. If the seller can show enough tokens, the seller can be considered trustworthy. At the same time, a seller can also ask the buyer to show trust tokens from past transactions to ensure that the payment will be made.

Over a certain period, this creates a history of verifiably successful transactions for all participants, which creates trust and gradually enables transactions with higher volumes. A network of trust is created. The proposed model becomes interesting in the presence of fraudsters, suppliers of inferior goods, non-paying customers or transaction participants who do not issue mutual trust tokens.

Fraud

The decentralized system proposed here lacks a central authority to turn to when transactions do not produce the desired result for one or both participants. To replace this central authority, it requires an extension of the presented concept:

First, the trust tokens mentioned above are extended by a textual description and issued in three (possibly more) tiers: 1 - Successful transaction "Good customer" / "Good seller". 2 - Successful transaction with restrictions "Poor payment record" , "Goods with defective..." 3 - Unsuccessful transaction: fraud. The issuance of a certificate from the Issuer to the Holder cannot be prevented in Atala PRISM. Consequently, a Seller can be issued a "Trust Token" of the "Fraud" type to a Buyer in case of non-payment of a delivered good. However, this alone is not enough, because the recipient (Holder) of these bad tokens can simply ignore it and does not have to show it to new potential sellers (whom he also wants to defraud). He would just always show the "good" Trust Token.

The problem can be solved by issuing a start-of-transaction token for both the seller and the buyer to a central location before each trade. This token contains no information other than the Id of the participant in the transaction. The central entity is thus a holder of all start-of-transaction tokens, but does not issue any certificates/tokens itself and can be used by all parties as a target of a verification process.

In the case of the above fraudster, who has now collected e.g. 3 "good" "trust tokens" and 10 "bad" ones (which he would like to ignore) there would thus be 13 start-of-transaction tokens in the central registry. Before starting a new trade with this fraudster, a potential buyer (verifier) can compare the number of transactions recorded in the registry with the presented tokens. However, if this person deliberately shows only his 3 "good" tokens, there is an obvious mismatch here and the participant is not transparent/not trustworthy.

Bad ratings and collateral

In the previous example it was assumed that the good or bad rating is justified. I.e. in case of objectively good delivery of goods or complete receipt of money a good rating was given and in case of missing delivery or insufficient quality a bad rating was given. An additional extension of the concept becomes necessary if the issuance of a "Trust Token" does not take place or is deliberately done with a negative evaluation, although the delivery of goods objectively complied with the terms of the agreement. In these and other cases, it may be necessary to involve a neutral third party to look at and judge the circumstance at hand. In a decentralized system, this may be randomly selected participants of the same transaction platform who decide on the case based on the facts presented by the disagreeing parties. Collateral deposited by both parties prior to the start of the transaction can ensure that both compensation can be given and the independent third parties are paid for their efforts. In this case, similar to a court case, the losing party has to bear the costs. There are already a number of game-theoretically well thought-out (in some cases multi-level) models for this, which an implementation could be based on.

Privacy

The central point of Atala PRISM's considerations is not only to create trust, but above all not to reveal too much information to interested parties.Before a transcation, the primary concern is to ensure that the counterpart is reliable and has already handled a certain number of transactions satisfactorily. Details about previous customers and their purchases should remain hidden. In the presented system, no data from previous transactions is disclosed to third parties. Only the number of transactions is transparent. The proposed platform also does not specify the payment method: whether payments are made in cash or ADA is irrelevant to the trust relationship.

Similarly, the way in which the parties come together for the purchase is basically independent of the trust relationship. Consequently, making the offer, making the payment, and building trust are three distinct aspects: The focus of this proposal is on implementing the latter, as it is the main innovation.

Implementation

The described process will be technically implemented with Atala PRISM and will result in an OpenSource library to map the trust-building processes using a "state machine" for the two interacting parties. Furthermore, it will include all functions with which potential buyers ("verifiers") can assess the trust of a future transaction partner.

Although a trust creation process could be implemented with third party wallets (PRISIM does not currently include a wallet), this will not a pleasant user experience due to the number of transactions and verification steps. Consequently, it requires a dedicated end-user-facing application (e.g., in the form of an app) that models the entire process, the DID wallet, and the implementation of the conflict resolution process (implemented as Plutus Smart Contracts) in one application.

However, before the technical development begins, an analysis of all the processes, the current and future technical capabilities of the PRISM SDK and the conflict resolution is required. This document will be provided to the community and ideally discussed with Emurgo/IOG.

Deliverables

1. Whitepaper describing technically how to use the Atala PRISM SDK in decentralized P2P transactions.
2. Open source library for the described processes (Kotlin)
3. Android (and iOS) app with integrated wallet as PoC

Adoption

It is difficult to make concrete statements about adoption goals at the current time. The focus is on theoretical and technical testing. If a PoC is successfully implemented, it should be followed by at least one further proposal that finalizes the application and then considers application scenarios.

Show us the money

1. Writing the whitepaper and technical evaluation of all scenarios.
   80 USD/h x 35h/week x 4 weeks
   11,200 USD
2. Developing the core libraries and the wallet.
   80 USD/h x 35h/week x 24 weeks
   67,200 USD
3. 3. Project website; documentation, explanatory material
   2,000 USD (including external contracting for design)

This sums up to 80,400 USD. As a professional software developer this isn't attractive to pursue considering the classic under-estimation problems of software development. For a community – on the other hand – it is a lot to ask for, and I believe it is even too much. Therefore, I would take 40% of the estimated costs from my on pocket, being a community project from which we all would profit in the long term. This way the requested amount is reduced to 48,240 USD

Getting on the road

Within 3 months after project start (directly after funding)

• Writing the whitepaper and presenting it within the community. Discussion with IOG/Emurgo about the proposed technical implementation.

Within 6 months after project start

• Build out the core libraries and a PoC solution of the wallet

Within 9 months

• Testing the capabilities of the implementation. Collecting community feedback and presenting and promoting the developed solution within the Cardano-Community.
• Depending on the feedback preparing for an additional proposal to get the application to use in specific regions or usecases.