The problem with (permissionless) decentralization

As we have seen in this blog post, one of the key flaws associated with the current approach to personal data protection and privacy management is the concentration of power within a few organizations. However, this flaw regards many more reasons, such as censorship and anti-competition issues. The concentration of power referenced here can be due to many factors, such as the spontaneous emergence of hierarchies in natural systems (Bakos et al., 2021) or market dynamics’ effect, such as preferential attachment and manifestation power law manifestation (Lopez et al., 2019). In general, the main risk that leads to this flaw is the existence of a single point of failure.

In systems theory, a system is decentralized when lower-level components operate on local information to accomplish global goals. Such a system operates through the emergent behavior of its component parts rather than as a result of the influence of a centralized part (Wikipedia community, 2022).

In a more technical definition, such systems are decentralized, meaning that their architecture is such that it tries to avoid single points of failure.

With the advent of Bitcoin (Nakamoto, 2009) as the first system providing a Peer-to-Peer (P2P) cryptocurrency, there has been a new wave of development of decentralized systems to combat the single point of failure issue. The first widely used systems of this type date back to the start of the new millennium, making it possible to share and exchange resources such as text files, music, and video, e.g., BitTorrent, Emule, Gnutella, and Napster. Generally speaking, P2P systems usually run on top of an already existing network, like the Internet. The underlying overlay network can be represented as a graph where the nodes are the “peers,” and the edges connect peers directly communicating. Two prominent aspects related to the functioning of a P2P system are (i) how the overlay network is built and maintained and (ii) how messages are exchanged among peers (Serena et al., 2020). Hybrid P2P systems might employ some servers for coordination, while pure P2P architectures do not rely on any centralized entity (Backx et al., 2002). Bitcoin is a DLT built on top of a pure P2P system, with the primary objective of storing transactions of assets in the form of so-called cryptocurrency. To achieve decentralized verification of each block, the entire DLT is replicated among all nodes forming the P2P system. Each peer is randomly connected to others, and transactions are disseminated across the entire network. Each node then independently verifies the transactions received to ensure their consistency and avoid attacks, e.g., double spending of Bitcoins. Different types of DLTs provide different implementations of the ledger that store transactions; however, in blockchains, transactions are collected in blocks, and each block contains the hash of the previous one. Nakamoto revolutionized the decentralized systems’ world (and even finance) by introducing a consensus mechanism to ensure all the copies of the ledger are the same for all peers (Nakamoto, 2009). All the other peers accept a block only if it “solves a puzzle”. To make it solving this “crypto-puzzle,” it is required intensive computation work that consumes time, i.e., at each cycle try and attach a different nonce (i.e., a random number) to the block until the execution of a hash function on the block together with the nonce returns a string prefixed with X zeros. This is a general description of Bitcoin’s Proof-of-Work (PoW) consensus mechanisms (also called mining). Moreover, the X is changed dynamically to make this crypto-puzzle more difficult.

Nakamoto’s is, in fact, a revolution since many industries and financial sectors have been influenced by it. In addition, it has also brought optimism for incentivizing participation models, resource contribution, and consensus that could provide a substrate for a decentralized Internet, i.e., the Web3. While there are many different types of DLT, each built with fundamentally different design decisions, the overarching value proposition of DLT and blockchains is that they can operate securely without any centralized control. However, this permissionless way of operating a sizeable decentralized system has also brought many criticisms. Several authors argue that the central problematic aspect of DLTs is their core notion of being trustless (De Filippi et al., 2020; Finocchiaro and Bomprezzi, 2020; Waldo, 2019). In many ways, their attempt to replace trust with code, i.e., the source code that implements the consensus algorithm, makes these DLTs less trustworthy than non-blockchain systems. Indeed, it can be argued that many permissionless DLTs are not truly decentralized, and their inevitable centralization is detrimental because it is essentially emergent and ill-defined (Schneier, 2019, 2022). In such systems, the need for trusted intermediaries is still present, and they often have more power and less oversight than non-blockchain systems: governance and regulations are needed.

Where does trust lie in permissionless decentralized systems?

A critical part of permissionless DLTs is that anyone can participate in the consensus mechanism. Thus, due to its distributed nature, there are no reference points for placing trust. Schneier (2019) argues that non-DLT systems are based on other general mechanisms that humans use to incentivize trustworthy behavior and that make consensus mechanisms unnecessary: morals, reputation, institutions, and security mechanisms. Morals make a person act in a trustworthy way based on decisions taken individually, while reputation is based on the influence of one’s social group. Institutions have rules and laws that induce people to behave according to the group norm, while security mechanisms such as door locks are employed to fulfill the gaps of the previous three mechanisms. What DLTs’ consensus mechanism does, is to shift some of the trust in people and institutions to trust in the technology (Schneier, 2019). When that trust turns out to be misplaced, there is no recourse. For example, if an individual is the sole holder of a private key used to unlock Bitcoin funds and this one is lost, then there is no remedy. In this case, Scheiner wonders whether it is better to trust a technology or a (or a group of) person(s).

By being open access and fully distributed, a permissionless environment may not be able to incentivize participants to adequately provide functions like quality control or coordination of system development and evolution (Bakos et al., 2021). Centralization emerges de facto because of the investment of expertise, reputation, time, or money of the hierarchy of developers or organizations required to enable open access and decentralized control. The higher the costs, the fewer the people that want to participate (Bakos et al., 2021). Permissionless consensus mechanisms require trust in the various members who execute it, i.e., miners or validators (depending on the consensus algorithm) or in their governance. Verifying that these members are not cheating on the hashing of a block is easy. The more extensive and diverse the group of validators or governance, the less likely anyone is to collude. However, even assuming that the group that computes the blocks is trusted, as is its governance, it is necessary to trust the developers of the software used to manage the blocks, ledgers, and all.

For this regard, Trail of Bits (2022) investigates these matters intending to show how a subset of participants can gain centralized control over the entire DLT. Their work is based on 6 measures of centrality:

• Authoritative centrality - What is the minimum number of entities necessary to disrupt the system? The Nakamoto coefficient represents the reply to such a question, and the closer this value is to one, the more centralized the system. It has been shown that for the most used permissionless DLTs, such as Bitcoin and Ethereum, the Nakamoto coefficient is relatively low. While it might be prohibitively expensive attacks such DLTs for individuals, competing technologies and nation-states might have the requisite resources.
• Consensus centrality - To what extent is the source of consensus centralized? The Bitcoin PoW consensus mechanism is currently not executed by single computers or machines owned by an individual but rather by so-called mining pools that aggregate several individual computing powers into one for the same objective, i.e., solving the crypto-puzzle. Only the four most popular mining pools consti- tute over 51% of Bitcoin’s computing power. This paves the way for the most impactful attacks possible to the DLT (Ye et al., 2018). Moreover, each mining pool operates its proprietary centralized protocol and interacts with the public Bitcoin network only through a gateway node, making them an easy target for single point of failure attacks.
• Motivational centrality - How are participants disincentivized from acting maliciously? The possibility of attacks, such as the 51% attack, shows how most Bitcoin nodes are incentivized to behave dishonestly. Kwon et al. (2019) have shown that there is no known way to create a permissionless DLT that is immune to malicious nodes without having a trusted centralized third party.
• Topological centrality - How resistant is the consensus network to disruption? Through empirical estimates of the degree distribution, the authors show that a dense subnetwork of public nodes in the P2P DLT permissionless network is largely responsible for reaching consensus and communicating with nodes executing the consensus mechanism.
• Network centrality - Are the nodes sufficiently geographically dispersed such that they are uniformly distributed across the Internet? Permissionless DLTs such as Bitcoin can suffer arbitrarily degradation or denial of services to any node because, in the past 5 years, 60% of all Bitcoin traffic has traversed just three Internet Service Providers. Moreover, these or any third party on the network route between nodes can observe and choose to drop any messages they wish, also when the Tor protocol is employed (Biryukov and Pustogarov, 2015).
• Software centrality: To what extent is the safety of the DLT dependent on the security of the software on which it runs? Each DLT has a privileged set of entities that can potentially modify past transactions: software developers and maintainers. They represent a centralized point of trust in the system, susceptible to targeted attacks; for example, there are currently four active contributors who have access to modify the Bitcoin Core code base. Software bugs can lead to consensus errors and change the state of the blockchain. In this case, trust in software development is to accept the immutability of the ledger and believe that the programmers have not introduced a bug. A not-so-popular alternative is to update the code off-chain, which shares the same trust issues as a centralized approach.

Some other problems are inherent to the P2P nature of decentralized, permissionless systems. Lopez et al. (2019) argue that decentralized, permissionless blockchains remain ill-suited. The first problem they analyze is the free-riding and incentives for peers. The issue is that, generally, peers do not donate their computing, storage, and bandwidth resources for altruistic reasons, i.e., without incentives. This led to the creation of mining pools and large mining industries, making it impossible for an average user to mine with an ordinary desktop computer to receive compensation. The second problem depicted by the authors regards the security and fragility of open permissionless networks, as attackers, in this case, have economic incentives to break the system. The third problem is a performance issue due to instability, heterogeneity, and churn in the P2P network. The “fatal” issue of P2P networks is that they show high heterogeneity and high degrees of churn, i.e., nodes that dynamically come and go in the system. In DLTs, this translates into the scalability trilemma: a DLT can only address two of the three scalability, decentralization, and security challenges. The solution to this is the employment of so-called layer-two or off-chain solutions that increase the system’s complexity. In fact, the fourth problem taken into consideration is system complexity and maintenance. Programming distributed systems that must be fault-tolerant, self-adjusting, and scalable is challenging.

Permissioned decentralized systems come to the rescue

If trust can be a pivotal element in making the promises of (permissionless) decentralized systems vain, at the same time, it can be that element that, if reinterpreted, can tell us why these systems could bring significant benefits in different contexts. Becker and Bodó (2021) define trust as a complex social phenomenon with interrelated individual and systemic aspects, a relational attribute between a social actor and other actors (interpersonal) and/or actors and institutions (institutional) and institutions and actors (shared expectations). The discussion on trust in DLT spans from the technological to the legal-social to the economic context. If we first need to clarify what trust means academically, its relationship with DLTs can be delineated: “does blockchain increase trust, decrease trust, make trust obsolete, or represent a shift in the nature of trust?” (Becker and Bodó, 2021). A DLT can be considered trustless or trust-free, i.e., that takes care of trust issues and frees individuals from the necessity of implementing mechanisms to signal or convey trust (Beck et al., 2016), or not wholly trustless, i.e., replacing interpersonal trust with trust in the DLT itself (miners, consensus mechanisms, nodes), software developers or new intermediaries (cryptocurrency exchanges). De Filippi et al. (2020) define this not wholly trustlessness as confidence, and thus the DLT becomes a “confidence machine” in the sense that it increases the confidence in the operation of a particular system. The authors argue that creating solid expectations about the correct behavior of operations performed by DLTs increases user confidence, thus eliminating the need for a centralized “trusted” authority. Therefore, confidence in DLTs ultimately depends on the proper governance of the system. This means increased confidence is intrinsically related to the degree to which the various actors involved in governance act as expected.

Both trustless and confidence visions mainly apply to the permissionless case, while permissioned DLTs are usually not considered trustless, as they afford one or more organizations in a maintaining role that need to be trusted. Nevertheless, the members of the latter kind of DLT do not necessarily trust each other, as problems such as authorization and auditing are intrinsic to permissioned DLTs. Although not fully decentralized by design, the governance structure of permissioned systems can also ensure some level of decentralization. As discussed above, in the absence of formal checks for the underlying centralization forces of permissionless systems, centralization emerges in practice. On the other hand, permissioned decentralized systems often operate thanks to contractual agreements between the entities that implement the governance aspect for the system’s operations. Permissioned refers mainly to access to information and governance aspects. In this regard, decentralized systems can be characterized on three key dimensions (Bakos et al., 2021):

1. architecture, which can be concentrated or distributed;
2. access, which can be permissionless or permissioned; and
3. control, which can be centralized or decentralized.

Even if permissioned DLTs are often compared to “not so interesting” distributed databases, when these systems are designed to streamline and convey business relations (that already require trust), they can be more effective than a non-DLT system in the transfer, clearing, and traceability of exogenous assets or rights (Bakos et al., 2021). Permissioned blockchains and the execution of smart contracts on top of them may enable trust, or, better say, confidence, between many players for the validation of contractual obligations (Lopez et al., 2019). Business relationships require trust in the operational and institutional setting, action accountability, and reputation. What permissioned DLT can bring is to achieve higher security at lower levels of trust that any single participant can be induced not to deviate from the protocol (Bakos and Halaburda, 2021). Permissioned DLT entities are identifiable outside the DLT, i.e., off-chain, and are thus subject to penalties imposed by the institutional setting.

The permissioned DLT is then a unique framework for collaboration in competition scenarios.

Entities competing at a business level can cooperate for other purposes through permissioned DLTs (Bakarich and Castonguay, 2021). Unlike a traditional distributed database, no central entity manages and protects the data. Instead, all “business-competing” permissioned DLT nodes control, maintain, and guard the information posted to it, providing an additional layer of control if one of the parties attempts to alter or change previously agreed-upon information. In this way, the ledger can securely and efficiently create a tamper-proof log of sensitive activity. The trust placed in off-chain negotiations between two or more entities, whether institutional or shared expectations, can allow for the design of consensus mechanisms where a large number of validator nodes have a say in the validation process (Bakos et al., 2021). Thus, the primary ability that (permissioned) decentralized systems can provide to their users when reinterpreted as a confidence machine is “gaining truth through the ability to share data safely” (Hardjono et al., 2019).

For Lopez et al. (2019), permissioned systems are of great value when used in environments composed by a collection of players or stakeholders that do not fully trust each other: supply chain & logistics, to trace products while different actors and companies handle them, without having to trust every node in the chain explicitly; healthcare, for the secure sharing of health data across hospitals and platforms; education, for validating of academic credentials and certifications, utilities, such as smart power grids with distributed power generation from both residential and businesses. Even if a centralized system for each case were feasible, such an approach would lack the flexibility of the evolution and portability of members and services and interoperability with other external DLTs and/or services. As an example, the European Blockchain Services Infrastructure (EBSI) (European Blockchain Partnership EBP, 2022) could become a superhub for a myriad of lesser national/local networks: DLT islands will emerge around the world in different sectors (Lopez et al., 2019). The EBSI leverages a permissioned DLT where each EU member state maintains nodes to accelerate the creation of cross-border services for public administrations. The DLT enables the EBSI ecosystem to verify the information and to make services more trustworthy, changing the traditional pattern of data sharing due to its distributed nature. In there, the ledger acts as a point of truth that supports the verification of the entities involved in the transaction and the authenticity of information without requiring real-time access to the source of information.

In conclusion, six key aspects can be guaranteed in for the data management in a permissioned decentralized setting:

• DLTs can provide a single source of verifiable truth among organizations and some level of appropriate automation of data processing.
• Organizations can arrange a form of governance to decide the distributed sources of trust and to moderate such permissioned systems.
• The authority can be distributed among many trusted actors so that compromise of one or even a few authorities does not destroy the consensus.
• Intrinsic cryptographical properties of DLTs can enable distributed safe computation and data minimization.
• The networked collaboration environment can be easily exploited for the audit and accountability of operations.
• P2P networks offer a valuable solution for data resiliency and scalability.

More on this in my Ph.D. Thesis…

References

Backx, P., Wauters, T., Dhoedt, B., and Demeester, P. (2002). A comparison of peer-to-peer architectures. In Eurescom Summit, volume 2. Citeseer.

Bakarich, K. and Castonguay, J. J. (2021). Using a permissioned blockchain? The CPA Journal, 91(6/7):48–51.

Bakos, Y. and Halaburda, H. (2021). Tradeoffs in permissioned vs permissionless blockchains: Trust and performance. NYU Stern School of Business working paper.

Bakos, Y., Halaburda, H., and Mueller-Bloch, C. (2021). When permissioned blockchains deliver more decentralization than permissionless. Communications of the ACM, 64(2):20–22. i, ii, iii, v, vi

Beck, R., Czepluch, J. S., Lollike, N., and Malone, S. (2016). Blockchain–the gateway to trust-free cryptographic transactions. In Twenty-Fourth European Conference on Information Systems (ECIS), ˙Istanbul, Turkey, 2016, pages 1–14. Springer Publishing Company.

Becker, M. and Bodó, B. (2021). Trust in blockchain-based systems. Internet Policy Review, 10(2):1–10.

Biryukov, A. and Pustogarov, I. (2015). Bitcoin over tor isn’t a good idea. In 2015 IEEE Symposium on Security and Privacy, pages 122–134. IEEE.

De Filippi, P., Mannan, M., and Reijers, W. (2020). Blockchain as a confidence machine: The problem of trust & challenges of governance. Technology in Society, 62:101284.

European Blockchain Partnership EBP (2022). European blockchain services infrastructure. https://ec.europa.eu/digital-building-blocks/wikis/display/EBSI/Home.

Finocchiaro, G. and Bomprezzi, C. (2020). Legal analysis of the use of blockchain technology for the formation of smart legal contracts. Media Laws Rivista di Diritto dei Media.

Hardjono, T., Shrier, D. L., and Pentland, A. (2019). 2 TOWARDS AN INTERNET OF TRUSTED DATA, pages 15–40. MIT Press.

Kwon, Y., Liu, J., Kim, M., Song, D., and Kim, Y. (2019). Impossibility of full decentralization in permissionless blockchains. In Proceedings of the 1st ACM Conference on Advances in Financial Technologies, pages 110–123. iii

Lopez, P. G., Montresor, A., and Datta, A. (2019). Please, do not decentralize the internet with (permissionless) blockchains! In 2019 IEEE 39th International Conference on Distributed Computing Systems (ICDCS), pages 1901–1911. IEEE.

Nakamoto, S. (2009). Bitcoin: A peer-to-peer electronic cash system.

Schneier, B. (2019). Blockchain and trust. https://www.schneier.com/blog/archives/2019/02/blockchain_and_.html. ii

Schneier, B. (2022). On the dangers of cryptocurrencies and the uselessness of blockchain. https://www.schneier.com/blog/archives/2022/06/on-the-dangers-of-cryptocurrencies-and-the-uselessness-of-blockchain.html. ii

Serena, L., D’Angelo, G., and Ferretti, S. (2020). Implications of dissemination strategies on the security of distributed ledgers. In Proceedings of the 3rd Workshop on Cryptocurrencies and Blockchains for Distributed Systems, pages 65–70.

Trail of Bits (2022). Are blockchains decentralized? Technical report, Trail of Bits.

Waldo, J. (2019). A hitchhiker’s guide to the blockchain universe. Communications of the ACM, 62(3):38–42.

Wikipedia community (2022). Decentralised system. ipfs://zdj7WX5pBeuj18FDbNqxv55msheeEwFnmcRExintmC2men7ZS/wiki/Decentralised_system.

Ye, C., Li, G., Cai, H., Gu, Y., and Fukuda, A. (2018). Analysis of security in blockchain: Case study in 51%-attack detecting. In 2018 5th International conference on dependable systems and their applications (DSA), pages 15–24. IEEE