Source: Orange Book
We are familiar with the successful business stories represented by Alibaba, Tencent and ByteDance. We know how WeChat, Taobao, and Douyin have become popular products for the whole people. These cases are within reach of consumers, and they have passed through their respective fields and eventually become an essential part of people's lives. These stories are icebergs floating on the water, and I call them application-level wars.
There is also a story, hidden under the sea level, which is much larger than the water, meaning that their impact is far-reaching and vast, but because it is not directly facing consumers, it is often unknown. I call it protocol-level war. The protocol layer is the foundation of the application layer.
- Analysis | 3 key indicators to measure the performance of the blockchain network
- Former JPMorgan Chase R & D: Why isn't the IBM blockchain real blockchain?
- Popular Science | Introduction to Cryptography (Part-1)
- DeFi weekly selection 丨 DeFi interest rates continue to fall, where is the market's breakthrough point?
- 44 "blockchain + AI" application scenario analysis, do you think it can be more complete?
- Interview with Vitalik: 25 years old worth 3 billion, the biggest fear comes from Ethereum | 8 questions
Just as an application needs to acquire users and occupy the market, the underlying protocol wants to be the ultimate winner, and it also needs to occupy the minds of its users, mostly developers. However, the war at the protocol layer is very different from the application layer. It can not be done by spending money for promotion. Many times, the protocol layer needs to win more trust in the form of open source because they need to build not only the market, And ecology.
What is the difference between ecology and market? For example, application-level wars are like two business rivals setting up a store in a square, competing with each other to attract customers from the town to their own store. The agreement-level war is more like two religions competing with each other. Whoever can call more people to become believers, who can motivate more believers to build more churches in the town, is the final winner.
Blockchain is in the early stages of the protocol-level war, and so far no big winner has been created. Each public chain is trying to establish its own ecology. Bitcoin and Ethereum are at the forefront, followed by many small and medium-sized projects; DeFi has become the mainstream narrative and application direction of smart contracts. At the front, there are a variety of other DeFi protocols behind them, each of which wants to be the basic puzzle of decentralized finance, the lowest building block of Lego Financial.
Every day there is a lot of innovation and competition. The Orange Book, like everyone else in the industry, is trying to think about that most important question: which protocols will ultimately win? Which horse race should I bet on in order to make the last laugh? The more I want to know the answer to this question, the more my thoughts seem to get confused.
As mentioned above, protocol-level warfare is not the same as application-level warfare that we are familiar with. Fortunately, history may help us, because the protocol-level war has actually happened once. In the ancient times when Internet protocols were just born, how to connect computers all over the world into a network also faced competition from different protocols. In the end we knew that the TCP / IP protocol had won.
But what exactly is this Internet protocol war? What kind of inspiration does it have for today's blockchain war? This article attempts to answer these two questions.
Agreement War 40 years ago
Everyone has reached a consensus on the big goal of the Internet: to build a global computer network. But they have different opinions on how to achieve this goal. By the early 1980s, several different protocols were competing with each other.
With the support of the European telephone monopoly giant and most governments, the OSI agreement was favored by more people at the time. Other strong competitors include two intra-company network protocols, IBM SNA and DEC DECNET. The Internet protocol (TCP / IP protocol) as we know it today is the dark horse in this protocol war at the time, and it was only supported by an autonomous community that relied on volunteers.
However, this autonomous community of the Internet Protocol is very agile and fast. Within a few months, the development progress has caught up with the progress made by the OSI Committee over the years. However, Internet protocols have scared away some potential users, because no one seems to be "responsible" for them here.
——Computer History Memorial 
Inconsistent agreement and standard, how big a problem can there be? At that time, the situation was similar. We can already connect computers all over the world, just like everyone has a phone at home, but because of different protocols and standards, everyone speaks a different language when answering the phone. Interconnection is still impossible.
Because it is impossible to unify the standards, it is very difficult and troublesome to connect computers with different protocols into a network. Cisco, which specializes in producing equipment and software for connecting computer network systems, has a t-shirt that lists the network protocols they could support at the time, and these network protocols were only part of all network protocols at the time.
Three major competitors of Internet protocols
DECNET data message exchange system label
DECNET is a popular network system architecture, but it is private and therefore has not been adopted by standards organizations and government customers. Beginning in December 1987, DECNET moved from DEC's own protocol to the OSI standard protocol, and the OSI protocol was eventually lost to TCP / IP.
IBM 3174 System Network Architecture (SNA) Controller
SNA was born in 1974. It is IBM's proprietary network architecture. It was originally used to connect mainframes and computer peripherals such as teletypes and monitors, and later extended to other computers. SNA began as a fixed and layered design, but eventually became more flexible. The SNA agreement has dominated decades in large companies.
Publication of CCITT designing OSI models
OSI is a direct competitor to Internet protocols. OSI is a well-defined example that is supported by governments and academia and benefits from XNS and other protocols. But it was eventually stuck with too much complexity, and it has not been able to produce code that actually works.
OSI and TCP / IP
The highlight of this protocol war is undoubtedly OSI and TCP / IP. Engineers, organizations, and countries have reached a very obvious polarization on the question of who can become the best and strongest computer network standard. Both standards are open and proprietary, but they are incompatible with each other.
A cartoon in 1988, it was thought that there might be two sets of network protocols around the world, OSI in Europe and TCP / IP in the United States, and the two were connected through a gateway.
OSI wants to create a series of complex and comprehensive standards for computer networks. The architects who designed OSI are composed of a group of outstanding representatives from the computer industry in the United Kingdom, France and the United States. They wanted to design a complete, open, multi-layered System, allowing users around the world to easily exchange data, creating new possibilities for business collaboration. For a long time, this vision seemed correct. OSI has also received support from almost all key personnel: computer companies, telecommunications companies, regulators, national governments, national standards development agencies, academic researchers, and even support from the US Department of Defense, which has invested in rival TCP / IP protocols . Large computer companies, including IBM, have also invested heavily in OSI. In the mid-1980s, the worldwide spread of the OSI standard seemed doomed and unavoidable.
However, by the early 1990s, OSI had everything in place, but its development rate was far behind another cheaper, more agile, and less comprehensive protocol: the Internet TCP / IP protocol suite. OSI is faltering and slow, but TCP / IP is running all the way forward, so people sigh: OSI is a beautiful dream, but TCP / IP has come true.
OSI was initially positioned as a cross-international, global work. From 1978 to the development of successive release drafts in 1980 and the final release of the OSI model in 1984, they were all cross-international working groups. The composition of the architect can also be seen.
Before the NSF gained control in the 1980s, TCP / IP was never even considered a candidate for global network standards adoption. Until 1989, a complete set of protocols was proposed in RFC 1122  and RFC 1123 , and TCP / IP established the foundation for a comprehensive protocol suite, which eventually developed into what is now familiar to people. Internet protocol suite .
Why did the dark horse of TCP / IP overcome the then-popular OSI and become the big winner of the Internet protocol? There are so many aspects to say.
Why TCP / IP wins
Concept and culture
When developing the TCP / IP protocol, Internet engineers are accustomed to continuous experiments in a fluid organization. They feel that the OSI committee is an over-bureaucratic, ungrounded, high-profile organization that never touches any existing network systems and computers. This has moved the Internet community away from the OSI model.
One small thing can reflect this cultural difference. At the IETF conference in 1992 (Internet Engineering Task Force ), Vint Cerf (one of the TCP / IP leaders) jumped up in a suit in a brawl, exposing the T-shirt, T-shirt inside The words IP on Everything are printed in the middle. Cerf claims that this behavior is to emphasize that the goal of the Internet is to make everything run on IP addresses.
Vint Cerf believes that this community culture formed in ARPANET in the early days is as important as technical factors, because it is this culture that allows the governance capabilities of the Internet to quickly follow and adapt to the scale and development of the agreement.
In addition, some people conclude that companies that win the Internet market, such as Cisco, are small companies. Because they embrace the culture of the Internet, are interested in it, and it's especially important that they can participate in the organization and meetings of the IETF.
In a 1992 speech, David Clark described how the IETF organization works:
We reject kings, presidents and voting. We believe in rough consensus and running code.
We don't want kings, presidents and votes. We only believe in "rough consensus" and "running code".
"Rough consensus" and "running code" are probably the most important features of the IETF. A large project, such as the creation of a new network, is usually designed from top to bottom, with the participation of the company or its affiliates. The young ARPA network and the Internet community have completed self-evolution through a bottom-up style, which is a productive but not structured group collaboration.
Participants usually solve the problem by themselves and then contribute their solution to the RFC (request for comment). The best RFCs have turned into a unified standard recognized by the community. This elite, peer-reviewed approach is very similar to the process of scientific research. This freewheeling style also provided templates for later projects, including the Web and the open source community.
In contrast, at OSI, a new technology wants to become an international standard, and each solution must go through the following four steps: first, a working draft is proposed first, then a proposal for a draft international standard is proposed, and then a change It became an international standard draft, and finally it became an international standard. Building consensus and related standards in OSI often involves a lot of additional meetings involving all members and committees.
The first plenary session of the OSI lasted three days, from February 28 to March 2, 1978. Participants included dozens of representatives from 10 countries, and selected from four international organizations The observer. Everyone brought their own market interest protection mentality and promoted with their own projects.
Many people are frustrated and frustrated with the complex technology of OSI. OSI defines a 7-layer model. Some people think that there are too many 7 layers, especially the transport layer (5 layers, compared to TCP / IP only 2 layers). The strict definition of each layer is supported by the TCP / IP protocol advocates. It is considered inefficient and does not allow trade-off to improve performance. Furthermore, OSI defines both datagram and virtual circuit methods at the network layer, and they are not interoperable with each other.
Researchers at Cornell University  believe that one of the reasons for OSI's failure was that it tried to standardize everything, and the OSI committee tried to control everything in the network. In the absence of instructive operating experience, OSI has been adding more and more features. The early TCP / IP technology concept was more practical. Its motto is "rough consensus and code that can run." TCP / IP only specifies the network and transmission protocols. It does not try to define the underlying network technology. The higher-level technologies, such as the protocols of applications such as e-mail, wait until after the code that can be run appears, and have practical experience and needs to begin to be standardized.
Practical and commercial applications
In addition to technology, in terms of practical applications, a key to TCP / IP's success is the decision to include the protocol in the Berkeley Standard Distribution (BSD) for Unix systems. This is also funded by ARPA. BSD 4.2, released in 1983, is equipped with a complete TCP / IP protocol suite, and the code is open source. This code was quickly ported to many other operating systems and became the basis for the first generation of the Internet.
ARPA and the telecommunications industry have established business partnerships, which have further promoted the spread and adoption of TCP / IP. The European Nuclear Research Organization (CERN)  purchased UNIX computers with TCP / IP for its intranet between 1984 and 1988. In 1988, the European UNIX network EUnet  also announced a move to the TCP / IP protocol.
Nevertheless, many people at the time still believed that the OSI agreement should be developed with other European countries instead of choosing ARPA. They take pride in what they do, not because of national pride or opposition to the United States, but because they think they are doing the right thing. This mentality slowly transformed into a religious dogma.
In addition, the ARPA Internet at that time was still a research project and did not allow commercial traffic or for-profit services to appear. The US Department of Commerce requires compliance with the standards of the OSI protocol, and the US Department of Defense also plans to transition from the TCP / IP protocol to the OSI protocol. At that time, many universities in the United States held the same mentality. When choosing the campus network, they first used the TCP / IP protocol, and thought about waiting until later to migrate to the OSI protocol. Some European countries and EEC have also ratified the OSI agreement, established RARE  to promote the OSI agreement , and restricted investment in non-OSI compatible agreements.
However, in 1989, Brian Carpenter, an advocate of the OSI protocol, published a technical conference entitled "Is OSI too late? ", This speech received warm applause and welcome. It shows that although OSI has been formally defined, the products of computer manufacturers and PTT network services related to OSI are still waiting for development.
In contrast, TCP / IP has not been an official standard (it is defined in the unofficial RFC ), but since 1983, TCP / IP has provided the inclusion of both Ethernet  and TCP / IP protocol for UNIX  workstations.
In 1990, the European Nuclear Research Organization and Cornell University established a trans-Atlantic TCP / IP link. Academic institutions in some European countries and organizations have adopted or expressed acceptance of the TCP / IP protocol. In January 1991, in the Rutherford Laboratory , DECnet accounted for 75% of the traffic, thanks to the Ethernet  between VAXs . The IP protocol is the second most popular protocol, with nearly 20% of the traffic. This is mainly due to UNIX computers. "IP is the natural choice."
In the Central Computing Newsletter, Paul Bryant, Head of Communications and Small Systems, Rutherford Labs wrote: "Experience shows that IP systems are very easy to install and use compared to systems such as SNA, while X.25 and color books Protocols and other systems are more complex, "he also wrote," The main network for academic traffic in the United States is now based on the IP protocol. The IP protocol has recently become popular in Europe due to intersite traffic. With this approach, large The combined US / Europe network is very attractive for UK users. "
At the time, many people had similar opinions. At the European Nuclear Research Center, François Flückiger stated:  "The technology is simple, efficient, and integrated into UNIX-type operating systems, and has no impact on users' computers. The company that first commercialized routers (such as Cisco) It's healthy and well-run, and most importantly, the technology used for local campus networks and research centers can also be used to connect remote centers in a simple way. "
Another key point of TCP / IP's victory in this protocol war took place in 1989, when Tim Berners-Lee  invented the World Wide Web at the European Nuclear Research Center . The World Wide Web, as an application on the Internet, ultimately brought many social and commercial uses to the Internet.
The Internet began to enter people's daily use from 1993-1994. NSFNET changed its policy to allow commercial communications in 1991 and was shut down in 1995, removing the final restrictions on the use of the Internet for commercial communications. Subsequently, the Internet backbone network  was provided by commercial Internet service providers . The internet has become ubiquitous.
Implications for blockchain
What reference does this history have for today's blockchain landscape? What kind of inspiration can the last protocol war bring to the protocol war in the blockchain field today?
Building the right organization and community culture
Everyone knows that "openness" is the most important, but there are still differences in the culture and organization of the community. OSI has been positioned as a transnational global working group from the beginning, and has also incorporated many open and diverse community members, but in the end it has become a chaotic commons where different stakeholders chase each other.
As a very important force in OSI, because of the maintenance of its existing business interests, under the situation that packet switching based on datagrams is becoming increasingly popular, it still chooses to maintain a pseudo-virtual circuit switching solution. This disadvantage of different stakeholders.
Therefore, for many blockchain projects, practicing the concept of open source must find the right direction. The RFC has played a very important role in the formulation of the TCP / IP protocol. Today, blockchain projects should have similar solutions in promoting technological development, new protocols and new standards.
Ethereum should be a very good template. The creativity given by community culture is obvious. The Orange Book has written a related article about "Interview with Vitalik: The community is more important than code". In contrast, the Libra project led by Facebook is almost difficult to be favored. In my opinion, it is similar to the OSI organization form. It is dominated by a vested enterprise giant and tries to attract the head power of other industries. I think Libra needs to face the same difficulties as OSI in how to coordinate the interests of its members. I even think in my heart that Libra is doomed to fail.
Don't get too entangled with ideas, let the code run first
"Rough consensus, runnable code"-this is the motto of the TCP / IP protocol working group. In the blockchain industry, I think a similar reason is not to be too entangled with fundamentalist ideas, such as decentralization, and do not start thinking about how to transition the project to the community to take over, or in the pursuit of voting Way to complete the upgrade and evolution of the project, the pursuit of on-chain governance direction wasted too much effort.
Because these things may be far less important than letting code and protocols run and run first. There is no shortage of people with the right ideas in this world, but people who run fast enough. In fact, there are many similar suggestions in the Orange Book before: "Blockchain application layer needs Napoleon."
Don't pursue the perfect agreement
One of the most direct lessons from the competition between OSI and TCP / IP is that there is no perfect protocol in the world. In the blockchain industry, I see that many project parties are pursuing this perfectionism, or not pursuing it, but using this perfectionism as a story to promote their projects.
As far as the large-scale infrastructure of the public chain is concerned, everyone hopes to get a perfect solution that can not only expand the capacity, but also be decentralized, do not waste electricity, and solve the cross-chain problem. It can run DeFi and can also Playing with spinach. If you want to use a chain technology, it is impossible to solve these problems at one time. To believe that useful protocols will eventually be completed and become a complete protocol group and protocol stack. Do not expect to invent a perfect protocol from the beginning. From this perspective, it seems Cosmos has a better strategy than Poca.
If you make a protocol, what kind of actual requirements this protocol can solve for developers is the most important. Different protocols can be combined into a protocol stack, which will become an indispensable building block in the future. The simplest protocols are often the most likely to survive first. For example Uniswap, 0x, Compound.
In this respect, similarly, the Orange Book actually wrote a similar point before: "BTC and ETH: Positioning Victory".
Let the agreement spread as soon as possible
The last point is to make the agreement as disseminated as possible.
There are two methods for disseminating the agreement. One is to find the carrier of the dissemination, which is promoted and popularized by some necessary tools and products.
Just as the TCP / IP protocol was first spread on UNIX systems, the blockchain protocol should also try to find such a carrier that is conducive to dissemination, so that your protocol can be used by developers as soon as possible.
Another method is to let the protocol produce influential products and applications, and popularize the underlying protocols through the popularization of applications. Just as the World Wide Web is based on TCP / IP, the World Wide Web has attracted many people outside the circle to use the Internet, and it has finally strengthened the development of TCP / IP protocols.
Ethereum, in my opinion, is the first to provide developers with a set of programmable smart contract functions. In the past few years, I have continuously heard criticisms of Ethereum's smart contracts and solidity language. A common criticism is that Ethereum does not need to provide a Turing-complete smart contract function. Not all code needs to be put on the chain. There is also no need to invent a new language specifically for writing Dapps.
These views are of course correct. But the reality is that Ethereum first occupied the developer's brain with the most understandable concept of smart contracts. It may not be the most perfect, but it was first disseminated. Those who have the right ideas need to catch up with Ethereum from scratch Leading pace.
If the Orange Book is an investment fund, how do we choose what kind of blockchain protocol to invest in?
The history of TCP / IP tells us that projects that believe in "rough consensus and executable code" should be selected. What Orange Book wants to invest in should be a protocol with this community culture.
Let us reiterate this community culture:
We reject kings, presidents and voting. We believe in rough consensus and running code.
 1123: https://tools.ietf.org/html/rfc1123
 Internet protocol suite: https://en.wikipedia.org/wiki/Internet_protocol_suite
 Internet Engineering Task Force: https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force
 Researchers at Cornell University believe that: http://www.cs.cornell.edu/wya/AcademicComputing/text/nationalnets.html
 European Organization for Nuclear Research (CERN): https://en.wikipedia.org/wiki/CERN
 EUnet: https://en.wikipedia.org/wiki/EUnet
 RARE: https://en.wikipedia.org/wiki/TERENA#History
 OSI protocol: https://en.wikipedia.org/wiki/OSI_protocols
 RFC: https://en.wikipedia.org/wiki/Request_for_Comments
 Ethernet: https://en.wikipedia.org/wiki/Ethernet
 UNIX: https://en.wikipedia.org/wiki/Unix
 Rutherford Lab: https://en.wikipedia.org/wiki/Rutherford_Appleton_Laboratory
 VAXs: https://en.wikipedia.org/wiki/VAX
 Ethernet: https://en.wikipedia.org/wiki/Ethernet
 François Flückiger said: https://en.wikipedia.org/wiki/Fran%C3%A7ois_Fl%C3%BCckiger
 Tim Berners-Lee: https://en.wikipedia.org/wiki/Tim_Berners-Lee
 World Wide Web: https://en.wikipedia.org/wiki/World_Wide_Web
 Internet backbone network: https://en.wikipedia.org/wiki/Internet_backbone
 Internet service provider: https://en.wikipedia.org/wiki/Internet_service_provider
 https://www.computerhistory.org/revolution/networking/19/376: https://www.computerhistory.org/revolution/networking/19/376
 https://en.wikipedia.org/wiki/Protocol_Wars: https://en.wikipedia.org/wiki/Protocol_Wars
 https://spectrum.ieee.org/tech-history/cyberspace/osi-the-internet-that-wasnt: https://spectrum.ieee.org/tech-history/cyberspace/osi-the-internet -that-wasnt
 http://www.cs.cornell.edu/wya/AcademicComputing/text/nationalnets.html: http://www.cs.cornell.edu/wya/AcademicComputing/text/nationalnets.html