This is my second post on defining a trust metric for Ripple, or in fact any peer-to-peer credit network which relies solely on trust. In my last post, I looked at a simple approach based on measuring the average ratio of credits and debts for a user. While this wasn’t a bad start to thinking about the problem of trust in general, it suffered from being too simple (I’ll explain why.) In this post, I want to explore a new approach suggested in a comment by Jordan Greenhall, based on measuring trust as a perspectival, probabilistic calculation rather than an inherent property of a node.
First, let’s revisit the reasons why a trust metric is so critical for any peer-based credit network like Ripple to scale.
Ripple is a system to create money out of credit relationships between peers, rather than between individuals and banking institutions, or the state. It uses a principle of mutual credit, allowing users to “create money” as IOUs within the context of a relationship of trust. Since IOUs can be used to cancel debts out over time, Ripple can be described as a way of keeping money as a unit of account, while dispensing with the complicated, undemocratic ways in which money supplies are created in modern economies.
The critical difference between Ripple and more traditional types of mutual credit circles is the reliance on pairwise relationships between nodes, rather than relationships between nodes and a centralised book-keeper. One of the chief difficulties with a LETS approach to mutual credit is getting debtors to pay down their negative balances, as well as preventing stagnation due to hoarding by creditors. This usually takes some administrative overhead. In Ripple’s case, we are leaving the job of settling balances to peers to sort out for themselves, rather than taking a top-down administrative approach. (For an overview of Ripple and its many advantages, see Is Ripple The Future of Money?)
There is however a tension within Ripple which needs to be resolved for it to scale and achieve its potential as a substitute for money. The more I think about Ripple, the more this basic problem looms: friendship is the predominant context for relationships with high degrees of trust. People tend to expect their “strong ties” not to wrong them by ignoring debts, for example. It’s always riskier to lend money to someone you don’t know, even with some legal recourse if things do go wrong. However, the problem this creates is that the use of money in general, which Ripple seeks to create, is typical of “weak tie” relationships. The vast majority of monetary expenditure, for the average person, is with people they don’t know or trust.
The basic tension is this: the people who a person typically trusts with money are not the kinds of people we need to use money with much. A Ripple network which tries to scale and become useful for impersonal transactions won’t work if the nodes in people’s immediate networks are predominantly friends and family. This would actually require friends to get used to having debts with each other quite a bit more than they already do, and would probably create some discomfort.
This sets the context for why Ripple needs a trust metric. As discussed in a previous posts on social currency, such metrics try to quantify and represent a person’s social capital. In Ripple-language, social capital is really credit-worthiness, or the extent to which you are “deserving of credit.” The effects of quantifying and making trust visible are not to be underestimated. A good trust metric reinforces positive behaviour, punished bad behaviour, and gives strangers an excuse to trust each other in ways they otherwise wouldn’t.
This sounds like the kind of tool which could help Ripple resolve the tension between strong ties and the ability to scale. With a trust metric, we have a way of quantifying and representing creditworthiness to people who don’t know each other, and therefore creating a basis for trust. A trust metric could oil the wheels of a more impersonal, highly scalable Ripple network, with far more extensive payment routing capacity. With that, let’s move on to discussing why the approach in my last post won’t cut it.
Trust as Credit Ratio
In Defining a Trust Metric for Ripple, I suggested that creditworthiness could be boiled down to the weighted average credit ratio for each of a user’s pairwise credit relationships. In simpler language, this is just a ratio which expresses how in debt or credit a user is overall, weighted against the volume of credit capacity in each relationship (i.e. giving 10 times more weight to a 50%-used credit allowance of a thousand pounds, to the same of a hundred pounds.) We can summarise this in a simple formula:
A’s overall credit ratio = A’s total credit capacity / A’s total credit limit
What comes out of this is a number which expresses the overall credit ratio. Someone with 1 has perfectly balanced accounts. This gives a snapshot of the overall credit balance at a given point, but we have to go further. What we’re really concerned with is how this ratio pans out over time, so we might take a six-monthly average ratio. This approach isn’t a bad start – it does make sense to look at credit ratio over time as evidence of whether someone is balancing their accounts (and is therefore creditworthy.)
However, there are some serious limitations. For one, we can’t distinguish between two people who have vastly different credit allowances and network size, but the same overall ratio. We could add the average amount of credit a user has to the metric, like so:
0.8 | £3,000
However, there’s another problem (which I think is the knock down argument for this approach in general.) We still can’t distinguish between someone who has a friend who says they will loan them a million pounds (but isn’t being serious), and someone with thousands of node relationships who will lend him a more modest but real number. This is where I’ll leave this approach (in the graveyard of ideas, somewhere.)
It’s time to move on to Jordan’s proposed approach. I think this has the beginnings of a real solution.
I’ve always defaulted to a sort of Bayesian “perspectival” model where you can’t really give a global universal score for anyone, but you can give *my* perspective on them. You look at the credit I’ve issued to people in the network, the credit they’ve issued to people in the network (etc.) and use this network-cascade to derive the credit score “my network” gives to any given individual. So if I don’t know you but many of my friends do, then your credit score for me is (my credit to friend n * their credit to you) summed over N.
Jordan Greenhall, Blog Comment, Aug 17th
The perspectival approach to measuring trust doesn’t treat trust as an inherent property of a node. Instead, it tries to make a logical, probabilistic calculation about how much you can trust someone, based on how this individual is connected to you in the trust graph. If you have no common connections with a user, there is no credit rating, but that’s not such a bad thing, as I’ll explain.
What’s elegant about this as a general approach is that it takes the act of extending someone a credit limit as a vote of trust. This is intuitive, since by extending credit you are explicitly trusting someone, to that degree. It’s also parsimonious, since it gives us a basis for deriving a trust metric without the hassle of additional social gestures like reviews, or ratings.
The information about trust is encoded in credit graph itself: all we need is a way of extracting it and working with it. Based on this information about trust in first-degree connections, we can make inferences about degrees in second, third and fourth (etc) connections. In other words, we can try to estimate how much a user should trust someone unknown to them, based on how much they trust people who (directly or indirectly) already trust him.
Here’s my attempt to turn Jordan’s suggestion into a formal approach which could be implemented. I don’t yet know if this is the best way, however I’m partly sharing this in order to get more feedback, and help improve it. First of all, let’s make a basic assumption:
Proportionality Principle: In a credit network, a user trusts someone in proportion to the amount of credit they give them.
This principle allows us to draw conclusions about degrees of trust within a user’s primary network. If trust is proportional to credit awarded, this becomes relatively easy. John trust Sarah with £100, but trusts Jane with £1,000 – he therefore trusts Sarah 10 times more than Jane. In reality, degrees of trust are not likely to be as precise or as directly proportional to credit allowance, as there are other factors which determine how much credit we extend to people. However, the assumption is generally true enough.
The second assumption is about how trust decays:
Trust Decay Principle: Trust from one node to another decays as a function of the distance between them, as measured by number of hops.
This reflects real life: we trust our friends more than our friends’ friends, but we trust the latter more than total strangers, and so on. In credit networks, there is a similar logic: if you are willing to extend credit to John, you must have some degree of confidence in who John extends credit to, as this has bearing on his ability to keep his promises to you.
The rate at which trust decays is something difficult to put a precise number on. It is probably going to be a subjective exercise in working out what feels right. However, since many laws in nature are power laws, and I find a linear relationship to overscore trust, we’ll go with this for now:
Trust coefficient c = 1 / Number of hops, squared
Finally, there is one more assumption we need to make. This one might be more controversial than others, but I think we gain some significant flexibility as a result:
Normalisation Principle: The trust score of the individual with the highest amount of credit in a user’s network is 1, (and every other trust score is therefore a proportion of 1.)
Here, we’ll assume that a score of 1 is the maximum anyone can have in a user’s primary network, as a matter of convention. Everyone else’s score can be worked out as a proportion of 1. This has the consequence that giving someone a million pounds of credit doesn’t allocate them proportionally more power in accumulating trust for their own network (which would be easier to game.) All it means is that, by implication, the user who extends credit has a very high threshold of trust for said user, which affects how the metric will diminish the significance of much lower levels of trust in her primary network.
Putting it to Work
With our basic assumptions in place, it’s time to try out the mechanics of the approach. Here is a credit network graph, showing a small cluster of users around A.
The numbers represent an amount of credit awarded between the two nodes, in the direction of the arrows. (A gives C 50 credit, etc.) As you can see, there are some first, second and third degree connections, as well as an ambiguous 3rd/4th degree connection, between A and H. We can now work out everyone’s trust score in this graph, from the perspective of A.
A extends the biggest credit line to B, so A‘s trust for B is simply 1.
C has half as much credit as B. A‘s trust for C is 0.5. In other words, A trusts C 50% as much as B, who is the baseline user.
C has 80% as much credit as B. A‘s trust for D is 0.8.
Moving on to the second row, we need to use our decay coefficient. Here’s how it can be done:
Starting with the simplest, A‘s trust for H is expressed as
A:H = A:D * c * (D:H)
c is our trust coefficient, not the speed of light. In this case, we’re at two hopes, so
c = 1 / 2^2
c = 0.25
D:H is simply 1, since D has given H the most credit. Plugging the values in, we have…
A:H = 0.8 * 0.25 * 1
A:H = 0.2
This one is also straightforward, like A:H…
A:E = 1 * c * B:E
A:E = 0.25 * 1
A:E = 0.25
Moving on to more complex examples, let’s take F, who has has multiple connections to A, via C and B. In this case, I suggest we just take the sum of the trust accumulated from both connections. (Rounded to the second decimal.)
A:F = (A:C * c * C:F) + (A:B * c * B:F)
A:F = (0.5 * 0.25 * 1) + (1 * 0.25 * 0.67)
A:F = 0.12 + 0.1675
A:F = 0.29
G is an orphan node, with no friends. He’s not connected to A, so from A‘s point of view, he has no trust score. If A decided to trust G with credit, he would have to rely on other information than his network’s opinion of G, because it doesn’t have one. This isn’t a bad consequence, since it’s true to life.
Finally, the most complex relationship, A:I. We need to find the sum of trust incurred through both paths, using different coefficients. However, we can make life simple. Since we already know A:F, we can use that for one of the branches, and a coefficient for just one additional hop. The other branch, via D, is straightforward enough. (Final value rounded to the second decimal, again.)
A:I = (A:F * c * F:I) + (A:D * c * D:I)
A:I = (0.29 * 0.25 * 1) + (0.8 * 0.25 * 0.7)
A:I = 0.0725 + 0.14
A:I = 0.21
No doubt, there will be more nuances to work out before this model can work well. One of them might be capping trust to 1, so no user’s trust can exceed the baseline user’s. There are also questions about how to communicate the meaning of the metric to users in an intuitive way, and calibrating the decay coefficient correctly. We also have to consider the problem of how to present a user’s trust degree back to them. I’ll leave these questions to future posts and comments.
Hopefully, this describes the beginning of an approach which can actually work. As a result, we might have a metric which works the same magic on Ripple as reputation points do on eBay. Imagine how limiting eBay would be if you had no metric serving as a basis for trust between strangers – it wouldn’t work. This is how important I think a trust metric is for Ripple to be able to scale properly in the real, impersonal world of money and credit.
Thanks to Jordan Greenhall for suggesting a perspectival approach. As usual, I would be grateful for any comments or suggestions from anyone which can help push this forward.
Find Out More