Re-examining blockchain from Satoshi Nakamoto’s white paper

Translation: Height difference signal is full

As we approach 2016, it feels like there is a lot of talk about blockchain. Even in the mainstream media, the term is increasingly mentioned, and in the field of Internet finance alone, there are a large number of people who claim to be service providers and users who assert that blockchain will have a revolutionary impact on many applications.

As this term is used by more and more people, we have to clarify its definition to help people better understand it, but this is more like a catchphrase than a deeper understanding.

There are a lot of opinions in the Internet space, but it is disappointing that we cannot find a unified opinion. Blockchain is not just an exaggerated buzzword in the market, we must answer some questions.

What is blockchain? What is it not? What could it be? Can we use it to build a new and lasting system? In short, what is the essence of blockchain?

Satoshi Nakamoto’s White Paper

Almost all discussions about blockchain originate from Satoshi Nakamoto's white paper, but it is this foundation that leads us to confusion. Whether it should be called "blockchain" or "blockchain", the book mentions "block" 67 times, "chain" 27 times, but "blockchain" or "blockchain" zero times. Putting this aside, let's see where this book leads us.

The white paper is short, only 9 pages. The first mention of "block" and "chain" is at the bottom of page 2, in Section 3, where the principle of the timestamp server is discussed. Before that, the author describes a series of design goals associated with Bitcoin, such as enabling transactions between two parties without the need for trust and a third party.

It is very important to discuss the design goals. It sets the stage for describing the application that achieves these goals. Such an application is characterized by one layer stacked on top of another, and we just need to understand what the role of each new layer is.

As we seek to answer the question of the nature of blockchain, we must look closely at the properties of things, rather than the characteristics of their first application.

trade

Chapter 1 of the white paper is the introduction to the entire book, and like Chapter 2, there is nothing of value there. Chapter 2 lays the groundwork for digital currency, but the author describes how “coins” are assigned to new owners in a chain of transactions. Here “coins” are just a metaphor for the history of associated transactions.

Interestingly, Section 2 also describes a centralized system that does not require the above operations to be completed.

Blocks and chains

In Chapter 3, we saw the essence of the design pattern, which can be regarded as the best description of the foundation of blockchain. The author designed a kind of data block that can be appended, each block has a hash code that is related to its content. In addition, each block can be merged with the cryptographic hash value of the previous data block, thus ensuring the construction of the entire chain.

The published block hash value can be used as evidence of the existence of the block data and the hash value of the previous block, and is open to the public online. If the previous block or other data in the entire block is changed, the system will generate a different block signature, which will not match the hash value previously witnessed by the public.

These features are fundamental to the whole design, and without them, we would not be able to build anything interesting. Also interesting are some of the things that are not mentioned here. There is no mention of "coins", no mention of peer-to-peer networks, no mention of mining, etc. Instead, the author thinks that it is enough to publish these hashes in a broad way, and he gives two examples, in a newspaper or on a user website.

But we found some features that lead us to speculate on the underlying meaning:

Unless an external observer obtains the data of the block in the chain and independently calculates and obtains the same hash value, then it makes sense to publish this hash value. External observers do not need to trust the creator of the blockchain, they only need to compare the historical hash values ​​themselves.

Recalculating the hash value requires a special algorithm based on which the blocks are generated. Without this algorithm, it is impossible for an external observer to recalculate the hash value.

Making peer-to-peer possible

In the next section, Section 4, the white paper discusses Proof of Work. The first line is very interesting: "To deploy a distributed timestamp server on a peer-to-peer (P2P) basis, we must use a Proof of Work system similar to Adam Back Hashcash. Proof of Work is not required to build a blockchain, it is only required to ensure the deployment of the timestamp server.

Subsequent cryptocurrency designs have shown that other approaches can be used (such as proof-of-stake, or a hybrid of the two), but if we feel that the client-server model is sufficient, the above approaches are unnecessary.

I’m not saying that proof of work doesn’t have other uses in blockchain design, but it doesn’t seem very important to our problem.

Web and beyond

Chapter 5 describes the application features of the Bitcoin network. It does not clarify or require the expansion of the concept of blockchain. In addition, the subsequent chapters 6, 7, 8, 9, 10, 11 or 12 (the last chapter) do not propose any new ideas about blockchain.

Answer our questions

If Satoshi Nakamoto’s white paper is the source of blockchain design, he left us with a thin definition, which is perhaps the most enlightening aspect. The author is very clear about the specific design choices and their purpose, and we seem to be able to conclude that the various discussions of blockchain may just be a matter of application, not a structural issue.

Here are some specific questions!

Does blockchain require the participation of “coins”?

The white paper has a fascinating discussion on how to provide incentives to ensure the honesty of participants in the P2P network, and whether to introduce "coins" into the system, but it is obvious that the discussion is within the framework of the P2P network. The book argues that the concept of "coins" is an unnecessary trustworthy "huge sum of money".

Trusted large sums of money are not what cryptocurrencies are about, but if we want to build a cryptographically linked blockchain, we don’t seem to need “coins.” This is a question of trust, which we will come back to later.

Does blockchain have to include smart contracts?

This is unlikely from the perspective of the white paper. The word "contract" does not appear in the white paper.

Can smart contracts be run on blockchain? Of course, blockchain can also run many other things.

Does blockchain have to be programmable?

Again, the answer to this question appears to be no. Neither “program” nor “script” appears in the white paper.

Blockchain does require interpretability. Blockchain must be interpretable by one or more independent observers, so blockchain is built on one or more well-defined data structures. This data block structure must include the hash value of the previous block, and the cryptographic hash of the block must follow a special method, but none of the above principles require the data structure to contain executable coding concepts.

Can a blockchain contain some form of programming code? This is a practical question, and the answer is yes. Bitcoin includes a limited scripting language, while other systems, such as Ethereum, have subsequently attempted to support more complex programming models.

If a blockchain can be designed to support these concepts, then it is a very ambitious design, but it seems that blockchains need to be more programmable than other linked data list structures.

Is blockchain a database?

Another question whose answer is no. As mentioned above, the word "database" does not appear in the white paper.

At its core, a blockchain is a special type of data structure. Blocks in a chain contain data, but we cannot think of it as a database; at most, a blockchain is a transaction record that represents a specific data application.

Likewise, there is no questioning of the semantics of a blockchain, nor of a list of associations. A particular application might allow for questioning, but the application cannot define the thing itself.

As a point of comparison, TCP packets contain this requirement in IP packets, which we define as a data structure in a series of IETF (Internet Engineering Task Force) RFCs (Request for Comments). These two documents describe the appearance of packets and the behavior of packets when they are transmitted. The receiver of the packet can determine for themselves whether the packet is valid without any network involvement between them and the originator of the message.

Any router or firewall can receive these packets and analyze them later. These instruments may provide data queries of information tables, but despite the above characteristics of IP packets, we do not regard them as databases, and there is nothing in the RFC that allows us to deduce that it is a database. Application characteristics and self-attributes are two completely different things.

Blockchain does not require trust between people?

The answer here is still no, but this question is too broad. With blockchain, we do need less trust than with traditional systems, but the execution of any application of blockchain still requires some level of trust.

The recipient must trust that the data block has not been altered or corrupted by any intermediary during its transmission. The purpose of establishing a P2P distributed blockchain network within Bitcoin and other networks is to reduce the trust requirements between people, but even with this model, there are still some potential failure points, for example:

We trust the blockchain software to be uncorrupted in operation and to transmit non-forged data.

We trust the operating system running the blockchain software to be uncorrupted and transmit non-forged data;

We trust the central processing unit that provides the network for the system to remain intact and transmit genuine data.

“We trust in code” is an interesting slogan, but with malware, spyware, etc. more than 30 years old, we still need to be skeptical of this strategy.

Blockchain design cannot make forgery more difficult, but it greatly reduces the possibility of accidental errors. We can "trust and prove" (within limits), which is already a huge improvement over blind trust. More importantly, these trust-reducing features are not features of P2P network design, but are the essence of blockchain encoding.

Is blockchain permissionless or permission-less?

Blockchains are just data structures, so this question is actually meaningless. Who has the ability to read or write on a data structure is a completely different question.

Let’s leave this subtle distinction aside for now, but as a question, it seems to make sense. Consider the example of Bitcoin, who is writing the blockchain?

The answer is that miners (or more specifically, block creators, such as mining pool operators, rather than those who hash blocks) are the ones who write new blocks. Processors on the network offer candidate transactions to be included in blocks, but they are not guaranteed to include them. In Bitcoin, we call this "permissionless" because no one needs explicit permission to be a block creator.

If we think about other potential applications of blockchain design, there is a clear set of participants who want to be able to write block data. But in many cases, there is even only one participant.

This criticism of the potential uses of blockchains makes them little better than databases, but in traditional databases there must be a place for blind trust, but the internal state of the blockchain is generally unknown. Even the simplest use of blockchains can at least provide a verification method for the system, and in order to complete the verification, it must ensure that the history can be verified. But this is just the beginning of the possibilities!

Is blockchain a network of money (or a network of something else?)

Practically speaking, no, or at least not by itself.

When we look at the statement “not a database”, we also touch upon why this statement is incorrect. On the surface, the argument is attractive. There is a view that we can build many technologies on top of the blockchain, so that a network overlay is a layer.

There are many problems with this suggestion, but the most obvious is that the blockchain is just a data structure. Using the blockchain, we can smoothly transmit information on the Internet, but the blockchain cannot generate anything inside or outside of it.

Separating blockchain from its delivery does give blockchain more hope that it can help create more effective Internet financial applications. A clear distinction also makes it possible to experiment with each layer of the design system, which was one of the key features that ensured the success of the Internet.

Just as with the Internet, layers of the network stack can be replaced or altered to ensure the best design wins, a standards-based approach ensures that different applications can work together without losing monetizable business advantages.

In the case of blockchain, we have found that there is already necessary support for external observers, which requires some level of coordination.

Final Thoughts

We have looked at what blockchain might be, or might not be, and what it can enable, and we may have discovered some clues. We can use the technology that powers Bitcoin for many things, and Bitcoin’s legacy cannot be just itself—it has revealed a more fundamental nature to us.

The discussion of what constitutes a blockchain will not end here, but we must move the discussion forward, and we must resist the urge to turn it into just another marketing buzzword.

To achieve the above goals, we need not only clear definitions, but also reasonable usage. We should avoid mixing many different ideas, we need technologies that are feasible and achievable. If we fail, the term "blockchain" will have no meaning and must be replaced. This will be a wrong result.

If we succeed, the idea of ​​blockchain won’t be the end of the story. Blockchain will be a layer upon which better, more useful systems will be built.