P2P Networks and Blockchains: A Perfect Match, Decades in the Making

Published in

The CoinFund Blog

10 min readMay 14, 2019

Introduction

P2P networks and blockchains are tales of many converging roads. While blockchain was invented in 2009, it combined multiple technologies from prior decades, such as Merkle trees (‘80), fault tolerance (‘89), linked timestamping (‘90), and proof-of-work (‘92). Similarly, the underlying components of P2P networks have also assembled themselves throughout the decades (e.g. Ethernet (’73), TCP/IP (‘83), distributed hash tables (‘01).)

It turns out that these are complementary technologies. P2P networks are a key component of cryptonetworks like Bitcoin, which describes itself as a “peer-to-peer electronic cash system”, since nodes need to broadcast transactions and blocks throughout the network.

While there were many attempts at other P2P networks prior to 2009, most of them failed. They did, however, leave behind a treasure trove of data and research about what worked, what didn’t, and what were the missing pieces. In this post I will discuss reasons why they failed, potential solutions, and arguments on why blockchains are an effective implementation of those solutions.

P2P 101

Formally, a distributed network architecture may be called a peer-to-peer network if the participants share a part of their own hardware resources (e.g. processing power, storage capacity, etc.). These shared resources are necessary to provide the service and content offered by the network and they are accessible by other peers directly without passing intermediary entities. The participants of such a network are both resource providers and resource requestors.

P2P networks have two flavors. It is “pure peer-to-peer” if any entity can be removed from the network without having the network suffering any loss of service. These nodes are referred to as “servents” (SERVer+cliENT). The benefit of this architecture is that it’s fault-tolerant and autonomous. That said, it has slow information discovery and no guarantees about the quality of service. Examples are Gnutella and Freenet.

“Hybrid peer-to-peer” has a central entity that’s necessary to provide parts of the offered network services. One example of such a service is indexing — while there exists a central server that maintains directories of information about registered users to the network, the end-to-end interaction remains between two peer clients.

There are also two flavors of indexing — centralized and decentralized. With centralized indexing, a central server maintains an index of the data or files that are currently being shared by active peers. Each peer maintains a connection to the central server, through which the queries are sent. This architecture is simple, operates efficiently for discovery information, and provides comprehensive searches. The downside is that it’s vulnerable to censorship and other types of attacks, and has a single point of failure. The most famous example is Napster, which had centralized indexing and distributed file exchange.

With decentralized indexing, the central server registers users and facilitates peer discovery, while “supernodes” maintain the central indexes and proxy search requests on behalf of peers. Queries are therefore sent to supernodes, not to other peers. Peers are automatically elected to become supernodes if they have sufficient bandwidth and processing power. Relative to purely decentralized systems, this architecture reduces the discovery time and message traffic between nodes. Relative to centralized indexing, this architecture reduces the workload on the central server but has slower information discovery. KaZaA is the most famous example here.

A Survey of Pioneers

While Napster and BitTorrent are the most famous examples of P2P networks, there were actually many attempts around other types of networks, mainly around compute and storage. Here’s a brief overview of the lesser-known but equally-interesting projects:

POPCORN, 1998: This project provided a market-based mechanism for trade in CPU time to motivate processors to provide their CPU cycles for other peoples’ computations. It had a notion of a “market” which was a trusted intermediary that was responsible for matching buyers and sellers, transmitting computation requests and results between them, and handling payments and accounts. Interestingly, the project also defined an abstract currency called a “popcoin”. All trade in CPU time was to be done in terms of popcoins, which were initially implemented as entries in a database managed by the market. Each user of the POPCORN system had a popcoin-account paying from it for CPU time required, or depositing into it when selling CPU time. An online Popcorn market was live from 1997 to 1998 but is no longer being maintained.

OceanStore, 2000: The goal was to provide a consistent, highly-available, and durable storage utility atop an infrastructure comprised of untrusted servers. Any computer can join the infrastructure, contributing storage in exchange for economic compensation. The project envisioned a cooperative utility model in which consumers paid a monthly fee in exchange for access to persistent storage. Pond, a prototype implementation of OceanStore, was published in 2003. It wasn’t commercialized, however, and the source code is available here.

MojoNation, 2002: This was an open-source P2P content sharing system that was used to share digital content. It used a swarm distribution mechanism that allowed file sharing from parallel and multiple peers, similar to BitTorrent (in fact, the founder, Bram Cohen later went on to create BitTorrent!). Interestingly, MojoNation created an economy of incentives, using micropayments called “Mojo” to reward users for distributing and uploading files to the network. To earn Mojo you can act as a server, allow your bandwidth or hard drive space to be used, or sell services, with those buying and selling determining the prices. Users also created a reputation system of sorts since the quality of service and the reliability of service providers were under review and tracked by agents. MojoNation ceased operation as a commercial enterprise in 2002, when it was replaced by the noncommercial Mnet project, which was open sourced but not actively maintained.

Tahoe-LAFS, 2008: This is a system for secure, distributed storage that uses capabilities for access control, cryptography for confidentiality and integrity, and erasure coding for fault-tolerance. It’s open sourced and still actively maintained, and is commercialized by LeastAuthority, which charges $25/month for storage. Notably, Zooko Wilcox of ZCash is one of the project founders.

“Sounds like most of these didn’t take off. Did anything succeed?”

Yes — BitTorrent. According to a 2018 report from Sandvine, file-sharing accounts for 3% of global downstream and 22% of upstream internet traffic, of which 97% comes from BitTorrent.

Even though it lost much of its market share over the past decade, today BitTorrent comfortably sits in fifth place with 4.10% of all Internet traffic. Here’s the full picture according to Sandvine:

Why did many P2P Networks fail?

There are many reasons, including legal issues, the convenience of alternatives, supply & demand dynamics, and overall PC & internet penetration. In this post, however, I will focus on the technical and economic reasons why P2P networks couldn’t scale and sustain themselves.

The Free Rider Problem

In 1954, Paul Samuelson highlighted the market failure of free-riding:

“It is in the selfish interest of each person to give false signals, to pretend to have less interest in a given collective consumption activity than he really has”.

This issue occurs with public goods, which have the properties of being non-excludable (everyone could use them) and non-rivalrous (one use does not reduce availability). Because the services provided over P2P networks have some characteristics of public goods, they often suffer from the under-provision of content. This is likely exacerbated by the voluntary nature of contributions. For example, an analysis of the Gnutella network found that more than 70% of its users contribute nothing to the system.

Large populations

Free-riding worsens with group size. For P2P networks, this limits scalability because it damages their “auto-replication” characteristic, which ensures that content on the network is available in proportion to its popularity because the consumption of resources through downloads is balanced by the provision of resources through sharing.

Natural disincentives

Cooperation consumes a user’s own resources and may degrade their performance; as a result, each user’s attempt to maximize her own utility effectively lowers the overall utility of the system.

The payoff matrix for an application like P2P file sharing

Imbalance of interests

Alice wants service from Bob, Bob wants service from Carol, and Carol wants service from Alice.

Zero-cost identities

While this is desirable for network growth as it encourages newcomers to join the system, it also allows misbehaving users to escape the consequences of their actions by switching to new identities.

How do we solve these issues?

Fortunately, there has been a large body of work in the ‘00s aimed at addressing many of these issues. Below are the five most relevant proposals based on published academic research:

Micropayment systems (Golle et al. 2001)
Shared History (Feldman et al. 2004)
Subjective Reciprocity (Feldman et al. 2004)
Network pricing (Cole et al. 2003)
Admission control systems (Kung and Wu 2003)

This is where cryptonetworks come in. In the next section, I will briefly go through each potential solution and provide a sense of whether cryptonetworks could be the missing piece to the puzzle

Micropayment Systems

In short, micropayment systems lead to a Nash equilibrium where the optimal strategy is to share resources.

Applicability: HIGH —In the ’00s, there was no effective solution to make the negotiation between resource consumers and providers automatic and it was too difficult to deploy the necessary infrastructure, such as secure e-cash and service auditing. Cryptocurrencies and smart contracts effectively solve both of these issues.

Shared History

Every peer keeps records about all of the interactions that occur in the system, regardless of whether he was directly involved in them or not. This allows users to leverage the experiences of others, resulting in higher levels of cooperation than with private history and scaling better to large populations and high turnovers.

Applicability: HIGH — Creating a shared history requires a distributed infrastructure to store the history; a *perfect* application for blockchains.

Subjective Reciprocity

While shared history is scalable, it is vulnerable to collusion, an issue magnified in systems with zero-cost identities since users can create fake identities that report false statements (i.e. Sybil attacks). To deal with collusion, entities can compute reputation subjectively, where player A weighs player B’s opinions based on how much player A trusts player B.

Applicability: MEDIUM — While this will help any P2P network, such algorithms do not benefit from smart contracts. That said, constructing a network graph will also require information to be stored using distributed infrastructure.

Network Pricing

Network users are assumed to selfishly route traffic on minimum-latency paths, but the outcome does not minimize the total latency of the network. One strategy, discussed informally as early as 1920, for improving the selfish solution is “marginal cost pricing”, where each network user on the edge pays a tax offsetting the congestion effects caused by its presence. This leads to a Nash equilibrium with the minimum-possible total latency.

Applicability: MEDIUM — Smart contracts provide the ability to create a contract which contains an algorithm computing the optimal price without the need for a trusted third party.

Admission control systems

A node desiring to receive content from other nodes will need to contribute to the P2P network at a certain level. A freeloader, which has a low service reputation and a high usage reputation, will be denied service. The node will need to either provide an increased level of service or reduce its content usage in order to be readmitted again.

Applicability: MEDIUM — While we haven’t yet solved decentralized reputation, blockchains provide a path forward for reputation without relying on a trusted third party.

Looking forward

Today, we’re seeing many cryptonetwork equivalents of last decade’s P2P networks (e.g. Golem, Livepeer, Filecoin). It’s unclear whether these networks have implemented all of the learnings above, but they did effectively implement at least two — micropayments and shared history.

In addition, the context within which these networks operate has changed. Global PC and internet penetration has dramatically increased, leading to a vastly larger amount of storage, compute, and bandwidth resources to be shared. Furthermore, the demand for resources has increased from primarily government and academia to organizations and individual that require additional resources for novel use-cases, such as machine learning and graphics rendering. Lastly, UX has come a long way to make these networks more accessible to non-technical users.

Lastly, the elephant in the room is the question of demand. In a 2001 article, Robert Metcalf said an interesting quote in regards to distributed computation as a commercial venture:

“The costs of computation keep going down, so why bother trying to recycle the waste of this renewable resource?”

Indeed, if people or companies don’t really need this or are fine with centralized alternatives that are cheap enough with a good enough quality of service, then this might be a solution looking for a problem.

As with so much in crypto, I think we’ll get preliminary answers over the next few years. If it doesn’t work out, at least we’ll walk away with more data to inform the next generation of resource sharing networks.