先有的Dapp還是基礎設施？也許你正被一個荒唐的類比誤導
不知怎的，馬克思理論在區塊鏈世界重新煥發生機。徘徊在歐洲的馬老師的幽靈，似乎恰巧賦予了某些特殊商業行為歷史合法性。其中最具代表性的是：“基礎設施決定上層建築”，所以我們應該先做公鏈(基礎設施)，以支援應用(上層建築)。這個想法最終決定了資本、研發力量投放的優先順序。可荒謬的是，“基礎設施”甚至不是馬老師的原話。到底應該先做應用，還是先做公鏈?在本文中，Union Square Ventures給出了他們的觀點和認知。
一個普遍認知是：區塊鏈行業正處於基礎設施階段，開展工作的正確姿勢是構建基礎設施——更好的基礎鏈，更好的鏈間互動性，更好的客戶端、錢包和瀏覽器。
他們說，“欲成其事必先利其器”，區塊鏈首先需要強大的工具，它能讓我們輕鬆地構建和執行DApp。
但是，當我們與一些基礎設施的創始人交談時，卻有人“幡然悔悟”：我們面臨的最大挑戰其實是讓開發人員構建頂層DApps。
荒唐的類比
用“基礎設施”形容公鏈、錢包是貼切的，但當新聞通稿中頻繁出現“基礎設施決定上層建築”的表述，問題就變得嚴重了。
這種類比不合邏輯。
馬克思的原話是“經濟基礎決定上層建築”而並非“基礎設施”。他的內在視角限定在社會經濟學的巨集觀領域。這種類比雖然牽強附會，卻有極大的歷史號召性。最終，連講故事的人都信了自己的邪。
我們能夠理解這種衝動，經過網際網路的教育，傻子都懂：投資或者建設“平臺”通常是最有價值的。所以，我們自然會急於建立一個主平臺。
可沒有金剛鑽不該攬瓷器活，商人通常沒有高屋建瓴的研究視角。我們不妨把問題從空中拉下來，回到平易近人的科技史中尋找答案，常識有時更準確。
下圖是一種新平臺出現的時間節點和爆款應用出現時間/數量的對比圖：
這張圖就像一本啟示錄。
一個領域沒有爆發性增長，很可能並非因為我們處在基礎設施(如果非要用這個詞來代指的話)落後的階段，這樣的描述過於靜態。
基礎設施和應用至少在互相影響著，它們的關係更像“……Apps => 基礎設施 => Apps ……”式的動態糾葛史。
我們正處在上述發展週期的某個轉折點上。
剩下的問題只有：現在，到底是應該先做DApp，還是先做基礎設施呢?
先有雞還是先有蛋?
爭論“先有雞先有蛋”，在古時候顯得很“哲學”，但在現代，卻有點兒蠢。
鳥類起源的三個假說：恐龍以及爬行動物中的槽齒類、鱷魚。
而這三種生物，都生蛋。
應用和基礎設施的關係同樣如此，歷史已經給出答案。
在大平臺轉變的歷史中，首先出現一個突破性的應用程式，然後該應用程式啟發了構建基礎設施的階段，先進的基礎施設使得構建更先進的應用程式和基礎設施變得容易，更促使消費者廣泛採用這些應用程式。
例如，燈泡(應用程式)是在有電網(基礎設施)之前發明的。為了讓廣大消費者購買燈泡，就需要建設電網。1879年，首先出現了燈泡這個突破性應用，然後1882年才開始建設電網。
另一個例子：飛機是在有機場之前發明的。為了讓消費者廣泛使用飛機，就需要建造機場。作為突破應用程式的飛機在1903年首先出現，並啟發了人們在1919年成立航空公司，1928年建造機場，1930年實施空中交通管制。
有時你需要的所有基礎設施
只是海灘和一些零部件而已
網際網路也遵循相同的模式。
第一個應用Messaging(1970年)以及後來的Email(1972年)，引爆了基礎設施建設，比如乙太網(1973年)、TCP / IP(1973年)和網際網路服務提供者ISPS(1974年)，使消費者能更廣泛地採用這兩種應用。
下一代突破性程式是入口網站(如1990年的Prodigy、1991年的AOL)，它們催熟了搜尋引擎和網路瀏覽器。
中生代的突破性程式是像1994年出現的Amazon這樣的早期網站，為它構建的基礎設施是程式語言(1994年的PHP，1995年的Javascript和Java)，它們使構建網站變得更加容易。
新世代的突破性應用程式如Napster(1999年)，Pandora(2000年)，Gmail(2004年)和Facebook(2004年)，這些應用程式使基礎設施跨越式進化，能更輕鬆地構建複雜的應用程式，如2004年的NGINX、Ruby on Rails，2006年的AWS，迴圈往復。
我們也看到了這種模式與我們最新的移動應用程式的迭代和發展：它們就是嚴重依賴視訊的流行移動Apps：Snapchat(2011年)和Instagram(2016年)等。
現在，我們看到公司們正構建基礎設施，使移動應用程式可以輕鬆新增視訊：Ziggeo(2014年)，Agora.io(2014年)，Mux(2017年)，Twilio Video API(2017年)，Cloudflare Stream(2018年)。
此迴圈還正確解釋了區塊鏈中的事件序列。
基於比特幣網路，BTC(2008年)是區塊鏈中第一個爆炸性應用，臭名昭著的早期加密貨幣交易網站Silk Road(2011年)緊隨其後。
這又激發了新一輪基礎設施建造，如Sidechains和Drivechain(2015年)，以太坊智慧合約和ERC-20(2015年)，Lightning Network(2015年)，可以在分散式網路上輕鬆構建新的應用程式。Coinbase(2012年)和Metamask(2016年)等基礎設施能夠解決支付問題從而使消費者採用這些新應用程式。
該輪基礎設施隨後推出了下一波應用程式：Tokens/ ICO(2017年)和早期的DApps(2016年的Rouleth和vDice，2017年的CryptoKitties)，它激發了新的基礎設施建設：Infura(2016年)、Web3js(2017年)和Zeppelin(2017年)。
事實上，分散式網路真正模糊了應用程式與基礎設施之間的界限，因為它們具有開放性和可互操作性。這也是我們愛上區塊鏈的原因之一。
如果有人利用某個DApp打造了新的應用，比如CryptoKitties或任何智慧合約，那這個“超級DApp”就變成了新基礎設施。就像在支付寶上面打造了基金投資介面，支付寶反而成為生態設施。
在過去，大平臺(如Amazon或Facebook)必須有意識地決定開放API併成為一個平臺，而加密應用程式從最開始就是開放和可互操作的。這使“Apps => Infrastructure => Apps = >基礎設施”的週期更緊湊。我們現在正在等待下一波能指導基礎設施建設的大型應用程式。
相鄰可能
每個大平臺(電力、汽車、飛機、網路、移動裝置等)發展的共同主題是用此刻可使用的工具儘可能多地進行創造。
在《偉大創意的誕生》裡，史蒂文·約翰遜 (Steven Johnson)將其稱為“相鄰可能”。
換句話說，你可以開啟相鄰房間的門，但你不能隔著臺階從前廊打開後門。很難成功地構建遠遠領先於應用市場的基礎設施。
每次“Apps =>基礎設施”週期重複時，本質上是之前迴圈中構建的基礎設施使新應用程式成為可能。
例如，YouTube只能在2005年建立，在1995年出現就毫無意義。因為2000年高速寬頻普及之後視訊觀看、分享才能實現，頻寬的不斷升級又催生了eBay、Amazon、Ask Jeeves、Neopets等更復雜的應用。
Chris Dixon
Chris Dixon和Fred Wilson在最近一集a16z播客中談到了這些概念。Chris Dixon曾嘲笑90年代後期那些天馬行空但很不實際的網路遊戲。
但後來Chris Dixon的觀點改變了，因為網路草根時代所有“愚蠢”的想法現在都是十億美元的獨角獸。它們經歷了無數輪“App =>基礎設施”的週期，才成為能夠實現的應用。僅僅是一兩輪週期往復是沒有太大現實意義的。
這正是我們所說的“基礎設施理論”的核心問題：我們構想了一個“基礎設施階段”，它與使用它的Apps在技術層面上相差太遠，我們冒著在臆想的空間中“超前建造”的風險。
我們急不得，必須依照“Apps => 基礎設施 => Apps =>基礎設施”的步驟不厭其煩地重複，確保自身行為不違背商業規律。
“App =>基礎設施”的週期也提出了這樣一個尚待討論的問題：區塊鏈時代，由於每個新平臺中的週期越來越緊湊，因此構建和使用這些Apps的成本比在傳統網際網路中更低。
比如，我們在1995年建立usv .com的成本要比現在構建它的成本高出許多。同樣，現在建立區塊鏈應用程式的資金、工作量和時間成本會比數年後多得多。
這最重要的價值在於說明：何時可以建立何種應用程式或基礎設施的基礎框架。
但困擾投資者的是：“Apps => 基礎設施 => Apps =>基礎設施”的週期說明了何時可以構建應用程式或基礎設施，但無法說明何時投資應用程式與何時投資基礎設施。
以燈泡為例，雖然它是在電網之前發明的，但從投資者的角度來看，沒有人能在電網到位之前賣掉很多燈泡。
總結
有一個問題是：為什麼是Apps出現在迴圈開頭，而不是基礎設施?
一個原因是，在有應用程式要求解決基礎設施問題之前，建立基礎設施是沒有意義的。直到有了要求解決問題的應用程式，才有可能知道要構建何種基礎設施。
現在，構建區塊鏈行業的加密基礎設施將是一個挑戰。我們特別需要一個突破性加密應用程式作為基礎，並圍繞它構建基礎設施和工具。