| Jun 25, 2022 |
|
|
|
(Nanowerk News) Distributed ledger technology, such as blockchains, has become more prevalent across a variety of contexts over the past decade. The premise is that blockchains operate securely without any centralized control and that they are immutable or unsusceptible to change.
|
|
Given its mission to create and prevent technological surprise, DARPA endeavored to understand those security assumptions and determine to what degree blockchains are actually decentralized. As such, the agency engaged cybersecurity research and consulting firm Trail of Bits to examine the fundamental properties of blockchains and the cybersecurity risks associated with them.
|
|
The study resulted in a report (PDF) that provides holistic analysis that’s available to anyone considering blockchains for important matters so they can better understand the potential vulnerabilities within these systems.
|
|
“The report demonstrates the continued need for careful review when assessing new technologies, such as blockchains, as they proliferate in our society and economy” said Joshua Baron, DARPA program manager overseeing the study. “We should not take any promise of security on face value and anyone using blockchains for matters of high importance must think through the associated vulnerabilities.”
|
Blockchains Are Decentralized, Right?
|
|
Distributed ledger technology (DLT)—and, specifically, blockchains—are used in a variety of contexts, such as digital currency, decentralized finance, and even electronic voting. 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. The cryptographic primitives that enable blockchains are, by this point, quite robust, and it is often taken for granted that these primitives enable blockchains to be immutable (not susceptible to change).
|
|
This report gives examples of how that immutability can be broken not by exploiting cryptographic vulnerabilities but instead by subverting the properties of a blockchain’s implementations, networking, and consensus protocol. The report shows that a subset of participants can garner excessive, centralized control over the entire system.
|
Sources of Centralization
|
|
This report covers several ways in which control of a DLT can be centralized:
|
|
Authoritative centrality: What is the minimum number of entities necessary to disrupt the system? This number is called the Nakamoto coefficient, and the closer this value is to one, the more centralized the system. This is also often referred to as “Governance Centrality”.
|
|
Consensus centrality: Similar to authoritative centrality, to what extent is the source of consensus (e.g., proof-of-work [PoW]) centralized? Does a single entity (like a mining pool) control an undue amount of the network’s hashing power?
|
|
Motivational centrality: How are participants disincentivized from acting maliciously (e.g., posting malformed or incorrect data)? To what extent are these incentives centrally controlled? How, if at all, can the rights of a malicious participant be revoked?
|
|
Topological centrality: How resistant is the consensus network to disruption? Is there a subset of nodes that form a vital bridge in the network, without which the network would become bifurcated?
|
|
Network centrality: Are the nodes sufficiently geographically dispersed such that they are uniformly distributed across the internet? What would happen if a malicious internet service provider (ISP) or nation-state decided to block or filter all DLT traffic?
|
|
Software centrality: To what extent is the safety of the DLT dependent on the security of the software on which it runs? Any bug in the software (either inadvertent or intentional) could invalidate the invariants of the DLT, e.g., breaking immutability. If there is ambiguity in the DLT’s specification, two independently developed software clients might disagree, causing a fork in the blockchain. An upstream vulnerability in a dependency shared by the two clients can similarly affect their operation.
|
Key Findings and Takeaways
|
|
The following are the key findings of this research. They are explained in more detail in the remainder of the report.
|
|
● The challenge with using a blockchain is that one has to either (a) accept its immutability and trust that its programmers did not introduce a bug, or (b) permit upgradeable contracts or off-chain code that share the same trust issues as a centralized approach.
|
|
● Every widely used blockchain has a privileged set of entities that can modify the semantics of the blockchain to potentially change past transactions.
|
|
● The number of entities sufficient to disrupt a blockchain is relatively low: four for Bitcoin, two for Ethereum, and less than a dozen for most PoS networks.
|
|
● The vast majority of Bitcoin nodes appear to not participate in mining and node operators face no explicit penalty for dishonesty.
|
|
● The standard protocol for coordination within blockchain mining pools, Stratum, is unencrypted and, effectively, unauthenticated.
|
|
● When nodes have an out-of-date or incorrect view of the network, this lowers the percentage of the hashrate necessary to execute a standard 51% attack. Moreover, only the nodes operated by mining pools need to be degraded to carry out such an attack. For example, during the first half of 2021 the actual cost of a 51% attack on Bitcoin was closer to 49% of the hashrate.
|
|
● For a blockchain to be optimally distributed, there must be a so-called Sybil cost. There is currently no known way to implement Sybil costs in a permissionless blockchain like Bitcoin or Ethereum without employing a centralized trusted third party (TTP). Until a mechanism for enforcing Sybil costs without a TTP is discovered, it will be almost impossible for permissionless blockchains to achieve satisfactory decentralization.
|
|
● A dense, possibly non-scale-free, subnetwork of Bitcoin nodes appears to be largely responsible for reaching consensus and communicating with miners—the vast majority of nodes do not meaningfully contribute to the health of the network.
|
|
● Bitcoin traffic is unencrypted—any third party on the network route between nodes (e.g., ISPs, Wi-Fi access point operators, or governments) can observe and choose to drop any messages they wish.
|
|
● Of all Bitcoin traffic, 60% traverses just three ISPs.
|
|
● Tor is now the largest network provider in Bitcoin, routing traffic for about half of Bitcoin’s nodes. Half of these nodes are routed through the Tor network, and the other half are reachable through .onion addresses. The next largest autonomous system (AS)—or network provider—is AS24940 from Germany, constituting only 10% of nodes. A malicious Tor exit node can modify or drop traffic similarly to an ISP.
|
|
● Of Bitcoin’s nodes, 21% were running an old version of the Bitcoin Core client that is known to be vulnerable in June of 2021.
|
|
● The Ethereum ecosystem has a significant amount of code reuse: 90% of recently deployed Ethereum smart contracts are at least 56% similar to each other.
|
