原標題《40年前的協議戰爭，對區塊鏈有什麼啟示？》
我們熟悉阿里巴巴、騰訊、位元組跳動所代表的成功的商業故事。我們知道微信、淘寶、抖音是怎樣成為全民爆款的產品。這些案例離消費者觸手可及，它們在各自的領域裡過關斬將，最終成為了人們生活必不可少的一部分。這些故事是漂浮在水面的冰山，我把它們稱之為應用層的戰爭。
還有一種故事，藏在海平面下，體積比水上的巨大得多，意味著它們的影響更深遠、更遼闊，但因為不直接面向消費者，往往不為人知。我把它稱之為協議層的戰爭。協議層是應用層之所以存在的基礎。
就像應用需要獲取使用者、佔領市場一樣，底層協議想要成為最終的贏家，也需要佔領自己的使用者——大部分是開發者——的心智。但協議層的戰爭又跟應用層很不一樣，並不是砸錢做推廣就可以搞定，很多時候，協議層需要以開源的形式，去贏得更多的信任，因為它們需要建立的不僅是市場，還有生態。
生態和市場有什麼不一樣？打個比方，應用層戰爭就像是兩個生意對手在廣場上建立一家商店，互相爭奪吸引鎮上顧客光臨自家商店。而協議層戰爭更像是兩個宗教互相競爭，誰能號召更多的人成為信徒，誰能鼓動更多信徒在鎮上建造更多的教堂，誰才是最後的贏家。
區塊鏈正處於協議層戰爭的早期階段，目前為止還沒有產生通吃一切的大贏家。每條公鏈都在嘗試建立自己的生態，比特幣和以太坊走在了最前面，身後跟著許許多多中小型的專案；DeFi 成為了智慧合約主流的敘事和應用方向，穩定幣 Maker 走在了前面，身後還有其他種類繁多的DeFi 協議，它們每個都希望成為去中心化金融的基礎拼圖，金融樂高中最底層的積木。
這裡面每天都在產生大量的創新，也有大量的競爭。橙皮書和這個行業裡的其他人一樣，我們也在試圖思考那個最重要的問題：哪些協議會最終勝出？應該把手中的賭注，押在哪隻賽馬身上才能笑到最後？越想知道這個問題的答案，思緒好像就越亂成一團。
就像上文所說的，協議層的戰爭跟我們所熟悉的應用層戰爭並不一樣。好在歷史或許能給我們一些幫助，因為協議層戰爭其實已經發生過一次了。在網際網路協議剛誕生的上古時期，如何把全世界的電腦連線成一個網路，同樣面臨著不同協議的競爭。最終我們知道，TCP/IP 協議獲得了勝利。
但網際網路的這場協議戰爭到底是怎麼樣的？它對今天區塊鏈領域的戰爭又有什麼樣的啟示？這篇文章嘗試著回答下這兩個問題。
40年前的協議戰爭
在網際網路的大目標上，所有人都達成了共識：要建立一個全球性的計算機網路。但是具體如何實現這個目標，他們意見各不相同。到20世紀80年代初，有幾個不同的協議開始相互競爭。
在歐洲電話壟斷巨頭和大多數政府的支援下，OSI協議受到了當時更多人的青睞。其他強有力的競爭對手還包括兩個企業內部的網路協議，IBM SNA 和 DEC DECNET。我們今天所熟知的網際網路協議（TCP/IP協議）是當時這場協議戰爭中的黑馬，它只由一個依靠志願者的自治社羣來支援。
但是網際網路協議的這個自治社羣動作非常敏捷快速，他們在幾個月內的時間裡，開發進度就趕上了 OSI 委員會耗費數年取得的進展。不過，網際網路協議卻嚇跑了一些潛在的使用者，因為這裡似乎沒有人為之“負責”。
——計算機歷史紀念館[1]
協議和標準的不一致，到底會產生都多大的問題？當時的情況類似於，我們已經可以把全世界的電腦都連起來了，就像所有人家裡都配備了電話，但是因為協議和標準的不同，每個人接電話講的卻是不同的語言，因此互聯互通仍然無法實現。
因為無法統一標準，想把不同協議的電腦連成網路，實操的難度和麻煩非常大。思科公司（專門生產用於連線計算機網路系統的裝置和軟體）有這樣一件文化衫，上面羅列了當時他們能支援的網路協議，而這些網路協議只是當時所有網路協議的一部分。
思科的文化衫網際網路協議的三個主要競爭對手
DECNET
DECNET的資料包文交換系統標籤
DECNET 是一個受歡迎的網路系統架構，但它是私有的，因此沒有被標準組織和政府客戶所採用。從1987年12月開始，DECNET 從 DEC 自己的協議轉移到了 OSI 標準的協議，OSI 協議最終又輸給了TCP/IP。
SNA
IBM 3174系統網路體系(SNA)控制器
SNA 誕生於1974年，是 IBM 的專有網路體系，一開始是專門用來連線大型機和類似電傳打字機、顯示器這樣的計算機外圍裝置的，後來又擴充套件到連線其他計算機上。SNA 最初是固定不變與分層的設計，最後變得更加靈活。SNA 協議在大公司內部主宰了幾十年的地位。
OSI
設計 OSI 模型的 CCITT 的出版物
OSI 是網際網路協議的直接競爭對手。OSI 是一個定義良好的、受到各國政府與學界支援的、受益於 XNS 與其他協議的例子。但它最終受困於過多的複雜性，一直沒能推出能實際執行的程式碼。OSI 與 TCP/IP
這場協議戰爭的重頭戲，無疑屬於 OSI 與 TCP/IP。工程師、機構組織和國家在誰能成為最好、最強壯的計算機網路標準這個問題上達成了非常明顯的兩極化，兩套標準都是開放和非專利佔有的，但彼此又互不相容。
1988年的一幅漫畫，人們認為全球可能會有兩套網路協議，歐洲用OSI，美國用TCP/IP，二者再透過閘道器連線起來
OSI 想要為計算機網路創造一系列複雜全面的標準，設計 OSI 的架構師由一群來自英國、法國和美國的計算機行業的傑出代表組成，他們暢想設計一套完整的、開放的、分為多層的系統，讓全世界的使用者可以輕鬆的交換資料，為商業協作創造新的可能性。在很長一段時間裡，這個願景看起來都是正確的。OSI 也因此獲得了幾乎所有重要人員的支援：計算機企業、電信公司、監管部門、國家政府、國家標準制定機構、學術研究人員，甚至是來自投資了競爭對手 TCP/IP 協議的美國國防部的支援。包括 IBM 在內的大型計算機企業也在 OSI 身上投入了大量的資金。在1980年代中期，OSI 標準在全世界普及似乎是命中註定、不可避免的。
但是，到了1990年代早期，OSI 萬事俱備，發展速度卻遠遠落後於另一種更便宜、更敏捷、更不全面的協議：網際網路 TCP/IP 協議群。OSI 步履蹣跚、速度緩慢，而 TCP/IP 卻一路向前狂奔，人們因此發出這樣的感嘆：OSI 是一個美麗的夢想，但 TCP/IP 已經夢想成真了。
OSI 一開始就是定位於跨國際的、全球性的工作，從1978年開始，到1980年開發陸續釋出草案，到1984年最終 OSI 模型正式釋出，都是跨國際的工作組，這一點從委員會和架構師的組成人員也可以看出。
而在1980年代 NSF 獲得掌控權之前，TCP/IP 甚至從來就沒有被當作過網路全球標準採用的候選者。一直到1989年，成套的協議群在RFC 1122[2]和RFC 1123[3]被提出，TCP/IP 才為成為一套全面完整的協議套件設立了基礎，最終發展成了現在人們所熟悉的Internet protocol suite[4]。
為什麼 TCP/IP 這匹黑馬能戰勝當時的大熱門 OSI ，成為網際網路協議的大贏家呢？有這麼幾個方面的說法。TCP/IP 獲勝的原因
理念與文化方面
在開發 TCP/IP 協議的時候，網際網路工程師們習慣於在流動的組織形式中持續不斷的做實驗。他們覺得 OSI 委員會是一個過度官僚化的、 不接地氣、高高在上的組織，從不觸碰任何現有的網路系統和計算機。這使得網際網路社羣逐漸遠離了 OSI 模型。
有一件小事可以反應這種文化的不同。在1992年的 IETF 會議（Internet Engineering Task Force[5]）上， Vint Cerf（TCP/IP的領導者之一）在一次爭吵中直接穿著西裝跳起了脫衣舞，露出裡面的T恤，T恤中間印著 IP on Everything 的字樣。Cerf 稱自己這個行為是為了強調網際網路的目標是讓一切都執行在IP地址上。
Vint Cerf 認為，早期在 ARPANET 中形成的這種社羣文化，與技術因素一樣重要，因為正是這種文化能讓網際網路的治理能力快速去跟隨並適應協議的規模和發展。
此外，還有人總結，贏得網際網路市場的公司，比如思科，都是小公司。因為它們擁抱了網際網路的文化，對這種文化感興趣，並且特別重要的是，它們能參加 IETF 的組織和會議。
在1992年的一次演講中，David Clark 這樣描述 IETF 這個組織的運作方式：
We reject kings, presidents and voting. We believe in rough consensus and running code.
我們不要國王、總統和投票。我們只相信“粗略的共識”和“能夠執行的程式碼”。
“粗略的共識”和“能夠執行的程式碼”可能是 IETF 最重要的特徵。一個大專案，比如發明一個新的網路，通常是從上到下進行設計的，由公司或所屬機構參與。而年輕的ARPA網和網際網路社羣則透過自下向上的風格完成自我進化，這種方式富有生產力，卻並非結構化的團體協作。
參與者通常自己解決問題，然後把他們的解決方案貢獻到 RFC（request for comment） 中。最好的 RFC 又變成了社羣認可的統一標準。這種精英式的、同行評審的方法，與科學研究的過程非常類似。這種隨心所欲的風格也為後來的一些專案提供了模版，包括 Web 和開源社羣。
作為對比，在 OSI 那邊，一個新的技術想要成為國際標準，每個方案都必須經過如下四個步驟：首先是先提出一個工作草案，然後再提出一個國際標準草案的提議，然後是變成國際標準草案，最後才是成為國際標準。在 OSI 中建立共識和相關標準，往往需要牽涉一大堆額外的涉及全體成員和委員會的會議。
OSI 的第一次全體會議整整持續了三天時間，從1978年2月28日開到了3月2日，參與者包括數十名來自10個國家的代表，以及從四個國際組織中挑選出的觀察者。每個人在參會時都帶著自己的市場利益保護心態，帶著自己的專案來推廣。
技術方面
許多人對 OSI 的複雜技術感到挫敗和沮喪。OSI 定義了7層的模型，有人認為7層太多了，特別是傳輸層（5層，對比TCP/IP只有2層）過多，而每一層的嚴格定義被TCP/IP協議的擁護者認為是不高效的，不允許提高效能的trade-off。並且，OSI 在網路層同時定義了資料包和虛擬電路兩種方法，而它們彼此是不具備互操作性的。
康奈爾大學的研究人員認為[6]，OSI 失敗的原因之一是它試圖對所有東西都進行標準化，OSI 委員會試圖控制網路中的一切。在缺少具備指導意義的操作經驗的情況下，OSI 一直不斷新增越來越多的功能。而早期的 TCP/IP 的技術理念則更為實用，它的座右銘是“粗略的共識和能夠執行的程式碼”，TCP/IP 只是指定了網路和傳輸協議，它沒有嘗試去定義底層的網路技術，而上層的技術，比如電子郵件等應用程式的協議，則一直等到出現了可執行的程式碼之後，有了實踐的經驗和需要才開始被標準化。
實踐與商業應用方面
除了技術，在實際應用方面，TCP/IP 一個成功的關鍵是決定將協議包含在 Unix 系統的Berkeley標準發行版（BSD）中。這也是由ARPA資助的。1983年釋出的BSD 4.2，配備了完整的 TCP/IP 協議群，而且程式碼都是開源的。這些程式碼很快被移植到了很多其他作業系統中，成了第一代網際網路的基礎。
ARPA 和電信行業建立了商業夥伴關係，也進一步推動了 TCP/IP 的傳播和採用。歐洲核子研究組織（CERN）[7]在1984年至1988年之間為其內部網購買了帶有TCP/IP的UNIX計算機。1988年，歐洲 UNIX 網路EUnet[8]也宣佈轉移到 TCP/IP 協議上。
儘管如此，當時很多人依然認為應該與歐洲其他國家一起繼續開發 OSI 協議，而非選擇 ARPA。他們為自己所做的事情感到驕傲，並不是出於民族自豪感或者反對美國，而是認為自己在做正確的事。這種心態慢慢轉化為了一種宗教教條。
此外，當時的 ARPA Internet 仍然是一個研究專案，不允許商業流量或營利性服務出現。美國商務部要求遵守 OSI 協議的標準，而美國國防部也計劃從 TCP/IP 協議過渡到 OSI 協議。當時美國許多大學也抱著同樣的心態，在校園網的選擇上他們先使用 TCP/IP 協議，想著等到後面再遷移到 OSI 協議去。一些歐洲國家和 EEC 也批准了 OSI 協議，成立了RARE[9]來推廣OSI協議[10]，並且限制了對非OSI相容協議的投資。
但是，到了1989年，OSI 協議的倡導者 Brian Carpenter 在一個技術會議上發表了題為《OSI是否已經太晚了？》的演講，這次演講受到了熱烈的掌聲和歡迎。它表明，雖然 OSI 已正式定義完成，但與 OSI 相關的計算機制造商的產品和PTT的網路服務產品卻還在苦苦等待開發中。
相比之下，TCP/IP 一直就不是官方標準（它是在非官方的RFC[11]中定義的），但是自1983年以來，TCP/IP 已經提供了同時包含乙太網[12]和TCP/IP協議的UNIX[13]工作站。
1990年，歐洲核子研究組織與美國康奈爾大學建立了跨大西洋的TCP/IP連結，歐洲一些國家和組織的學術機構已經採用或表示接受TCP/IP協議。1991年1月在盧瑟福實驗室[14]裡，DECnet 佔了75％的流量，這歸功於VAXs[15]之間的乙太網[16]。而 IP 協議則是第二大流行的協議，擁有近 20％ 的流量，這主要歸功於UNIX計算機，“ IP是自然的選擇”。
在中央計算部新聞通訊中，盧瑟福實驗室通訊與小型系統主管 Paul Bryant 這樣寫道：“經驗表明，與SNA等系統相比，IP系統非常易於安裝和使用，而 X.25 和彩色書協議等系統則比較複雜”，他還寫道：“美國學術流量的主要網路現在是基於IP協議的。IP協議最近在歐洲因站點間流量而變得流行。隨著這種方法的出現，大型組合的美國/歐洲網路對英國使用者來說具有很大的吸引力。“
當時，很多人也有類似的看法。在歐洲核子研究中心，FrançoisFlückiger表示：[17]“該技術簡單，高效，已整合到UNIX型別的作業系統中，並且對使用者的計算機沒有任何影響。最早將路由器商業化的公司（例如Cisco）看起來執行得很健康並且供應良好，最重要的是，用於本地校園網路和研究中心的技術也可以用於以簡單的方式互連遠端中心。”
TCP/IP 在這場協議戰爭中取得勝利的另一個關鍵點，發生於 1989 年，Tim Berners-Lee[18]在歐洲核子研究中心發明了全球資訊網[19]。全球資訊網作為網際網路上的應用程式，最終為網際網路帶來了許多社會和商業用途。
網際網路在1993-1994年開始進入人們的日常使用。NSFNET 在1991年更改了其政策以允許商業通訊，並在1995年被關閉，取消了對使用網際網路進行商業通訊的最後限制。隨後，Internet骨幹網[20]由商業Internet服務提供商提供[21]。網際網路變得無處不在。
對區塊鏈的啟示
這段歷史對今天區塊鏈的格局有什麼樣的參考意義呢？上一場協議戰爭能為今天發生在區塊鏈領域裡的協議戰爭帶來怎樣的啟發？建立正確的組織形式和社羣文化
所有人都知道“開放”是最重要的，但具體到社羣文化和組織形式上仍然會有差異。OSI 從一開始就定位於跨國的全球性工作組，也融入了許多開放性多樣化的社羣人員，但最後它卻變成了一個不同利益方互相追逐的混亂公地。
IBM 作為 OSI 中非常重要的一股力量，因為對自己已有業務利益的維護，在基於資料包的包交換（Packet switching）日益流行的情況下，依然選擇維護仿虛擬電路交換的方案，正是這種不同利益方的弊端。
所以，對於很多區塊鏈專案來說，踐行開放開源的理念一定要找對方向。RFC 在 TCP/IP 協議的制定上起到了非常重要的角色，今天，區塊鏈專案在推動技術發展、新協議和新標準上也應該有類似的方案。
以太坊應該是一個很不錯的模版，社羣文化所賦予的創造力是顯而易見的，橙皮書之前寫過相關的文章介紹《專訪Vitalik：社羣遠比程式碼更重要》。而反觀 Facebook 主導的 Libra 專案，幾乎很難被人看好，在我看來，它類似於 OSI 的組織形式，由一家既得利益者的巨頭企業主導，試圖拉攏其他行業裡的頭部力量，我認為在怎樣協調各成員的利益上，Libra 需要面臨與 OSI 相同的難題。我在心裡甚至認為，Libra 註定是要失敗的。不要過分糾結理念，先讓程式碼跑起來
“粗略的共識，可執行的程式碼”——這句話是 TCP/IP 協議工作組的座右銘。換作在區塊鏈行業裡，我覺得類似的道理是，不要太過於糾結原教旨主義的理念，比如去中心化，也不要過早開始考慮怎樣把專案過渡給社羣接管，或者是在追求透過投票的方式完成專案的升級和進化、追求鏈上治理的方向上浪費太多力氣。
因為這些事情也許都遠不如讓程式碼和協議能先跑起來、執行起來，來得更重要。這世界不缺理念正確的人，缺的是跑得足夠快的人。其實類似的建議橙皮書之前也寫過許多：《區塊鏈應用層需要拿破崙》。不要追求完美的協議
OSI 與 TCP/IP 的競爭，最直接的一個教訓是，世界上並不存在完美的協議。在區塊鏈行業裡，我看到不少專案方都在追求這種完美主義，或者不是追求，而是在以這種完美主義作為故事宣傳自己的專案。
就公鏈這種大型基礎設施而言，所有人都希望得到一個完美的解決方案，既能擴容、又去中心化、不用浪費電力、還能順帶解決跨鏈問題，既能跑DeFi，又能玩菠菜。想用一條鏈的技術，一次性解決這些問題是不可能的。要相信有用的協議最終都會逐漸得到補全、成為完整的協議群和協議棧，不要一開始就寄希望於發明一套完美的協議。從這個角度來說，似乎 Cosmos 的策略要比波卡更好。
如果你做了一個協議，這個協議能為開發者解決什麼樣的實際需求才是最重要的，不同的協議可以組合成協議棧，成為日後不可或缺的積木。而最簡單的協議，往往最有可能率先存活下來。比如 Uniswap、0x、Compound。
這方面，同樣的，橙皮書之前其實也寫過類似的觀點：《BTC與ETH：定位的勝利》。儘早讓協議傳播開來
最後一點，是讓協議儘可能得到傳播。
讓協議傳播有兩種方法，一是找到傳播的載體，藉著某些必要的工具和產品得到推廣和普及。
就像 TCP/IP 協議最早是搭載 UNIX 系統而得到傳播一樣，區塊鏈協議也應該儘可能去尋找這樣利於傳播的載體，讓你的協議儘早可以被開發者使用上。
另一種方法是，讓協議產生有影響力的產品和應用，藉著應用的普及而使底層協議得到普及。就像全球資訊網建立在 TCP/IP 的基礎上一樣，全球資訊網吸引了許多圈外的人使用網際網路，最終也壯大了 TCP/IP 協議的發展。
以太坊，在我看來，它就率先為開發者提供了一套可程式設計的智慧合約的功能。過去幾年我不斷聽到有人對以太坊的智慧合約以及solidity語言的批評，常見的批評觀點是，以太坊沒有必要提供一個圖靈完備的智慧合約功能，不是所有程式碼都需要放到鏈上，也沒必要專門為編寫 Dapp 發明一套新的語言。
這些觀點當然都是正確的。但現實是，以太坊用智慧合約這個最容易理解的概念先佔領了開發者的大腦，它可能不是最完美的，但它率先得到了傳播，那些掌握正確觀點的人反而需要從頭開始追趕以太坊領先的步伐。
最後
如果橙皮書是一家投資基金，我們該如何選擇投資什麼樣的區塊鏈協議？
TCP/IP 的歷史告訴我們，應該選擇那些信奉“粗糙的共識與可執行的程式碼”的專案，橙皮書想要投資的，應該是擁有這種社羣文化的協議。
讓我們把這種社羣文化，再次重申一遍：
We reject kings, presidents and voting. We believe in rough consensus and running code.
（完）
參考來源：
https://www.computerhistory.org/revolution/networking/19/376[22]
https://en.wikipedia.org/wiki/Protocol_Wars[23]
https://spectrum.ieee.org/tech-history/cyberspace/osi-the-internet-that-wasnt[24]
http://www.cs.cornell.edu/wya/AcademicComputing/text/nationalnets.html[25][1]
計算機歷史紀念館:https://www.computerhistory.org/revolution/networking/19/376[2]
1122:https://tools.ietf.org/html/rfc1122[3]
1123:https://tools.ietf.org/html/rfc1123[4]
Internet protocol suite:https://en.wikipedia.org/wiki/Internet_protocol_suite[5]
Internet Engineering Task Force:https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force[6]
康奈爾大學的研究人員認為:http://www.cs.cornell.edu/wya/AcademicComputing/text/nationalnets.html[7]
歐洲核子研究組織（CERN）:https://en.wikipedia.org/wiki/CERN[8]
EUnet:https://en.wikipedia.org/wiki/EUnet[9]
RARE:https://en.wikipedia.org/wiki/TERENA#History[10]
OSI協議:https://en.wikipedia.org/wiki/OSI_protocols[11]
RFC:https://en.wikipedia.org/wiki/Request_for_Comments[12]
乙太網:https://en.wikipedia.org/wiki/Ethernet[13]
UNIX:https://en.wikipedia.org/wiki/Unix[14]
盧瑟福實驗室:https://en.wikipedia.org/wiki/Rutherford_Appleton_Laboratory[15]
VAXs:https://en.wikipedia.org/wiki/VAX[16]
乙太網:https://en.wikipedia.org/wiki/Ethernet[17]
FrançoisFlückiger表示：:https://en.wikipedia.org/wiki/François_Flückiger[18]
Tim Berners-Lee:https://en.wikipedia.org/wiki/Tim_Berners-Lee[19]
全球資訊網:https://en.wikipedia.org/wiki/World_Wide_Web[20]
Internet骨幹網:https://en.wikipedia.org/wiki/Internet_backbone[21]
Internet服務提供商提供:https://en.wikipedia.org/wiki/Internet_service_provider[22]
https://www.computerhistory.org/revolution/networking/19/376:https://www.computerhistory.org/revolution/networking/19/376[23]
https://en.wikipedia.org/wiki/Protocol_Wars:https://en.wikipedia.org/wiki/Protocol_Wars[24]
https://spectrum.ieee.org/tech-history/cyberspace/osi-the-internet-that-wasnt:https://spectrum.ieee.org/tech-history/cyberspace/osi-the-internet-that-wasnt[25]
http://www.cs.cornell.edu/wya/AcademicComputing/text/nationalnets.html:http://www.cs.cornell.edu/wya/AcademicComputing/text/nationalnets.html
