diff --git a/reputation/invoice_based_reputation.pdf b/reputation/invoice_based_reputation.pdf new file mode 100644 index 00000000..ab1f9221 Binary files /dev/null and b/reputation/invoice_based_reputation.pdf differ diff --git a/reputation/invoice_based_reputation.tex b/reputation/invoice_based_reputation.tex new file mode 100644 index 00000000..45cfe4f3 --- /dev/null +++ b/reputation/invoice_based_reputation.tex @@ -0,0 +1,192 @@ +\documentclass{article} +\usepackage{amsfonts} +\usepackage{amsmath} +\usepackage{hyperref} + +\title{Invoice - based reputation system} +\author{Jan Betley\\ Golem Factory} + +\begin{document} +\maketitle + +\section{The main concept} + +General note: this is a crude description of an idea, not a "final" design I'm covinced will work. +IOW, this document should be enough for discussions and future plans, not something we can now go and implement. + +\subsection{Assumptions} + +The most important assumption in this document is the expected utility maximization hypothesis\footnote{ +\href{https://en.wikipedia.org/wiki/Expected\_utility\_hypothesis} + {https://en.wikipedia.org/wiki/Expected\_utility\_hypothesis} +}: providers and requestors will do what they think is best for them, and the main purpose of the reputation system +is to construct an environment where the most profitable behaviour is also the desired behaviour. + +Few more assumptions (some of them are questionable even as approximations - there is a further section discussing them): + +\begin{enumerate} + \item The ground truth about all payments on the market (timestamp, amount, sender, receiver) is known. + \item The ground truth about all invoices on the market (timestamp, amount, sender, receiver) is known. + \item Obtaining \& parsing the data about invoices/payments costs neither money nor time. + \item The only thing provider cares about is "how much I will be paid?" and the only thing requestor cares about + are the quality of the services received and amount paid. + \item The market is balanced, i.e.: + \begin{enumerate} + \item Good enough and sufficiently cheap provider will spend no more than X\% of time waiting for agreements, for a reasonable X (e.g. 10\%). + \item Requestor willing to pay a sufficient amount of money will find enough providers fast enough + \end{enumerate} +\end{enumerate} + + +\subsection{General idea} + +The full knowledge about invoices and payments gives us a crude approximation of the "reputation-like" information: +good requestors pay, good providers are paid. In more detail: +\begin{enumerate} + \item Provider POV: the requestor who paid bigger part of their past invoices will more likely pay another invoice than another requestor + who paid less past invoices. + \item Requestor POV: the provider whose invoices are usually paid more likely provides high quality services than a provider who is paid + only rarely or never. +\end{enumerate} + +Justification behind these statements: +\begin{itemize} + \item Both first and second: providers/requestors market strategy rarely changes, so it's likely that when trading with us + they will behave similarly to the way they behaved in the similar past situations. + \item Second: if a requestor doesn't pay the provider, they are less likely to trade with them in the future (e.g. because of the provider's local history), + and thus requestors more often pay providers they want to trade with, and those are more likely the providers we want to trade with. +\end{itemize} + +\subsection{Detailed strategies} + +There are countless possible strategies that are consistent with the main idea, strategies in this section are just examples. + +Provider strategy: +\begin{enumerate} + \item Gather a local history of all our contracts - (requestor id, invoice amount, paid amount) + additional details (e.g. agreement length, initial demand etc). + \item Send offers to the market with "base" prices, that will later (in the negotiation phase) be increased for untrusted requestors. + \item When a requestor responds to the our initial offer: + \begin{itemize} + \item If this is a new requestor (i.e. one that didn't yet trade with anyone on the market, or didn't trade enough): + \begin{enumerate} + \item Counteroffer with a "payment in advance" property + \item If accepted, start with sending a debit note (for some fixed amount) with a short payment time + \item Refuse to start an activity until the first debit note is paid + \item Continue in the same manner, i.e. request upfront payments + \end{enumerate} + \item If this is a requestor we've already traded with, and they didn't pay all the due amount: + \begin{enumerate} + \item Add the missing amount (possibly with some discounting factor) to the fixed amount + \item If agreed, start with sending a debit note for the missing amount, with short payment time + \item Refuse to start an activity until the debit note is paid + \end{enumerate} + \item In other cases, i.e. when requestor has some experience on the market and they either didn't trade with us or paid a full amount: + \begin{enumerate} + \item Estimate the \% of the final invoice we expect the requestor to pay us. In the most primitive version this might be just the \% + of their invoices they paid until now, although this can (and should) be done much better\footnote{E.g. if they didn't pay a provider that is + never paid, there's a big chance this is an invalid provider who just does no work at all, but if they didn't pay a provider who's usually + paid fully then probably something's wrong with the requestora. + We should also include in the estimations few other types of the information, e.g. + \begin{itemize} + \item Our own experiences with this requestor (i.e. requestor who dutifully paid us a lot will probably pay again). + \item Expected agreement length, proposed payment interval etc. + \end{itemize}} + \item If we estimate $\sim$100\% of the invoice will be paid, accept the offer. + \item If we estimate less will be paid, reply with a counter-offer with higher prices, so that they compensate for the \% of the invoice + we expect not to be paid. + \end{enumerate} + \end{itemize} +\end{enumerate} + +Requestor strategy: +\begin{enumerate} + \item Gather similar local history as the provider + \item Sign agreements that require an advance payment only with providers you have a reason to trust + (e.g. because you traded with them before or because they have a good history on the market) + \item Except for the previous point, just try to sign the most profitable agreements, including any information about the "provider quality" you have. + This should include "high quality providers are paid more often than low quality providers", but also other things like "provider benchmarks" or + the history of the requestor's trades. + \item Provider sends debit notes/invoices stating the expected amounts, but requestor decides freely about the amount paid (they might also decide not to pay at all). + When deciding about the amount to pay, consider a following tradeof. The less money I pay: + \begin{itemize} + \item (gain) The more money I still own. + \item (loss) The more expensive deals I will have with other providers, especially if I decide not to pay a provider who's usually paid. + \item (loss) The more I will have to pay to trade with this provider again. + \end{itemize} + And pay any amount you consider best from your POV.\footnote{ + This should somehow converge to "the worse is the provider, the less we want to pay" - and that's exactly what we want. + } +\end{enumerate} + +\subsection{The reputation system deployment process} + +So we have defined some strategies for requestors/providers. +Who will use them? How to encourage others to use similar strategies? +The plan looks as follows: +\begin{enumerate} + \item Implement provider/requestor strategies described above. Set them as default provider strategies and recommended requestor strategies. + \item Put on the market enough providers/requestors who use these strategies. + \item (Crucial assumption that should be analyzed) When a new provider/requestor enters the market, they use these (or similar) strategies, because they + are the most profitable. Thus, as the market grows, the adoption level of these strategies remains high. + \item Finally, we can remove the initial providers/requestors and the reputation system will still work. +\end{enumerate} + +\section{Discussion} +\subsection{Assumption 2 - ground truth about invoices} + +This is hard, and this must be solved well for this whole idea to work. +There are two general directions: +\begin{enumerate} + \item Implement some logic that will enforce this ground truth, e.g.: + \begin{itemize} + \item Put invoices on some additional chain + \item Require invoices to be signed by both sides (?) + \end{itemize} + \item Drop this assumption, but modify the strategies so that "agreeing on the invoice amount" will be profitable for both sides, e.g. + \begin{itemize} + \item Both provider and requestor "report" invoices somewhere + \item For the requestor it's always (or usually?) better to report the same value that was reported by the provider + \item For the provider it's always (or usually?) better to have the invoice value confirmed by the requestor + \end{itemize} +\end{enumerate} + +\subsection{Assumption 3 - obtaining/parsing invoice data cost} + +We'll need a node information API (GAP-14) that will gather the data and provide useful simple aggregates that will be consumed in strategies. + +This looks like a fully centralized solution, but: +\begin{itemize} + \item If the invoices are gathered in a public location (e.g. a side chain) then there can be multiple different APIs aggregating the same information. + \item If the invoices are gathered in a database without a public access, then there could be some other entity who also gathers invoice data. +\end{itemize} + +\subsection{Other assumptions} + +\begin{itemize} + + \item Assumption 1 (payments ground truth) is true, because we pay in crypto. + \item Assumption 4 (providers care only about money, requestors care only about service quality) is false\footnote{e.g. requestor would also want their data not to be stolen.}, but this is simply what this reputation system gives us - and it's quite a lot, +hopefully enough for a "serious" start of the market. + \item Assumption 5 is fulfilled for any functioning market. +\end{itemize} + +\subsection{Misc random notes} +\begin{enumerate} + \item There is a malicious strategy available: + \begin{enumerate} + \item Put my own providers and requestors on the market + \item Trade between them only until their reputation grows enough + \item Use requestors to steal from other providers, use providers to steal from other requestors + \end{enumerate} + This is an important problem, but hopefully solvable: + \begin{itemize} + \item Because of the transaction costs, building up reputation this way costs + \item Provider-requestor clusters like this will be visible in the data. E.g. a provider who got paid by X different requestors surely looks better than + a provider who was paid multiple times by only one requestor. + \end{itemize} + \item Maybe debit notes would be better than invoices? This seems to be a good direction, because it gives us an additional useful information - + the amount accepted by the requestor. Accepting and not paying later is much worse than just rejecting the debit note. + \item The obvious vulnerability is that if an estabilished requestor (i.e. not paying in advance) intends to leave the market, then there's no + incentive for them to pay the last invoice(s). This is true, but not really important - estabilished requestors will be rarely deciding to leave the market. +\end{enumerate} +\end{document}