2016年 8 月份，聯合廣場基金 USV 分析師 Joel Monegro 發表了一篇名為「胖協議」的文章，指出在分散式網路中，價值通常在協議層，而非構建於協議層之上的應用程式。這篇文章被眾多區塊鏈投資人奉若圭臬，也推動了大量投資流向區塊鏈基礎設施專案。
但是，如果只關注基礎設施建設，而忽視應用的開發，對整個分散式網路生態系統的發展並無益處。聯合廣場基金兩位員工 Dani Grant、Nick Grossman 剛剛發表了一篇文章，透過大量例子，旗幟鮮明的指出：新技術的歷史表明，應該先有應用程式，因為應用程式會催生基礎設施。他們還提出了「應用程式=>基礎設施=>應用程式=>基礎設施」迭代迴圈週期，指明開發者應該遵循這樣的週期，把握住這個迴圈週期中的不同機會。
鏈聞 ChainNews 獲得了聯合廣場基金授權，翻譯了這篇文章，發表中文版本，希望藉此幫助讀者理順「應用程式和基礎設孰先孰後」這個一直困擾加密世界的蛋生雞、雞生蛋難題。
不過需要讀者注意，作者在文章中也特別指明：文章中提出的迴圈週期模型解釋了什麼時候可以開發搭建應用程式或基礎設施，這是從開發者和專案建設者的視角著眼，這一理論並不解釋什麼時候投資應用程式、什麼時候投資基礎設施。
撰文：Dani Grant、Nick Grossman，聯合廣場基金 編譯：詹涓
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 Stories 2016 年。現在，我們看到一些公司正在建設基礎設施，以便移動應用程式輕鬆新增影片：Ziggeo 2014 年、Agora.io 2014 年、Mux 2017 年、Twilio Video API 2017 年 和 Cloudflare Stream 2018 年。
這個週期也合理地解釋了 Web 3.0 事件的順序。
我們從第一個突破性的應用程式開始說起：BTC/" target="_blank"">比特幣出現於 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投資框架
站在我們投資者的立場上想想就知道，區分技術框架和投資框架是很重要的，前者解釋了何時可以構建什麼，後者解釋了何時適合投資什麼。應用程式=>基礎設施=>應用程式=>基礎設施這個迴圈解釋了什麼時候可以構建應用程式或基礎設施，但並不一定能解釋什麼時候投資應用程式、什麼時候投資基礎設施。
讓我們以燈泡為例。是的，燈泡是在電網出現之前發明的，但從投資者的角度來看，在電網建成之前，沒有人賣出很多燈泡。
讓我做一個總結
我們先前遇到的一個問題是：為什麼應用程式在週期中首先出現，而不是基礎設施？一個原因是，除非出現了應用程式，召喚你解決其基礎設施問題，否則憑空建立基礎設施是沒有意義的。在沒有一個相關的應用程式團隊之前，如何能知道你正在構建的基礎設施能解決一個真正的問題？所以說，現在構建加密基礎設施將是一大挑戰，只有等到有一天，出現一個突破性的加密應用程式令其他開發人員爭相效仿，並呼喚更好的開發工具和基礎設施來實現這一目標，雙腳才能踏到實處。
在加密領域中有這樣一種說法，首先我們需要構建出色的工具，一旦有了工具，就可以構建應用程式。
但我們希望指出的是，從其他平臺的變遷來看，我們可以在出色的工具出現之前，先嚐試開發幾個應用程式，儘管這需要更多的資金和時間，然後，這些早期的應用程式將激發我們構建工具。
這個迴圈將不斷重複。
