The design of a trustworthy ecosystem around media sharing
In this living document, we describe the design of a trustworthy ecosystem around media sharing in Tribler. This ecosystem addresses a key problem in Tribler: free-riding on bandwidth. Specifically, many users that use Tribler to fetch their media content only leech resources from the network, without contributing anything back. Our ecosystem rewards structural good behaviour while punishing free-riding behaviour. We will describe the required components, associated research questions, and implementation challenges.
The design described in the document is written for an integration in Tribler, our academic testbed for research in decentralized technologies. Even though the ideas in this document most likely also apply to other systems, we try to keep the current design focussed and self-contained. The described ecosysystem is an amalgamation of existing ideas and components that work together to address free-riding behaviour at scale. I tried to integrate as much of the existing lab research as possible.
A note on terminology - Even though the original ticket is using the term “token economy”, I’m adopting the term “ecosystem” instead, for the following two reasons. First, it is inaccurate to summarise the whole ecosystem with the term “tokens”. Tokens are only a small part of the entire system and are utilised during the accounting of bandwidth contributions and consumptions. Individual contributions and consumptions are fed to a reputation mechanism, that outputs a (subjective) ranking of trustworthiness. Second, using the term “economy” is misleading since users might think that our system is designed around trade-based incentives (e.g., as in FileCoin). Though we will describe some ideas on making reputation tradable, our system is mostly based on trust-based incentives.
Tribler is our academic testbed that is is downloaded by over 1.5 million users. Our software features an onion-routing overlay that tunnels BitTorrent traffic through relay and exit nodes to provide anonymity. Specifically, a downloader creates a circuit with zero or more relay nodes that ends with one exit node. The number of hops in a circuit refers to the total number of exit and relay nodes used. Each relay node adds an additional layer of encryption, and an exit node proxies traffic from the Internet into our darknet. Users themselves can input how many hops they wish to utilise for their download. Downloading over circuits with more hops features better anonymity but impacts download speed.
Our anonymous overlay suffers from an undersupply of exit nodes, leading to frequent network congestions and an overall degradation of download speeds for all users. This is not entirely unexpected since running an exit node is often not without legal risks. As such, we consider our exit node capacity as a scarce resource, that must be allocated amongst users in a fair manner in case of undersupply. Similarly, we require relay nodes when one wishes to include one or more relay nodes in its circuits. By default, every Tribler user operates a relay node by default since there are minimal legal risks involved with running a relay node. The full protocol description is provided in this document.
In summary, we want to reward good behaviour (providing anonymous bandwidth to the network) and punish bad behaviour (structurally leeching anonymous bandwidth from the network, e.g., free-riding).
Given our problem description, we now state three design requirements for our ecosystem.
Incentivise structural good behaviour - TODO
Minimal user intervention - TODO
No centralised components - TODO
Our ecosystem consists of four mechanisms, as given in the figure below.
The first component that we introduce is an accounting mechanism, used to securely record community contributions on a distributed ledger. Our primitive ledger, named TrustChain, is capable of tamper-proof recording of events and has superior scalability compared to state-of-the-art blockchain ledgers. Instead of maintaining a fully shared log of records, TrustChain equips each user with its own individual ledger, fully maintained by that user themself. Individual ledgers are cryptographically linked when two users interact. We specifically avoid the need for network-wide consensus, since such a mechanism is unable to scale to Internet-level communities. Instead, bilateral agreement is reached between interacting participants. At the time of writing, TrustChain has recorded over 141 million transactions, created by over 80.000 unique participants. TrustChain is currently being used as a primitive component for decentralized applications, including self-sovereign identity and secure payments between strangers.
TODO: The above text should be replaced by the Bami mechanism, which is more scalable, secure and mature than TrustChain.
The second component is a reputation mechanism that estimates the trustworthiness of agents in a digital community. Trust is a cardinal requirement for sustainable management of a common good since the reputation of individual and others heavily influence the incentives of agents to show good behaviour. We envision that each user locally computes trustworthiness scores, based on the discovered records in the global DAG. The output of the reputation mechanism is a trustworthiness ranking.
Our third component is an allocation mechanism, that determines who gets access to a shared resource. These local decisions are driven using trust scores computed by reputation algorithms. Allocation is at the core of commons management since improper allocation policies will still lead to a collapse of the community. Our allocation policies do not require mediation by a centralized authority; instead, community members work together to ensure fair and efficient allocation amongst all members.
We now describe different attacks on ecosystem and elaborate on possible solutions for each attack.
The Sybil Attack is one of the most challenging attacks in open decentralized systems. It involves an adversary that operates multiple, fake identities in order to subvert the network. This attack mostly happens when the cost of creating a new identity is negligible. Within Tribler, a peer can mount a Sybil Attack to leech resources from the network.
We are well-aware of the threats that Sybils pose to our network integrity. Addressing the Sybil Attack is a cardinal research direction of our lab. Existing proposals to address Sybil Attacks at the network layer include the adoption of a Proof-of-(useful)-Work, leveraging self-sovereign identities, exploiting geographic proximity and building a latency-diverse neighbourhood in the overlay. In addition, the adopted reputation mechanism should address Sybils in some form. We require adequate protection against Sybils at different layers in our stack. This includes defence mechanisms in both the network layer and in the adopted reputation mechanisms.
TODO
- What is the effect of partial/imperfect accounting? We cannot assume that every user possesses the most recent version of the global work graph at any time. Therefore, the adopted reputation mechanism must be able to deal with partial information, e.g., a user might be not know some contributions/consumptions.