The paper Bitcoin: A Peer-to-Peer Electronic Cash System (2008) by Satoshi Nakamoto describes a distributed system framework which allows for electronic payments without the need for a centralized institution to manage the process. Bitcoin is an application of blockchain, a decentralized distributed consensus algorithm, which this paper introduces to accommodate the needs of Bitcoin. Bitcoin and, more generally, blockchain offer an approach to solving consensus with Byzantine actors which has become very popular since this paper’s publication.
The paper is motivated by the apparent necessity of trust in modern electronic payment processing systems. Since many systems rely on a centralized financial system to facilitate and execute transactions, users are at the mercy of the institution with respect to how their transactions are handled. If, for example, a dispute is made to the institution with regards to a particular transaction, the payment may be reversed, resulting in the potential for a user on one side of the transaction to be cheated out of money or services. Because of this, the need to trust both sides of the transaction increases, requiring more information between both parties to be shared. Even with this, some amount of fraud will still take place, which is treated as unavoidable. Bitcoin aims to avoid these problems altogether by relying on cryptographic proof instead of trust.
The paper defines an electronic coin as a chain of digital signatures. The owner of a coin can transfer its ownership to another user by digitally signing a hash of the previous transaction and the public key of the next owner adding this information to the end of the coin. Others can verify the signatures to verify the chain of ownership. The problem with this approach is that a payee can’t verify that one of the owners of the coin did not transfer it already, a form of fraud called double-spending. Typically a centralized institution would be responsible for assuring this isn’t the case. In a decentralized setting, transactions need to be publicly announced and a system of participants need to agree on a single history of the order in which transactions occurred. The payee, then, needs proof that the majority of nodes agree on the order of the transactions. To solve this, the paper proposes a timestamp server where a hash of the previous block is generated and published. The timestamp proves that the data existed at the time since the hash incorporates it. Each timestamp includes the previous timestamp, forming a chain with each additional timestamp enforcing the ones before it.
In order to implement a distributed timestamp server on a peer-to-peer basis, the paper utilizes a proof-of-work system. This involves scanning for a value that, when hashed, begins with a number of zero bits. A nonce in the timestamp is incremented until the block’s hash begins with the required bits. This means that, in order to change the value of a block in a chain, all the following blocks will also need to be hashed correctly. As blocks are added, this becomes infeasible. By using this proof-of-work model, the paper solves the problem of determining representation in majority decision making. Proof-of-work, here, is essentially one-CPU-one-vote (versus something like one-IP-address-one-vote), so that if a majority of CPU power is controlled by honest nodes, the honest chain will grow fastest.
The network runs by first broadcasting a transaction to all nodes. Each node collects new transactions into a block while trying to find a difficult proof-of-work for its block. When such a proof-of-work is found, it’s broadcasted to all nodes. Nodes accept the block only if it’s valid, which then leads to the nodes working on creating the next block in the chain (using the hash of the accepted block). The longest chain is considered the correct chain, so nodes always work on extending the same chain. Owners of nodes are incentivised to mine blocks by creating a new coin, for themselves, as a transaction in the block they are working on.
Blockchain provides rather unique features for a distributed system. A decentralized architecture seems foreign relative to the typically centralized nature of the internet and its services. Despite the issues that come with such a system (which we’ve been able to witness since the publication of this paper), blockchain seems like an interesting and promising approach to a problem we didn’t know existed.
This paper lacks a formalization of the problem it aims to tackle, and in retrospect this seems obvious. Clearly, Bitcoin is an attempt to provide a “better” payment processing system, but it’s not clear how Bitcoin compares to other approaches since we aren’t really provided with such comparisons. Even if it’s the case that Bitcoin can’t be properly compared to other approaches or that this paper simply doesn’t focus on this perspective, I’m not sold on the validity of it’s arguments since I can’t conceptualize what’s being discussed. And obviously, in retrospect, we can see that blockchain and Bitcoin does work and the real-world with moderate success, but this fact doesn’t provide any more insight into what it is we’re really discussing.
I’m curious as to how such ideas could be formalized and what insights we could find through such an exploration. This likely begins with a generalization of the ideas of this paper, and we see, now, where those generalizations can lead to with ideas such as smart contracts and off-chain transactions becoming popular. Still, these advancements seem to have occurred not through rigorous research progress but, rather, as the growth of a popular idea that seemingly came out of nowhere and has provided low hanging fruit for many researchers and engineers.
To start, distributed systems could be broadly classified as centralized or decentralized. According to this paper, there are centralized systems which can be decentralized, and such papers will be made better in this paradigm. Does this mean there are decentralized systems which can be centralized? If so, will they be improved? The paper doesn’t provide such examples or explanations beyond their focus on financial institutions and centralized payment processing.
To me, Bitcoin seems like a specific example of decentralized state management in a distributed application. With Bitcoin, the state is represented by the amount of coin owned by each participant where the state is represented as a sequence of transactions. User’s are provided individual control through hashing so that only they can transact their coins.
Compared to a generic web application, Bitcoin checks many of the boxes required to provide a value for the users. For example, some form of a social media network can be built using the same components. The state of a generic social media network can be represented by transactions of messages. A user replies to a message found in the state by posting a text message which references that message. The user sending this reply can be uniquely identified by their hash (although this isn’t even a requirement in some social media networks). The process can proceed in the same way as Bitcoin.
A system like this may differ from Bitcoin in some important aspects. This blockchain social media network may not need one main chain like Blockchain. In a social media system, threads can be created, replied to, then abandoned, all while being completely disjoint from other threads. Would this allow for such a system to have the flexibility to have multiple active chains? If so, what are the ramifications of such systems? What other systems share a similar quality that can be exploited like this?
The individual user control also offers some interesting potential for more general use. In the social media system, the encryption protocol prevents unauthorized users from creating transactions on other user’s behalf. But this not only means that users can be identified, but it also means that the user can “store” arbitrary private data on the chain. Can this allow for users to communicate privately and anonymously by communicating on this open network? Users can be incentivised to participate in mining through payments which allow them to use the network (similar to Ethereum gas). A user wanting to send a message in this network will need to mine blocks which allow for other users to send messages.
This idea extends to ideas of decentralized web apps where backends don’t exist. Clearly, plenty of web apps depend on a centralized architecture. But would it be possible to run an app where the clients not only facilitate the front-end, but also run the “back-end” through such a distributed scheme? If so, can it be made profitable? Or have it benefit an institution in some way without compromising the decentralized nature of the application?
Many web apps boil down to CRUD operations in a database with role-based permissions granted to authenticated users. Centralized servers typically handle these processes, and often provide some private control important to the functioning of the application. But how much of these apps can be separated and moved to blockchain microservices? Can we offload some of this work on the users? And do we gain anything from this?
This paper is great in how it provokes many interesting questions, but it raises many unanswered questions in the process. Although it is well written and the ideas have been proven to be successful, it almost reads as fiction or a pitch. The lack of formalization in this paper hints at some of the glaring issues with Bitcoin and blockchain, but the core concepts and ideas are certainly worth some attention.