Eric Budish\nhttps://www.nber.org/system/files/working_papers/w24717/w24717.pdf\nWorking Paper 24717\nDOI 10.3386/w24717\nIssue Date June 2018

Eric Budish Booth School of Business University of Chicago 5807 South Woodlawn Avenue Chicago, IL 60637 and NBER eric.budish@chicagobooth.edu

Abstract

The amount of computational power devoted to anonymous, decentralized blockchains such as Bitcoin's must simultaneously satisfy two conditions in equilibrium: (1) a zero-profit condition among miners, who engage in a rent-seeking competition for the prize associated with adding the next block to the chain; and (2) an incentive compatibility condition on the system's vulnerability to a “majority attack”, namely that the computational costs of such an attack must exceed the benefits. Together, these two equations imply that (3) the recurring, “flow”, payments to miners for running the blockchain must be large relative to the one-off, “stock”, benefits of attacking it. This is very expensive! The constraint is softer (i.e., stock versus stock) if both (i) the mining technology used to run the blockchain is both scarce and non-repurposable, and (ii) any majority attack is a “sabotage” in that it causes a collapse in the economic value of the blockchain; however, reliance on non-repurposable technology for security and vulnerability to sabotage each raise their own concerns, and point to specific collapse scenarios. In particular, the model suggests that Bitcoin would be majority attacked if it became sufficiently economically important — e.g., if it became a “store of value” akin to gold — which suggests that there are intrinsic economic limits to how economically important it can become in the first place.

Conclusion

The anonymous, decentralized trust enabled by the Nakamoto (2008) blockchain, while ingenious, is expensive. Equation (3) says that for the trust to be meaningful requires that the flow cost of running the blockchain is large relative to the one-shot value of attacking it. In the doublespending attack considered in Section 2.1, the implication is that the transaction costs of the blockchain must be large in relation to the largest-possible economic uses of the blockchain, which can be interpreted as a large implicit tax. The argument that an attack is actually more expensive than this flow cost, considered in Section 3, requires one to concede both (i) that the security of the blockchain actually relies on its use of scarce, non-repurposable technology (counter to the Nakamoto (2008) vision of “one-CPU-one-vote”), and (ii) that the blockchain is vulnerable to sabotage, and at a cost that is linear in the amount of specialized computational equipment devoted to its maintenance. These concessions leave the blockchain vulnerable to collapse if either conditions change in the specialized chip market or if the Bitcoin blockchain becomes economically important enough to tempt a saboteur. Overall, the results place potentially serious economic constraints on the use of the Nakamoto (2008) blockchain innovation.

It bears emphasis that the earliest use cases of Bitcoin—black-market transactions, purchases by computer hobbyists, intra-family international transfers, etc., all of relatively modest value—are completely consistent with the model in this paper. In the language of the model, v¯transaction is low relative to the acceptable levels of ptransaction for such transactions. Rather, this paper suggests skepticism and caution about larger-scale uses of this technology, such as Bitcoin as a “store of value” akin to gold, or the use of the Nakamoto (2008) blockchain by businesses and governments. Most businesses and governments presumably have access to cheaper forms of data security, e.g., distributed ledgers or databases that require a trusted party (e.g., the business or businesses themselves), rather than having to pay the high costs of the trust that is emergent from a large network of untrusted computers coordinating on maximum proof-of-work.

Relatedly to this last point, an important clarification: as interest in Bitcoin and its blockchain have surged, some have started to use the phrase “blockchain” to refer as well to the use of distributed ledgers or databases among known, trusted parties—that is, without the anonymous, decentralized trust innovation of Nakamoto (2008). An example is the uses by Walmart and British Airways described in Nash (2018)—essentially, the use of well-architected databases, strong version control (possibly utilizing one-way hash functions), and allowing multiple interested parties to easily search or update the data in accordance with prescribed business practices. As one financial columnist astutely observed: “If you announce that you are updating the database software used by a consortium of banks to track derivatives trades, the New York Times will not write an article about it. If you say that you are blockchaining the blockchain software used by a blockchain of blockchains to blockchain blockchain blockchains, the New York Times will blockchain a blockchain about it.”(Levine, 2017) The WSJ reports that “Companies that have taken an ‘If it ain’t broke, don’t fix it’ attitude toward back-office processes and logistics IT might be ready to spend big on updating those systems when they hear the buzzword ‘blockchain’.”(Mims, 2018) As should be quite clear, this paper’s critique is about blockchain in the sense of Nakamoto (2008), not about the use of distributed databases more broadly. Indeed, what this paper highlights is that it is exactly the aspect of Bitcoin and Nakamoto (2008) that is so innovative relative to traditional 16 distributed databases — the anonymous, decentralized trust that emerges from proof-of-work — that is so economically limiting.

An interesting open question raised by this paper — perhaps more for computer scientists than for economists, or perhaps requiring both perspectives — is whether there is some other approach to generating anonymous, decentralized trust in a public ledger that is less economically constrained by the possibility of an attack. More precisely, allowing that some version of equations (1)-(3) seems intrinsic to any anonymous, decentralized blockchain protocol, is there an alternative to Nakamoto (2008) that either reduces Vattack or raises α, relative to a given level of payment for maintenance of the ledger, Pblock. Within the proof-of-work paradigm, the most natural idea is to find a modification to the longest-chain convention that utilizes the fact that, in the event of an attack, it will be widely “noticed”. Or, perhaps one can prove a theorem that shows that no such modification can exist while preserving anonymity and decentralization, suitably defined. Another interesting idea in this regard is proof-of-stake (cf., Buterin and Griffith (2017), Ethereum Wiki (2018b)). The usual motivation for proof-of-stake over proof-of-work — the deadweight loss and environmental harm associated with proof-of-work mining, currently estimated to utilize over 0.30% of global electricity consumption (Digiconomist, 2018; Vries, 2018; Saleh, 2018) — is in fact completely orthogonal to the concerns raised in this paper. Just conceptualize c as the per-block opportunity cost of holding one unit of stake, and versions of equations (1)-(3) obtain immediately. But, the use of “stakes” instead of computational work may open new possibilities for thwarting attacks, e.g., confiscation of an attacker’s stake, or building some limited forms of reputation (e.g., Buterin, 2016). It will be interesting to watch this research develop, and see whether or not it constitutes a valid response to the critique in this paper.

","enableWebSigning","origin","homeMetadata",{"_159":355,"_356":183,"_357":59,"_358":359,"_360":59,"_361":362,"_363":6,"_364":365},"originHomeId",{"_176":148,"_37":398,"_152":656,"_146":-5,"_178":-5,"_179":-5,"_180":-5,"_181":-5},[],"meta",{"_659":660,"_762":763},"values",{"_661":662,"_664":665,"_666":667,"_668":669,"_671":672,"_673":674,"_675":676,"_678":679,"_680":681,"_682":683,"_684":685,"_686":687,"_688":689,"_690":691,"_692":693,"_694":695,"_696":697,"_698":699,"_700":701,"_702":703,"_704":705,"_706":707,"_708":709,"_710":711,"_712":713,"_714":715,"_716":717,"_718":719,"_720":721,"_722":723,"_724":725,"_726":727,"_728":729,"_730":731,"_732":733,"_734":735,"_736":737,"_738":739,"_740":741,"_742":743,"_744":745,"_746":747,"_748":749,"_750":751,"_752":753,"_754":755,"_756":757,"_758":759,"_760":761},"document.generationInfo.generation",[663],"bigint","dehydratedState.queries.0.state.data.document.generationInfo.generation",[663],"dehydratedState.queries.1.state.data.document.generationInfo.generation",[663],"dehydratedState.queries.1.queryKey.2",[670],"undefined","dehydratedState.queries.2.state.data.0.createTime.seconds",[663],"dehydratedState.queries.2.state.data.0.updateTime.seconds",[663],"dehydratedState.queries.2.state.data.0.sortTime",[677],"Date","dehydratedState.queries.2.state.data.0.activitySummary.latestCommentTime",[670],"dehydratedState.queries.2.state.data.0.activitySummary.latestChangeTime.seconds",[663],"dehydratedState.queries.2.state.data.0.generationInfo.generation",[663],"dehydratedState.queries.2.state.data.0.redirectInfo",[670],"dehydratedState.queries.2.state.data.1.createTime.seconds",[663],"dehydratedState.queries.2.state.data.1.updateTime.seconds",[663],"dehydratedState.queries.2.state.data.1.sortTime",[677],"dehydratedState.queries.2.state.data.1.activitySummary.latestCommentTime",[670],"dehydratedState.queries.2.state.data.1.activitySummary.latestChangeTime.seconds",[663],"dehydratedState.queries.2.state.data.1.generationInfo.generation",[663],"dehydratedState.queries.2.state.data.1.redirectInfo",[670],"dehydratedState.queries.2.state.data.2.createTime.seconds",[663],"dehydratedState.queries.2.state.data.2.updateTime.seconds",[663],"dehydratedState.queries.2.state.data.2.sortTime",[677],"dehydratedState.queries.2.state.data.2.activitySummary.latestCommentTime.seconds",[663],"dehydratedState.queries.2.state.data.2.activitySummary.latestChangeTime.seconds",[663],"dehydratedState.queries.2.state.data.2.generationInfo.generation",[663],"dehydratedState.queries.2.state.data.2.redirectInfo",[670],"dehydratedState.queries.2.state.data.3.createTime.seconds",[663],"dehydratedState.queries.2.state.data.3.updateTime.seconds",[663],"dehydratedState.queries.2.state.data.3.sortTime",[677],"dehydratedState.queries.2.state.data.3.activitySummary.latestCommentTime",[670],"dehydratedState.queries.2.state.data.3.activitySummary.latestChangeTime.seconds",[663],"dehydratedState.queries.2.state.data.3.generationInfo.generation",[663],"dehydratedState.queries.2.state.data.3.redirectInfo",[670],"dehydratedState.queries.2.state.data.4.createTime.seconds",[663],"dehydratedState.queries.2.state.data.4.updateTime.seconds",[663],"dehydratedState.queries.2.state.data.4.sortTime",[677],"dehydratedState.queries.2.state.data.4.activitySummary.latestCommentTime",[670],"dehydratedState.queries.2.state.data.4.activitySummary.latestChangeTime.seconds",[663],"dehydratedState.queries.2.state.data.4.generationInfo.generation",[663],"dehydratedState.queries.2.state.data.4.redirectInfo",[670],"dehydratedState.queries.2.state.data.5.createTime.seconds",[663],"dehydratedState.queries.2.state.data.5.updateTime.seconds",[663],"dehydratedState.queries.2.state.data.5.sortTime",[677],"dehydratedState.queries.2.state.data.5.activitySummary.latestCommentTime",[670],"dehydratedState.queries.2.state.data.5.activitySummary.latestChangeTime.seconds",[663],"dehydratedState.queries.2.state.data.5.generationInfo.generation",[663],"dehydratedState.queries.2.state.data.5.redirectInfo",[670],"dehydratedState.queries.5.state.data.document.generationInfo.generation",[663],"dehydratedState.queries.5.queryKey.2",[670],"dehydratedState.queries.6.state.data.metadata.summary",[670],"referentialEqualities",{"_661":764,"_673":765,"_686":766,"_702":767,"_716":768,"_730":769,"_744":770,"_752":771},[664],[680],[688,694],[708],[722],[736],[750],[756],"actionData","errors"]