While the term "decentralization" has a long history of use in economics, politics, religion, and international development, [Baran] gave one of the first definitions relevant to computer networking as a condition when "complete reliance upon a single point is not always required".

Such technical centralization (while not a trivial topic) is relatively well understood. Avoiding all forms of centralization -- including non-technical ones -- using only technical tools (like protocol design) is considerably more difficult. Several issues are encountered.

First, and most critically, technical decentralization measures have, at best, limited effects on non-technical forms of centralization. Or, per [Schneider1], "decentralized technology alone does not guarantee decentralized outcomes". As explored below in Section 3.1, technical measures are better characterized as necessary but insufficient to achieve full decentralization of a function.

Second, decentralizing a function requires overcoming challenges that centralized ones do not face. A decentralized function can be more difficult to adapt to user needs (for example, introducing new features or experimenting with user interfaces) because doing so often requires coordination between many different actors [Marlinspike]. Economies of scale are more available to centralized functions, as is data that can be used to refine a function's design. All of these factors make centralized solutions more attractive to service providers and, in some cases, can make a decentralized solution uneconomic.

Third, identifying which aspects of a function to decentralize can be difficult, both because there are often many interactions between different types and sources of centralization and because centralization sometimes only becomes clear after the function is deployed at scale. Efforts to decentralize often have the effect of merely shifting centralization to a different place -- for example, in its governance, implementation, deployment, or ancillary functions.

For example, the Web was envisioned and widely held to be a decentralizing force in its early life. Its potential as an enabler of centralization only became apparent when large websites successfully leveraged network effects (and secured legal prohibitions against interoperability, thus increasing switching costs; see [Doctorow]) to achieve dominance of social networking, marketplaces, and similar functions.

Fourth, different parties might have good-faith differences on what "sufficiently decentralized" means based upon their beliefs, perceptions, and goals. Just as centralization is a continuum, so is decentralization, and not everyone agrees what the "right" level or type is, how to weigh different forms of centralization against each other, or how to weigh potential centralization against other architectural goals (such as security or privacy).

These tensions can be seen, for example, in the DNS. While some aspects of the system are decentralized -- for example, the distribution of the lookup function to local servers that users have the option to override -- an essentially centralized aspect of the DNS is its operation as a name space: a single global "source of truth" with inherent (if beneficial) centralization in its management. ICANN mitigates the associated risk through multi-stakeholder governance (see Section 3.1.3). While many believe that this arrangement is sufficient and might even have desirable qualities (such as the ability to impose community standards over the operation of the name space), others reject ICANN's oversight of the DNS as illegitimate, favoring decentralization based upon distributed consensus protocols rather than human governance [Musiani].

Fifth, decentralization unavoidably involves adjustments to the power relationships between protocol participants, especially when it opens up the possibility of centralization elsewhere. As [Schneider2] notes, decentralization "appears to operate as a rhetorical strategy that directs attention toward some aspects of a proposed social order and away from others", so "we cannot accept technology as a substitute for taking social, cultural, and political considerations seriously". Or, more bluntly, "without governance mechanisms in place, nodes may collude, people may lie to each other, markets can be rigged, and there can be significant cost to people entering and exiting markets" [Bodo].

For example, while blockchain-based cryptocurrencies purport to address the centralization inherent in existing currencies through technical means, many exhibit considerable concentration of power due to voting/mining power, distribution of funds, and diversity of the codebase [Makarov]. Overreliance on technical measures also brings an opportunity for latent, informal power structures that have their own risks -- including centralization [Freeman].

Overall, decentralizing a function requires considerable work, is inherently political, and involves a large degree of uncertainty about the outcome. If one considers decentralization as a larger social goal (in the spirit of how the term is used in other, non-computing contexts), merely rearranging technical functions may lead to frustration. "A distributed network does not automatically yield an egalitarian, equitable or just social, economic, political landscape" [Bodo].

This section examines some common strategies that are employed to decentralize Internet functions and discusses their limitations.

Protocol designers often attempt to address centralization through federation, i.e., designing a function in a way that uses independent instances that maintain connectivity and interoperability to provide a single cohesive service. Federation promises to allow users to choose the instance they associate with and accommodates substitution of one instance for another, lowering switching costs.

However, federation alone is insufficient to prevent or mitigate centralization of a function because non-technical factors can create pressure to use a central solution.

For example, the email suite of protocols needs to route messages to a user even when that user changes network locations or becomes disconnected for a long period. To facilitate this, SMTP [RFC5321] defines a specific role for routing users' messages, the Message Transfer Agent (MTA). By allowing anyone to deploy an MTA and defining rules for interconnecting them, the protocol avoids a requirement for a single central server in that role; users can (and often do) choose to delegate it to someone else or they can run their own MTA.

Running one's own MTA has become considerably more onerous over the years due, in part, to the increasingly complex mechanisms introduced to fight unwanted commercial emails. These costs create an incentive to delegate one's MTA to a third party who has the appropriate expertise and resources, contributing to market concentration [Holzbauer].

Additionally, the measures that MTAs use to identify unwanted commercial emails are often site specific. Because large MTAs handle so many more addresses, there is a power imbalance with smaller ones; if a large MTA decides that email from a small one is unwanted, there is significant impact on its ability to function and little recourse.

The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is a chat protocol that demonstrates another issue with federation: the voluntary nature of technical standards.

Like email, XMPP is federated to facilitate the rendezvous of users from different systems - if they allow it. While some XMPP deployments do support truly federated messaging (i.e., a person using service A can interoperably chat with someone using service B), many of the largest do not. Because federation is voluntary, some operators captured their users into a single service, deliberately denying them the benefits of global interoperability.

The examples above illustrate that, while federation can create the conditions necessary for a function to be decentralized, it does not guarantee that outcome.

Increasingly, distributed consensus technologies (such as a blockchain) are touted as a solution to centralization. A complete survey of this rapidly changing area is beyond the scope of this document, but we can generalize about its properties.

These techniques typically guarantee proper performance of a function using cryptographic techniques (often, an append-only transaction ledger). They attempt to avoid centralization by distributing the operation of a function to members of a sometimes large pool of protocol participants. Usually, the participants are unknown and untrusted, and a particular task's assignment to a node for handling cannot be predicted or controlled.

Sybil attacks (where a party or coordinated parties cheaply create enough protocol participants to affect how consensus is judged) are a major concern for these protocols because they would have the effect of concentrating power into the hands of the attacker. Therefore, they encourage diversity in the pool of participants using indirect techniques, such as proof-of-work (where each participant has to show a significant consumption of resources) or proof-of-stake (where each participant has some other incentive to execute correctly).

While these measures can be effective in decentralizing a function's operation, other aspects of its provision can still be centralized: for example, governance of its design, creation of shared implementations, and documentation of wire protocols. That need for coordination is an avenue for centralization even when the function's operation remains decentralized. For example, the Ethereum "merge" demonstrated that the blockchain could address environmental concerns but only through coordinated community effort and governance: coordination that was benign in most eyes but, nevertheless, centralized [ETHEREUM].

Furthermore, a protocol or an application composed of many functions can use distributed consensus for some but still be centralized elsewhere -- either because those other functions cannot be decentralized (most commonly, rendezvous and global naming; see Section 2.2) or because the designer has chosen not to because of the associated costs and lost opportunities.

These potential shortcomings do not rule out the use of distributed consensus technologies in every instance, but they do merit caution against uncritically relying upon these technologies to avoid or mitigate centralization. Too often, the use of distributed consensus is perceived as imbuing all parts of a project with "decentralization".

Federation and distributed consensus can both create the conditions for the provision of a function by multiple providers, but they cannot guarantee it. However, when providers require access to a resource or cooperation of others to provide that service, that choke point can itself be used to influence provider behavior -- including in ways that can counteract centralization.

In these circumstances, some form of governance over that choke point is necessary to assure the desired outcome. Often, this is through the establishment of a multi-stakeholder body, which is an institution that includes representatives of the different kinds of parties that are affected by the system's operation ("stakeholders") in an attempt to make well-reasoned, legitimate, and authoritative decisions.

A widely studied example of this technique is the governance of the DNS name space, which exhibits centralization as a "single source of truth" [Moura]. That source of truth is overseen by the Internet Corporation for Assigned Names and Numbers (ICANN) <https://www.icann.org/resources/pages/governance/governance-en>, a global multi-stakeholder body with representation from end users, governments, operators, and others.

Another example is the governance of the Web's trust model, implemented by web browsers as relying parties that have strong incentives to protect user privacy and security and CAs as trust anchors that have a strong incentive to be included in browser trust stores. To promote the operational and security requirements necessary to provide the desired properties, the CA/Browser Forum <https://cabforum.org> was established as an oversight body that involves both parties as stakeholders.

These examples are notable in that the governance mechanism is not specified in the protocol documents directly; rather, they are layered on operationally, but in a manner that takes advantage of protocol features that enable the imposition of governance.

Governance in this manner is suited to very limited functions like the examples above. Even then, the setup and ongoing operation of a governance mechanism is not trivial, and their legitimacy may be difficult to establish and maintain (e.g., see [Palladino]); by their nature, they are vulnerable to capture by the interests that are being governed.