From “Information Blocks” to “Blockchains”: Blockchain as a Completion of the Internet

8,004 characters2019.10.27

A commissioned piece riding a hot topic for JieMian. I’m currently in Hefei attending the annual conference on Chinese history of science, and I wrote this last night on my bed after a full day of meetings, so it’s a bit rushed.

Still, this counts as my first article that departs from Bitcoin and talks specifically about blockchain. In my view, the core application of blockchain is undoubtedly still currency; blockchain technology divorced from currency, or from currency in the broader sense (securities, etc.), is basically just a gimmick. But that does not stop us from indeed being able to seek a place for blockchain technology in the history of the internet’s development, beyond Bitcoin. Below is the full repost:

 

In 1959, Paul Baran, who had just joined RAND, took part in a project commissioned by the U.S. Air Force, with the goal of devising a scheme to keep the communications command system operating under nuclear war.

The Soviet Union was the first to launch an artificial satellite in 1957, which meant that the Soviets could deliver nuclear warheads anywhere on Earth. Under the pressure of the Cold War, Americans studied countermeasures on the premise that they might at any time suffer a nuclear strike. Under nuclear attack, the command center would certainly be a primary target; no matter how much air-defense infrastructure was built, it would be difficult to ensure that the command center would not be paralyzed for a shorter or longer period of time. So how could communications among different regions be maintained after the command center or the hub of the communication lines was destroyed? The solution Baran finally came up with was “distributed communication.”

The core concept Baran proposed was “message blocks,” that is, to split the message to be transmitted into chunks and send them separately, rather than, as in the traditional telephone system, establishing a continuous connection between two points.

Later, this term was replaced by the concept we now know as the “data packet”: each “block” of data is like a postal parcel. The sender does not designate a single route of transmission, but only specifies a definite “destination.” The same block of data can propagate simultaneously along different paths, as long as it ultimately reaches the recipient.

For example, if A wants to send a message to D, it does not have to be relayed through the central node O; it could go A→B→C→D, or A→F→E→D, or A→C→E→D, and so on. In this way, no matter which node fails, the message can still find another path to be transmitted. Thus the entire communications system’s resilience, or rather its fault tolerance, is greatly strengthened.

 

Of course, remote transmission of information will always have problems of error and omission, so a series of protocol rules still needs to be designed so that data can be checked in time and retransmission or connection termination can be requested when problems arise.

This distributed communication system is the prototype of the “network”; communication networks born of similar ideas were the precursor of the later internet. Put simply, the starting point of internet technology was to solve the problem of “decentralizing communication.”

Message fragmentation ensured a network that was no longer centered, but once continuous messages were broken into blocks, a new problem immediately arose: how do we determine the order of the blocks? When the first block of data is transmitted along A→F→E→D, the second block may already have reached its destination via A→C→D. The recipient then needs to reconstruct their original order in order to accurately recover the complete message.

At first glance, this problem seems easy to solve: as long as A stamps a “time stamp” on each “parcel” when sending the information, the recipient can rearrange them according to the stamps on the parcels and naturally recover the correct order.

But that is premised on the sender not cheating. What if the sender deliberately or inadvertently sends false information? How should that be handled?

If the only things exchanged in network communication are digital information itself, then erroneous and contradictory information is nothing more than a bit of clutter; it can simply be cleaned up in the end. But the key point is that, with the development of the information age, what we exchange through the internet is no longer merely numbers in the abstract, or rather, some numbers have acquired extra value.

For instance, the string of numbers in my bankbook is enormously valuable. If that string of numbers is off by a bit, with the order changed around, I might end up getting rich. And when I take a big flourish and write a string of numbers on a check and send it to a friend, that letter too acquires extra value. Of course, the recipient will ultimately still have to go to the bank to cash it in, in order to ensure that my check does not contain deliberate or inadvertent errors.

Whether filling out a check or cashing a check, it all amounts to processes of information transmission and verification. So can all these processes be carried out on the network? Of course they can; by now we are long used to online banking and online payments.

But in this case, we find that the “center” has come back. When the sender may falsify, we must appeal to a third party for trust or verification. Thus one often needs a core node O (such as a bank) to provide the most authoritative judgment.

Then can this core arbiter be further “decentralized”? For example, we let nodes such as B, C, E, and F all have the authority to arbitrate, so that even if the central node is lost, trustworthy transactions can still be established among the nodes.

For instance, A’s “bankbook” is not stored only at O; B, C, E, and F each keep a copy. When A issues a check, they can all compare it against the balance in the record; as long as A’s deposit is sufficient, the corresponding amount is transferred to D’s name and the completion of this remittance is confirmed; if A’s deposit is insufficient, the remittance is vetoed and A is judged to be cheating.

This scheme of replacing a “central ledger” with a “public ledger” is not hard to imagine, but the problem with it is also easy to imagine—what if contradictions arise among the verifiers again?

For example, A sends a message to B saying: transfer all my deposits to C; at the same time, A sends a message to F saying: transfer all my deposits to E. The result is that C and E both receive all of A’s deposits. Who, exactly, should be awarded them?

Perhaps we can do it this way: we wait a bit, and after all nodes across the network have received the information, we vote together, and the information with more support gets priority. But the problem is, how can we tell that the information has been disseminated widely enough across the “entire network”? And how should the counting of nodes be compared? (Because on the internet, one can create countless virtual nodes at any time.)

So many people gave up on pushing decentralization of the network further, believing that decentralization is only possible in those simple processes of information transmission that do not involve trust issues, while once trust and arbitration are involved, one must still establish a supreme authority.

It was not until 2008, when Satoshi Nakamoto proposed the concept of “blockchain,” that this final piece was added to the “distributed network.”

The “block” in blockchain is of course not Baran’s “message block,” but the underlying logic is strikingly similar. Baran broke continuous messages into blocks, while Satoshi Nakamoto broke up the “public ledger” into blocks. The public ledger is no longer the accumulation of records written continuously one by one, but rather records over a certain period of time are packaged into blocks and accumulated block by block.

The basic scheme remains this: all nodes in the network have the right to verify every piece of information, and in the end, through “voting,” the majority decides the contents of the ledger. But both “voting” and “accounting” are done in units of “blocks,” not continuously; after each “ledger block” is packaged, there is sufficient time for the whole network to confirm it. And voting power is not determined by the number of nodes, but by a kind of “computational competition.”

The specific details of ledger blockification and computational competition involve cryptographic techniques, so I won’t expand on them here. This article only wants to discuss the result achieved by blockchain technology, namely, that it enables the propagation of “trust” in a distributed network in the absence of an authority center.

Some people describe blockchain technology as a marker of “Web 3.0,” and that is not without reason, but I would rather say that it was not until blockchain technology that “Web 1.0” was truly completed. It made this “decentralized communication network” not merely “effective,” but also “trustworthy.”

Of course, like the internet, blockchain technology, as a kind of underlying design, may support entirely different directions of application. For example, the internet can be welcomed by the military and the government, welcomed by scholars and merchants, and at the same time welcomed by anarchists and criminals. Blockchain is the same. This is precisely why we must, with an open mind, actively push forward the development of blockchain-related technologies and the legislative process.

Translated from the Chinese original with AI assistance. The original text is authoritative.

After submitting, click the confirmation link in your inbox to complete the subscription.

Advanced: subscribe only to selected topics

勾选后只收所选主题的新文章;不勾选则订阅全部。

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

To respond on your own website, enter the URL of your response which should contain a link to this post’s permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post’s URL again. (Find out more about Webmentions.)