The farther backward you can look, the farther forward you will see. Bitcoin is a testament to that saying: the extraordinary and successful thing about Bitcoin is not that it is at the forefront of any component research, but that it integrates old ideas from many unrelated fields.
This paper reviews the academic pedigree of bitcoin and blockchain, showing examples of combinatorial innovation. The article is long, but it gets to the core of the evolution of technology. Throughout the text, as shown in the table of contents below, it is easy for readers to build up an overall picture of bitcoin’s technical route. The article sorted out the general ledger, currency and technical route of miners, and explained how the technological accumulation of these three different fields came together in the magical idea of Bitcoin.
It is worth mentioning that regarding the distributed consistency and consensus mechanism, the current mainstream distributed technologies, including various cloud computing solutions, have not faced the Byzantine failure. Then how does bitcoin, based on the large-scale P2P network structure, solve these problems? And how to motivate nodes to participate in consensus? I believe this article will give you wonderful answers!
If you have read about bitcoin in the media and have some knowledge of academic research in the field of cryptography, you may have the impression that decades of efforts to develop digital cash by many people, starting with David Chaum (reference 10,12), have ultimately failed to achieve commercial success. Because these jobs require a centralized bank server to control the system, no bank is willing to endorse them. With the advent of Bitcoin, a solution to a decentralized cryptocurrency that doesn’t require a bank, digital cash finally takes off. Bitcoin’s mysterious inventor, Satoshi Nakamoto, is not an academic man, and bitcoin bears little resemblance to early academic schemes.
David Chaum invented digital cash in 1983, 25 years before bitcoin.
This paper argues that almost all of bitcoin’s technical components originate from academic literature in the 1980s and 1990s (see Figure 1). This is not to diminish Nakamoto’s achievements, but to point out that he stands on the shoulders of giants. In fact, by tracing the origins of bitcoin’s thinking, we can trace the real leap in Satoshi Nakamoto’s insights to a specific, complex way — a way of combinatorial innovation (bringing the underlying components together). This helps explain why bitcoin has taken so long to be invented. Readers already familiar with how bitcoin works can gain further insight from this historical backtrack (for more information, see Arvind and Narayanan et al. ‘s Bitcoinand Cryptocurrency Technologies(Reference 36). The intellectual and cultural history of Bitcoin can also serve as a case study to demonstrate the collaborative relationship between academia, outside researchers and practitioners, and provide lessons for how these diverse groups can benefit from working together.
* Bitcoin is a prime example of combinatorial innovation.
1. The Ledger
If you have a secure ledger, the process for using it in a digital payment system is simple. For example, if Alice gives Bob $100 via PayPal, PayPal deducts $100 from Alice’s account and credits $100 to Bob’s account. This is more or less what happens in traditional banking, although there is no shared master ledger among the bank’s complex businesses.
The concept of a general ledger is the starting point for understanding Bitcoin. It records all transactions occurring in the system and is open to, and trusted by, all participants in the system. Bitcoin converts the system’s payment record into a currency record. In banking, account balances represent cash that can be withdrawn from the bank, but what does one bitcoin represent? For now, bitcoin represents a purchase (transaction) with a fixed value.
How do you build a master ledger in an environment like the Internet, where players may not trust each other? Let’s start with the easy part: the choice of data structure. This data structure must meet certain attribute requirements — the ledger should be immutable. More precisely, you can only add: new transactions can be added, but you cannot delete, modify, or reorder existing transactions. In addition, you need a way to get a cipher summary of the general ledger state. A summary is a short string that avoids storing the entire ledger. If the master ledger is tampered with, the resulting summary must change so that tampering can be detected. These attributes are needed because, unlike regular data structures stored on a single machine, a master ledger is a global data structure maintained by a group of participants who do not trust each other. This differs from the approach used in decentralizing digital ledgers (reference 7,13,21) where participants maintain local ledgers and users query these ledgers to resolve conflicts.
1.1 Linked timestamping
Bitcoin’s master ledger data structure has been modified by borrowing from a series of papers written between 1990 and 1997 by Stuart Haber and Scott Stornetta (their 1991 paper was co-authored by Dave Bayer, ref. 5,22,23). We know these historical origins because Satoshi Nakamoto mentioned them in his Bitcoin white paper (Reference 34). The main work of Stuart Haber and Scott Stornetta deals with the documentation of timestamps – their aim is to build a “digital notary” service. For patents, business contracts, and other documents, one may want to be sure that the document was created at or no later than a certain point in time. Stuart Haber and Scott Stornetta’s document concept is very general and can be any type of data. They did mention financial transactions as potential applications, but that was not their focus.
In a simplified version of Stuart Haber and Scott Stornetta’s scheme, documents are constantly created and broadcast. The creator of each document declares a creation time (and signs the document), the document’s timestamp, and the previous broadcast document. The previous broadcast document has signed its predecessor, so the document forms a long backward chain. External users cannot change the timestamp information because it is signed by the creator; The creator also cannot change the timestamp information without changing the entire following information chain. Thus, if a single item in the chain is obtained from a trusted source (for example, another user or a specialized timestamp service), the entire chain up to that point in time is locked, immutable, and ordered in time. Further, if you think the system rejects a document that was created at the wrong time, you can reasonably guarantee that the document is at least as old as it claims to be. Further, if you assume that the system rejects documents with incorrect creation times, you can be reasonably assured that documents are at least as old as they claim to be. In any case, Bitcoin simply borrowed the data structure of Stuart Haber’s and Scott Stornetta’s work, and then redesigned the security properties (as evidenced by the increased work, described later in this article).
Further, if you think the system rejects a document that was created at the wrong time, you can reasonably guarantee that the document is at least as old as it claims to be. The original: Further, if you assume that the system rejects documents with incorrect creation times, you can be reasonably assured that documents are at least as old as they claim to be.
In a follow-up paper, Stuart Haber and Scott Stornetta introduced other schemes (some of which were hinted at in the first paper) to make this data structure more effective and efficient. First, you can use hashes instead of signatures to create links between documents; Because hashing is easier, it’s faster. Such links are called hash Pointers. Second, instead of threading documents individually (which can be inefficient if multiple documents are created almost simultaneously), they can be divided into batch groups or blocks, with documents in each block having essentially the same timestamp. Third, within each block, documents can be joined together with a binary tree of hash Pointers, called a Merkle tree, rather than a linear chain. Incidentally, in 1991, six years after the first paper by Stuart Haber and Scott Stornetta was published, Josh Benaloh and Michael de Mare independently proposed these three schemes.
1.2 Merkle Trees
Bitcoin essentially uses data structures proposed by Josh Benaloh and Michael de Mare in 1991 and 1997 (the work of Josh Benaloh and Michael de Mare is presumably unknown to Satoshi nakamoto), shown in simplified form in Figure 2. Of course, in Bitcoin, transactions take the place of documents. In a Merkle tree per block, the leaf nodes are transactions, and each internal node consists of two Pointers. This data structure has two important properties. First, the latest block is hashed as a digest. Changes to any transaction (leaf node) require propagating the changes all the way to the root of the block, as well as the root of all subsequent blocks. So if you know the latest hash value, you can download the rest of the ledger from an untrusted source and verify if it has changed. Similar ideas establish a second important property of data structures — that is, someone can simply and efficiently prove to you that a particular transaction is included in the master ledger. The user only needs to send you a small number of nodes in that transaction block (a characteristic of Merkle trees) and a small amount of information for each subsequent block. Proving the containment capability of transactions efficiently is essential for performance and scalability.
Ralph Merkle is a computer scientist who has made important contributions to public-key encryption. Later, research moved into nanotechnology and cryonics.
For the record, Merkle trees are named after Ralph Merkle, a pioneer of symmetric cryptography. Ralph Merkle proposed this idea in a 1980 paper (reference 33). His target application is to produce a public catalog digest of digitally signed certificates. For example, when a web site provides you with a certificate, it can also provide a short proof that the certificate is displayed in the global directory. As long as you know the root hash of the Merkle tree in the certificate directory, you can verify the proof efficiently. The idea is ancient in cryptographic standards, but its power has only recently been recognized. It is at the heart of the recently implemented certificate transparency system (reference 30). A 2015 paper proposed CONIKS, applying Merkle trees to the public key directory of end-to-end encrypted email (Reference 32). Efficient verification of parts of the global state is one of the key features that the total ledger provides in the new cryptocurrency “Ethereum.”
Bitcoin may be the most famous real-world use of the Josh Benaloh and Michael de Mare data structures, but it’s not the first. At least two companies — Surety since the mid-1990s and Guardtime since 2007 — have used document timestamp services. An interesting twist of these services is An idea mentioned by Bayer, Haber, and Stornetta(Reference 5), which is to regularly publish Merkle roots in the form of advertisements in newspapers. Figure 3 shows the Merkle root published by Guardtime.
1.3 Byzantine Fault Tolerance
Of course, Internet money without central authority has stricter requirements. There will inevitably be forks in distributed ledgers, meaning that some nodes will think that block A is the latest block and others will think that block B is the latest block. This could be because an attacker is trying to disrupt the operation of the master ledger; It could also be that different nodes do not know each other’s blocks and occasionally generate blocks at the same time simply because of network latency. It is not enough to rely only on chain timestamps to solve forking, as demonstrated by Mike in 1998 (reference 26).
A different field of research — fault-tolerant distributed computing — has studied this problem with different names, including State replication. The solution to this problem is to have a set of nodes apply the same state transitions in the same order — usually, the exact order doesn’t matter as long as all the nodes are consistent. For digital currency, the state to be copied is a set of balances, and the transaction is a state transition. Early solutions included Paxos, proposed by Turing prize winner Leslie Lamport in 1989 (references 28,29), in which a few nodes may suffer from certain “realistic” failures, such as being permanently offline or restarted, when the communication channel is unreliable. Stale messages received when initially offline are sent, etc. – State replication is considered. Subsequently, a large literature has been produced dealing with more complex (hostile/adverse) environments and tradeoffs against efficiency.
A series of related work has studied the mostly reliable case of networks (messages are delivered with limited delay), but the definition of “error” has been extended to deal with any deviation from the protocol. This Byzantine error includes both natural errors and malevolent acts. As early as 1982 (ref. 27), Lamport, along with Robert Shostak and Marshall Pease, published a paper called the Byzantine Generals Problem. Later, in 1999, Miguel Castro and Barbara Liskov published a landmark paper introducing PBFT (Practical Byzantine Fault Tolerance) to accommodate both Byzantine failures and unreliable networks (reference 8). Compared to chained timestamps, the amount of literature on fault tolerance is enormous, including hundreds of variations and optimizations of Paxos, PBFT, and other important protocols.
Satoshi Nakamoto did not cite BFT literature or use its language in his original white paper. He uses a number of concepts, using protocols as a consensus mechanism and thinking about failures in terms of attackers and nodes joining and leaving the network. This is in sharp contrast to his explicit references to chained timestamps in the literature (including proof of work, discussed below). When asked about the mailing list discussion about bitcoin’s relationship to the Byzantine General problem (a thought experiment that requires BFT to solve), Satoshi nakamoto claimed that the proof-of-work chain solved the problem (reference 35).
In the following years, other scholars studied Nakamoto’s consensus mechanism from the perspective of distributed systems — which is still a work in progress. Some people say that the attributes of bitcoin are quite weak (reference 43); While others argue that BFT’s view is unfair to the consistency properties of Bitcoin (reference 40). Another approach is to define well-studied variations of properties and prove that Bitcoin satisfies them (reference 19). Recently, these definitions have been greatly strengthened to provide a more standard conformance definition that retains more realistic assumptions for messaging (reference 37). However, all of this work assumes that some participants are acting “honestly” (i.e., protocol-compatible), whereas Satoshi argues that there is no need to blindly assume that the behavior is honest because the behavior is motivated. The comprehensive analysis of Satoshi nakamoto’s incentive consensus mechanism is not suitable for the past fault-tolerant system model.
2. Proof of Work
Almost all fault-tolerant systems assume that most or most of the nodes in the system (e.g., more than half or two-thirds) are honest and reliable. In an open peer-to-peer network, there is no registration of nodes, and nodes can join and leave freely. Therefore, an attacker can create enough Sybils or SockPuppet nodes to break the system’s consistency guarantee. The Sybil attack was formalized by John Douceur in 2002 and defused with the help of cryptography infrastructure, proof of work.
2.1 The Origins
To understand proof of work, let’s look at its origins. What is today called proof of work was first proposed by Cynthia Dwork and Moni Naor in 1992. Their goal is to stop spam. Note that spam, Sybil attacks, and denial of service are all broadly similar problems: attackers increase their influence over the network compared to regular users. Proof of work applies to the tripartite defence. In Cynthia Dwork and Moni Naor’s design, email recipients would only process emails with a “proof of work” attached that the sender had performed a reasonable amount of computational work. Calculating proof of work can take a few seconds on an ordinary computer. Thus, there is no difficulty for the average user, but it would take weeks for a spammer hoping to send a million e-mails with equivalent hardware,
Note that proof of work (also known as problem solving) must be specific to the email and the recipient. Otherwise, a spammer would be able to send multiple messages to the same recipient (or send the same message to multiple recipients) at the same cost as sending one to one. The second important feature is that it should impose only minimal computational burden on the recipient; Problem solutions should be easy to verify, no matter how hard they are to calculate. In addition, Cynthia Dwork and Moni Naor argue that functionality with backdoors — a secret known to central authorities — allows authorities to solve problems without proof of work. One possible application backdoor is to open up a mailing list for authorities to send messages at no cost. Cynthia Dwork and Moni Naor’s proposal contains three candidate puzzles that meet their nature and kick-start an entire field of research, to which we will return.
2.2 Hashcash
A very similar idea called Hashcash was independently invented in 1997 by Adam Back, then a post-doctoral fellow in the Cypherpunk community. Cypherpunk members are activists against government and anti-central institutional forces and are committed to promoting social and political change through cryptography. Adam Back is a man of practice: he first released the Hashcash software and published the Internet draft (standardization document) and paper (Reference 4) five years later, in 2002.
Hashcash is much simpler than Cynthia Dwork and Moni Naor’s idea: it has no back door, no central authority, and it uses hash functions instead of digital signatures. Hashcash is based on a simple principle: Hash functions behave as random functions for some practical purposes, which means that the only way to find the input that hashes to a particular output is to try various inputs until the desired output is produced. Furthermore, the only way to find the input that hashes to any set of outputs is to try hashing the different inputs one at a time again. So, if you try to find a hash value output begins with 10 zero input (binary), you will have to try a lot of input, you will find that each output from 10 zero chance are 10 ^ (1/2), which means you will have to try to 10 ^ (2) the order of the input, or about 1000 hash is calculated.
As the name suggests, in Hashcash, Adam Back treats proof of work as a form of currency. On his website, he identifies the currency as one of David Chaum’s options for implementing DigiCash — a system in which banks issue untraceable digital cash to users. He even made some trade-offs in the technical design to make it look more like a currency. Later, Adam Back commented that Bitcoin was a direct extension of Hashcash. However, Hashcash is not cash because it has no protection against double spending (double spending). Hashcash tokens cannot be exchanged between peers.
At the same time, in the academic field, researchers have found that in addition to spam, proof of work has many application scenarios, such as preventing denial of service attacks (reference 25), ensuring the authenticity of network analysis (reference 17), rate limited password online guessing (reference 38), etc. Incidentally, the term proof of work was first coined in a 1999 paper by Markus Jakobsson and Ari Juels, which is an excellent review of this research up to that point (reference 24). It’s worth noting that these researchers don’t seem to know that hashcash, which independently aggregates in the direction of hash-based proof-of-work, This is mentioned in papers by Eran Gabber et al., as well as in papers by Juels(Reference 18) and Brainard(Reference 25) (many of the terms used here did not become standard until long after the papers in question were published).
Sidebar: Sybil-Resistant Networks
In his paper on Sybil attacks, John Douceur proposed that all nodes participating in the BFT protocol need to solve the hashcash problem. If a node masquerades as N identities, N problems cannot be solved in time and its forged identities will be removed. However, malicious nodes can still gain an advantage over honest nodes that claim a single identity. A follow-up article published in 2005 (Reference 1) suggested that honest nodes should in turn mimic the behavior of malicious nodes and claim as many virtual identities as their computing power can afford. Using these virtual identities to execute the BFT protocol, the original assumption that “at most some F nodes fail” can be replaced by “at most a fraction of the total computing power controlled by the failed nodes is F”. So authentication is no longer required, and open peer-to-peer networks can run THE BFT protocol, an idea that Bitcoin uses exactly, but Nakamoto raises a further question: What is the incentive for nodes to perform expensive proof-of-work calculations? The answer requires a further leap: digital currency.
2.3 Proof of Work and Digital Cash: A catch-22
As you probably know, proof of workload as an anti-spam measure has not been successfully applied to the application from which it originated. One possible reason is the huge difference in the speed at which different devices solve difficult problems. This means that spammers can increase the rate of spamming by orders of magnitude by customizing hardware for a small investment. In economics, the natural response to asymmetries in the cost of production is to trade — that is, to a market for proof of work. But this is a catch-22, because it would require a working digital currency. In fact, it is the lack of such a currency that causes the greatest incentive to use proof of work to be inadequate. A crude solution to this problem would be to declare that the solution to the problem is cash, as Hashcash tries to do.
* A double-loop dilemma is an inextricable predicament caused by conflicting laws or conditions; Or illogical or contradictory questions. For example, this is a paradox: no one wants to support you unless you are already successful, but if no one supports you, how can you be successful?
A clearer solution to treating problem solving as cash was found in two previous articles on Bitcoin, which described B-Money (reference 13) and Bit Gold (Reference 42) respectively. These schemes provide a timestamp service to sign the creation of the money (with proof of work), and once the money has been created, the transfer can be signed. However, the article does not provide a clear solution if the total ledger is inconsistent between servers or nodes. Relying on majority rule to decide seems to be the implicit implication of the authors’ paper, but due to the Sybil issue, these mechanisms are not very secure unless there is a Gatekeeper to control network access, or the Sybil antagonism itself is implemented through proof of work.
3. Putting It All Together
By getting to know all these predecessors who contributed to bitcoin’s various design details, you can appreciate satoshi’s true genius of innovation. In Bitcoin, problem solutions don’t build themselves into cash; instead, they’re just used to protect the general ledger. The work-to-prove solution is done by specialized entities called miners (although Satoshi nakamoto underestimated how specialized mining would be achieved).
Miners are constantly competing with each other to find the next solution to the puzzle. Each miner has to solve a slightly different variant of the puzzle, so the chance of success is proportional to the share of global mining capacity that the miner controls. The miners who solved the puzzle contributed the next lot, or block (i.e., the next transaction) of the ledger based on a chained timestamp. By maintaining and exchanging master ledgers, miners who contribute a block are rewarded with a share of newly mined currency. It is likely that if one miner contributes an invalid block or transaction, it will be rejected by most other miners who contribute the next block, thus invalidating the award for the invalid block. Thus, with financial incentives, the miners ensured that they followed the same agreement with each other.
Bitcoin deftly avoids the double-spending problem that plagues proof-of-work-as-cash because it avoids the value of the solution itself. In fact, Bitcoin decouples the solution from economic value twice: the amount of work required to produce a block is a floating parameter (proportional to global mining capacity), and the number of bitcoins issued per block is not fixed. Block rewards (that is, how new bitcoins are mined) are set in half every four years (in 2017, the reward was 12.5 bitcoins per block, halved from the original 50 bitcoins per block). Bitcoin includes an additional reward program — the originator of a transaction pays a transaction fee to a miner who has the block containing the transaction, and expects the market to determine the transaction fee and the miner’s compensation.
The genius of Satoshi Nakamoto, then, was not any single component of Bitcoin, but a complex way of bringing technologies together to breathe life into the system. To be fair, researchers on timestamps and Byzantine protocols did not touch on the node incentive problem until 2005, nor did they use proof of work to eliminate the node identity problem. Conversely, the authors of Hashcash, B-Money, and Bit Gold do not incorporate the idea of consensus/consistency algorithms to solve the double-spending (double-spending) problem. In Bitcoin, a secure master ledger prevents the double spending problem and thus ensures that the currency has value. Miners are rewarded with valuable currency, and then the strength of the mining force keeps the ledger safe. Without sufficient mining power, an adversary could capture more than 50% of the global mining capacity, thus being able to generate blocks of data faster than the rest of the network, and then double pay for transactions and effectively rewrite the historical record, leaving the entire system in the red. Therefore, Bitcoin is boothigh, with a closed-loop dependency between the three components of the ledger, the currency, and the miners. The challenge for Satoshi Nakamoto is not just design, but being able to convince initial users to take the leap, along with the mining community, into an era of the unknown: a time when pizza cost more than 10,000 bitcoins and the mining capacity of the web was less than a trillionth of what it is today.
Sidebar: Smart Contracts
A smart contract is all about putting data in a secure master ledger and extending the smart contract to computing. In other words, it is a consensus protocol that publicly specifies the proper execution of the program. Users can invoke functions in the smart contract program, subject to any restrictions specified by the program, and the functional code is executed by miners in tandem. Users can trust the output without having to redo calculations, and can write their own programs to handle the output of other programs. Combined with a cryptocurrency platform, smart contracts are especially powerful because the programs can handle money — owning, transferring, destroying, and in some cases even printing it.
Bitcoin implements a restrictive programming language as a smart contract. A “standard” transaction (in which money is transferred from one address to another) is a short script implemented in this language. Ethereum offers a more tolerant and powerful language.
The idea of smart contract was put forward by Nick Szabo in 1994 (reference 41). Because it can be compared with legal contract (smart contract has more automatic execution function than legal contract), it is named smart contract. Nick Szabo presciently (this view has been criticized by Karen Levy (reference 31) and Ed Felten (reference 16)) proposed smart contracts as extensions of digital cash protocols and recognized that Byzantine protocols and digital signatures (etc.) can be used as building blocks. The success of cryptocurrencies has made smart contracts a reality, and research on the topic has taken off. For example, programming language researchers have adapted their methods and tools to automatically detect errors in smart contracts and write checkable smart contracts.
3.1 Public Keys as Identities
This article is based on the understanding that a secure master ledger makes it easier to create digital currencies. Let’s revisit this assertion. When Alice wishes to pay Bob, she broadcasts the transaction to all the Bitcoin nodes. A transaction is nothing more than a string: a statement “Alice wishes to pay Bob some money” signed by Alice. Eventually, the claim was entered into the miner’s master ledger and the deal became a reality. Note that Bob is not required to participate in any way in this process. But let’s focus on the absentees of this transaction: the obvious absentees are the identities of Alice and Bob; Instead, the transaction contains only their respective public keys. This is an important concept of Bitcoin: the public key is the unique identity in the system. Transactions that pass in or out value to a public key are known as addresses.
From this introduction of the address concept, Satoshi nakamoto’s innovation is ingenious compared to the traditional distributed system.
In order to be able to “speak” an identity, you must know the corresponding key. You can create a new identity at any time — by generating a new key pair — without the need for a central authority or registry. You don’t need to apply for a username or notify others that you have chosen a specific name — the concept of decentralized identity management — and Bitcoin doesn’t specify how Alice tells Bob what her Pseudonyms are, which is external to the system.
Unlike most other payment systems today, these ideas are quite “old”, dating back to David Chaum, the father of digital cash. In fact, David Chaum also made a pioneering contribution to the anonymous web, and it was in this context that he invented the idea of Digital Pseudonyms. In his 1981 paper “Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms(Reference 9)”, he stated: A digital name is a public key used to verify that a signature has been obtained by the anonymous holder of the corresponding private key.
Now, knowing the recipient only through the public key is an obvious problem: not being able to route messages to the correct computer. This results in the David Chaum scheme being extremely inefficient: anonymous transactions that cannot be eliminated. Bitcoin is also extremely inefficient compared to centralized payment systems: the ledger containing each transaction is maintained by each node in the system. In any case, bitcoin chooses security over inefficiency, thereby achieving “free” anonymity (that is, public key identity). David Chaum took these ideas a step further in his 1985 paper (Reference 11) with a vision of e-commerce based on universal “alias” privacy protection and “blind signatures”, the key idea behind digital cash.
The idea of “public key as identity” also exists in the pioneering literature of Bitcoin discussed earlier: B-Money and Bit Gold. But much of the work was based on David Chaum, and David Chaum’s own later work, including e-cash, strayed from this idea. The Cypherpunk community has a strong interest in privacy-protected communications and commerce, and they have embraced what they call nyMS ‘aliases’. But to them, NYMS is not just a cryptographic identity (that is, a public key), but an E-mail address typically associated with a public key. Similarly, Ian Goldberg’s paper – the basis of subsequent anonymous communication work – agrees with David Chaum, but argues that “alias” NYMS should be a credential bound nickname that people can easily remember. Bitcoin therefore proved to be the most successful example of David Chaum’s ideas.
4. The Blockchain
So far, this article has made no mention of blockchain. If you believe the hype, blockchain is the main invention of Bitcoin. What may surprise you is that Satoshi nakamoto didn’t mention the word at all. In fact, blockchain is a technical term that has no standard technical definition, but is used by various parties to refer to systems that bear varying degrees of similarity to bitcoin and the master ledger.
A discussion of sample applications that benefit from blockchain will help clarify the different uses of the term. First, consider the back end of a database of transactions between a consortium of banks, which are netted at the end of each day, with accounts settled by the central bank. Such a system has a few clear parties, so Mr Nakamoto’s consensus would be overkill. There is also no need for currencies on the blockchain, since accounts are denominated in traditional currencies. On the other hand, chained timestamps are clearly useful, at least to ensure consistent global transaction ordering in the case of network latency. State replication is also useful: a bank knows that its local copy of data is the same as the data the central bank uses to settle its accounts. This frees banks from the costly co-ordination process they now have to carry out.
Second, consider an asset management application, such as a document registry that tracks ownership of financial securities, real estate, or any other asset. Using blockchain can improve interoperability and lower barriers to entry. We want a secure global register of documents, preferably with public participation. This is essentially what the timestamp service of the 1990s and the new millennium provided. Public blockchains provide a particularly efficient way to do this (the data itself may be stored off the chain, only the metadata stored on the chain). Other applications also benefit from timestamp or “bulletin board” abstractions, most notably electronic voting.
Let’s move on to the asset management example. Suppose you want to execute an asset transaction via blockchain, rather than just keep a record of the transaction. If the asset itself is issued digitally on the blockchain and the blockchain supports smart contracts, it can be traded. In this case, smart contracts solve the “fair exchange” problem of ensuring that payments are made only when assets are transferred. More generally, smart contracts can encode complex business logic as long as all the necessary input data (assets, prices, etc.) are represented on the blockchain.
This mapping of blockchain properties to applications allows us not only to appreciate its potential, but also to inject a much-needed dose of skepticism. First, many of the proposed blockchain applications, particularly in banking, do not use Nakamoto’s consensus mechanism. Instead, they use master ledger data structures and Byzantine protocols (techniques that, as mentioned earlier, date back to the 1990s). This implies that blockchain is a new revolutionary technology. Instead, the buzz around blockchain has helped banks launch collective actions to deploy shared ledger technology, a metaphor for stone soup. Bitcoin is also a very obvious proof of concept for decentralized ledger work, and the Bitcoin Core project provides a handy codebase that can be tweaked as needed.
“Stone Soup” is an adaptation of a French folktale, but Joan Mutter set the story in ancient China. Three monks came to a village that had suffered so much that the villagers had hardened their hearts and were unwilling to accept anyone. However, the monks use the method of cooking stone soup, so that the villagers unknowingly pay a lot, understand the true meaning of sharing and happiness.
Joan Mutter is an American picture book writer and painter who studied in Japan and was fascinated by traditional Japanese and Chinese culture. He has created many picture books with Oriental philosophical wisdom, such as The Story of Zen.
Second, there is a misleading claim that blockchains are generally more secure than traditional document registries. To understand why, it is important to separate the overall stability of a system or platform from end-point security (that is, the security of users and devices). True, the systemic risk of blockchain may be lower than that of many central institutions, but the endpoint security risk of blockchain is much higher than the corresponding risk of traditional institutions. Blockchain transactions are almost instantaneous, irreversible and, in a public blockchain, designed to be anonymous. In a blockchain-based stock registry, if a user (broker or agent) loses control of his private key — as long as the phone is lost or malware is installed on the computer — the user loses his assets. Bitcoin’s extraordinary history of hacking, theft and fraud does not inspire much confidence, with it estimated that at least 6% of all bitcoins in circulation have been stolen once (Reference 39).
Sidebar: Permissioned Blockchains
While this article highlights that private and licensed blockchains don’t use most of bitcoin’s innovation, that doesn’t mean there’s less interesting work happening in this space. Licensed blockchains restrict who can join the network, write transactions or mine (blocks). In particular, if miners are restricted to a list of trusted participants, proof of work can be waived in favour of the more traditional BFT approach. Therefore, most of the research is a rebirth of the BFT algorithm, and can ask the following questions: Can we use hash trees to simplify the consensus algorithm? What if the network can only fail in a certain way?
There are also important considerations around topics such as identity and public key infrastructure, access control, and the confidentiality of the data stored on the blockchain. These issues are largely absent from public blockchains and have not been examined in the traditional BFT literature.
Finally, there is an engineering effort to increase the throughput of blockchain and apply it to a variety of businesses: supply chain management and financial technology, for example.
5 Concluding Lessons
The history described here offers rich (and complementary) lessons for practitioners and professional scholars alike. Practitioners should be skeptical of claims of revolutionary technology. As noted above, most of the ideas in Bitcoin that have caused corporate excitement, such as distributed ledgers and Byzantine protocols, date back more than 20 years. Recognize that your problem may not require any radical innovation — long-forgotten solutions can be found in research papers.
Academia seems to have the opposite problem, at least in this case: resistance to radical, exotic ideas. Many of the ideas in the Bitcoin white paper, while dating back to its pedigree, are newer than most academic studies. Moreover, Satoshi nakamoto does not care about academic peer review and does not fully relate it to academic history. So for years, academia almost completely ignored bitcoin. Many academic communities have informally argued that while bitcoin actually works well in practice, it cannot be based on the theoretical models and experiences of past systems.
We see time and again that ideas in the research literature can be gradually forgotten or ignored, especially if they are ahead of their time, even outside popular research areas. Practitioners and academics alike should review old ideas and glean insights into current systems. What’s remarkable and successful about Bitcoin is not that it’s at the forefront of any component research, but that it incorporates many old ideas from unrelated fields. It’s not easy to do this because it requires bridging different terms, assumptions, etc., but it’s a valuable blueprint for innovation.
Practitioners should be able to identify and benefit from over-hyped technologies. There are some indicators to identify technology hype: it is difficult to determine its technological innovation; Because companies are eager to attach their products to trends, it is difficult to determine the meaning of so-called technical terms; Difficulty identifying the problem being solved; Finally, technology is required to solve social problems or create economic/political instability.
Academia, by contrast, has struggled to sell its inventions. Unfortunately, for example, the initial workload proved that the researchers were not given credit for Bitcoin, probably because the work was not well known outside academia. In academia, activities such as publishing code and collaborating with practitioners are underrewarded. In fact, to date, the original branch of academic proof of work still does not recognize the existence of Bitcoin! Getting in touch with the real world not only helps you get credit, but it also cuts down on reinventing the wheel and leads to new ideas.
6 (Acknowledgements) thank you.
The authors are grateful to Adam Back, Andrew Miller, Edward Felten, Harry Kalodner, Ian Goldberg, Ian Grigg, Joseph Bonneau, Malte Möser, Mike Just, Neha Narula, Steven Goldfeder, and Stuart Haber for valuable feedback on a draft.
7 References
1. Aspnes, J., et al. 2005. Exposing computationally challenged Byzantine imposters. Yale University Department of Computer Science; http://cs.yale.edu/publications/techreports/tr1332.pdf.
2. Back, A. 1997. A partial hash collision based postage scheme; http://www.hashcash.org/papers/announce.txt.
3. Back, A. 2001. Hash cash; https://web.archive.org/web/20010614013848/http://cypherspace.org/hashcash/.
4. Back, A. 2002. Hashcash – A denial of service counter measure; http://www.hashcash.org/papers/hashcash.pdf.
5. Bayer, D., Haber, S., Stornetta, W. S. Improving the efficiency and reliability of digital time-stamping. Proceedings of Sequences 1991; https://link.springer.com/chapter/10.1007/978-1-4613-9323-8_24.
6. Benaloh, J., de Mare, M. 1991. Efficient broadcast timestamping; http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.9199.
7. Boyle, T. F. 1997. GLT and GLR: Component architecture for general ledgers; https://linas.org/mirrors/www.gldialtone.com/2001.07.14/GLT-GLR.htm.
8. Castro, M., Liskov, B. 1999. Practical Byzantine fault tolerance. Proceedings of the Third Symposium on Operating Systems Design and Implementation; http://pmg.csail.mit.edu/papers/osdi99.pdf.
9. Chaum, D. 1981. Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM 24(2): 84-90; https://dl.acm.org/citation.cfm?id=358563.
10. Chaum, D. 1983. Blind signatures for untraceable payments. Advances in Cryptology: 199-203.
11. Chaum, D. 1985. Security without identification: transaction systems to make Big Brother obsolete. Communications of the ACM 28(10): 1030-1044; https://dl.acm.org/citation.cfm?id=4373.
12. Chaum, D., et al. 1988. Untraceable electronic cash. Advances in Cryptology: 319-327; https://dl.acm.org/citation.cfm?id=88969.
13. Dai, W. 1998; http://www.weidai.com/bmoney.txt.
14. Douceur, J. R. 2002. The Sybil attack; https://dl.acm.org/citation.cfm?id=687813.
15. Dwork, C., Naor, M. 1992. Pricing via processing or combatting junk mail; https://dl.acm.org/citation.cfm?id=705669.
16. Felten, E. 2017. Smart contracts: neither smart nor contracts? Freedom to Tinker; https://freedom-to-tinker.com/2017/02/20/smart-contracts-neither-smart-not-contracts/.
17. Franklin, M. K., Malkhi, D. 1997. Auditable metering and lightweight security; http://www.hashcash.org/papers/auditable-metering.pdf.
18. Gabber, E., et al. 1998. Curbing Junk E-Mail via Secure Classiffication. http://www.hashcash.org/papers/secure-classification.pdf.
19. Garay, J. A., et al. 2015. The bitcoin backbone protocol: analysis and applications. Advances in Cryptology: 281-310; https://eprint.iacr.org/2014/765.pdf.
20. Goldberg, I. 2000. A pseudonymous communications infrastructure for the Internet. Ph.D. dissertation, University of California Berkeley; http://moria.freehaven.net/anonbib/cache/ian-thesis.pdf.
21. Grigg, I. 2005. Triple entry accounting; http://iang.org/papers/triple_entry.html.
22. Haber, S., Stornetta, W. S. 1991. How to timestamp a digital document. Journal of Cryptology 3(2): 99-111; https://link.springer.com/chapter/10.1007/3-540-38424-3_32.
23. Haber, S., Stornetta, W. S. 1997. Secure names for bit-strings. In Proceedings of the 4th ACM Conference on Computer and Communications Security: 28-35; http://dl.acm.org/citation.cfm?id=266430.
24. Jakobsson, M., Juels, A. 1999. Proofs of work and bread pudding protocols; http://www.hashcash.org/papers/bread-pudding.pdf.
25. Juels, A., Brainard, J. 1999. Client puzzles: a cryptographic countermeasure against connection completion attacks. Proceedings of Networks and Distributed Security Systems: 151-165; https://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/juels.pdf.
26. Just, M. 1998. Some timestamping protocol failures; http://www.isoc.org/isoc/conferences/ndss/98/just.pdf.
27. Lamport, L., et al. 1982. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems 4(3): 382-401; https://dl.acm.org/citation.cfm?id=357176 .
28. Lamport, L. 1989. The part-time parliament. Digital Equipment Corporation; https://computerarchive.org/files/mirror/www.bitsavers.org/pdf/dec/tech_reports/SRC-RR-49.pdf.
29. Lamport, L. 2001. Paxos made simple; http://lamport.azurewebsites.net/pubs/paxos-simple.pdf.
30. Laurie, B. 2014. Certificate Transparency. acmqueue 12(8); https://queue.acm.org/detail.cfm?id=2668154.
31. Levy, K. E. C. 2017. Book-smart, not street-smart: blockchain-based smart contracts and the social workings of law. Engaging Science, Technology, and Society 3: 1-15; http://estsjournal.org/article/view/107.
32. Melara, M., et al. 2015. CONIKS: bringing key transparency to end users. Proceedings of the 24th Usenix Security Symposium; https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-melara.pdf.
33. Merkle, R. C. 1980. Protocols for public key cryptosystems. IEEE Symposium on Security and Privacy; http://www.merkle.com/papers/Protocols.pdf.
34. Nakamoto, S. 2008. Bitcoin: a peer-to-peer electronic cash system; https://bitcoin.org/bitcoin.pdf.
35. Nakamoto, S. 2008. Re: Bitcoin P2P e-cash paper; http://satoshi.nakamotoinstitute.org/emails/cryptography/11/.
36. Narayanan, A., et al. 2016. Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press; http://bitcoinbook.cs.princeton.edu/.
37. Pass, R., et al. 2017. Analysis of the blockchain protocol in asynchronous networks. Annual International Conference on the Theory and Applications of Cryptographic Techniques; https://link.springer.com/chapter/10.1007/978-3-319-56614-6_22.
38. Pinkas, B., Sander, T. 2002. Securing passwords against dictionary attacks. Proceedings of the Ninth ACM Conference on Computer and Communications Security: 161-170; https://dl.acm.org/citation.cfm?id=586133.
39. Reuters. 2014. Mind your wallet: why the underworld loves bitcoin; http://www.cnbc.com/2014/03/14/mind-your-wallet-why-the-underworld-loves-bitcoin.html.
40. Sirer, E. G. 2016. Bitcoin guarantees strong, not eventual, consistency. Hacking, Distributed; http://hackingdistributed.com/2016/03/01/bitcoin-guarantees-strong-not-eventual-consistency/.
41. Szabo, N. 1994. Smart contracts; http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart. contracts.html.
42. Szabo, N. 2008. Bit gold. Unenumerated; https://unenumerated.blogspot.com/2005/12/bit-gold.html.
43. Wattenhofer, R. 2016. The Science of the Blockchain. Inverted Forest Publishing.
44. Rivest, R. L., Shamir, A. 1996. PayWord and MicroMint: Two simple micropayment schemes. International Workshop on Security Protocols.