Skip to content

Latest commit

 

History

History
31 lines (19 loc) · 7.02 KB

web-of-credit.md

File metadata and controls

31 lines (19 loc) · 7.02 KB

A Web of Credit Framework

By Yonatan Sompolinsky and Alexandra Tran

This document is a high-level discussion on using webs of trust for decentralized credit systems, to be further explored at Rebooting Web of Trust IX.

Web of Trust

Web of Trust (WoT) can refer to the concept of assigning trust among decentralized peers, and to the general data structure central to such assignment processes—a graph of related nodes reflecting various kinds of trust relationships. The social networks encoded in these graphs enable peer-to-peer verifiable trust relationships among all participating nodes. WoT developed in 1992 as a method for decentralized PGP public key verification; direct trust relationships, e.g., those established at in-person key-signing parties, digitally cumulated into massive identity certificate WoTs. Today, many in the cryptography and blockchain communities, notably, the Rebooting Web of Trust community, aim to bring in the next generation of WoTs for decentralized identity.

Web of Credit

As widely understood, “trust” encompasses a range of contexts. Trusting that a key belongs to an entity, evaluating an identity, is different from trusting that entity to sign others’ keys accurately, which is different from trusting it to share objective news articles online or to babysit your kids.

Creditworthiness, or a trustworthiness in one’s promise to pay back a debt, is one such trust context, and thus one natural application of Web of Trust. Our framework for credit assignment, then, currently deviates from WoT’s traditional and prevalent emphasis on identity assessment. One potential route for exploration is if and how a WoT credit system relates to the established decentralized identity framework.

Traditional Credit Markets to Webs of Credit

The traditional credit market is limited by the cost of capital and the cost of underwriting. The cryptocurrency market created a liquidity pool, reducing the cost of capital; digital assets, chiefly, crypto- and fiat-pegged cryptocurrencies, can be transferred with negligible friction. To reduce the cost of underwriting, we envision a WoT that represents credit relationships and functions as a decentralized underwriting platform, operating on top of a blockchain—a web of credit (WoC). Nodes assess the creditworthiness of loan-seeking nodes, and give out loans according to their local credit scoring of nodes (we are not trying to achieve global trust values).

A WoC is represented as a typical WoT, a weighted directed graph (V, E, w), where V and E represent the set of nodes and the set of edges, respectively, and w is a weight function on edges. An edge e=(u,v) ∈ E and its weight w(e) represent the amount of credit u extends to v, and are considered valid only if they are signed by u’s public key. Importantly, this induces a credit relationship between a pair (u,v) of any two nodes: if u and v are directly connected (e=(u,v)), then w(u,v)=w(e). Otherwise, w(u,v) can be inferred from the WoC in a number of ways: w(u,v) can be set to the maximum flow between u and v, or a multiplication of the edge weights on the maximal path, etc. Deciding on how to calculate credit between indirectly connected nodes in a web of credit is crucial in leveraging the graph’s connectivity to defend against Sybil nodes. There is a large literature on crawling social graphs for peer-to-peer Sybil defense, which is necessary to explore further.

Rich Webs of Credit and Skin in the Game

WoCs can organically affect and be affected by smart contracts’ logic, yielding “rich” WoCs. In one direction, a smart contract’s behavior can be conditioned on given users’ contexts; e.g., Alice lets a smart contract govern her lendable funds according to her local view of the WoC. In the other direction, WoCs can be conditioned to update based on on-chain data; e.g., the credit from Alice to Bob automatically increases upon an on-chain transaction from Bob to Charlie, which makes sense, for example, if Charlie is an exchange compliant with AML/KMC regulations.

One important implication is that users can decide how much credit to extend to one another based on how much skin in the game their trustees have; e.g., Alice can lend through her trustee, Bob, specifying in a smart contract that she lends $2 for each dollar Bob lends, up to $200. This further exploits the social graph structure, distributes risk, and enhances users’ trust metrics, reducing the cost of underwriting.

This peer-to-contract lending model automates users’ decisions and updates, and enables complex and efficient credit relationships. It allows users to invest in companies, projects, instruments, and individuals in ways that are impractical with current P2P lending platforms, let alone traditional lending vehicles. With such a system, we can easily imagine how credit can flow from a Korean businesswoman to a young student who has joined an Income Share program to cover his studies; or from a Russian financier to a Filipino worker who needs a stream of payday loans to bridge the gap between his daily expenses and payday. These credit paths will be found and governed by smart contracts, automatically, thereby forming a faster, cheaper, and orders-of-magnitude more connected credit market.

Tradeoffs

The WoC framework introduces some tradeoffs. The first is a passivity-privacy tradeoff: an extreme peer-to-contract, rich WoC model allows the participating users to be offline and completely passive, delegating the lending operation, decision making, context updating, and sybil protection to the smart contracts—but it requires that the contracts know the entire topology of the WoC and the users’ local views. On the other end of the spectrum, the WoC is hidden from everyone, and the decision making happens off-chain—but this requires participating parties to be online at the time of the loan request.

Another tradeoff occurs when a WoC system is serviced by “hubs”—that is, instead of recording the topology of the WoC themselves, users will join a hub, which acts as a server that records and updates the topology of the WoC upon a payment, providing proof of loan request and sufficient credit line to the smart contract. Users can directly borrow and lend with each other through a mutual hub. If a user requests a loan and there is no sufficient credit line within his hub, the hub will act as a node in a higher WoC consisting of other hubs as nodes, and request additional funds from this higher WoC. With inter-hub lending, the credit flows from hub to hub, not from user to user, so credit relationships between users of different hubs are not recorded anywhere.

The fewer the hubs there are in the system—at the extreme, a single hub servicing all users—the more the underlying trust graph can be used; edges between individual users in a single-hub system can always be used to pass funds. However, a system with one or few hubs lacks the high data availability and redundancy of a many-hub system, risking a single point of failure.