2016年 8 月份，聯合廣場基金 USV 分析師 Joel Monegro 發表了一篇名為「胖協議」的文章，指出在分布式網絡中，價值通常在協議層，而非構建于協議層之上的應用程序。這篇文章被眾多區塊鏈投資人奉若圭臬，也推動了大量投資流向區塊鏈基礎設施項目。但是，如果只關注基礎設施建設，而忽視應用的開發，對整個分布式網絡生態系統的發展并無益處。聯合廣場基金兩位員工 Dani Grant、Nick Grossman 剛剛發表了一篇文章，通過大量例子，旗幟鮮明的指出：新技術的歷史表明，應該先有應用程序，因為應用程序會催生基礎設施。他們還提出了「應用程序=>基礎設施=>應用程序=>基礎設施」迭代循環周期，指明開發者應該遵循這樣的周期，把握住這個循環周期中的不同機會。鏈聞 ChainNews 獲得了聯合廣場基金授權，翻譯了這篇文章，發表中文版本，希望借此幫助讀者理順「應用程序和基礎設孰先孰后」這個一直困擾加密世界的蛋生雞、雞生蛋難題。不過需要讀者注意，作者在文章中也特別指明：文章中提出的循環周期模型解釋了什么時候可以開發搭建應用程序或基礎設施，這是從開發者和項目建設者的視角著眼，這一理論并不解釋什么時候投資應用程序、什么時候投資基礎設施。

Web 3.0 社區的一個常見說法是，我們正處于基礎設施階段，現在應該做的是構建基礎設施：我們需要更好的基礎鏈、更好的鏈間互操作性、更好的客戶端、錢包和瀏覽器。

這種說法背后的思路是：首先我們需要工具，以便輕松構建和使用在區塊鏈上運行的應用程序，一旦擁有了這些工具，我們就可以開始構建應用程序了。

但當我們與正在構建基礎設施的創始人交流時，我們不斷聽到他們說，自己面臨的最大的挑戰，就是讓開發人員在其基礎設施頂層構建應用程序。

如果我們現在真的處于應該興建基礎設施的階段，為什么會出現這樣的情況呢？

我們只好據此假設：事情并不是按原有構想那樣發展的。我們目前并不處在基礎設施階段，而是處于應用程序-基礎設施周期的另一個轉折點。

事實上，新技術的歷史表明，應用程序會催生基礎設施，而不是反之。我們并不是必須先得建立所有的基礎設施，在有了需要的基礎設施后才開始構建應用程序。

情況恰恰相反。

這一點居然值得討論，其中一個重要原因在于，現在人人都知道「平臺」通常是最大的價值機會，尤其對 Facebook、Amazon/AWS、Twilio 等而言，確實如此。因此，人們自然會急于建立一個重要的平臺來攫取價值。在分布式網絡中，這一點可能尤其正確。因為在分布式網絡中，價值通常 不過并不總是 在協議層，而非位于頂層的應用程序中累積。

但是，正如我們將會看到的那樣，平臺是從這樣一個迭代周期中演化而來：應用程序=>基礎設施=>應用程序=>基礎設施。平臺極少在外部真空中構建。

首先，應用程序賦予了基礎設施靈感。接著，基礎設施為新的應用程序帶來賦能。

我們在最重要的平臺看到的變遷模式是，首先出現一個突破性的應用程序，然后該應用激發了一個構建基礎設施的新的階段，令人們更容易在其基礎上構建類似的應用程序，便于消費者廣泛采用這些應用。

情況有點像下圖這樣的發展模式：

應用程序和基礎設施是在響應周期里不斷演進，而不是相互獨立、各自為政。

打比方說，燈泡 應用程序 是在有電網 基礎設施 之前發明的。不是非得有電網才能安燈泡。但要讓消費者廣泛接受燈泡，你確實需要電網，所以突破性的應用，也就是燈泡，在 1879 年率先誕生，而后電網于 1882 年開始逐步發展。

再舉一個例子：飛機 應用程序 是機場 基礎設施 出現之前發明的。 飛機并不是非得有機場才行。但是為了廣大消費者接受飛機，確實得有機場配套，所以作為突破性應用的飛機在 1903 年首先出現，激勵人們在 1919 年開始建立航空公司，1928 年建造機場，到了 1930 年開始出現空中交通管制——這些基礎設施都出現在飛機之后。

有時候你需要的基礎設施無非是一片海灘和一些備件而已。

互聯網也遵循同樣的模式。

先說首批應用程序：即時短信 1970 年 和電子郵件 1972 年，它們促成了便于消費者廣泛采用短信和電子郵件的基礎設施，即以太網 1973 年、TCP/IP 1973 年 和互聯網服務提供商 1974 年。

接著是下一波應用程序浪潮，也就是門戶網站 1990 年的 Prodigy，1991 年的 AOL，它們進而啟發我們建構了新的基礎設施 1990 年代初的搜索引擎和網絡瀏覽器。

再接下來的應用程序浪潮中，出現的是像亞馬遜 1994 年 這樣的早期網站，激勵我們搭建編程語言 1994 年的 PHP，1995 年的 Javascript 和 Java 等基礎設施，以簡化網站構建。

往后是下一波更復雜的應用，如 Napster 1999 年、Pandora 2000 年、Gmail 2004 年 和 Facebook 2004 年，而這催生的是可以更輕松地構建復雜應用的基礎設施 2004 年有 NGINX 和 Ruby on Rails，2006 年出現了 AWS。

這樣的周期還在繼續。

我們在最新的移動應用中也看到了這種模式：首先出現了一系列非常依賴流媒體視頻的流行移動應用，如 Snapchat 2011 年、Periscope 2014 年、Meerkat 2015 年 和 Instagram Stories2016 年。現在，我們看到一些公司正在建設基礎設施，以便移動應用程序輕松添加視頻：Ziggeo 2014 年、Agora.io 2014 年、Mux 2017 年、Twilio Video API 2017 年 和 Cloudflare Stream 2018 年。

這個周期也合理地解釋了 Web 3.0 事件的順序。

我們從第一個突破性的應用程序開始說起：比特幣出現于 2008 年，這激發了一些便于開發應用的新基礎設施，如以太坊智能合約 2015 年；以及便于消費者廣泛采用這些新應用的基礎設施，如 Coinbase 2012 年 和 Metamask 2016 年。

這一新的基礎設施催生了下一波應用：代幣/ICO 2017 年 和早期的 DApp 2016 年是 Rouleth 和 vDice，2017 年有加密貓，而這又進而激發出了新的基礎設施，如 Infura 2014 年 和 Web3js、Zeppelin 和 ERC20 2017 年。

目前，我們正在等待下一批重大的應用程序來引導下一波基礎設施建設。

鄰近的可能

開發每個重要平臺 電力、汽車、飛機、網絡、移動設備等 的共同主題是，我們構建的是當下能為我們自己所用的工具。在《好點子從何而來》 Where Do Good Ideas Come From 一書中，史蒂文·約翰遜 Steven Johnson 將其稱為「相鄰可能」。

換句話說，你可以打開通往隔壁房間的大門，但是你不能在前門那里越過臺階，打開后院的大門。如果構建的基礎設施遠遠超前于應用程序市場，這樣很難成功。

每當應用程序=>基礎設施這個周期再現，新的應用程序就會成為可能，這是因為在之前的循環中已構建了基礎設施。例如，YouTube 可以在 2005 年建成，但在 1995 年顯然沒法實現，因為只有在 2000 年代初寬帶等基礎設施部署之后 YouTube 才有意義，而寬帶能應運而生，原因在于 eBay、亞馬遜、AskJeeves 和 Neopets 等受歡迎的網站誕生，催生了之后的基礎設施階段。

區塊鏈投資基金 a16z crypto 的 Chris Dixon 和 Fred Wilson 在最近一期的博客節目中，談到了這個理念。

Chris 有一款來自互聯網泡沫時代的棋盤游戲，叫「dot Bomb」，游戲嘲笑了 20 世紀 90 年代末那批愚蠢的互聯網公司。他指出，網絡時代所有「愚蠢」的想法現在都演化成了價值 10 億美元的獨角獸公司。現在可能出現的情況是，出現多個應用程序=>基礎設施循環，而只有一兩個應用程序=>基礎設施周期沒有多少意義。

這就是我們所謂的「基礎設施階段迷思」的關鍵所在。

如果我們在考慮一個「基礎設施階段」的時候，完全將它與要使用它的應用程序割裂開來，就有可能面臨在抽象的真空中布局、步伐過于超前的風險。我們需要「應用程序=>基礎設施=>應用程序=>基礎設施」這樣的循環，來保持步伐的穩健。

隨著每個新平臺的周期越來越長，構建和使用這些應用程序的成本越來越低。如果是在 1995 年建設 usv.com 這個網站，花費的成本會比如今多出很多個數量級；而如果是在 15 年后創建 Web 3.0 應用，花費的金錢、精力和時間都會比現在少很多。

開發框架VS投資框架

站在我們投資者的立場上想想就知道，區分技術框架和投資框架是很重要的，前者解釋了何時可以構建什么，后者解釋了何時適合投資什么。

應用程序=>基礎設施=>應用程序=>基礎設施這個循環解釋了什么時候可以構建應用程序或基礎設施，但并不一定能解釋什么時候投資應用程序、什么時候投資基礎設施。

讓我們以燈泡為例。是的，燈泡是在電網出現之前發明的，但從投資者的角度來看，在電網建成之前，沒有人賣出很多燈泡。

讓我做一個總結

我們先前遇到的一個問題是：為什么應用程序在周期中首先出現，而不是基礎設施？

一個原因是，除非出現了應用程序，召喚你解決其基礎設施問題，否則憑空創建基礎設施是沒有意義的。在沒有一個相關的應用程序團隊之前，如何能知道你正在構建的基礎設施能解決一個真正的問題？所以說，現在構建加密基礎設施將是一大挑戰，只有等到有一天，出現一個突破性的加密應用程序令其他開發人員爭相效仿，并呼喚更好的開發工具和基礎設施來實現這一目標，雙腳才能踏到實處。

在加密領域中有這樣一種說法，首先我們需要構建出色的工具，一旦有了工具，就可以構建應用程序。

但我們希望指出的是，從其他平臺的變遷來看，我們可以在出色的工具出現之前，先嘗試開發幾個應用程序，盡管這需要更多的資金和時間，然后，這些早期的應用程序將激發我們構建工具。

這個循環將不斷重復。