文 | DappReview
導讀：不知怎的，馬克思理論在區塊鏈世界重新煥發了生機。徘徊在歐洲的馬老師的幽靈，似乎恰巧賦予了某些特殊商業行為歷史合法性。其中最具代表性的是：“基礎設施決定上層建築”，所以我們應該先做公鏈（基礎設施），以支援應用（上層建築）。這個想法最終決定了資本、研發力量投放的優先順序。可荒謬的是，“基礎設施”甚至不是馬老師的原話。到底應該先做應用，還是先做公鏈？在本文中，Union Square Ventures給出了他們的觀點和認知。
本文取材於Union Square Ventures在10月1日的一篇博文（作者：Dani Grant，Nick Grossman），由DappReview翻譯並重新編輯，USV是美國知名風投機構，曾參與Twitter，Tumblr，Kickstarter，stackoverflow，CodeAcademy等專案的早期投資，在加密貨幣和區塊鏈領域於2011年開始佈局，參與投資的專案包括Coinbase，Polychain Capital，Algorand，CryptoKitties等。
一個普遍的認知是：區塊鏈行業正處於基礎設施階段，開展工作的正確姿勢是構建基礎設施——更好的基礎鏈，更好的鏈間互動性，更好的客戶端、錢包和瀏覽器。
他們說，「欲成其事必先利其器」，區塊鏈首要需要強大的工具，它能讓我們輕鬆地構建和執行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年的亞馬遜這樣的早期網站，為它構建的基礎設施是程式語言（1994年的PHP，1995年的Javascript和Java），它們使構建網站變得更加容易。
新世代的突破性應用程式如Napster（1999），Pandora（2000），Gmail（2004）和Facebook（2004），這些應用程式使基礎設施跨越式進化，能更輕鬆地構建複雜的應用程式，如2004年的NGINX和Ruby on Rails，2004年的AWS，迴圈往復。
我們也看到了這種模式與我們最新的移動應用程式的迭代和發展：它們就是嚴重依賴影片的流行移動apps：Snapchat（2011）和Instagram（2016）等。
現在，我們看到公司們正構建基礎設施，使移動應用程式可以輕鬆新增影片：Ziggeo（2014），Agora.io（2014），Mux（2017），Twilio Video API（2017），Cloudflare Stream（2018）。
此迴圈還正確地解釋了區塊鏈中的事件序列。
基於BTC/" target="_blank"">比特幣網路，BTC（2008）是區塊鏈中第一個爆炸性應用，臭名昭著的早期加密貨幣交易網站Silk Road（2011）緊隨其後。
這又激發了新一輪基礎設施建造，如Sidechains和Drivechain（2015），以太坊智慧合約和ERC20（2015），Lightning（2015），可以在分散式網路上輕鬆構建新的應用程式。Coinbase（2012）和Metamask（2016）等基礎設施能夠解決支付問題從而使消費者採用這些新應用程式。
該輪基礎設施隨後推出了下一波應用程式：Tokens/ ICO（2017）和早期的dapps（2016年的Rouleth和vDice，2017年的CryptoKitties），它激發了新的基礎設施建設：Infura（2016）和Web3js和Zeppelin（2017）。
事實上，分散式網路真正模糊了應用程式與基礎設施之間的界限，因為它們具有開放性和可互操作性。這也是我們愛上區塊鏈的原因之一。
如果有人利用某個Dapp打造了新的應用，比如CryptoKitties或任何智慧合約，那這個“超級Dapp”就變成了新基礎設施。就像在支付寶上面打造了基金投資介面，支付寶反而成為了生態設施。
在過去，大平臺（如亞馬遜或Facebook）必須有意識地決定開啟API併成為一個平臺，而加密應用程式從最開始就是開放和可互操作的。這使apps => infrastructure => apps = >基礎設施週期更緊湊。我們現在正在等待下一波能指導基礎設施建設的大型應用程式。
相鄰可能
每個大平臺（電力，汽車，飛機，網路，移動裝置等）發展的共同主題是用此刻可使用的工具儘可能的進行創造。
在《偉大創意的誕生》，史蒂文約翰遜將其稱為相鄰可能。
換句話說，你可以開啟相鄰房間的門，但你不能隔著臺階從前廊開啟後門。很難成功地構建遠遠領先於應用市場的基礎設施。
每次「apps =>基礎設施」週期重複時，本質上是之前迴圈中構建的基礎設施使新應用程式成為可能。
例如YouTube只能在2005年建立，但在1995年出現就毫無意義。因為2000年高速寬頻普及之後影片觀看、分享才能實現，頻寬的不斷升級又催生了eBay，亞馬遜，AskJeeves，Neopets等更復雜的應用。
Chris Dixon
Chris Dixon和Fred Wilson在最近一集a16z播客中談到了這些概念。Chris 有一個名為Dot Bomb的網路遊戲，它嘲笑了90年代後期的那些天馬行空但很不實際的網路遊戲。
但Chris的觀點改變了，因為網路草根時代所有「愚蠢」的想法現在都是十億美元的獨角獸。它們經歷了無數輪「app =>基礎設施週期」才成為能夠實現的應用。僅僅是一兩輪週期往復是沒有太大現實意義的。
這正是我們所說的「基礎設施理論」的核心問題：我們構想了一個「基礎設施階段」，它與使用它的apps在技術層面上相差太遠，我們冒著在臆想的空間中「超前建造」的風險。
我們急不得，必須依照「apps => 基礎設施 => apps =>基礎設施」的步驟不厭其煩的重複，確保自身行為不違背商業規律。
「app =>基礎設施週期」也提出了這樣一個尚待討論的問題：
區塊鏈時代，由於每個新平臺中的週期越來越緊湊，因此構建和使用這些apps的成本比傳統網際網路中更低。
可是，我們在1995年建立usv .com的成本要比現在構建它的成本高出許多。同樣的，現在建立區塊鏈應用程式的資金、工作量和時間成本會比數年後多得多。
這對投資者而言，很煩。
先摘掉投資者的帽子，本文最重要的價值在於說明：何時、可以建立什麼的技術框架。
「apps => 基礎設施 => apps =>基礎設施」週期說明了何時可以構建應用程式或基礎設施，但無法說明何時投資應用程式與何時投資基礎設施。
以燈泡為例，雖然它是在電網之前發明的，但從投資者的角度來看，沒有人能在電網到位之前賣掉很多燈泡。
總結
有一個問題是：為什麼apps出現在迴圈開頭，而不是基礎設施首先出現？
一個原因是，在有應用程式要求解決基礎設施問題之前，建立基礎設施沒有意義。直到有要求解決問題的的應用程式們，才可能知道正在構建的基礎設施解決了一個真正的問題。
現在構建加密基礎設施將是一個挑戰，特別需要一個突破性加密應用程式，圍繞它構建基礎設施和工具。
加密世界中有一個認知：首先我們需要構建強大的工具，一旦我們擁有了工具，我們就可以構建應用程式。
但我們希望展示的是，在其他平臺轉變中，我們能夠在有強大工具之前構建前幾個應用程式（儘管它會需要更多的資金和時間），然後這些早期應用程式激勵我們構建工具，迴圈往復。
